[Licenties]Open source en closed source combineren

[mithras]

Ik heb een klein cms ontwikkeld en heb deze onder de GPL vrij gegeven. Ik ben een groot voorstander van open source en ik vind het dus belangrijk dat deze software vrije software is. Omdat de GPL het makkelijkste en het meest bekend is heb ik dus die genomen. Zonder verdere overwegingen eigenlijk of het wel de beste keuze was.

Nu zit ik eigenlijk met een "probleempje". Het systeem zelf bestaat voornamelijk uit plugins, ook de meest basale onderdelen van het cms. Ik heb gewoon het geheel een licentie gegeven, maar nu kom ik er niet meer uit. Ik ben namelijk benaderd of ik mijn cms op maat wil maken voor iemand (onder betaling). Dat zullen dan ook plugins worden die niet onder de GPL worden vrij gegeven. Maar ik vraag me dan een aantal dingen af.

[list]• Is het mogelijk om bepaalde plugins wel, en bepaalde zaken niet open source te maken? Is het juridisch gezien onzin dat een gesloten plugin op een systeem draait met GPL software, of kan dit wel?
• Is het verstandig om de licentie te veranderen naar een ander? Is het bijvoorbeeld voor mijzelf beter een BSD / Apache / MIT licentie eraan te hangen omdat ik nu ook met closed source plugins ga werken? Ik heb er weinig verstand van, maar ik weet wel ("van horen zeggen") dat de GPL eigenlijk wel de meest harde licentie is. Met zegt dat de GPL het strengst de vrije software bewaakt ten opzichte van andere licenties.
• En dan een hele andere vraag: is het uberhaupt wel mogelijk om php scripts closed source te maken, zonder de Zend Encoder à $2400 te gebruiken? En dan wil ik eigenlijk ook niet die andere optimizers gebruiken die iemand dan specifiek moet installeren voor mijn systeem. Volgens mij heb ik dan namelijk gewoon pech gehad. Ik kan wel de plugin closed source (met een licentie) maken, mijn klant kan de code rippen en er zelf gewoon mee doorgaan toch?
• En dan bedenk ik me nog iets omdat het waarschijnlijk (nu ik dit typ) toch onmogelijk is om de plugins closed source te maken: hoe werkt het dan met betaling e.d.? Ik zal wellicht support blijven leveren (en daar betaald voor krijgen), maar kan je gewoon geld vragen voor het ontwikkelen, ook al is het open source software? Hebben mensen ervaring met professioneel open source applicaties te ontwikkelen (hoewel dat beter in WI kan)? Googlen op 'professional open source' helpt namelijk niet echtAlvast bedankt

[Cyphax]

Open source hoeft niet gratis te zijn, dat weet je waarschijnlijk ook.
Dus dat het open source software is wil niet zeggen dat je het niet kan verkopen, alleen voor GPL'ed software betekent dat dat je de source meelevert. Voor support kun je ook gerust geld vragen, dat staat los van de ontwikkeling van je open source software.
Maar die plugins... als je CMS GPL'ed is moeten volgens mij de plugins dat ook zijn.

Als je niet zoveel zin hebt in al die toestanden moet je eigenlijk het licentiemodel aanpassen. Naast die GPL en BSD-licenties zijn er nog wel meer die misschien te overwegen zijn (Apache license, Mozilla license, Sun heeft er ook nog eentje liggen )

[Mr_gadget]

Misschien LGPL ?

Je wilt dus eigen geschreven plugins closed source maken zodat je hier support op kan blijven leveren en men niet zelf er aan kan zitten?

[ Voor 53% gewijzigd door Mr_gadget op 10-04-2007 21:19 ]

[Rukapul]

Om te beginnen zou ik je adviseren eerst te bedenken wat jij wilt nog even los van bestaande licenties. Hoe wil je dat 'men' (=een willekeurig persoon of een willekeurig bedrijf) je software kan gebruiken (=gebruiken/distribueren/aanpassen)? Hoe wil jij er geld mee verdienen (=voor de software/support/...)? Etc.

