GPL: naar niet-GPL library linken?

[ATS]

Ik wil een programma maken dat gebruik maakt van de GPL versie van Qt. Ik moet (en wil) mijn programma dus ook onder GPL maken als ik het wil verpreiden (en dat wil ik). Tot nu toe geen probleem. Echter, nu wil ik in mijn programma ook een 3rd party lib gebruiken die welliswaar vrij te gebruiken is, maar die niet onder GPL is vrijgegeven. Is dat toegestaan? Ik kan er tot nu toe geen duidelijke uitspraak over vinden.

[kunnen]

Jazeker.

[roy-t]

Ik denk niet dat iemand hier snel een antwoord op wil geven die er ook echt wat over te zeggen heeft aangezien het nogal gevoelig is.

Dit illustreert wel het grote probleem dat GPL is, het verziekt het hergebruik van code zodra het maar gemengd wordt met andere code.

Ik denk dat als je de Qt-GPL lib niet aanpast en alleen linkt vanuit je programma en dat je de 3rd party lib ook niet aanpast en ook alleen linked, dat je dan hoogstens de code van het linkende gedeelte hoeft vrij te geven (de 3rd party lib staat dan haast los van je app en is niet relevant).

Maarja 100% legaal kan ik hier niets over zeggen. (Is dat een probleem voor je app? Wat voor app is het en hoe ga je het herdistributeren).

Zelf heb ik echt een bloedhekel aan de GPL en andere licenties die je verplichten code weer uit te geven / dezelfde license te gebruiken. Vrije code is pas echt vrij als je er mee mag doen wat je wilt! (Een korte license met 'deze code is echt van mij en je kan me nooit aanklagen voor schade' is alles wat je wilt!)

[Room42]

Volgens mij mag dat wel, alleen moet je natuurlijk wel de licentie van die 3rd party library naleven. Dus als dat betekent dat je die niet vrijelijk mag verspreiden, heb je een uitdaging.

[RobIII]

ThomasB schreef op maandag 10 november 2008 @ 00:32:
Jazeker.

Dat is een erg solide onderbouwing

Kijk hier eens; de auteur geeft duidelijk IANAL aan, maar linkt wel naar relevante delen uit de GPL FAQ. Dat zou je moeten helpen bij het uitpuzzelen van de exacte relevante delen voor de voor jou relevante situatie.

edit:

Tsssk, tussenposterts...

[ Voor 37% gewijzigd door RobIII op 10-11-2008 00:45 ]

[Gomez12]

Ja, mits de 3rd party licentie het toestaat.

Het enige wat je volgens mij in de gaten moet houden is dat jouw pakket dan onder meerdere licenties valt ( of geef alleen een link naar de 3rd party lib zodat mensen verantwoordelijk zijn ervoor ) en dat er nooit code van jouw project in die 3rd party library mag komen.

Zolang het een binary lib is waartegen je alleen zit te linken mag het. ( anders was er uberhaupt bijna geen GPL software voor windows )
Is het een source code van een lib dan wordt het al gevaarlijker omdat als jij iets copieert uit je eigen prog en dit paste in de lib dan moet de lib ook gelijk GPL worden en dan heb je de uitdaging dat jij niet de rechten heb om de licentie van de lib te veranderen...

[Verwijderd]

Nee, dat gaat niet gebeuren. Jouw programma linkt naar Qt, dus dat betekent dat jouw afgeleide werk ook GPL moet zijn (ook niet LGPL!). En een GPL-programma mag niet linken naar een GPL-incompatible library.

Bottom line: als het gecombineerde werk 1 programma is, dan geldt de GPL voor alles. Mag niet dus.

Dit is de grote reden dat Trolltech Qt onder de GPL heeft uitgebracht en niet onder de LGPL: ze willen geld vangen als je een proprëtair programma wilt maken.

Ik ben het gedeeltelijk eens met roy-t dat de GPL in het geval van libraries erg onhandig is. Maar dat was precies het doel van Trolltech.

Er is trouwens een mooi alternatief: Gtk. Die is LGPL, waardoor je dit probleem niet hebt.

Gomez12 schreef op maandag 10 november 2008 @ 00:51:
Zolang het een binary lib is waartegen je alleen zit te linken mag het. ( anders was er uberhaupt bijna geen GPL software voor windows )

Dat mag alleen als het verwaarloosbaar verbonden is met je eigen programma (bijvoorbeeld Netscape-compatible plugins voor Firefox). Dit is bijna nooit het geval. Als je praat over "een lib gebruiken" dan zeker niet.

Dat er veel GPL-software voor Windows is, komt omdat het wel toegestaan is om met propriëtaire libraries te linken als die libraries zogenaamde "System Libraries" zijn, die onderdeel zijn van het operating system, en die nodig zijn om het programma op dat OS te kunnen draaien.

Is het een source code van een lib dan wordt het al gevaarlijker omdat als jij iets copieert uit je eigen prog en dit paste in de lib dan moet de lib ook gelijk GPL worden en dan heb je de uitdaging dat jij niet de rechten heb om de licentie van de lib te veranderen...

Dat ligt helemaal aan de licentie van die 3rd party code. Als het toegestaan is om de code aan te passen, dan kan jij jouw code onder diezelfde licentie vrijgeven voor de gevallen waar je jouw code naar de library hebt verplaatst. Dit is het geval als de library bijvoorbeeld LGPL is. Bij LGPL heb je dan nog het voordeel dat jouw uiteindelijke programma legaal is. Als de library MS-PL was geweest, of een andere GPL-incompatible licentie, dan mag je jouw uiteindelijke programma niet distribueren, om redenen die ik hierboven heb aangegeven.

IANAL, dus als je het zeker wilt weten: mail de FSF. En als je het commercieel wilt exploiteren: laat het onderzoeken door een advocaat.

[ Voor 62% gewijzigd door Verwijderd op 10-11-2008 01:59 ]

[Gerco]

roy-t schreef op maandag 10 november 2008 @ 00:37:
Zelf heb ik echt een bloedhekel aan de GPL en andere licenties die je verplichten code weer uit te geven / dezelfde license te gebruiken. Vrije code is pas echt vrij als je er mee mag doen wat je wilt! (Een korte license met 'deze code is echt van mij en je kan me nooit aanklagen voor schade' is alles wat je wilt!)

Ik denk dat je de GPL verkeerd begrijpt en daar kan een hoop woede uit voorkomen.

De GPL draait niet om vrijheid voor de ontwikkelaar, maar om vrijheid voor de software en de garantie dat die software altijd vrij zal blijven. Om dat mogelijk te maken moet je als ontwikkelaar inderdaad wat vrijheden inleveren (aan de andere kant, door copyright wetgeving zou je überhaupt geen vrijheden hebben als de license je ze niet zou geven).

Wanneer je de GPL niet ziet als een soort ultieme vrije licentie, maar het ziet voor wat het is, vind ik er helemaal niets mis mee en is het voor veel projecten prima geschikt. Als je maximale vrijheid voor de ontwikkelaar wilt moet je een BSD-achtige license op je code zetten of de code in het geheel in het public domain releasen.

[Niemand_Anders]

QT heeft geen LGPL license, dus nee, je kunt het programma dus niet linken aan bijvoorbeeld een applicatie onder de BSD license. Wat je wel kunt doen is contact opnemen bij Trolltech en vragen om een uitzondering. Afhankelijk van de 3rd party toepassing, krijgt de 3rd party wel of geen toestemming. Dat zou wel betekenen dat de 3rd party applicatie dan niet meer zelf gelinkt mag worden.

