[GPL]Hoe te controleren?

[RooT]

Ik post dit even hier, omdat ik denk dat hier de meeste kenners van de GPL licentie zitten.

Het volgende ben ik niet van plan te doen, maar is gewoon uit pure interesse.

Hoe zit het nu met de GPL, als iemand dit omzet in closed-source? Hoe is dit te controleren? Men kan het natuurlijk zien aan het uiterlijk van een programma, maar stel het gaat om een driver? Hier is niet aan te zien of dit van iemand gekopieerd is (mss als je low-level gaat debuggen, maar dan nog is hier geen keihard bewijs van te vinden). Hoe kan een GPL licentie dit voorkomen?

[smokalot]

Ook een binary kun je inspecteren, je kunt kijken naar variabele-namen en functienamen bijvoorbeeld.

Als je alleen maar het strings-commando draait kun je al heel veel zien:

quote: strings /bin/ls

$ strings /bin/ls
LS_COLWIDTHS
%llu : %qu : %lu : %i : %i : %i : %qu : %lu : %lu
%s: %s
fflagstostr
%llu
fts_open
%s: directory causes a cycle
bin/ls
fts_read
COLUMNS
CLICOLOR
1@ABCFGHLOPRSTWabcdefghiklmnopqrstuvwx
CLICOLOR_FORCE
TERM
LSCOLORS
exfxcxdxbxegedabagacad
file_inherit
directory_inherit
[....]

[RooT]

En als je bijvoorbeeld een driver in de kernel compileerd wat je zelf gemaakt hebt, valt deze dan automatisch onder de GPL omdat de kernel dat is? En als module? Want in principe verander je aan de bestaande kernel source niks, je voegt alleen een extra component erbij. Dus ja in de hele kernel verander je dan wel wat, maar niet in de "kern" kernel

[riddles]

Voor dat laatste zijn er hele lange discussies geweest m.b.t. de closed source video drivers zoals die bijvoorbeeld door Nvidia en ATI worden gedistribueerd. Ten eerste, de GPL gaat alleen over het distribueren van code. Zo lang je voor jezelf aanpassingen maakt en die alleen zelf gebruikt, ben je nergens toe verplicht. Ten tweede, als je een patch op de kernel toepast (bijv. een extra driver toevoegt) en de kernel daarna verder distribueert, ben je inderdaad verplicht om de source beschikbaar te maken. Het probleem met de kernel is dat het mogelijk is om modules buiten de kernel te compileren en dan te laden. De meeste kernel ontwikkelaars zijn van mening dat ook deze modules onder de GPL zouden vallen, maar niemand kan het hard genoeg en de meningen zijn verdeeld. Voorlopig ligt er niemand dwars bij dit soort binary modules (zoals die van Nvidia en ATI).

[Osiris]

smokalot schreef op woensdag 11 maart 2009 @ 13:14:
Ook een binary kun je inspecteren, je kunt kijken naar variabele-namen en functienamen bijvoorbeeld.

Die crap komt toch helemaal niet in de binary tenzij je debugging keihard aan hebt staan?

[lordgandalf]

Een gpl project kan nooit omgezet worden naar een closed-source zover ik weet. Een goed voorbeeld hiervan is het gebeuren omtrent linksys. Deze gebruikte open-source aka. GPLed code in hun closed-source product.
Deze code hebben ze moeten releasen - de aanpassingen van hun kant.

[Cobalt]

lordgandalf schreef op woensdag 11 maart 2009 @ 13:36:
Een gpl project kan nooit omgezet worden naar een closed-source zover ik weet. Een goed voorbeeld hiervan is het gebeuren omtrent linksys. Deze gebruikte open-source aka. GPLed code in hun closed-source product.
Deze code hebben ze moeten releasen - de aanpassingen van hun kant.

Maar hoe bewijs je dat jou (open source) code (onder GLP licentie) gebruikt is in hun (closed source) code?

[RooT]