Jij bent hier de rechthebbende en jij bepaalt dus de licentie.

[ Voor 9% gewijzigd door Rukapul op 10-04-2007 21:18 ]

[mithras]

Cyphax schreef op dinsdag 10 april 2007 @ 21:06:
Open source hoeft niet gratis te zijn, dat weet je waarschijnlijk ook.
Dus dat het open source software is wil niet zeggen dat je het niet kan verkopen, alleen voor GPL'ed software betekent dat dat je de source meelevert. Voor support kun je ook gerust geld vragen, dat staat los van de ontwikkeling van je open source software.

Dat had ik inderdaad begrepen ja

Maar die plugins... als je CMS GPL'ed is moeten volgens mij de plugins dat ook zijn.

Daar zat ik inderdaad aan te denken. Het punt is dat ik niet juridisch oid ben ingesteld, en het lastig vind om uit een korte tekst op te maken of dit soort dingen nu wel of juist niet mogelijk zijn.

Als je niet zoveel zin hebt in al die toestanden moet je eigenlijk het licentiemodel aanpassen. Naast die GPL en BSD-licenties zijn er nog wel meer die misschien te overwegen zijn (Apache license, Mozilla license, Sun heeft er ook nog eentje liggen )

Er zijn gewoon erg veel open source licenties beschikbaar, en dat is een beetje mijn punt ook. Het is allemaal leuk, maar een eigen licentie schrijven kan ik helemaal niet. De MIT en BSD zijn bijvoorbeeld erg kort (hoewel dat waarschijnlijk weinig zegt). Dat is de reden dat ik het hier vraag

Maar ik zit er nu meer aan te denken ook de speciale (op maat gemaakte) plugins open source te maken: de source heeft de klant toch al. Een open source licentie eraan plakken en ik ben klaar. Maar ik wil die graag wat minder open maken dan de rest. Het is nu niet de bedoeling dat de klant de plugin pakt en zelf door gaat ontwikkelen. Het is niet tegen te houden, maar het zou fijn zijn als de licentie zegt "hier heb je het programma, inclusief bron code. Wil je echter veranderingen aanbrengen zal je de eigenaar van de code dit moeten vragen". Zoiets, maar dan wat netter enzo

Mr_gadget schreef op dinsdag 10 april 2007 @ 21:14:
Misschien LGPL ?

Het is een mooie licentie om het cms en de meeste plugins in onder te brengen. Echter:

Het virale aspect van de GPL is echter nog steeds aanwezig. Wijzigingen in de broncode van de LGPL delen van een product moeten dus ter beschikking worden gesteld aan de gebruikers.

Het is dus nog wel mogelijk met de extra plugins onder de LGPL om die te kopieren en zelf door te ontwikkelen. Iets wat ik liever niet heb. Voor het standaard cms is het wel een betere optie dan de GPL inderdaad

Rukapul schreef op dinsdag 10 april 2007 @ 21:18:
Om te beginnen zou ik je adviseren eerst te bedenken wat jij wilt nog even los van bestaande licenties. Hoe wil je dat 'men' (=een willekeurig persoon of een willekeurig bedrijf) je software kan gebruiken (=gebruiken/distribueren/aanpassen)? Hoe wil jij er geld mee verdienen (=voor de software/support/...)? Etc.

Jij bent hier de rechthebbende en jij bepaalt dus de licentie.

Het staat een beetje kris kras door mijn verhaal heen, maar het komt hier op neer:
Het algemene deel en de meeste onderdelen worden vrijgegeven. Iedereen mag eraan mee ontwikkelen, mits de wijzigingen terug gegeven worden (aan "de community"). Eigenlijk het algemene open source idee. Het zal ook gratis ter beschikking worden gesteld (hoewel dat niet veel met de licentie te maken heeft).