Lees daarnaast ook eens rustig de reactie van DOT. Die bevat precies de kern waarom iets wel of niet mag.

[Ilmar]

Verwijderd schreef op maandag 10 november 2008 @ 01:33:
Nee, dat gaat niet gebeuren. Jouw programma linkt naar Qt, dus dat betekent dat jouw afgeleide werk ook GPL moet zijn (ook niet LGPL!). En een GPL-programma mag niet linken naar een GPL-incompatible library.

Ten eerste hebben de nieuwste versies van Qt een lijst met uitzonderings licenties die je ook mag gebruiken voor je programma ( http://doc.trolltech.com/4.4/license-gpl-exceptions.html ). Ten tweede klopt het inderdaad dat je een GPL programma niet mag linken met een GPL-incompatible library. Dat betekent dat je library dus net zo vrij of vrijer te verspreiden moet zijn als je GPL programma. Kortweg betekend dat dat Public Domain/BSD/MIT/Zlib etc. licenses mogen, LGPL mag ook en GPL natuurlijk ook, alle andere dingen moet je case-by-case beoordelen. (zie ook http://www.gnu.org/philosophy/license-list.html voor een lijst met compatible licenses)

[ Voor 3% gewijzigd door Ilmar op 10-11-2008 10:03 . Reden: Bron voor GPL exceptions opgezocht ]

[roy-t]

Gerco schreef op maandag 10 november 2008 @ 07:15:
[...]

Ik denk dat je de GPL verkeerd begrijpt en daar kan een hoop woede uit voorkomen.

De GPL draait niet om vrijheid voor de ontwikkelaar, maar om vrijheid voor de software en de garantie dat die software altijd vrij zal blijven. Om dat mogelijk te maken moet je als ontwikkelaar inderdaad wat vrijheden inleveren (aan de andere kant, door copyright wetgeving zou je überhaupt geen vrijheden hebben als de license je ze niet zou geven).

Wanneer je de GPL niet ziet als een soort ultieme vrije licentie, maar het ziet voor wat het is, vind ik er helemaal niets mis mee en is het voor veel projecten prima geschikt. Als je maximale vrijheid voor de ontwikkelaar wilt moet je een BSD-achtige license op je code zetten of de code in het geheel in het public domain releasen.

Hmm zo had ik het nog niet bekeken. Maar GPL is (vanuit de programmeurs) dus een erg onvrije license maar vanuit het programma zelf erg bevrijdend.

Hmm...

Ik heb liever licenties als dit:

quote: http://nickontech.com/IRF.txt

The "It's Really Free" License

You may use this software however you want. It's really free. None of that fake "free"
like the GPL or others. This is really free. Totally free. You want to sell it? Sure.
Put it in your code? Great. Say you wrote it? Fine by me. Give it to others? Cool beans.
Go wild with this software.

By using this software and accepting the license, you acknowledge that you are using the
software at your own risk and that nobody is responsible for any damages should the
software crash your computer, kill your dog, steal your girlfriend, or anything else.

hoewel het natuurlijk prima is als je een readme.txt moet meeleveren waarin staat welke code je gebruikt hebt met een naam en linkje ofzo.

GPL dwingt progressie af en zorgt er ook weer voor dat er niet te veel progressie komt. Professionals durven geen GPL te gebruiken op hun werk bijvoorbeeld (dat mag natuurlijk niet). Nu zie je veel pro's met een blog waarin ze van allerlei technologie die ze op hun werk gebruiken uitleggen hoe het werkt, compleet met tutorials code en verbeteringen (natuurlijk slecht kleine stukjes van hun echte werk, maar wel heel waardevol).

bij GPL code gebeurt dit niet omdat ze niet gebruikt worden, de die-hard gpl-ers daar gelaten natuurlijk. Ik heb liever wat pro's die code goed gebruikt hebben en er wat tutorials over schrijven op hun blog dan zo'n restricted license waardoor ik af en toe een programma zou kunnen bekijken dat iemand anders geschreven heb. (Het is vaak erg moeilijk om zo'n grote brok code te begrijpen en de relevante beetjes eruit te halen.)

[ Voor 22% gewijzigd door roy-t op 10-11-2008 10:07 ]

[leuk_he]

ATS schreef op zondag 09 november 2008 @ 21:42:
Echter, nu wil ik in mijn programma ook een 3rd party lib gebruiken die welliswaar vrij te gebruiken is, maar die niet onder GPL is vrijgegeven. Is dat toegestaan? Ik kan er tot nu toe geen duidelijke uitspraak over vinden.

Heb je een link naar de licentie van de library?

Ik weet niet hoe groot je project wordt, maar wellicht kun je ook redeneren: zal iemand bezwaar maken tegen dit gebruik van de library op deze manier? Als QT het goed vind (niet vragen daar, die vekropen alleen licenties...) en de 3th library en jij, wat let je dan?

[ Voor 26% gewijzigd door leuk_he op 10-11-2008 10:24 ]

[Gomez12]

@leuk_he, je beseft dat je nu gewoon mogelijk illegale acties promoot?

Als niemand bezwaar maakt != toegestaan.

Zoals je zelf al zegt verkoopt QT licenties, dus die zullen waarschijnlijk wel bezwaar maken als je ze op de hoogte stelt.

[ATS]

Dank voor de reacties tot nu toe, even wat meer details:

Het gaat om een wetenschappelijke applicatie, waarvan ik een deel wil versnellen met Cuda. De applicatie zal wel blijven werken zonder Cuda ondersteuning overigens.

Deze applicatie zal verspreid worden, maar niet commercieel. Ik sta achter het via GPL distribueren van deze software, omdat ik in de wetenschappelijke community waarvoor deze software interessant is ruimte zie voor meer samenwerking op het gebied van de tools die we gebruiken. Ook met betrekking tot peer-review mogelijkheden vind ik dat wetenschappelijke software open hoort te zijn. Ik zou zelf bovendien graag ook profiteren van fixes en uitbreidingen van anderen. GPL helpt daarbij (maar het is geen garantie: zolang ze het niet verspreiden hoeven gebruikers hun aanpassingen ook niet te delen). Ik wil dus geen propriëtair programma maken en ik probeer niet onder de voorwaarden van Trolltech/Nokia uit te komen voor een "free lunch".

Overstappen op een andere toolkit zoals GTK is geen optie. Ik ben erg bekend met Qt, vind het prettig werken en ik heb momenteel gewoon niet de tijd of de motivatie om een compleet nieuwe omgeving te leren waarvoor ik moet overstappen van zowel toolkit als taal (C++ naar C).

Misschien moet ik uitwijken naar een van de andere licenties die genoemd worden door Qt als exceptie op http://doc.trolltech.com/...cense-gpl-exceptions.html. Wellicht dat een van die licenties wel het gebruik van 3rd party closed source libraries toestaat. Ik ga namelijk wel grote hoeveelheden data uitwisselen tussen Cuda en de rest van het programma, daar heb je tenslotte Cuda voor.

Ik heb overigens contact proberen op te nemen met Trolltech/Nokia hierover (zowel per mail als via hun mailinglijst), maar tot nu toe niets van hen gehoord. Dit is de licentie van Cuda.

[H!GHGuY]

Eventueel kun je het Cuda gedeelte afsplitsen in een plugin en die apart verspreiden als library volgens de licentievoorwaarden van cuda. Je programma blijft werken zonder dus kan je dit deel zeker afsplitsen.

Ik weet echter niet of je hiermee onder GPL vandaan komt, maar het is zeker te bekijken.

[Gerco]

Wellicht moet je daarvoor de plugin interface (header files enzo) als LGPL verspreiden, die constructie zie je ook weleens namelijk.

[leuk_he]

Gomez12 schreef op maandag 10 november 2008 @ 11:04:
@leuk_he, je beseft dat je nu gewoon mogelijk illegale acties promoot?

Als niemand bezwaar maakt != toegestaan.

Zoals je zelf al zegt verkoopt QT licenties, dus die zullen waarschijnlijk wel bezwaar maken als je ze op de hoogte stelt.

Nee, dat zeg ik niet. Ik ben echter tegen mensen die maar roepen dat gpl zus en zo niet mag, maar vergeten dat de copyright houder daar over gaat.

QT staat geloof ik ook meer licenties toe, als het maar open source is.

http://system-linux.net/d...cense-gpl-exceptions.html

/edit
=========

Die CUDA licentie is dus overduidelijk closed source. Het programm dat gebruik maakt van CUDA zul je dus appart moeten distribueren, en je progamma moet ook zonder CUDAkunne werken.

Je moet met een QT acedemic license eens kijken of die voldoet?

========
Ik onderhoud een GPL applicatie die MFC libraries gebruikt. Duidelijk een grensgeval van

"However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work

[ Voor 35% gewijzigd door leuk_he op 10-11-2008 17:59 ]

[Rukapul]

H!GHGuY schreef op maandag 10 november 2008 @ 14:10:
Eventueel kun je het Cuda gedeelte afsplitsen in een plugin en die apart verspreiden als library volgens de licentievoorwaarden van cuda. Je programma blijft werken zonder dus kan je dit deel zeker afsplitsen.

Ik weet echter niet of je hiermee onder GPL vandaan komt, maar het is zeker te bekijken.

Over het algemeen worden kunstmatig gecreeerde interfaces (ongeacht of dit een plugin architectuur, netwerkmiddleware, etc. betreft) om onder licenties uit te komen beschouwd als zijnde niet in overeenstemming zijnde met de GPL. Gebruik making van generieke interfaces die worden aangeboden door het operating system in combinatie met bestaande interfaces van de software waarmee wordt geinteracteerd (pipes, file based, etc.) worden typisch als acceptabel beschouwd, evenals generieke plugin architecturen (zoals het Firefox/Mozilla/Netscape argument van hierboven).

DOT heeft de kern van de zaak al helder uitgelegd.

Gerco schreef op maandag 10 november 2008 @ 14:17:
Wellicht moet je daarvoor de plugin interface (header files enzo) als LGPL verspreiden, die constructie zie je ook weleens namelijk.

De LGPL kan nooit de oplossing zijn voor een GPL probleem.

[ Voor 12% gewijzigd door Rukapul op 10-11-2008 14:29 ]

[Gerco]

Rukapul schreef op maandag 10 november 2008 @ 14:24:
Gebruik making van generieke interfaces die worden aangeboden door het operating system in combinatie met bestaande interfaces van de software waarmee wordt geinteracteerd (pipes, file based, etc.) worden typisch als acceptabel beschouwd

Wat is er generiek aan applicatiespecifieke data over een pipe versturen? En waarom zou dat dan opeens niet de GPL schenden terwijl bijvoorbeeld een plugin als dll laden dat wel zou doen? Die plugin kan met geen enkele andere applicatie werken en die applicatie accepteert ook geen andere plugins.

[Rukapul]

Gerco schreef op maandag 10 november 2008 @ 14:37:
[...]

Wat is er generiek aan applicatiespecifieke data over een pipe versturen? En waarom zou dat dan opeens niet de GPL schenden terwijl bijvoorbeeld een plugin als dll laden dat wel zou doen? Die plugin kan met geen enkele andere applicatie werken en die applicatie accepteert ook geen andere plugins.

Voorbeeld: een GPL videoplayer ondersteunt out of the box bediening via een eenvoudig protocol over een pipe. Vervolgens kan een closed source applicatie deze player via het OS invoken (runnen) en besturen middels commando's over de pipe te sturen.

Dit wordt over het algemeen gezien als zijnde toegestaan binnen de GPL. Niet acceptabel wordt gezien wanneer men eerst zelf een interface aan de GPL software klust (bv. om commando's over een pipe te ontvangen).

Sowieso laat de GPL zich niet uit over data, maar alleen over (herbruik van) code.
Een plugin impliceert linking, juist een aspect waar de GPL de lat hoog legt. Een plugin-oplossing is typisch dus geen oplossing tenzij er reden is anders te vermoeden (typisch de gevallen waarbij het geen 1-op-1 relatie tussen plugin en host bestaat).

[Ilmar]

ATS schreef op maandag 10 november 2008 @ 11:51:
Misschien moet ik uitwijken naar een van de andere licenties die genoemd worden door Qt als exceptie op http://doc.trolltech.com/...cense-gpl-exceptions.html. Wellicht dat een van die licenties wel het gebruik van 3rd party closed source libraries toestaat. Ik ga namelijk wel grote hoeveelheden data uitwisselen tussen Cuda en de rest van het programma, daar heb je tenslotte Cuda voor.

Ik heb overigens contact proberen op te nemen met Trolltech/Nokia hierover (zowel per mail als via hun mailinglijst), maar tot nu toe niets van hen gehoord. Dit is de licentie van Cuda.

Volgens mij staan vrijwel alle licenties in die lijst wel linken met closed libraries toe, alleen maakt dat vaak ook gebruik in een closed programma mogelijk. Vzw zijn MIT en BSD licenties vrij gebruikelijk voor wetenschappelijke projecten uit het oogpunt van vrij beschikbare kennis.

[Verwijderd]

Dat zijn grijze gebieden. De bottom line blijft: is het 1 programma, dan mag het niet, zijn het aparte programma's die niets met elkaar te maken hebben, dan mag het wel.

Als jouw Qt GUI app data op stdout zet die je normaal gesproken in een file zou stoppen (een XML scene graph voor rendering ofzo), dan kan je je GPGPU-renderer aanspreken met stdin net zoals je 't zou doen met een gewone file.

Ik weet niet wat de GPGPU in dit programma moet doen, maar als het batch-werk is, dan zou je daar een simpel commandline tooltje voor kunnen schrijven die wordt uitgevoerd door je GUI. Dan nog zou ik de render-executable in de GUI configureerbaar maken, en de CUDA-renderer niet als default instellen (maar wel een SSE-renderer ofzo).

Maak je het zo, dat je de CLI CUDA-renderer ook los kan gebruiken, dan zijn het zeker weten losse programma's en is er niets aan de hand. Je kan 'm dan zelfs onder de GPL uitgeven, met exception voor CUDA.

Ilmar schreef op maandag 10 november 2008 @ 15:22:
[...]


Volgens mij staan vrijwel alle licenties in die lijst wel linken met closed libraries toe, alleen maakt dat vaak ook gebruik in een closed programma mogelijk. Vzw zijn MIT en BSD licenties vrij gebruikelijk voor wetenschappelijke projecten uit het oogpunt van vrij beschikbare kennis.

Hmm, ja, ze hebben hier wel een gigantisch gat in de GPL geslagen. Nouja, fijn voor de TS. De TS hoeft nu alleen de software te releasen onder de LGPL. (GPL mag niet, omdat je van Trolltech alleen plain GPL mag gebruiken, maar om CUDA te gebruiken moet je daarvoor een extra exception geven.)

[ Voor 27% gewijzigd door Verwijderd op 10-11-2008 15:37 ]

[Gerco]

Rukapul schreef op maandag 10 november 2008 @ 15:22:
Niet acceptabel wordt gezien wanneer men eerst zelf een interface aan de GPL software klust (bv. om commando's over een pipe te ontvangen).

Lijkt me een bijzonder grijs gebied op die manier en juridisch ook niet hard te maken natuurlijk. Wie zegt dat je dat alleen voor jouw app gedaan hebt, misschien hoop je wel dat er vele andere apps komen die er ook tegenaan gaan praten.

Straks krijg je het scenario dat iemand eerst de GPL schend door zo'n interface te maken voor zijn specifieke closed source programma, maar diezelfde schending bestaat dan twee weken later niet meer omdat iemand anders ook die interface is gaan gebruiken en die dus niet meer specifiek, maar generiek is geworden.

Lijkt me persoonlijk behoorlijk onhoudbaar. Dat linking niet mag van de GPL lijkt me duidelijk, maar als je dat via een in principe open interface doet (zoals pipes, mits voldoende gedocumenteerd), kan ik me niet voorstellen dat je de GPL schend, ook niet als je een closed source programma aan de andere kant van die pipe zet.

Maar goed, IANAL enzo en de wet laat zich niet altijd uitdrukken in logica.

[ Voor 3% gewijzigd door Gerco op 10-11-2008 17:40 ]

[leuk_he]

Gerco schreef op maandag 10 november 2008 @ 17:37:
[...]
Lijkt me persoonlijk behoorlijk onhoudbaar. Dat linking niet mag van de GPL lijkt me duidelijk, maar als je dat via een in principe open interface doet (zoals pipes, mits voldoende gedocumenteerd), kan ik me niet voorstellen dat je de GPL schend, ook niet als je een closed source programma aan de andere kant van die pipe zet.

Als je ze samen distribueert wel...

maar

quote: http://www.gnu.org/licens...html#WindowsRuntimeAndGPL

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.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

[Gerco]

hmm, leuk_he. Ik zie nu dat ik me ook niet helemaal aan de GPL houd. Ik release een Free program wat non-free (zelfs closed source) libraries gebruikt van het closed source product waar het een tool voor is (ok, dat is wat vaag).

Zonder die libs kan het niet werken, het is een client van het closed source systeem en heeft dus client libraries nodig. Daar moet ik dus een uitzondering voor maken in de license, toch goed om die FAQ weer eens door te lezen...

Nu staat er in die FAQ dat een programma met non-Free componenten/libraries sowieso ethisch twijfelachtig is, maar dat vind ik een beetje te sterke taal.... ik release alles als Free Software wat ik kan en mag releasen en dan vind ik niet dat iemand dat ethisch twijfelachtig kan noemen.

[Rukapul]

Daarom moet je informatie van GNU en de FSF over de GPL altijd met een korreltje zout nemen indien het niet GNU software betreft. Men predikt graag terwijl de intentie van degene die software onder de GPL releaset anders kan zijn of is. Zie bijvoorbeeld het kernel module verhaal waar Linus de interpretatie heeft bepaald welke de GNU/FSF mensen waarschijnlijk liever niet zouden zien.

[Verwijderd]

Ach, ik heb RMS nog niet op een leugen kunnen betrappen. Hij is altijd erg precies in z'n bewoordingen. Hij heeft het over onethisch, dan weet je al dat het niet gaat om een juridisch bezwaar. De redenatie is dat je eigenlijk non-free software promoot als je non-free onderdelen in je programma hebt. Dat is exact hetgene waartegen de free software movement is gestart en de GPL is geschreven.

Ik kan me daar wel in vinden. Nu moet ik zeggen dat het in het geval van CUDA niet zo zwart-wit is, omdat CUDA nauwelijks software is, maar een manier om bepaalde hardware aan te sturen. Straks komen Direct3D 11 en OpenCL (Open Computing Language) uit, en dan zijn het opeens System Libraries geworden.

[Rukapul]

Ik doelde ook niet zozeer op leugens, maar wel op het de wijze waarop ze de GPL plegen te interpreteren. Volstrekt logisch vanuit hun achtergrond, maar niet altijd in overeenstemming met wat de auteurs die de GPL licentie op hun software plakken bedoelen

[leuk_he]

en daarom poste ik eerder ook:

Ik weet niet hoe groot je project wordt, maar wellicht kun je ook redeneren: zal iemand bezwaar maken tegen dit gebruik van de library op deze manier? Als QT het goed vind (niet vragen daar, die vekropen alleen licenties...) en de 3th library en jij, wat let je dan?

Jij als autheur van JOUW code mag ermee doen wat jij wil.

Als iemand de code misbruikt (b.v.verkoopt op er een ander stempel op plaatst) zul je bezwar krijgen. Als iemand de code in een open source manier gebruikt dan zul je niet snel bezwaar krijgen.

CUDA zou je ook kunnen zien als een compiler, en dat is weer borderline toegestaan....

[MSalters]

Het is belangrijk om in dit verband te beseffen dat de GPL een licentie is, die binnen de copyright wetgeving wordt geinterpreteerd. Zonder copyright wetgeving zou je namelijk alle binaries zonder voorwaarden mogen kopieren, ook bijvoorbeeld Linux kernels.

Een belangrijk onderdeel van copyright wetgeving is dat het zaken regelt als samenstelling/samenvoeging. Trolltech kan daarom niet zomaar verzinnen dat de dynamische library deel uitmaakt van jouw programma. Jouw "programma" is een beschermd werk, met binary en source componenten. De binary componenten bevatten ook delen van Qt. Daarom is TrollTech mede-eigenaar van het copyright op dat werk.

De vraag is nu in hoeverre de binary ook delen van die andere library bevat. De technische term is hier statisch versus dynamisch linken. Als je dynamisch tegen een andere library linkt, dan is die library dus geen onderdeel van jouw binary. Link je statisch, dan is die library wel een onderdeel van je binary. In het dynamische geval kun je de sources van je binary dus vrijgeven, in het statische geval niet. Alleen in het dynamische geval voldoe je dus aan de eisen die TrollTech stelt, omdat alleen in dat geval de closed-source library buiten de copyrightwetgeving van jouw werk valt.

[leuk_he]

MSalters schreef op dinsdag 11 november 2008 @ 13:33:
De vraag is nu in hoeverre de binary ook delen van die andere library bevat. De technische term is hier statisch versus dynamisch linken.

Dit is een onderscheid dat je zelf verzint. Niet voor niks spreekt de gpl over

quote: gpl nl 1.c

Maar als U die zelfde delen verspreidt als deel van een geheel dat een werk is
gebaseerd op het Programma, dan moet de verspreiding van het geheel op de
bepalingen van deze licentie geschieden

Lees anders de gpl faq er maar op na. dynamicsh via statitisch was in de gpl v1 een probleem, maar is met de gpl v2 eignelijk opgelost dacht ik.

[Rukapul]

leuk_he schreef op dinsdag 11 november 2008 @ 15:45:
[...]


Dit is een onderscheid dat je zelf verzint.

Inderdaad. De criteria voor een afgeleid werk laten zich niet zo eenvoudig vangen.

[Stukfruit]

Wat een moeilijke teksten hier zeg, het komt er gewoon op neer dat als je een GPL library gebruikt dat je je programma ook GPL moet maken. Behalve als je LGPL libraries gebruikt, dan hoeft het weer niet. Tenzij je statisch wil linken met die library die onder de LGPL gelicenseerd is, want dan moet je je programma toch weer GPL maken.

LGPL kan je hierboven vervangen door iedere andere licentie (mits compatible met de voorwaarden van de GPL, daaronder valt bv. BSD, Apache, enz), maar de GPL overruled die (voor zover ik weet) allemaal. Dus als je een programma schrijft waarmee je een GPL library gebruikt (bijvoorbeeld Qt), dan is de rest dat automatisch ook, zelfs wanneer je er dynamisch mee linkt (alleen de LGPL biedt in dat geval de uitzondering om zelf voor een licentie te kiezen voor je programma zelf).

Simpel, toch?

[ Voor 40% gewijzigd door Stukfruit op 11-11-2008 16:58 ]

[Gomez12]

Stukfruit schreef op dinsdag 11 november 2008 @ 16:52:
LGPL kan je hierboven vervangen door iedere andere licentie (mits compatible met de voorwaarden van de GPL, daaronder valt bv. BSD, Apache, enz), maar de GPL overruled die (voor zover ik weet) allemaal.
[snip]
Simpel, toch?

Een licentie die andere licenties overruled mits ze compatibel zijn dat noem jij simpel?

Als ik een BSD library maak, iemand anders maakt dit onderdeel van een GPL prog en weer iemand anders pakt uit die GPL prog alleen mijn library. Mag de laatste persoon dit dan gebruiken in een closed source binary?

GPL kan imho niet een bsd licentie overrulen, want hij is restrictiever.

[Herko_ter_Horst]

De GPL "overruled" alleen i.c.m. de GPL software. De 3rd party software blijft daarnaast gewoon bestaan onder andere licenties. Voorwaarde is dus wel dat de andere license dit toestaat.

[ Voor 18% gewijzigd door Herko_ter_Horst op 11-11-2008 21:01 ]

[Verwijderd]

Alles kan een BSD-licentie overrulen. Dat is nogal hét nadeel van een BSD-licentie.

[.oisyn]

Het is dan ook écht vrije software.

[Gomez12]

Verwijderd schreef op woensdag 12 november 2008 @ 00:52:
Alles kan een BSD-licentie overrulen. Dat is nogal hét nadeel van een BSD-licentie.

Het voordeel is dan wel weer dat iedereen het kan gebruiken wat goed is voor de acceptatie en standaardisatie graad van je apps, terwijl de meeste grote commerciele bedrijven met een grote boog om alles wat maar naar GPL ruikt heenlopen

[curry684]

Verwijderd schreef op woensdag 12 november 2008 @ 00:52:
Alles kan een BSD-licentie overrulen. Dat is nogal hét nadeel van een BSD-licentie.

Daarom heeft Windows ook zo'n goeie TCP stack.

[Stukfruit]

Gomez12 schreef op dinsdag 11 november 2008 @ 19:45:
Als ik een BSD library maak, iemand anders maakt dit onderdeel van een GPL prog en weer iemand anders pakt uit die GPL prog alleen mijn library. Mag de laatste persoon dit dan gebruiken in een closed source binary?

Als toevoeging op wat Herko_ter_Horst hierboven vertelde; ja dat mag in het geval van BSD, en dan is je library (of welke andere code met die licentie dan ook) nog steeds BSD, tenzij iemand in de tussentijd je library afhankelijk heeft gemaakt van een stuk code uit een library of programma die onder de GPL geleverd wordt.

Als de laatste persoon daarna de code nog wil gebruiken in een closed source programma dan zijn er twee mogelijkheden:

• Alle toegevoegde code die onder de GPL of andere licentie met zoveel restricties valt eruit vissen

• Vragen aan de persoon die de toegevoegde code heeft geschreven of zijn/haar code onder een andere licentie en/of commercieel gebruikt mag worden (die persoon is tenslotte de eigenaar van de code die hij/zij schreef en houdt ook met de GPL altijd zelf de rechten, tenzij specifiek overgedragen aan een derde partij)

[The - DDD]

Gerco schreef op maandag 10 november 2008 @ 07:15:
[...]

Ik denk dat je de GPL verkeerd begrijpt en daar kan een hoop woede uit voorkomen.

De GPL draait niet om vrijheid voor de ontwikkelaar, maar om vrijheid voor de software en de garantie dat die software altijd vrij zal blijven. Om dat mogelijk te maken moet je als ontwikkelaar inderdaad wat vrijheden inleveren (aan de andere kant, door copyright wetgeving zou je überhaupt geen vrijheden hebben als de license je ze niet zou geven).

Wanneer je de GPL niet ziet als een soort ultieme vrije licentie, maar het ziet voor wat het is, vind ik er helemaal niets mis mee en is het voor veel projecten prima geschikt. Als je maximale vrijheid voor de ontwikkelaar wilt moet je een BSD-achtige license op je code zetten of de code in het geheel in het public domain releasen.

GPL verplicht je helemaal niet om de code vrij te geven. Enkel als je je programma aan iemand beschikbaar stelt, dien je je code voor die ENE partij beschikbaar te maken. Gewoon de zooi publiek op internet klatsen is een eenvoudige manier om dat te doen.

Kijk eens naar FogCreek's Co-Pilot. Een compleet systeem gebouwd met open source en van de client is volgens mij ook de bron beschikbaar, aar het server component, dus niet.

Overigens zou ik voor de door de topic starter genoemde applicatie kiezen voor een BSD style research license. Daarmee sluit je de mogelijkheid niet uit dat de zaken ooit nog eens commercieel ingezet kunnen worden en het is open source. Zo'n BSD license verplicht de gebruiker enkel tot het doen van een bronvermelding indien ze de code gebruiken in een programma. Echter, je kan ook zeggen, het is GPL en als iemand dan iets commercieels wil maken met de code, dan kunnen ze bij de copyright houder leuren om een andere licentie. Niemand verbiedt in GPL namelijk de copyright houder om bron onder twee verschillende licenties uit te brengen. Let er bij zulk soort dingen wel op dat alle mensen die bijdragen aan het product hun eigen auteursrechten op bijdragen automatisch overdragen aan de jou of je instelling. Anders kan het weer wel lasti worden.

GPL kan vanwege haar virale karakter echt een totaal verkeerde licentie zijn.

[Confusion]

Rukapul schreef op maandag 10 november 2008 @ 14:24:
Over het algemeen worden kunstmatig gecreeerde interfaces (ongeacht of dit een plugin architectuur, netwerkmiddleware, etc. betreft) om onder licenties uit te komen beschouwd als zijnde niet in overeenstemming zijnde met de GPL.

Maar in dit geval lijkt het om een optioneel deel van de applicatie te gaan. In dat geval kan je toch sowieso de applicatie, zonder het optionele deel, met de GPL releasen en opmerken dat de applicatie versnelt kan worden door er Cuda bij te hangen en de noodzakelijke configuratieaanpassingen te maken? Het geheel mag alleen niet met de GPL gedistribueerd worden, maar kan je daar niet onderuit komen door in dezelfde tarball beide licenties op te nemen en duidelijk te maken welk licentie waar op van toepassing is?

[Gerco]

The - DDD schreef op woensdag 12 november 2008 @ 07:43:
GPL verplicht je helemaal niet om de code vrij te geven. Enkel als je je programma aan iemand beschikbaar stelt, dien je je code voor die ENE partij beschikbaar te maken. Gewoon de zooi publiek op internet klatsen is een eenvoudige manier om dat te doen.

Ik heb nog eens mijn post doorgelezen, maar ik kan niet vinden waar ik zeg dat je verplicht bent om je code vrij te geven. De GPL zegt er ook niets over, maar stelt alleen verplichtingen op wanneer je er zelf voor kiest om de code te verspreiden.

Hoewel je post volkomen correct is kan ik de relevantie van het quoten van mijn post er niet in vinden.

GPL kan vanwege haar virale karakter echt een totaal verkeerde licentie zijn.

Ongeschikt voor bepaalde projecten (mogelijk heel veel projecten) ja. Totaal verkeerd? Nee.

Overigens zijn niet alle BSD style licenses compatible met de GPL. Hoewel dat probleem niet aan de BSD license ligt volgens mij. (bron)

[ Voor 9% gewijzigd door Gerco op 12-11-2008 09:03 ]

[leuk_he]

Gerco schreef op woensdag 12 november 2008 @ 08:27:
[...]

Ik heb nog eens mijn post doorgelezen, maar ik kan niet vinden waar ik zeg dat je verplicht bent om je code vrij te geven. De GPL zegt er ook niets over, maar stelt alleen verplichtingen op wanneer je er zelf voor kiest om de code te verspreiden.

Niet jouw post.. maar om misverstanden te voorkomen....

3. U mag het Programma, of een werk gebaseerd op het Programma,
zie paragraaf 2, verspreiden en kopiëren, in binaire of uitvoerbare vorm onder
de bepalingen van paragraaf 1 en 2 hierboven, op voorwaarde dat U aan een van
de volgende voorwaarden voldoet :

a) Voeg een volledige overeenkomende broncode bij, leesbaar door computers,
verspreid onder de bepalingen van de paragrafen 1 en 2, op een medium dat
gebruikelijk is voor het uitwisselen van software; of,

(3 b & c geven aan datje broncode ook op andere manieren mag aanbieden)

[MSalters]

leuk_he schreef op dinsdag 11 november 2008 @ 15:45:
[...]
[dynamisch versus statisch linken] is een onderscheid dat je zelf verzint.

Nee, dat heb ik absoluut niet zelf verzonnen. Dat verschil is technisch gezien overduidelijk. Als jij dat verschil niet kent, google het dan.
De volgende vraag is wat dat voor de wet betekent. Linken is juridisch gezien het maken van een afgeleid werk. Bij dynamisch linken gebeurt dat als onderdeel van het opstarten van een proces.
De GPL mag vervolgens details invullen, maar kan niet afwijken van de technische of juridische werkelijkheid.

[MSalters]

Rukapul schreef op dinsdag 11 november 2008 @ 15:47:
[...]
Inderdaad. De criteria voor een afgeleid werk laten zich niet zo eenvoudig vangen.

De exacte criteria zijn lastig. Maar wil B een afgeleid werk van A zijn, dan moet er een voorafgaande transformatie zijn geweest. Oorzaken komen vóór gevolgen. Een executable A die linkt met library L om op tijdstip T afgeleid werk B te vormen is op moment T-1 nog gewoon een losse exectutable.

[abeker]

leuk_he schreef op woensdag 12 november 2008 @ 09:33:
[...]
Niet jouw post.. maar om misverstanden te voorkomen....
[...]
(3 b & c geven aan datje broncode ook op andere manieren mag aanbieden)

Paragraaf 3b en 3c bevatten nog genoeg mogelijkheden om het voor de gebruiker moeilijk te maken om de source te krijgen, afhankelijk van hoe vrij je het wilt interpreteren (naar de letter of naar de geest).

b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

Wat is een 'written offer'? Een handgeschreven brief? Een getypte brief? Een emailtje? Een tekstdocument die met de applicatie meegeleverd wordt? Moet dat documentje dan in de root staan, of mag het ook helemaal ergens 'verborgen' in een directory staan?

Wie bepaald hoe de sourcecode gedistribueerd wordt, de gebruiker of de ontwikkelaar? Mag de ontwikkelaar er voor kiezen om de source op een CD te zetten en deze persoonlijk te overhandigen, en daarvoor een flink uurtarief in rekening brengen?

Wat is "a medium customarily used for software interchange"? Ponskaarten? Internet? 5 1/4" floppies? Blu-ray disc? Mag de gebruiker eisen stellen aan het gebruikte medium? Wat dan als de ontwikkelaar niet kan leveren via het gewenste medium?

Genoeg mogelijkheden dus, maar je krijgt er uiteraard geen goede naam mee... En uiteraard geldt nog steeds dat gebruikers vrij zijn om de sourcecode zelf weer te distribueren als ze deze eenmaal in bezit hebben.

[ Voor 3% gewijzigd door abeker op 12-11-2008 11:24 ]

[leuk_he]

abeker schreef op woensdag 12 november 2008 @ 11:23:
[...]


Paragraaf 3b en 3c bevatten nog genoeg mogelijkheden om het voor de gebruiker moeilijk te maken om de source te krijgen, afhankelijk van hoe vrij je het wilt interpreteren (naar de letter of naar de geest).


[...]

Wat is "a medium customarily used for software interchange"? Ponskaarten? Internet? 5 1/4" floppies? Blu-ray disc? Mag de gebruiker eisen stellen aan het gebruikte medium? Wat dan als de ontwikkelaar niet kan leveren via het gewenste medium?

Ja, een gebruikelijk medium. ponskaarten mag dus niet. Er staat overigens niet dat de source GRATIS moet worden geleverd, dat kan een vel hogere drempel zijn.... als een consultant een paar uurtjes moet besteden om de source in te pakken ben je een kapitaal kwijt dat in hobby sferen niet meer leuk is....

[MBV]

400 euro voor een halve dag ofzo? 't werkt alleen zo slecht als je meer dan 1 klant hebt

[Herko_ter_Horst]

leuk_he schreef op woensdag 12 november 2008 @ 17:44:
[...]

Ja, een gebruikelijk medium. ponskaarten mag dus niet. Er staat overigens niet dat de source GRATIS moet worden geleverd, dat kan een vel hogere drempel zijn.... als een consultant een paar uurtjes moet besteden om de source in te pakken ben je een kapitaal kwijt dat in hobby sferen niet meer leuk is....

Als je even verder had gelezen in de GPL zelf, in plaats van direct te gaan blaten over consultants, dan had je gezien dat de source weliswaar niet persé gratis, maar ook niet zomaar tegen hoge kosten mag worden meegeleverd: "for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge."

En daarbij komt: een eventueel truukje met hoge kosten kun je maar één keer uithalen, want degene die de source ontvangen heeft mag die net zo vaak (onder de GPL en gratis) verspreiden als hij wil.

[ Voor 10% gewijzigd door Herko_ter_Horst op 12-11-2008 19:45 ]

[MBV]

@Herko: dat was precies wat ik bedoelde met de €400 voor een halve dag. Als je je software er niet op hebt ingericht kan het best wel een paar uurtjes duren, en €100/u voor een consultant is nou niet echt een raar bedrag.

Over de TS: ik denk dat je geen enkel probleem hebt, omdat CUDA een system-library (driver) is. Als het dat niet is, vraag ik me af wie moeilijk gaat doen wanneer die ontsnapping niet opgaat.
Als je het risico niet wilt lopen, dan zorg je dat er een plugin nodig is voor de berekening, waarbij je @runtime kan kiezen welke je gebruikt. Je maakt eerst een triviale implementatie op de CPU (sowieso niet onverstandig om te kijken of je algoritme goed is). Daarna verander je niets meer aan die kant van de code, en maak je een andere plugin met BSD-licentie, die wel van CUDA gebruik maakt. Hij moet dan op dezelfde manier communiceren als de triviale plugin. Als je runtime kan wijzigen van welke plugin je gebruik maakt zal niemand je erop kunnen aanvallen, want dan zou elke media-player en zelfs heel alsa in overtreding zijn.
Jij kan er toch ook niks aandoen dat ik een BSD-plugin schrijf die communiceert met jouw applicatie om op AMD te draaien? Zelfde verhaal.

[Verwijderd]

Het hele topic is ook irrelevant omdat Qt heel wat excepties toestaat die de TS genoeg bewegingsvrijheid geven om Qt met CUDA te combineren.

[ATS]

Dank iedereen voor de bijdragen. Ik heb inmiddels weer contact gehad met Trolltech. Ze staan er niet onwelwillend tegenover, maar het lijkt erop dat het handiger is om een andere licentie te kiezen dan GPL in dit geval om aan de veilige kant te blijven. Ik denk dat ik voor de "Open Source Software" licentie ga: wel copyleft, maar niet zo restrictief als de GPL in waar je het mee mag linken.

Of Cuda gezien kan worden als system library is discutabel. Het is niet standaard aanwezig, en het voldoet ook niet aan het criterium dat er maar een beperkte uitwisseling van informatie is (wat dat dan ook mag betekenen; een videoplayer stuurt ook heel wat data naar een (gesloten) videokaart driver zou ik zeggen). Ik denk ook niet dat ik tegen de "geest" van de GPL of van Trolltech/Nokia in zou gaan als ik het gewoon zou doen, maar better safe than sorry.

[Verwijderd]

ATS schreef op dinsdag 18 november 2008 @ 10:00:
Dank iedereen voor de bijdragen. Ik heb inmiddels weer contact gehad met Trolltech. Ze staan er niet onwelwillend tegenover, maar het lijkt erop dat het handiger is om een andere licentie te kiezen dan GPL in dit geval om aan de veilige kant te blijven. Ik denk dat ik voor de "Open Source Software" licentie ga: wel copyleft, maar niet zo restrictief als de GPL in waar je het mee mag linken.

Of Cuda gezien kan worden als system library is discutabel. Het is niet standaard aanwezig, en het voldoet ook niet aan het criterium dat er maar een beperkte uitwisseling van informatie is (wat dat dan ook mag betekenen; een videoplayer stuurt ook heel wat data naar een (gesloten) videokaart driver zou ik zeggen). Ik denk ook niet dat ik tegen de "geest" van de GPL of van Trolltech/Nokia in zou gaan als ik het gewoon zou doen, maar better safe than sorry.

Je bedoelt deze? Eén ding is mij onduidelijk. Derivative Work wordt niet echt goed gedefinieerd. Wordt machine code ook gezien als derivative work? In dat geval lijkt het erg op de LGPL. Anders lijkt het erg op de MS-PL.

[ATS]

Verwijderd schreef op dinsdag 18 november 2008 @ 15:15:
Je bedoelt deze? Eén ding is mij onduidelijk. Derivative Work wordt niet echt goed gedefinieerd. Wordt machine code ook gezien als derivative work? In dat geval lijkt het erg op de LGPL. Anders lijkt het erg op de MS-PL.

Die ja. De definitie is gegeven in de licentie:

1b) to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works ("Derivative Works") based upon the Original Work;

Dus ja, machinecode is een Derivative work, omdat dat een translation of een transformation is. Echter, wegens 1c) moet ook zo'n Derivative Work onder de OSL vallen, waarbij deze passage:

Licensor agrees to provide a machine-readable copy of the Source Code of the Original Work along with each copy of the Original Work that Licensor distributes.

vervolgens verplicht om sources van dat werk te verspreiden. De licentie is dus net als GPL viraal. Dat maakt het IMHO anders dan LGPL, als ik het allemaal goed begrijp, want je mag tegen LGPL linken zonder dat je eigen programma LGPL wordt. MS-PL ken ik niet verder, maar die staat ook niet op de uitzonderingenlijst van de Qt licentie en is dus zowiezo geen optie.

De uitleg die eronder gelinkt staat is wat duidelijker dan de licentie zelf vind ik, maar dat komt waarschijnlijk omdat ik niet zo gewend ben om contract-taal te lezen. Doe mij maar source code

[Verwijderd]

ATS schreef op dinsdag 18 november 2008 @ 17:07:
[...]

Die ja. De definitie is gegeven in de licentie:

[...]


Dus ja, machinecode is een Derivative work, omdat dat een translation of een transformation is. Echter, wegens 1c) moet ook zo'n Derivative Work onder de OSL vallen, waarbij deze passage:

[...]

vervolgens verplicht om sources van dat werk te verspreiden.

Ok, dat is zo inderdaad.

De licentie is dus net als GPL viraal. Dat maakt het IMHO anders dan LGPL, als ik het allemaal goed begrijp, want je mag tegen LGPL linken zonder dat je eigen programma LGPL wordt. MS-PL ken ik niet verder, maar die staat ook niet op de uitzonderingenlijst van de Qt licentie en is dus zowiezo geen optie.

Nee, de GPL wordt viraal genoemd omdat het andere code 'infecteert' door linking. De LGPL is daarom niet viraal, net als deze licentie, omdat linken niet onder de definitie van derivative work valt. De OSL is dus eigenlijk gewoon de LGPL, maar dan incompatible. Dit wordt ook wel licence-proliferation genoemd, en werkt versnippering van de open source scene in de hand.

Volgens het report valt de OSL onder "Other/Miscellaneous", dus blijkbaar vonden zij het niet duidelijk een kopie van de LGPL, maar ik zal eens vragen wat de belangrijke verschillen zijn die de OSL bestaansrecht geven.

[ Voor 19% gewijzigd door Verwijderd op 18-11-2008 18:21 ]

[ATS]

Verwijderd schreef op dinsdag 18 november 2008 @ 18:13:
Nee, de GPL wordt viraal genoemd omdat het andere code 'infecteert' door linking. De LGPL is daarom niet viraal, net als deze licentie, omdat linken niet onder de definitie van derivative work valt.

