Commerciële software met GPL-gelicenseerde modules

[Amanoo]

Beste mensen. Naar mijn begrijpen is GPL een virale licentie: als je iets onder GPL in je software gebruikt, dan wordt ook jouw creatie GPL en moet je als je het niet enkel intern gebruikt de broncode onder GPL vrijgeven. Hoe zit dit precies met modules? Stel dat ik voor modules (voor bijvoorbeeld taal) maak die los van mijn applicatie te downloaden zijn, en deze zijn gebaseerd op GPL-gelicenseerd materiaal, wanneer zorgt dat ervoor dat mijn software onder de GPL valt? Wanneer mag ik de hoofdzakelijke applicatie closed source houden of onder een andere licentie die niet GPL-compatible is (al dan niet een andere open source) uitgeven?

Ik maak hier een Android app en overweeg ervoor te zorgen dat je in de market aparte taalmodules kan downloaden, maar ik weet nog niet zeker of ik het zo wil oplossen (hangt vooral af van de precieze technische mogelijkheden).

[djc]

IANAL: als je je werk serieus neemt moet je hier met een advocaat over praten.

Als jouw applicatie te gebruiken is zonder de modules die afhankelijk zijn van GPL-gelicenseerd materiaal lijkt dat me genoeg om ervoor te zorgen dat jouw applicatie geen zgn derivative work is van het GPL-werk, zodat je applicatie dus niet onder de GPL gedistribueerd moet worden.

[Ghostbird]

Kijk hier eens naar Wikipedia: GPL linking exception als je modules die uitzondering bevatten is het mogelijk wel toegestaan.

[H!GHGuY]

Gaat het over GPL of LGPL? Daar is namelijk ook nog een verschil in mbt linken.

@djc: daar valt ook nog over te discussieren...
Dynamisch code laden wil niet zeggen dat je zomaar GPL mag inladen.

Veel bedrijven gebruiken eerder het onderscheid op basis van de interface:
header files en linking (voor bvb C++) impliceert dat je kennis hebt van de interface/functies en datastructuren, wat een stap te ver is. Dit geldt ook voor dynamisch laden (denk aan dlopen()).
Late-binding is ook binding... Dat jouw code ook zonder die module kan werken wil absoluut niet zeggen dat die ene GPL module niet viral is.

Gebruik je daarentegen standaard IPC mechanismes (bvb parsing van de output van een command) dan heb je dit niet. Datastructuren uitwisselen over een pipe valt dan weer in een grijze zone...

Anderzijds is er soms ook voor interfaces een uitzondering te maken als de module een interface implementeert die standaard is en als er meerdere libraries (waarvan zeker ook niet-GPL) zijn die die interface implementeren. Denk aan een GPL java VM. Dit is echter een grijze zone (denk maar aan glibc) en je hebt er bij voorkeur toch de linking exception bij die hierboven genoemd wordt.

Maar volg djc zijn goede raad op en spreek erover met een advocaat - ook ik ben geen advocaat en kan jou geen bindend advies geven.
Als je die stap niet wil nemen, kun je ook de auteur van die library contacteren en vragen of je een commerciele license kan krijgen. Dan vermijd je het hele GPL gebeuren met een wijde boog.

[Zoijar]

Niemand weet het precies

Dit stukje vind je het meest:

Does the use of GPL'ed DLLs from the GnuWin project in your program need you to release your program under GPL too?

There seem to be two different strands of opinion. The FSF holds that dynamic linking creates a derivative work, and so any program designed to run with a GPL-ed DLL, must be GPL itself; see http://www.fsf.org/licenses/gpl-faq.html. The only exception they make is for DLL's that come with the compiler and the kernel, such as the MS VC run-time DLL's; see http://www.fsf.org/licens...html#WindowsRuntimeAndGPL. On the other hand some OpenSource lawyers hold that dynamically linking does not make your program GPL; see http://www.nusphere.com/products/library/gpl_0401openmag.pdf and the discussion in http://www.linuxjournal.com/article.php?sid=6366. There is no doubt that programs that link dynamically to DLL's from libraries with the LGPL or with the GPL with special provisions, are GPL free if you decide so.

offtopic:
Ik vind het maar niks die GPL... kies bij voorkeur LGPL

[ Voor 3% gewijzigd door Zoijar op 26-02-2013 20:29 ]

[MSalters]

Het onderliggende probleem hier is dat er geen fundamenteel verschil is. "Shell command wel, dynamisch gelinkt niet" lijkt aardig totdat je .Net Powershell ziet. Twee stukken software kunnen op een onbeperkt aantal manieren samenwerken, en we kunnen die methodes niet automatisch klassificeren.

De praktische oplossing is daarom dat elke gevestigde methode om te communiceren, niet specifiek aan 1 situatie wordt geaccepteerd, terwijl een customized oplossing dat niet wordt. Jouw modules lijken in eerste instantie te vallen onder de "customized oplossing". Een implementatie van `System.Windows.Controls.SpellCheck` in .Net zou dat niet zijn.