Nu moet ik dus ook wat extra dingen gaan ontwikkelen. Wat het precies wordt is nog onduidelijk. Waarschijnlijk zullen deze onderdelen niet verder openbaar worden gemaakt. Het is maatwerk waar de rest van de wereld weinig mee te maken heeft. Het is wel zo dat php makkelijk te stelen valt (zonder die encoders etc). Ik geef dus eigenlijk de broncode mee, dus een closed source licentie is niet heel zinvol. Het gaat me erom dat mijn ontwikkeltijd niet voor niets is. Er zullen nog dingen in gewijzigd moeten worden, er zal misschien support gegeven worden. Het is niet de bedoeling dat de plugin door mij gemaakt wordt, maar door een vriendje van de klant bugfree gemaakt wordt en dat hij de support voor een vriendenprijsje levert. Ik ben de eigenaar, ik ben degene die aan die onderdelen sleutelt. En niemand meer. Dat is wat ik eigenlijk wil, en mijn vraag is dus hoe je dit kan combineren met een licentie die zoiets ondersteund

[ Voor 25% gewijzigd door mithras op 10-04-2007 21:26 ]

[Rukapul]

Je kunt bedrijven ook een custom proprietary license aanbieden. Dat bevat dan het basissysteem + plugins

Dat je het basissysteem daarnaast onder de GPL aanbiedt staat daar compleet los van (dual licensing).

Overigens kun je het basissysteem ook onder de LPGL licenseren en per plugin bepalen wat voor license je er aan hangt. Je doet er dan wel verstandig aan om een opmerking toe te voegen aan de LGPL license waarin jij de grenzen van de 'libary' (=het basissysteem) definiteert teneinde duidelijk te maken dat plugins niet onder de LGPL vallen.

[eamelink]

Allereerst moet je onderscheid maken tussen wat er mag en wat er kan. Als je je software onder de GPL uitgeeft kan jouw klant het niet alleen kopiëren, wijzigen en doorverkopen, maar het mág ook. Als jij geen OS licentie meegeeft en niet codeert, dan kán het nog steeds, maar mag het niet. Daarmee voorkom je dus dat jouw klant het ook open en bloot aanbiedt aan derden

Verder staat het je vrij om het spul onder meerdere licenties aan te bieden, zolang jij het auteursrecht draagt van alles. Dus degenen die de GPL versie willen mogen die downloaden, degenen die een andere licentie willen en daarvoor willen betalen kunnen dat ook krijgen

Als het basissysteem GPL is en er hebben ook andere personen aan meegewerkt dan wordt het lastiger, want dan heb jij niet het auteursrecht en kan je niet beslissen dat jij het aan een bepaalde klant samen met wat closed source plugins onder een andere licentie verkoopt

[mithras]

Rukapul schreef op dinsdag 10 april 2007 @ 21:27:
Je kunt bedrijven ook een custom proprietary license aanbieden. Dat bevat dan het basissysteem + plugins

Dat je het basissysteem daarnaast onder de GPL aanbiedt staat daar compleet los van (dual licensing).

Overigens kun je het basissysteem ook onder de LPGL licenseren en per plugin bepalen wat voor license je er aan hangt. Je doet er dan wel verstandig aan om een opmerking toe te voegen aan de LGPL license waarin jij de grenzen van de 'libary' (=het basissysteem) definiteert teneinde duidelijk te maken dat plugins niet onder de LGPL vallen.

Dual licensing klinkt inderdaad wel leuk. Dan wordt het total vrijgegeven onder de GPL.

Wil je extra dingen op maat? Dan is het basissysteem LGPL gelicenseerd en alle aparte plugins ook LGPL of een closed source licentie waarbij je zelf het niet mag doorontwikkelen en/of verkopen.