OK, ik gebruikte de term viraal verkeerd. Ik bedoelde dat de licentie naar beneden propageert: je mag iets maken op basis van broncode onder deze licentie, maar alleen onder deze licentie.

De OSL is dus eigenlijk gewoon de LGPL, maar dan incompatible. Dit wordt ook wel licence-proliferation genoemd, en werkt versnippering van de open source scene in de hand.

Volgens het report valt de OSL onder "Other/Miscellaneous", dus blijkbaar vonden zij het niet duidelijk een kopie van de LGPL, maar ik zal eens vragen wat de belangrijke verschillen zijn die de OSL bestaansrecht geven.

Wat ik ervan begrijp is het verschil dat OSL toestaat om naar andere libs te linken, of die nu zelf OSL zijn of niet, maar wat gebaseerd wordt op een onder OSL uitgebracht project ook OSL moet blijven. LGPL lijkt andersom te werken: hetgeen gemaakt wordt met LGPL moet gebaseerd zijn op iets dat minstens zo open is als LGPL zelf, maar dingen die op hun beurt afgeleid zijn van dat project hoeven niet aan diezelfde voorwaarden te voldoen. Maar: ik ben zeker geen expert; daarom vroeg ik hier ook om hulp.

[Verwijderd]

ATS schreef op dinsdag 18 november 2008 @ 22:29:
[...]

