[GPL] Aanroep van een GPL cmdline tool

[BoomSmurf]

Welke rechten/plichten heb je als je een GPL'd command line tool wil gebruiken in een (gratis, maar niet OSS, en als het dat wel zo worden al zeker niet GPL) ander programma? Gebruik is puur dat tooltje aanroepen met wat parameters en de output parsen. Moet mijn eigen programma dan ook GPL zijn? Verder, als ik dat tooltje mee wil distribueren moet ik ook de source er van beschikbaar maken, toch?

Hopelijk weet iemand het antwoord want ik kom er niet echt uit aan de hand van de tekst Is overigens GPLv2.

[MTWZZ]

Volgens mij (IANAL) is het commercieel gebruik van GPL'ed software gewoon toegestaan totdat je de broncode (of delen ervan) van een GPL'ed programma gaat gebruiken in je eigen commerciele applicatie.

[Sendy]

Je hebt natuurlijk de GNU GPL FAQ gelezen? Daarin staat namelijk bijna precies het antwoord op jouw vraag.

Volgens de FSF is het antwoord dus nee, en misschien "ligt eraan".

edit:

Soultaker, jouw antwoord spits zich toe op het omgekeerde verhaal: een programma onder GNU GPL dat een proprietair programma aanroept.

[ Voor 20% gewijzigd door Sendy op 02-10-2006 15:35 ]

[Soultaker]

BoomSmurf schreef op maandag 02 oktober 2006 @ 14:51:Welke rechten/plichten heb je als je een GPL'd command line tool wil gebruiken in een (gratis, maar niet OSS, en als het dat wel zo worden al zeker niet GPL) ander programma? Gebruik is puur dat tooltje aanroepen met wat parameters en de output parsen. Moet mijn eigen programma dan ook GPL zijn?

Nee; je gebruikt het GPL'ed programma immers alleen om data mee te verwerken. Zie ook de GPL FAQ:

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in.
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

Dat is hier van toepassing (en verschilt wezenlijk van het gebruik van libraries/DLLs).

Verder, als ik dat tooltje mee wil distribueren moet ik ook de source er van beschikbaar maken, toch?

Ja, als je een binary versie van een GPL programma distribueert moet je in het algemeen ook de broncode beschikbaar maken. Dat betekent ook dat je het op verzoek per post moet leveren. In de praktijk zal zo'n verzoek natuurlijk zelden voorkomen als de broncode elders beschikbaar is.

@Sendy: volgens mij is jouw interpretatie verkeerd. De GPL maakt onderscheid tussen het gebruik van een programma (waar geen restricties op plaatsvinden) en het linken van programma's zo dat ze één geheel vormen (waarbij alle onderdelen aan de GPL moeten voldoen). Als je een programma gebruikt zonder ermee te linken, is de GPL niet van toepassing op jouw programma. Zie ook de FAQ:

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Dit stemt overeen met de tekst die ik hierboven al aanhaalde, en maakt het vrij duidelijk dat in het scenario wat Boomsmurf omschrijft er twee aparte programma's zijn, één GPL'ed programma en één ander programma wat helemaal niets met de GPL te maken heeft.

Gegevens die een GPL programma uitvoert zijn met nadruk niet beschermd (denk aan dingen als executables van GCC, of plaatjes gemaakt met GIMP of GraphViz); die mag je vrij gebruiken zoals je maar wil, dus ook in een proprietary applicatie.

Sendy schreef op maandag 02 oktober 2006 @ 15:28:
Soultaker, jouw antwoord spits zich toe op het omgekeerde verhaal: een programma onder GNU GPL dat een proprietair programma aanroept.

Nee, het maakt niet uit wie wat aanroept. Het gaat om de vraag of de programma's op zichzelf staande programma's zijn, of niet: "[..] in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program."

Het hele concept van 'aanroepen' komt in de licentie niet voor.

[ Voor 52% gewijzigd door Soultaker op 02-10-2006 15:43 ]

[Sendy]

Misschien interpreteer ik het inderdaad wel verkeerd, ik ben dan ook geen advocaat

Uit het stuk FAQ door mij gelinkt, en door jou vakkundig weggelaten:

You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too.

A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.

Hieruit lijkt mij dat het niet per-definitie is toegestaan. Maar, zoals verder op staat (de quote van Soultaker), ligt het helemaal aan de koppeling tussen de twee programma's. Als je de gebruikte binary configureerbaar maakt en communiceert via pipes zal er geen probleem zijn.

[Soultaker]

Die twee alinea's zijn van toepassing op een systeem dat een GPL'ed applicatie inbouwt of uitbreid; het is dus nodig te weten wat er onder inbouwen wordt verstaan, en dat wordt juist daaronder uitgelegd. Dan blijkt dat het gebruik zoals Boomsmurf voorstaat niet als 'incorporating' opgevat hoeft te worden, en de restricties uit die eerste twee alinea's dus helemaal niet van toepassing zijn.

[Hertog]