eamelink schreef op dinsdag 10 april 2007 @ 21:36:
Allereerst moet je onderscheid maken tussen wat er mag en wat er kan. Als je je software onder de GPL uitgeeft kan jouw klant het niet alleen kopiëren, wijzigen en doorverkopen, maar het mág ook. Als jij geen OS licentie meegeeft en niet codeert, dan kán het nog steeds, maar mag het niet. Daarmee voorkom je dus dat jouw klant het ook open en bloot aanbiedt aan derden

Ok, daar was ik naar op zoek: een OS licentie geeft je het recht om wel er zelf mee door te gaan. Een closed source niet: hoewel je de broncode hebt is het eigenlijk niet toegestaan dus.

Als het basissysteem GPL is en er hebben ook andere personen aan meegewerkt dan wordt het lastiger, want dan heb jij niet het auteursrecht en kan je niet beslissen dat jij het aan een bepaalde klant samen met wat closed source plugins onder een andere licentie verkoopt

Dat is niet het geval: ik ben de enige ontwikkelaar, en ook voor deze klant zal dat zo blijven.

[EfBe]

Licenses gaan over distributie en gebruik. Jij als eigenaar van de code kan doen wat je wilt met de code, dus ook gebruiken voor een klant en daar geen GPL aan hangen. Het punt is nl, dat alleen de code die jij ter distributie aanbiedt GPL-ed is. Een exact dezelfde bak met code die je in een andere folder hebt staan kan wel een andere license hebben, het gaat om de distributie.

GPL is voor libraries beroerd en voor totale systemen die andere libs consumen weer OK. Voor libraries is het beroerd want door de GPL wordt de gebruikende app van de library ook GPL-ed. Dit is iets wat je niet echt wilt vaak. LGPL voor libraries is dan ook beter.

Maar in jouw geval is er niets aan de hand, je kunt doen en laten wat je wilt met jouw code. Het is nl. JOUW code, dus of jij dat nu 300 keer released onder een andere license, boeie...

[MSalters]

GPL voor libraries is een serieuze optie. De FSF ziet het zelfs als de regel, en LGPL als de uitzondering.

@TS: dual-licensing is inderdaad een optie, als je inderdaad nergens GPL-code hebt geleend.

Plugins staan in principe los van je applicatie en de eventuele GPL. Als jij (als enige copyright-owner) expliciet zegt dat plugins niet automatisch onder de GPL vallen, dan doen ze dat niet. Voorbeeld: Torvalds zei dat expliciet over Linux programma's, en de consensus is dat (los van andere redenen) die uitspraak juridisch voldoende is. Er is in elk geval geen rechterlijke uitspraak die iets anders beweert. Het is een beetje vager of je het omgekeerde kunt stellen, dat plugins automatisch onder de GPL vallen. Dat hangt namelijk af van de definitie "samengesteld werk", en dat is nationale copyright wetgeving.

Support kun je zelfs voor Linux verkopen; het hoeft niet eens je eigen GPL software te zijn.

[Confusion]

mithras schreef op dinsdag 10 april 2007 @ 21:01:
• En dan een hele andere vraag: is het uberhaupt wel mogelijk om php scripts closed source te maken, zonder de Zend Encoder à $2400 te gebruiken? En dan wil ik eigenlijk ook niet die andere optimizers gebruiken die iemand dan specifiek moet installeren voor mijn systeem. Volgens mij heb ik dan namelijk gewoon pech gehad. Ik kan wel de plugin closed source (met een licentie) maken, mijn klant kan de code rippen en er zelf gewoon mee doorgaan toch?

In de praktijk kan dat, maar het is niet legaal en je kan dus juridische stappen ondernemen. Als een goede verstandhouding met jou in hun belang is, dan zullen ze dat niet doen.

Je kan ook overwegen ze de code in licentie te geven voor een bedrag dat dusdanig hoog is dat ze er daarna mee mogen doen wat ze willen.

[Verwijderd]

Ik denk dat je niet echt dual-licencing nodig hebt.