OK, ik gebruikte de term viraal verkeerd. Ik bedoelde dat de licentie naar beneden propageert: je mag iets maken op basis van broncode onder deze licentie, maar alleen onder deze licentie.


[...]

Wat ik ervan begrijp is het verschil dat OSL toestaat om naar andere libs te linken, of die nu zelf OSL zijn of niet, maar wat gebaseerd wordt op een onder OSL uitgebracht project ook OSL moet blijven. LGPL lijkt andersom te werken: hetgeen gemaakt wordt met LGPL moet gebaseerd zijn op iets dat minstens zo open is als LGPL zelf, maar dingen die op hun beurt afgeleid zijn van dat project hoeven niet aan diezelfde voorwaarden te voldoen. Maar: ik ben zeker geen expert; daarom vroeg ik hier ook om hulp.

Nee, het werkt in alle gevallen beide kanten op. Het verschil tussen de licenties is dat de GPL zegt dat het gehele derivative work onder de GPL moet vallen, terwijl de OSL en de LGPL zeggen dat de code die gelinkt is ook onder een andere licentie mag vallen.

Een bedrijf mag dus een library gebruiken die onder de OSL/LGPL is uitgegeven, zonder de code van hun eigen programma mee te leveren (maar wel die van de library, onder dezelfde licentie). Ook mag een bedrijf een OSL/LGPL-programma aanpassen zodat het een propriëtaire library gebruikt (zonder die code mee te leveren), zolang de code van het programma zelf maar wordt meegeleverd onder dezelfde licentie.