Soultaker schreef op maandag 02 oktober 2006 @ 16:27:
Die twee alinea's zijn van toepassing op een systeem dat een GPL'ed applicatie inbouwt of uitbreid; het is dus nodig te weten wat er onder inbouwen wordt verstaan, en dat wordt juist daaronder uitgelegd. Dan blijkt dat het gebruik zoals Boomsmurf voorstaat niet als 'incorporating' opgevat hoeft te worden, en de restricties uit die eerste twee alinea's dus helemaal niet van toepassing zijn.

Dat kun je overigens ook zelf beredeneren aan de hand van de laatste zin van die eerste alinea:

it would have the effect of making the GPL-covered software non-free too.

En dat is niet zo als je de tool aanroept, de tool is niet 'ingebakken' in het programma en nog steeds vrij te verspreiden.

Zie ook het bij de tweaker vast wel bekende koppeltje EAC + Lame: Lame is, dacht ik, GPL, maar de source van EAC is niet te krijgen. Toch kan EAC met Lame werken, er zitten zelfs specifieke Lame-opties in EAC. Geen probleem

[Soultaker]

Die situatie is nog wel iets anders. Als ik me goed herinner (maar ik heb al tijden geen cd's meer geript onder Windows) kan EAC zowel de codec API van Windows gebruiken, als een extern programma aanroepen. In beide gevallen wordt LAME (anders dan wat Boomsmurf wil) niet meegeleverd met EAC, maar moet je het zelf installeren.

Verder is LAME niet gelicenseerd onder de GPL, maar de LGPL. Daarom kun je LAME ook als audio codec onder Windows installeren, waarbij de DLL automatisch in andere processen geladen wordt, wat met GPL-applicaties in het algemeen niet mag.

[ Voor 21% gewijzigd door Soultaker op 02-10-2006 16:53 ]

[MSalters]

Toegestaan, mits je uiteraard de source code van de GPL tool meelevert. De reden is simpel te achterhalen als je de filosofie van de GPL begrijpt. De user moet GPL delen kunnen aanpassen, nieuwe sourcecode toevoegen etctera. Daar belemmer je hem niet in, doordat je puur de publieke interfaces gebruik. Elke wijziging die de publieke interface ongemoeid laat is dus door de gebruiker te realiseren, en je ontneemt hem geen vrijheden die hij anders wel zou hebben.

De LGPL wordt relevant op het moment dat je derived works wil maken, maar dat is hier niet het geval.

[BoomSmurf]

Ok dan... thanks voor de antwoorden. Of ik er nu wijzer van ben is iets anders

Andere vraag. Omdat het wellicht voor mijzelf handiger is om niet een externe tool te gebruiken maar interne code ben ik verder gaan zoeken en na wat speurwerk heb ik iets gevonden wat een deel (het moeilijke deel) van de functionaliteit bied, deze code is onder LGPL.

Zoals ik het nu begrijp werkt het ook bij de LGPL zo dat je aanpassingen e.d. moet publiceren en anders de originele code beschikbaar maakt. Het pluspunt is hier wel dat ik zonder problemen met die library kan linken. In dit geval brouw ik het echter liever in mijn eigen code. Omdat de source in C++ is en ik zelf het liefst in Delphi werk moet ik hem dus wel eerst vertalen. Ben ik overigens al aan begonnen, toch niks beters te doen tot dit deel af is. Nu blijkt echter dat ik ontzettend veel ook aan het veranderen ben in de vertaalslag. Dingen die ik niet nodig heb laat ik weg, andere constructies verander ik zodat ze me zelf beter uitkomen, etc.

De vraag is nu natuurlijk, geldt dit nu wel of niet als derivative work? Ik gebruik in feite geen van de originele code, nja, om af te kijken hoe het moet, dat wel, met als referentie de papers door de wiskundige die de hele zooi bedacht heeft. Maar als je dit ziet als derivative work, dan zou het toch ook onmogelijk zijn om een wiskundige paper te pakken en daar zomaar code voor te schrijven ivm copyrights etc?

Wat een lol, coden

[Gerco]

BoomSmurf schreef op dinsdag 03 oktober 2006 @ 01:32:
Ben ik overigens al aan begonnen, toch niks beters te doen tot dit deel af is. Nu blijkt echter dat ik ontzettend veel ook aan het veranderen ben in de vertaalslag. Dingen die ik niet nodig heb laat ik weg, andere constructies verander ik zodat ze me zelf beter uitkomen, etc.

De vraag is nu natuurlijk, geldt dit nu wel of niet als derivative work?

Ik denk van niet, aangezien je nu gewoon de library aan het herimplementeren bent. Niet op een clean-room manier, maar dat is ook niet nodig. Alleen een rechter of gespecialiseerd jurist kan hier echt een uitspraak over doen. Over het algemeen geld dat je copyright hebt op de code die jij schrijft. Als jij alle code nu aan het schrijven bent (met of zonder afkijken), heb jij het copyright en kun je er elke license opplakken die je wilt (patent issues uitgezonderd natuurlijk).

Dit kan echter slechts een produkt van mijn simplistische wereldvisie zijn, dus vaar hier niet blind op

Wat een lol, coden

Coden is geweldige lol, de problemen beginnen pas als je werk van anderen wilt gebruiken en je je eigen werk niet onder dezelfde voorwaarden wilt verspreiden (in het geval van GPL). Schrijf je alles zelf is er überhaupt geen probleem.