Wat je wilt is dat mensen je systeem mogen gebruiken, kopiëren, aanpassen, en distribueren, als het maar vrij blijft. Dat is wat je kan met GPL.

Verder wil je dat men plugins mag maken die non-free zijn. Dit mag niet van de GPL, maar wel van de LGPL.

De LGPL maakt ook alles mogelijk dat de GPL mogelijk maakt; dual-licencing van GPL en LGPL is dus overbodig. De vereninging tussen LGPL en GPL resulteert in LGPL.

Als je wilt dat alleen jij non-free plugins mag maken, dan hoef je het alleen te releasen onder de GPL. Als een klant een non-free plugin van je koopt, dan bundel je die met je CMS, waarbij je alleen aan die klant een gebruikslicentie geeft. Dit kan alleen als je geen plagiaat hebt 'gepleegd' op GPL-code, want dat mag alleen onder de GPL uitgegeven worden.

[ Voor 9% gewijzigd door Verwijderd op 11-04-2007 23:16 ]

[Not Pingu]

Een BSD-licentie lijkt me een goede optie. Die biedt nog steeds het gedachtengoed achter open source, maar dan zonder het dwingende aspect van de (L)GPL. En niets let je om precies dezelfde code (of met kleine wijzigingen) uit te brengen onder een andere licentie.

Bijv. Dotnetnuke maakt daar gebruik van, en dat is een CMS/portal framework dat toch een aardig commercieel succes geniet. Het is hiermee goed mogelijk om het framework als basis van een apart pakket te gebruiken, waaraan je klantspecifieke modules toevoegt.

[ Voor 36% gewijzigd door Not Pingu op 11-04-2007 23:18 ]

[MSalters]

Verwijderd schreef op woensdag 11 april 2007 @ 23:09:
Ik denk dat je niet echt dual-licencing nodig hebt.

Wat je wilt is dat mensen je systeem mogen gebruiken, kopiëren, aanpassen, en distribueren, als het maar vrij blijft. Dat is wat je kan met GPL.

Verder wil je dat men plugins mag maken die non-free zijn. Dit mag niet van de GPL, maar wel van de LGPL.

Feitelijk onjuist; de TS zit namelijk aan de kant waarbij hij mag bepalen of plugins in een GPL systeem het geheel onder de GPL brengen. Als de TS zegt :"CMS+plugins is een collectie, en geen samengesteld werk", dan mag dat (hij is copyright eigenaar van het CMS en bepaalt de plugin interface). Het gevolg van collectie ipv samengesteld werk is dat de delen van een collectie hun eigen licenties houden.

Zelfs als de TS non-GPL plugins had willen verbieden, is het de vraag of de GPL voldoende is. De TS kan namelijk wel stellen dat CMS+plugins een collectie is, maar niet noodzakelijk dat het een samengesteld werk is. In het eerste geval ziet de TS af van een recht (wat altijd mag); in het laatste geval eist de TS een recht wat hij wettelijk mogelijk niet heeft.

De LGPL maakt ook alles mogelijk dat de GPL mogelijk maakt; dual-licencing van GPL en LGPL is dus overbodig. De vereninging tussen LGPL en GPL resulteert in LGPL.

Feitelijk onjuist; de vereniging levert de GPL omdat de meest restrictieve licentie geldt.

Als je wilt dat alleen jij non-free plugins mag maken, dan hoef je het alleen te releasen onder de GPL. Als een klant een non-free plugin van je koopt, dan bundel je die met je CMS, waarbij je alleen aan die klant een gebruikslicentie geeft. Dit kan alleen als je geen plagiaat hebt 'gepleegd' op GPL-code, want dat mag alleen onder de GPL uitgegeven worden.

Dat is dus allemaal subtiel, want op dat moment wordt het de vraag of of CMS+plugins een collectie of een samengesteld werk is. ZIt er GPL code van derden in, dan is de beslissing niet meer alleen aan de TS. Het kan nog steeds zo zijn - met name als de TS de plugin interface handig kiest - dat CMS+plugins een collectie wordt, en dan kan de TS dus niet-GPL plugins maken.