Maar wat nu praktisch het verschil is tussen OSL en LGPL... dunno.

---

Ik heb het op de license-discuss mailinglist van het OSI gevraagd.

[ Voor 4% gewijzigd door Verwijderd op 18-11-2008 23:14 ]

[MBV]

LGPL kan je dus vrij makkelijk onderuit komen: je kan het altijd zo organiseren dat jouw eigen wijzigingen buiten schot vallen. Hier wil ik iets veranderen, prima, functieaanroep naar buiten, en dat 'buiten' krijg je de source niet van.

[Verwijderd]

Ja, op zich wel... maar dat is dan ook de bedoeling van de LGPL. Het heet niet voor niets de Lesser GPL. Het biedt geen volledig sluitende bescherming.

Maar de originele code kan nooit propriëtair worden, zoals bij BSDL wel kan. In alle forks blijft de code onder de LGPL meegeleverd worden. Het lijkt me ook sterk dat men voor elk wissewasje een API gaat bouwen naar een propriëtaire lib om zo maar niet de eigen code te hoeven vrijgeven.

[ATS]

@Dot. Dank voor je inzicht. Misschien heb ik dan toch de verkeerde licentie voor ogen. Is er toevallig ergens een soort van site waarop je kan aangeven wat je wensen zijn licentie-technisch, en wat er dan in aanmerking komt? Als ik de (relatief eenvoudige) OSL al verkeerd lees, dan vertrouw ik mezelf niet helemaal om de ingewikkelder licenties zoals die genoemd zijn op de uitzonderingenlijst van Qt te doorgronden.