lordgandalf schreef op woensdag 11 maart 2009 @ 13:36:
Een gpl project kan nooit omgezet worden naar een closed-source zover ik weet. Een goed voorbeeld hiervan is het gebeuren omtrent linksys. Deze gebruikte open-source aka. GPLed code in hun closed-source product.
Deze code hebben ze moeten releasen - de aanpassingen van hun kant.

Tussen theoretisch/juridisch niet kunnen en praktisch niet kunnen zit nogal een verschil. Zie de post van Cobalt hierboven.

[lordgandalf]

Een stuk code levert een constant eindproduct op als het goed is. Iedere keer als je een stuk code compiled zou er volgens mij het zelfde stuk binaire code uit moeten komen.
En die code kun je als het goed is vergelijken met hun eindproduct toch ??

[RooT]

Ja oke, maar wat als ik aanpassingen maak in dat stukje code? Volgens de GPL moet ik deze aanpassing dan ook opensource maken blabla etc. Maar als ik die aanpassing dan closed source maak, is de binary dus ook anders dan het origineel.

[Kees]

RooT schreef op woensdag 11 maart 2009 @ 14:26:
Ja oke, maar wat als ik aanpassingen maak in dat stukje code? Volgens de GPL moet ik deze aanpassing dan ook opensource maken blabla etc. Maar als ik die aanpassing dan closed source maak, is de binary dus ook anders dan het origineel.

En daar heb je meteen het probleem te pakken. Echter, de meeste open-source pakketten zijn zo groot dat het niet te doen is om alles aan te passen, verder zijn de meeste open-source programma's redelijk uniek in hun functie, en als jij als open-source ontwikkelaar een closed-source product ziet dat (vrijwel) exact hetzelfde doet, dan is het vaak niet al te moeilijk om te zien of ze inderdaad jouw source hebben gebruikt.

Dat kun je vaak aan het gedrag van een programma zien, de naamgeving in een control panel/config file, en als je bij de binaries kan komen is het vaak nog makkelijker, want niemand gaat van een groot project alles aanpassen, en dus zul je dezelfde namen tegen komen voor libraries, md5sums die gelijk zijn van onderdelen, overeenkomende output-gegeven-een-bepaalde-input e.d.

Om het 'echt' goed te rippen zul je echt bijna alles moeten aanpassen, zelfs lullige dingen als de output van een --version commando of bijgeleverde documentatie (die je dan echt alleen maar aanpast omdat je het wil verbergen dat je open-source in je closed-source gebruikt).

[RooT]

Nee ok, bij van die grote projecten, vooral met GUI is dat vaak moeilijk. Maar bij wat kleinere tools, of iets wat geen GUI heeft, dan is het dus wel mogelijk.

[maleadt]

^^ wat Kees zegt. Als voorbeeld van zo'n groot project heb je ffmpeg, die ene Hall of Shame onderhoudt. Als je de issues nauwer bekijkt zie je dat het meestal over inspectie van een binary gaat, die dan bestandsnamen e.d. oplevert die naar ffmpeg terug wijzen.

Interessant zijn ook de "--enable-gpl" en "--enable-nonfree" opties die bijvoorbeeld MPlayer heeft.

[ Voor 14% gewijzigd door maleadt op 11-03-2009 16:16 ]

[riddles]

Ook bij kleine projecten is het niet heel eenvoudig. Kijk maar eens naar de output van strings op simpele binaries, bijvoorbeeld "strings /bin/ls". Je vind een enorme hoeveelheid identificerende strings terug. Die zul je in de code aan moeten passen (of in ieder geval voor een aanzienlijk deel) om te voorkomen dat je nieuwe binary nog herkenbaar is. Daarnaast, als de functionaliteit gelijk is aan een open source programma, is dat al vaak een hint. Dan kun je ook nog eens dezelfde bugs terug zien komen (ook dat is wel eens gebeurd). Je zult aan een open source programma echt heel veel aanpassingen moeten maken om het onherkenbaar te maken voordat je het echt opnieuw kunt distribueren. Volgens mij is dan opnieuw beginnen bijna eenvoudiger.