[ Voor 9% gewijzigd door MSalters op 12-04-2007 23:38 ]

[Verwijderd]

Als je CMS GPL is, dan kunnen plugins alleen maar GPL zijn. Afgeleide werken van GPL-software moeten ook GPL zijn.

En als een programma (de plugin) een ander programma (het CMS) nodig heeft om te werken, dan is het een afgeleid werk. Als dat niet het geval zou zijn, dan zou een diff-file op de Linux-kernel met een proprietary licentie ook legaal zijn. Dan heeft de hele GPL geen zin meer.

Er wordt dacht ik bij de GPL van de GNU binutils specifiek een uitzondering gemaakt op die regel, zodat je wel proprietary programma's ermee mag builden en draaien. Anders zou je free- en non-free software helemaal niet kunnen mixen op een GNU systeem.

[MSalters]

Ah - maar de TS heeft de controle over de plugin interface. Als je die zo generiek maakt dat meerdere CMSsen gebruik zouden kunnen maken van dezelfde plugin, dat wordt die ene plugin geen GPL puur omdat één van die CMSsen toevallig GPL is.

[ATS]

Dual licencing is echt niet zo heel ingewikkeld. Kijk bijvoorbeeld eens naar hoe Trolltech Qt heeft gelicenceerd. Deze is te verkrijgen onder GPL, maar ook onder een propriety licence. Deze laatste biedt meer beschikbare plugins en mag gebruikt worden voor commercieële doeleinden. Met de GPL versie mag alleen GPL software gemaakt worden. Simpel en effectief.

[Verwijderd]

Misschien mierenneuken, maar de GPL verbiedt geen commercieële doeleinden, anders zouden bedrijven zoals Red Hat nogal een probleem hebben.

[mithras]

Verwijderd schreef op zondag 22 april 2007 @ 01:16:
Misschien mierenneuken, maar de GPL verbiedt geen commercieële doeleinden, anders zouden bedrijven zoals Red Hat nogal een probleem hebben.

Maar wel dat onderdelen closed source zijn. Ik ben er nu wel min of meer uit. Hert zal een dual license worden, met standaard de GPL.

Wordt mij gevraagd iets commercieel "bij te klussen", gaat het basissysteem (fundament + standaard plugins) in een LGPL hoesje en kunnen de losse plugins closed source gelicenceerd worden.

Dank voor alle tips qua mogelijkheden trouwens

[Verwijderd]

Nog een aantal dingen om te bedenken:
[list]
• Zodra andere mensen bijdragen aan de GPL-software, kan die branch niet meer zomaar geher-licencieerd worden naar LGPL door jou. LGPL naar GPL kan wel.
• De proprietary-onderdelen kunnen niet zomaar 'ingewoven' worden in de software. De proprietary plugins mogen alleen gebruik maken van functies uit de LGPL-ed software. Andersom dus niet.
• Iedereen met een kopie van de GPL-ed software, mag deze aan iedereen geven. Iedereen met een kopie van de LGPL-ed software, mag deze aan iedereen geven. Iedereen mag dus doen wat ze willen (en mogen volgens de licentie) met beide branches.
Ik vraag me af waarom je niet gewoon alleen voor LGPL kiest.

Oja, en voordat je het released, lees de licenties even door.

[engelbertus]

als je het onder de bsd licentie doet voor betalende klanten dan krijgen ze wel de source, maar is het dus wel een gesloten programma, dus zeg maar gewoon jou eigendom.
dan kun je het algemene deel onder de gpl aanbieden zodat iemand die die versie wil gebruiken er ook wat mee mag doen, en wijzigingen weer vrij moet geven. diegene kan dan alsnog beslissen dat hij het alleen voor zichzelf gebruikt. maar zodra hij het wel aan iemand geeft, al was het zijn moeder, dan heeft zijn moeder wel weer het recht het gratis aan te bieden aan iedereen die het wil ( of tegen betaling)