Eisen: te linken aan niet-open libs en op de lijst van opties van Qt
Wensen: aanpassingen ook weer onder dezelfde (of een andere open) licentie, niet naar linken vanuit of opnemen in gesloten software.

[Herko_ter_Horst]

Wij hebben enige tijd geleden ook moeten kiezen voor een bepaalde Open Source licentie. OSL en LGPL zijn inderdaad vergelijkbaar qua uitwerking. Je mag bij beiden de software as-is gebruiken en meeleveren, ook als onderdeel van een pakket onder een andere licentie (óók proprietary licenties).

Wij hebben gekozen voor de OSL om een aantal redenen:
- de OSL doet specifiek moeite om óók terminologie te gebruiken die in Europa gebruikelijk is om bepaalde begrippen te omschrijven (aldus de maker)
- de OSL maakt met opzet expliciet gebruik van de term "derivative work" uit het auteursrecht, omdat er veel jurisprudentie is over wat nou wel en wat nou geen afgeleid werk is.
- (L)GPL wordt door bepaalde organisaties waar wij zaken mee wilden doen niet geaccepteerd, vanwege onduidelijkheid over de uitleg van bepaalde passages

Het al dan niet toestaan van gebruik binnen software onder een andere licentie is onder de OSL dus afhankelijk van de specifieke invulling van het begrip "derivative work" in een bepaald geval.