[Rukapul]

Buiten directe string matching is het ook niet bar moeilijk om software als het ware te fingerprinten. Dat kan varieren van het detecteren van bepaalde technieken tot het extraheren van de structuur / dependencies en dat vergelijken met de eigen software.

Na zo'n eerste filtering is het vrijwel triviaal om handmatig infringement verder te bewijzen. Een compiler heeft namelijk best wel deterministisch en het automatisch herschrijven van sourcecode komt met nogal haken en ogen.

Voorbeeldje: A Static Birthmark of Binary Executables Based on API Call Structure

[ Voor 45% gewijzigd door Rukapul op 11-03-2009 21:19 ]

[deadinspace]

riddles schreef op woensdag 11 maart 2009 @ 13:32:
Voor dat laatste zijn er hele lange discussies geweest m.b.t. de closed source video drivers zoals die bijvoorbeeld door Nvidia en ATI worden gedistribueerd.

Hier staat een mail-thread over dat onderwerp, met onder andere wat redelijk duidelijke statements van Linus Torvalds. Wel een beetje oud, maar nog steeds wel aardig leesvoer.

Rukapul schreef op woensdag 11 maart 2009 @ 21:10:
Buiten directe string matching is het ook niet bar moeilijk om software als het ware te fingerprinten. Dat kan varieren van het detecteren van bepaalde technieken tot het extraheren van de structuur / dependencies en dat vergelijken met de eigen software.

Na zo'n eerste filtering is het vrijwel triviaal om handmatig infringement verder te bewijzen. Een compiler heeft namelijk best wel deterministisch en het automatisch herschrijven van sourcecode komt met nogal haken en ogen.

Hier iemand die een binary van een vermeende GPL-schending gedisassembled heeft. Met wat moeite kun je daar best het een en ander uit afleiden.

[smokalot]

Osiris schreef op woensdag 11 maart 2009 @ 13:35:
[...]

Die crap komt toch helemaal niet in de binary tenzij je debugging keihard aan hebt staan?

ligt aan de taal, bij java bijvoorbeeld is er nog heel veel terug te vinden van je code in de bytecode, bij C of C++ inderdaad een stuk minder.

[wzzrd]

Osiris schreef op woensdag 11 maart 2009 @ 13:35:
[...]
Die crap komt toch helemaal niet in de binary tenzij je debugging keihard aan hebt staan?

Ook zonder debuginfo komt er heel veel herkenbare informatie in je binary image te staan. Debuginfo zorgt er idd wel voor dat namen van variabelen herkenbaar worden en zo, maar haal maar eens strings over een willekeurige binary. Komt er nog best veel uit.

lordgandalf schreef op woensdag 11 maart 2009 @ 14:16:
Een stuk code levert een constant eindproduct op als het goed is. Iedere keer als je een stuk code compiled zou er volgens mij het zelfde stuk binaire code uit moeten komen.
En die code kun je als het goed is vergelijken met hun eindproduct toch ??

Nee. Als je dezelfde code compileert met dezelfde compiler en dezelfde compiler flags tegen dezelfde libs zou er dezelfde binary uit moeten komen. Da's best een verschil ;-)

[jj71]

RooT schreef op woensdag 11 maart 2009 @ 13:25:
En als je bijvoorbeeld een driver in de kernel compileerd wat je zelf gemaakt hebt, valt deze dan automatisch onder de GPL omdat de kernel dat is? En als module? Want in principe verander je aan de bestaande kernel source niks, je voegt alleen een extra component erbij. Dus ja in de hele kernel verander je dan wel wat, maar niet in de "kern" kernel

Nee. Er zijn toch ook proprietary drivers, zoals de graphics drivers van NVIDIA, die niet open source (en niet GPL) zijn?