de bsd licentie verhendert dat. als jij het aan iemand geeft onder de bsd licentie ( en zolang jij de auteur bent, kan dat) kan de ontvnger het niet verder distribueren, en mag die het zelf ook niet wijzigen.

hoe je de licentie dan vorm moet geven dat iemand de software bug vrij kan maken weet ik zo snel niet, maar het lijkt me dan da diegene bijvoorbeeld de fouten aangeeft en jij de aanpassingen in de software doet. je kunt hem dan bijvoorbeeld toestaan voor testdoeleinden zelf de source aan te passen, dan heeft diegene dus niet het rect dat te puliceren. hij mag dat testen onder een gesliten bsd licentie immers niet doen, officieel.
of je stelt een soort voorwaarde op dat degene die de software bugfree moet maken zeg maar voor jou werkt, en zodoende de source wel mag aanpassen omdat hij dan niet de bsd licentie gebruikt, maar meer gewoon werkt als een microsoft programeur, die heeft ook geen rechten als auteur van code.

[Verwijderd]

De originele BSD-licentie stelt dat je het mag gebruiken en herdistribueren zolang je de copyright-houder noemt bij reclame, documentatie, en in de source. De BSD-licentie verplicht niet de source openbaar te maken, maar verbiedt dit ook niet.

Omdat vooral de reclame-clausule nogal een praktisch probleem wordt als er 10.000en mensen aan werken, is er een aangepaste BSD-licentie gekomen, waarin dat dus niet hoeft.

http://en.wikipedia.org/wiki/BSD_license

De 3-clause BSD-licentie is dus eigenlijk bijna public domain, behalve dat in de source moet blijven staan dat het BSD-gelicencieerd is, en dus door iedereen onder die voorwaarde mag worden verder gedistribueerd.

[ Voor 32% gewijzigd door Verwijderd op 22-04-2007 13:47 ]

[Borromini]

Verwijderd schreef op vrijdag 13 april 2007 @ 02:45:
Als je CMS GPL is, dan kunnen plugins alleen maar GPL zijn. Afgeleide werken van GPL-software moeten ook GPL zijn.
[...]

Er wordt dacht ik bij de GPL van de GNU binutils specifiek een uitzondering gemaakt op die regel, zodat je wel proprietary programma's ermee mag builden en draaien. Anders zou je free- en non-free software helemaal niet kunnen mixen op een GNU systeem.

Als dat voor binutils zo is, dan moet dat toch voor de hele GNU toolchain zo zijn? Voor zover ik weet kan je met de GNU (en dus GPL) toolchain perfect closed source software compileren. Ik denk niet dat gecompileerde binaries onder 'afgeleide software' vallen, want dan is je hele GNU/Linux systeem gewoon afgeleide software (!). Dat lijkt me een beetje vreemd - maar ik kan natuurlijk mis zijn.

Wat de CMS betreft: ik denk dat je de situatie een beetje kan vergelijken met de binaire drivers van ATi en nVidia (alhoewel het hier natuurlijk een stuk soepeler is, de TS kan zijn licenties volledig vrij kiezen aangezien hij eigenaar is van alle code).
Die drivers hebben de kernel nodig om te draaien (en de kernelsources om te compileren), en er is zware discussie of dit soort trucjes (binary blobs, zoals ze genoemd worden) nu moet worden onmogelijk gemaakt of niet...

De plugins van de CMS kunnen niet draaien zonder de CMS zelf, dus misschien dat die kwestie inderdaad wel aan de orde is hier.

Nu, mocht je er niet uit raken, of twijfels blijven hebben, je kan altijd je licht opsteken bij de Free Software Foundation, die helpen je met plezier .

[ Voor 5% gewijzigd door Borromini op 22-04-2007 13:50 ]

[Confusion]