Overigens is wat DOT zegt over het "propriëtair" worden van BSD code m.i. niet juist, de code blijft BSD. Het is wel toegestaan de code mee te leveren in een propriëtair pakket zonder veel verdere verplichtingen (buiten het in stand houden/tonen van de copyright notice en disclaimer).

[ Voor 12% gewijzigd door Herko_ter_Horst op 19-11-2008 16:20 ]

[Verwijderd]

ATS schreef op woensdag 19 november 2008 @ 15:32:
@Dot. Dank voor je inzicht. Misschien heb ik dan toch de verkeerde licentie voor ogen. Is er toevallig ergens een soort van site waarop je kan aangeven wat je wensen zijn licentie-technisch, en wat er dan in aanmerking komt? Als ik de (relatief eenvoudige) OSL al verkeerd lees, dan vertrouw ik mezelf niet helemaal om de ingewikkelder licenties zoals die genoemd zijn op de uitzonderingenlijst van Qt te doorgronden.

Ja, licenties zijn echt verrekte lastig. Ik ben ook zeker geen expert (bij lange na niet). Je moet echt rechten hebben gestudeerd en advocaat zijn om een goed oordeel te hebben.

Op die malinglist zou je je in de discussie kunnen mengen, hoewel ik niet helemaal zeker ben of het objectief is. De auteur van de OSL is daar aanwezig (hij is die Larry). Ik heb in ieder geval al wat verschillen tussen de LGPL en de OSL gehoord/bedacht:
[list]
• De LGPL is populairder, meer getest, waardoor je meer op de geldigheid kan vertrouwen.
• De OSL is minder ingewikkeld en duidelijker, waardoor je meer op de geldigheid kan vertrouwen.
• De LGPL is populairder, waardoor meer code 'out there' compatible is.
• De LGPL staat toe dat iemand de code opnieuw uitgeeft onder de GPL, waardoor jij de aanpassingen niet meer terugkrijgt onder de LGPL.
• De LGPL staat niet toe om de software te distribueren op een door de fabrikant gecontroleerd platform (zoals de Tivo), OSL wel.
• De OSL vereist een "reasonable effort" van de uitgever dat de gebruiker akkoord gaat met de licentie. Ik neem aan dat je dan een licentie voor hun neus moet zetten met een "I Agree"-knop. De LGPL geeft gebruikers impliciet het recht om de software te gebruiken.
• De LGPL staat gebruik in een bedrijf toe, zonder dat dat geldt als distributie. Bij de OSL moet de source in dat geval ook meegeleverd worden.

Een aantal dingen zijn voor jou waarschijnlijk niet relevant. In ieder geval is relicensen onder de GPL niet zo'n gevaar, omdat dat toch niet mag vanwege CUDA.

Eisen: te linken aan niet-open libs en op de lijst van opties van Qt
Wensen: aanpassingen ook weer onder dezelfde (of een andere open) licentie, niet naar linken vanuit of opnemen in gesloten software.

Voor die wensen zou je het beste de GPL kunnen gebruiken, omdat dat gesloten software uitsluit (met speciale uitzondering van CUDA). Het is echt onwijs jammer dat dit niet kan in combinatie met Qt, want verder is het de perfecte licentie hiervoor.

Zowel de LGPL als de OSL staan toe dat er wordt gelinkt met gesloten software, voor zover het als afzonderlijke werken gelden volgens de copyright-wetgeving.

Maar van je wensen is dus alleen het linken niet te verbieden; zowel LGPL als OSL staan niet toe dat de software zelf gesloten wordt door er een andere licentie aan te hangen.

Het kan best zijn dat een andere licentie van de Qt lijst van exceptions beter op je wensen aansluit, maar ik heb persoonlijk niet zo'n zin om ze allemaal uit te pluizen.

Je kan natuurlijk ook vragen of Trolltech speciaal voor jou (en toekomstige programmeurs) "GPL + exception voor CUDA" wil toevoegen aan de lijst.