Verwijderd schreef op vrijdag 13 april 2007 @ 02:45:
Als je CMS GPL is, dan kunnen plugins alleen maar GPL zijn. Afgeleide werken van GPL-software moeten ook GPL zijn.

En als een programma (de plugin) een ander programma (het CMS) nodig heeft om te werken, dan is het een afgeleid werk. Als dat niet het geval zou zijn, dan zou een diff-file op de Linux-kernel met een proprietary licentie ook legaal zijn. Dan heeft de hele GPL geen zin meer.

Ieder linux programma heeft de linux kernel nodig om te werken. Die hoeven toch ook niet allemaal onder de GPL licentie te worden vrijgegeven?

MSalters schreef op vrijdag 13 april 2007 @ 22:52:
Ah - maar de TS heeft de controle over de plugin interface. Als je die zo generiek maakt dat meerdere CMSsen gebruik zouden kunnen maken van dezelfde plugin, dat wordt die ene plugin geen GPL puur omdat één van die CMSsen toevallig GPL is.

Zolang je maar een interface definieert waarvan de plugin gebruik maakt, dan staat het andere CMS'en toch vrij dezelfde interface te implementeren?

Iets hoeft toch pas onder de GPL te worden vrijgegeven als hetgeen gedistribueerd wordt ge-GPL'de code bevat?

[EfBe]

Confusion schreef op zondag 22 april 2007 @ 19:21:
[...]

Ieder linux programma heeft de linux kernel nodig om te werken. Die hoeven toch ook niet allemaal onder de GPL licentie te worden vrijgegeven?

Volgens mij bevat de Linux license daar een expliciete uitzondering voor.

[...]
Iets hoeft toch pas onder de GPL te worden vrijgegeven als hetgeen gedistribueerd wordt ge-GPL'de code bevat?

Nee, het is stricter: als de code linkt naar een GPL-ed library, dan moet je de code onder de GPL distribueren.

[Confusion]

EfBe schreef op maandag 23 april 2007 @ 08:56:
Volgens mij bevat de Linux license daar een expliciete uitzondering voor.

Dan is die uitzondering ook een oplossing voor de topicstarter. Maar zoals DOT schreef

Als dat niet het geval zou zijn, dan zou een diff-file op de Linux-kernel met een proprietary licentie ook legaal zijn. Dan heeft de hele GPL geen zin meer.

Nee, het is stricter: als de code linkt naar een GPL-ed library, dan moet je de code onder de GPL distribueren.

Tjah, maar hoe is 'linken naar' gedefinieerd? Als je in Java een bepaalde library met een import binnenhaalt, dan link je er waarschijnlijk wel rechtstreeks naar, maar wat als je een interface importeert en middels een config file een instantie van een library die die interface implementeert injecteert en vervolgens alleen de naam van een library geeft die gebruikt zou kunnen worden en die niet meelevert?

[MSalters]

Linken is een technische term, geen juridische, en tot op zekere hoogte heeft de originele ontwerper van een link-proces de vrijheid om te bepalen wat de juridische consequenties van een dergelijke linkstap zijn (afgeleid werk of samenstelling).

[MSalters]

Verwijderd schreef op vrijdag 13 april 2007 @ 02:45:
Als je CMS GPL is, dan kunnen plugins alleen maar GPL zijn. Afgeleide werken van GPL-software moeten ook GPL zijn.

Ik had er in eerste instantie overheen gelezen, maar dit is natuurlijk helemaal niet waar. De GPL is een distributie licentie. Je mag een GPL CMS alleen met GPL plugins distribueren, maar de GPL regelt absoluut niets ten aanzien van gebruik. De combinatie van een GPL CMS met een niet-GPL plugin levert in het ergste geval een afgeleid werk op wat niet verder verspreid mag worden.

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted

(Dat staat los van de eerdere vastgestelde mogelijkheden voor de TS: dual-licensing en een soepele definitie van linken)