licenties icm open source

[chielsen]

Ik vraag me af hoe geld te verdienen aan modules die gemaakt zijn voor open source (GPL) systemen.
Je ziet op veel plaatsen mensen die geld vragen voor een module, maar als ik goed lees dan vallen alle modules gemaakt voor GPL software ook onder GPL. Iemand anders mag die dan dus gratis verspreiden.

Hoe pakken jullie dat aan?

En bij Zend Framework zeggen ze dat het een makkelijke commercieele licentie is.
Maar in de licentie staat dat ik de licentievoorwaarden ook weer moet verspreiden en daarin staat dat andere vrij zijn de code te verspreiden. Gaat dat dan alleen over de ZF code, of ook over mijn code?
Zo niet welke licentie moet daarvoor gelden?

[Verwijderd]

Bijvoorbeeld door het leveren van support of via certificering. Kijk bijvoorbeeld naar Red Hat.

[mithras]

Het verschil is of het een (externe) library is of niet. Als je apart linkt naar de library, valt het er niet onder. Als je de code modificeert en verder distribueert zit je er wel mee.

In het geval van Zend moet je dus, als je zelf het ZF gaat verspreiden, ook de licentie meeleveren. Bouw je een applicatie met ZF en verkoop je die, hoef je afaik niet de licentie door te sturen naar je klanten.

Hoe je er geld aan verdient? Bij Zend zit de New BSD license en kan je met gerust hart een applicatie bouwen en die verkopen. Met andere (GPL) projecten zal dat iets moeilijker zijn. Winst kan je maken door je eigen configuratie te installeren en support te bieden.

[ Voor 25% gewijzigd door mithras op 11-11-2009 19:35 ]

[chielsen]

mithras schreef op woensdag 11 november 2009 @ 19:34:
Het verschil is of het een (externe) library is of niet. Als je apart linkt naar de library, valt het er niet onder. Als je de code modificeert en verder distribueert zit je er wel mee.

In het geval van Zend moet je dus, als je zelf het ZF gaat verspreiden, ook de licentie meeleveren. Bouw je een applicatie met ZF en verkoop je die, hoef je afaik niet de licentie door te sturen naar je klanten.

Hoe je er geld aan verdient? Bij Zend zit de New BSD license en kan je met gerust hart een applicatie bouwen en die verkopen. Met andere (GPL) projecten zal dat iets moeilijker zijn. Winst kan je maken door je eigen configuratie te installeren en support te bieden.

Ja het zijn aparte modules, maar in de GPL staat dat als de GPL code functionaliteiten en data deelt dat het ook onder GPL moet vallen. Op de site van drupal valt dan ook te lezen dat modules onder GPL moet worden gepubliceerd.

Bij Zend weet ik dat het onder de New BSD valt, maar de vraag is onder welke licentie mijn code moet vallen om compatible te zijn?

[HuHu]

chielsen schreef op woensdag 11 november 2009 @ 20:24:
[...]


Ja het zijn aparte modules, maar in de GPL staat dat als de GPL code functionaliteiten en data deelt dat het ook onder GPL moet vallen. Op de site van drupal valt dan ook te lezen dat modules onder GPL moet worden gepubliceerd.

Bij Zend weet ik dat het onder de New BSD valt, maar de vraag is onder welke licentie mijn code moet vallen om compatible te zijn?

Kom op man, de licentie bestaat effectief uit een intro, 3 regels belangrijke informatie en nog wat extra dingen. Minder dan een half A4-tje: http://framework.zend.com/license

Samengevat: je mag er mee doen wat je wil, als je het ZF mee levert moet je bij de ZF distributie die license vermelden en je mag je eigen software niet aanprijzen als zijnde gemaakt met/bij/door/van/via Zend.

Dus, je maakt je eigen software, gooit daar de license op die je wil hebben, maar in het library/Zend mapje stop je die license specifiek voor het gedeelte met de Zend code.

[Gomez12]

HuHu schreef op woensdag 11 november 2009 @ 21:12:
[...]
Dus, je maakt je eigen software, gooit daar de license op die je wil hebben, maar in het library/Zend mapje stop je die license specifiek voor het gedeelte met de Zend code.

Mag dit serieus volgens de zend licentie? Dus als ik hoop pakketten ( met de zend-licentie ) bij elkaar prak en enkel de losse pakketten diep verstop in een vage directory structuur met in de juiste dir de licensie dan is het voldoende?

Want dan creeer je toch een complete chaos. Je eigen prakje heeft natuurlijk zijn licentie in de hoofddir staan ( oftewel die ziet 99.9% van de mensen enkel als licentie ), daarin verwijs je niet naar de losse licenties, je zegt enkel dat er per onderdeel mogelijk andere licenties gelden ( in het meest kleine lettertype en de meest juridische taal die je kan vinden )

[Freeaqingme]

Gomez12 schreef op woensdag 11 november 2009 @ 21:29:
[...]

Mag dit serieus volgens de zend licentie? Dus als ik hoop pakketten ( met de zend-licentie ) bij elkaar prak en enkel de losse pakketten diep verstop in een vage directory structuur met in de juiste dir de licensie dan is het voldoende.

Ja Het gaat _enkel_ om de Zend library code, niet om de code die eventueel van ZF gebruik maakt, of waar ZF mee wordt meegescheept.

[DiedX]

chielsen schreef op woensdag 11 november 2009 @ 19:31:
Ik vraag me af hoe geld te verdienen aan modules die gemaakt zijn voor open source (GPL) systemen.
Je ziet op veel plaatsen mensen die geld vragen voor een module, maar als ik goed lees dan vallen alle modules gemaakt voor GPL software ook onder GPL. Iemand anders mag die dan dus gratis verspreiden.

Hoe pakken jullie dat aan?

En bij Zend Framework zeggen ze dat het een makkelijke commercieele licentie is.
Maar in de licentie staat dat ik de licentievoorwaarden ook weer moet verspreiden en daarin staat dat andere vrij zijn de code te verspreiden. Gaat dat dan alleen over de ZF code, of ook over mijn code?
Zo niet welke licentie moet daarvoor gelden?

Volgens mij klopt dat niet helemaal. Zover ik weet (maar: correct me if I'm wrong) MOET je je broncode openen op het moment dat je gebruik maakt van (delen van) de broncode die gebruik maakt van de GPL(2). Ik heb het hier over de "oude" GPL, niet de GPL-3:

2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

Als dus je eigen programma niet gebaseerd is op (delen van) GPL-code, maar volledig zelf bedacht is (voor zover dat kan in de OSS wereld!) dan mag je dat gewoon closed-source houden.

Let wel: ik heb het hier *NIET* over het linken naar libraries. Daar is weer wat anders voor, maar dat kan je prima zelf lezen: http://www.gnu.org/licenses/gpl-2.0.txt

Verder: de GPL is inderdaad vergif. Het is niet mogelijk om BSD-code met GPL te mengen, aangezien de BSD-code (die "losser" is) dan GPL moet worden.

[HuHu]

Gomez12 schreef op woensdag 11 november 2009 @ 21:29:
[...]

Mag dit serieus volgens de zend licentie? Dus als ik hoop pakketten ( met de zend-licentie ) bij elkaar prak en enkel de losse pakketten diep verstop in een vage directory structuur met in de juiste dir de licensie dan is het voldoende?

Want dan creeer je toch een complete chaos. Je eigen prakje heeft natuurlijk zijn licentie in de hoofddir staan ( oftewel die ziet 99.9% van de mensen enkel als licentie ), daarin verwijs je niet naar de losse licenties, je zegt enkel dat er per onderdeel mogelijk andere licenties gelden ( in het meest kleine lettertype en de meest juridische taal die je kan vinden )

Ja, dat staat er. Het zijn maar 3 punten, waarvan er slechts 2 van toepassing zijn. Zo moeilijk is het niet.

[Nick_S]

DiedX schreef op woensdag 11 november 2009 @ 22:27:
Verder: de GPL is inderdaad vergif. Het is niet mogelijk om BSD-code met GPL te mengen, aangezien de BSD-code (die "losser" is) dan GPL moet worden.

De GPL is geen vergif, maar een manier om de vrijheid van de gebruiker te waarborgen. Als jij andere "vrijheden" als dat de GPL voorschijft wil waarborgen naar jouw gebruikers, vind ik het niet meer dan fair als je dan niet de code gebruikt die geschreven is door programmeurs die dat wel willen. Je maakt nog altijd vrijwillig gebruik van GPL code en als je je daar niet in kan vinden, blijf er dan van weg. You can't eat your cake and have it too.

[Gomez12]

freakingme schreef op woensdag 11 november 2009 @ 22:12:
[...]
Ja Het gaat _enkel_ om de Zend library code, niet om de code die eventueel van ZF gebruik maakt, of waar ZF mee wordt meegescheept.

Tja, vaag dan dat je het niet ergens algemeen ( bijv je eigen license file ) moet melden. Dit vraagt wmb om misbruik ( we encrypten ons hele pakket en alle afhankelijkheden, dus ook ZF, maar als je het unencrypted bekijkt ( bijv in je RAM ) dan staat daar de license file, oftewel wij voldoen aan de licentie eis )

DiedX schreef op woensdag 11 november 2009 @ 22:27:
[...]
Verder: de GPL is inderdaad vergif. Het is niet mogelijk om BSD-code met GPL te mengen, aangezien de BSD-code (die "losser" is) dan GPL moet worden.

GPL is ietwat moeilijk, maar vergif is een groot woord.

Je zou bijv een interface kunnen maken die samenwerkt met de GPL-code, deze zet een bestand ergens klaar, je BSD-code pikt het bestand weer op, verwerkt dit en voert het weer aan je interface.
Heb je enkel een GPL-interface nodig.

Voldoet perfect aan de GPL license ( of is het bewerken van een csv-bestand geproduceerd door een GPL-product in excel en het daarna weer terugvoeren ook al illegaal ) en heeft gelijk als voordeel dat mensen dingen leren te scheiden zodat een ander product ook weer gebruik kan maken van die interface.

Wat je specifieke voorbeeld betreft qua BSD / GPL zie ik al helemaal weinig problemen, BSD staat afaik relicensing toe ( waardoor je het ook kan gebruiken in closed source etc ), als je ook maar 1 regel code moet veranderen heb je een aparte versie. Die specifieke versie heeft vanaf dat moment een GPL licentie.
In je BSD versie kun je nog steeds alles aanpassen / distribueren en copy-pasten naar je GPL versie. Enkel je kan het niet andersom doen, maar zolang jij zorgt dat je alle aanpassingen onder je BSD versie doet en enkel copy paste naar je GPL versie dan gaat alles goed

In pure theorie zou je in de problemen komen als je een quick-fix maakt in de GPL versie omdat je dan die code niet mag copieren naar je BSD-versie ( volgens mij mag je het zelfs niet overtikken / nabouwen ) maar in de praktijk gebeurt dit inhouse en zolang je niet consequent je GPL-versie 2 dagen voor je BSD-versie released ( zonder code wijzigingen ) gok ik dat er geen haan naar kraait ( en zelfs 2 dagen valt nog wel te verkopen door te zeggen dat je je bsd-code beter test )
In een discussie met een fanaticus als Stallman zal je misschien een probleem hebben, maar 99,99999% van de vakmensen snapt echt wel hoe de wereld werkt

[danslo]

Code die gebruik maakt van een GPL licensed library moet nog steeds onder de GPL gereleased worden:

If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL or a GPL-compatible license?

Yes, because the program as it is actually run includes the library.

Tenzij de code onder de LGPL is gelicensed (alleen gemodificeerde LGPL code moet vrijgegeven worden):

If I distribute a proprietary program that links against an LGPLv3-covered library that I've modified, what is the “contributor version” for purposes of determining the scope of the explicit patent license grant I'm making—is it just the library, or is it the whole combination?

The “contributor version” is only your version of the library.

[Grijze Vos]

Daar is niet iedereen het over eens. Als je dynamisch linked hoeft het niet per se zo te zijn dat je een derivative work hebt gemaakt:

http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works

A key dispute related to the GPL is whether or not non-GPL software can be dynamically linked to GPL libraries. The GPL is clear in requiring that all derivative works of code under the GPL must themselves be under the GPL. While it is understood that static linking produces derivative works, it is not clear whether an executable that dynamically links to a GPL code should be considered a derivative work (see Weak Copyleft). The free/open-source software community is split on this issue.

The FSF asserts that such an executable is indeed a derivative work if the executable and GPL code "make function calls to each other and share data structures",[28] with certain others agreeing (e.g. Jerry Epplin[29]), while some (e.g. Linus Torvalds) agree that dynamic linking can create derived works but disagree over the circumstances.[30] On the other hand, some experts have argued that the question is still open: one Novell lawyer has written that dynamic linking not being derivative "makes sense" but is not "clear-cut",[31] but that evidence for good-intentioned dynamic linking can be seen by the existence of proprietary Linux kernel drivers.

Lawrence Rosen has claimed that a court of law would "probably" exclude dynamic linking from derivative works although "there are also good arguments" on the other side and "the outcome is not clear"[32] (on a later occasion, he argued that "market-based" factors are more important than the linking technique[33]). This is ultimately a question not of the GPL per se, but of how copyright law defines derivative works. In Galoob v. Nintendo the Ninth Circuit Court of Appeals defined a derivative work as having "'form' or permanence" and noted that "the infringing work must incorporate a portion of the copyrighted work in some form", but there have been no clear court decisions to resolve this particular conflict.

Gomez12 schreef op woensdag 11 november 2009 @ 23:42:
[...]

Tja, vaag dan dat je het niet ergens algemeen ( bijv je eigen license file ) moet melden. Dit vraagt wmb om misbruik ( we encrypten ons hele pakket en alle afhankelijkheden, dus ook ZF, maar als je het unencrypted bekijkt ( bijv in je RAM ) dan staat daar de license file, oftewel wij voldoen aan de licentie eis )

Euhm, nee. Je moet de licentie ongewijzigd includen..

[ Voor 10% gewijzigd door Grijze Vos op 12-11-2009 00:44 ]

[Gomez12]

cls schreef op donderdag 12 november 2009 @ 00:17:
Code die gebruik maakt van een GPL licensed library moet nog steeds onder de GPL gereleased worden:

Zoals ik al eerder schreef is dit redelijk simpel te omzeilen door een interface onder GPL te schrijven en dan met ander gelicenseerde code tegen die interface aan te praten.

Ik durf zo snel even niet te zeggen waar de scheidslijn precies ligt qua mogelijkheden van de interface, maar als je een bestand wegschrijft mag dit rustig door een 3e opgepikt worden.

Zoniet kan je gelijk de hele GPL weggooien, want van ongeveer elk groot closed source pakket is er wel een versie geweest die ooit een bestand geproduceerd door een GPL heeft geopend.

Simpel voorbeeldje, een GPL daemon wat naar netwerkverkeer luistert in een No-GPL os, het OS gebruikt de daemon om de networkstream af te handelen.
Of omgekeerd, een GPL-OS wat een closed-source programma draait, welke code handelt de raw-interfaces van het keyboard / muis af en stuurt dan de resultaten door?
Elk programma onder een GPL-OS gebruikt OS-library's, wil jij even aan alle software fabrikanten melden dat ze geen closed source meer onder een GPL-OS mogen uitbrengen???

[chielsen]

Gomez, dat is niet zo simpel. Als je modules voor drupal maakt dan deel je dus data structuren en doe je functie aanroepen. Ik zie dus niet in hoe dat niet onder GPL kan vallen.
Gewoon puur alle logica in een apart php bestand zetten en dan in de module aanroepen doen met alle relevante data is ook weer een koppeling, of zie ik dat verkeerd?

[DiedX]

chielsen schreef op donderdag 12 november 2009 @ 02:24:
Gomez, dat is niet zo simpel. Als je modules voor drupal maakt dan deel je dus data structuren en doe je functie aanroepen. Ik zie dus niet in hoe dat niet onder GPL kan vallen.

Je maakt niet gebruik van de softwarecode, maar inderdaad wel naar de ideeen van de GPL-Software. Lastig.

Mijn eerdere uitspraak is niet alleen door mij gedaan, en ik heb er zelf weinig mee van doen: ik ben geen programmeur, maar wel een OSS, en dan speciaal FreeBSD aanhanger

[MSalters]

Ik neem aan dat er consensus genoeg is over de mogelijkheid om closed-source software voor Linux te schrijven. Aangezien die zonder enige twijfel functies aanroept uit de GPL kernel, volgt daaruit dat het wel degelijk toegestaan kan zijn.

Ik ben het met je eens dat er een inherent grijs gebied is, want dynamisch linken versus statisch linken is niet zwart-wit. Als een linker alle addressen resolved, maar binaries produceert die gedeeltelijk on-demand geladen worden, is er dan sprake van statisch linken?

[Freeaqingme]

Er zijn mensen die ook beweren dat wanneer je een module schrijft voor een willekeurig GPL-licensed product welke los verspreid wordt ook per se GPL moet zijn omdat het alleen werkt in combinatie met dat GPL licensed product (en 'dus' een deritative work). Of het nou klopt of niet; juist vanwege al dit soort onduidelijkheden, heb ik voor mezelf inmiddels enige tijd besloten absoluut niets aan GPL producten te conctributen of te gebruiken in anderen producten (lang leve new BSD!).

[Mei]

Gomez12 schreef op donderdag 12 november 2009 @ 00:43:
[...]

Zoals ik al eerder schreef is dit redelijk simpel te omzeilen door een interface onder GPL te schrijven en dan met ander gelicenseerde code tegen die interface aan te praten.

Nope. Je interface maakt gebruikt van GPL'ed code en valt zelf dus ook onder de GPL. Als je derde stukje software weer van je interface gebruik maakt moet deze óók GPL zijn. Als je derde stuk software met de interface communiceert door er gewoon een lading XML tegenaan te gooien (wat in principe door elke XML reader begrepen kan worden), dan mag het wél volgens mij.

[Herko_ter_Horst]

Communiceren via data mag inderdaad gewoon, aangezien de GPL alleen betrekking heeft op de software, niet op wat die software produceert.

Enkel gebruik maken van interfaces mag alleen als die interfaces vallen onder "System Libraries", zoals gedefinieerd in de GPL. Hieronder vallen de standaard libraries van het OS, zodat het inderdaad mogelijk is non-GPL code te draaien op een GPL-based OS zoals Linux.

Deze uitzondering geldt dus NIET voor willekeurige andere software. Als je een interface van GPL code gebruikt, is het in elk geval de bedoeling van de FSF dat de aanroepende code óók onder de GPL valt. Of dit ook echt zo is, is uiteindelijk aan de rechter.

[DiedX]

Alleen al het feit dat het zo onduidelijk is is des te meer een reden om de GPL te laten zitten

Serieus: volgens mij moet je gewoon data kunnen zenden en ontvangen met en naar een GPL app. Anders zie ik nog wel rechtzaken komen. Die rechtzaken zijn er al geweest op de source, maar nooit over data...

[Herko_ter_Horst]

DiedX schreef op woensdag 16 december 2009 @ 23:42:
Alleen al het feit dat het zo onduidelijk is is des te meer een reden om de GPL te laten zitten

Serieus: volgens mij moet je gewoon data kunnen zenden en ontvangen met en naar een GPL app. Anders zie ik nog wel rechtzaken komen. Die rechtzaken zijn er al geweest op de source, maar nooit over data...

Mijn reactie niet gezien? De GPL heeft zonder meer geen betrekking op de data die de app produceert (en voordat iemand slim denkt te zijn en een GPL module maakt die de source code van een GPL app als "data" uitspuugt: die vlieger gaat niet op ). Zie de GPL FAQ.

[Gomez12]

Mei schreef op woensdag 16 december 2009 @ 01:25:
[...]
Nope. Je interface maakt gebruikt van GPL'ed code en valt zelf dus ook onder de GPL. Als je derde stukje software weer van je interface gebruik maakt moet deze óók GPL zijn. Als je derde stuk software met de interface communiceert door er gewoon een lading XML tegenaan te gooien (wat in principe door elke XML reader begrepen kan worden), dan mag het wél volgens mij.

Tja, wat zal jij in de knoop komen als ik een xml interface bouw denk ik dan

Of stel nu eens even dat ik non-conformante XML gebruik ( normaal noemen we het gewoon binair, maar dat schijnt niet te mogen XML wel, dus is binair in mijn interfaces hernoemd naar non-conformante XML )

Maar als ik jouw uitleg dus goed begrijp mag ik geen interface bouwen die via het geheugen loopt, maar wel als hij via een XML ( volgens welke definitie ) bestand loopt.
Dus als ik even 2k aan data via een interface wil versturen dan moet ik eerst alle filecaches etc gaan flushen ( want gemiddeld hedendaags systeem laat 2k enkel via het geheugen lopen zolang je het maar snel genoeg oppakt en geen speciale voorzieningen voor opslag opzet )

Om de een of andere reden heb ik toch meer vertrouwen in mijn uitleg dat je interface GPL moet zijn en dat je met niet GPL-software tegen die interface aan mag praten, anders kom je echt in een moeras van definities en mitsen en maren.
Met mijn definitie heb je ook nog ietwat problematiek ( wat is de definitie van een interface ) maar dan houd je in ieder het idee van code die door iedereen gebruikt kan worden ( via de interface ) in stand terwijl je wel enigszins closed source kan combineren met GPL.

Met jouw definitie had alles wat aan het internet hing / gehangen heeft al GPL-infected geweest vanaf het moment dat er 1 GPL programma via internet bereikbaar was.

Herko_ter_Horst schreef op woensdag 16 december 2009 @ 09:46:
Communiceren via data mag inderdaad gewoon, aangezien de GPL alleen betrekking heeft op de software, niet op wat die software produceert.

Enkel gebruik maken van interfaces mag alleen als die interfaces vallen onder "System Libraries", zoals gedefinieerd in de GPL. Hieronder vallen de standaard libraries van het OS, zodat het inderdaad mogelijk is non-GPL code te draaien op een GPL-based OS zoals Linux.

Deze uitzondering geldt dus NIET voor willekeurige andere software. Als je een interface van GPL code gebruikt, is het in elk geval de bedoeling van de FSF dat de aanroepende code óók onder de GPL valt. Of dit ook echt zo is, is uiteindelijk aan de rechter.

Tja, dus een GPL-mailserver die via een GPL-interface mail binnenkrijgt dwingt MS om Exchange GPL te maken? Een Outlook client die contact maakt via een GPL reverse-engineered MAPI-protocol met een GPL Groupware server die zorgt er even voor dat Outlook GPL wordt...

Ik begin echt te begrijpen waar de gedachte dat GPL een letterlijke plaag is die uitgeroeid moet worden vandaan komt, interfaces zijn er om tegenaan te praten door iedereen en alles, niet om te infecteren.

Als het FSF echt via interfaces wil infecteren dan mogen ze van mij zo snel mogelijk van de aardbodem verdwijnen. Dan zijn ze echt geflipt

[Herko_ter_Horst]

Datauitwisseling van een GPL-programma valt NIET onder de GPL (zoals ik inmiddels al 2 keer eerder heb gezegd, zie ook - nogmaals - de FAQ entry over de output van een GPL programma).

Ik weet niet wat ik me voor zou moeten stellen bij de GPL-interface van een mailserver. Mail wordt in het algemeen uitgewisseld via een protocol: de code van de mailclient roept nooit rechtstreeks code van de mailserver aan, er wordt slechts data naar een poort gestuurd en via dezelfde of een andere poort komt data terug.

Voor de duidelijkheid: met interfaces bedoel ik dus de API van een softwarebibliotheek, en NIET een protocol-"interface", user-"interface", xml-"interface" of wat dan ook.

De bedoeling van de GPL is heel simpel: iets wat GPL is, moet GPL blijven. De voorwaarden van de GPL zijn er dus op gericht dat je niet "stiekem" GPL-code verpakt in proprietary software o.i.d. De GPL heeft uitsluitend betrekking op het dupliceren, modificeren en vervolgens weer verspreiden van de software, niet op het gebruik ervan. Bij het uitwisselen van data via een protocol of een XML file of wat dan ook verspreid je de software niet, dus de GPL is niet van toepassing.

De GPL is geboren vanuit een extremistische open source visie, die weliswaar lang niet altijd even praktisch is, maar waar niets "evil" aan is (en al helemaal niet zozeer dat het "uitgeroeid" zou moeten worden). Niemand verplicht je jouw software op GPL software te baseren. En zolang je geen GPL-based software verspreidt, heb je sowieso nergens last van. Doe je dat wel, dan is het onder GPL uitbrengen van jouw code de prijs die je betaalt voor het gratis gebruik van de oorspronkelijke code.

[ Voor 121% gewijzigd door Herko_ter_Horst op 17-12-2009 01:18 ]

[Gomez12]

Herko_ter_Horst schreef op donderdag 17 december 2009 @ 00:18:
Voor de duidelijkheid: met interfaces bedoel ik dus de API van een softwarebibliotheek, en NIET een protocol-"interface", user-"interface", xml-"interface" of wat dan ook.

Yep, dat bedoelde ik ook. Daarom zei ik in 1e instantie ook : Jij maakt een GPL-interface die babbelt met de GPL-software API en je closed source software babbelt weer via je eigen opgestelde API met je GPL-interface et voila, je bent for all practical purposes om de GPL heen.

Kost je enkel 1 GPL interface bouwen.

De bedoeling van de GPL is heel simpel: iets wat GPL is, moet GPL blijven. De voorwaarden van de GPL zijn er dus op gericht dat je niet "stiekem" GPL-code verpakt in proprietary software o.i.d. De GPL heeft uitsluitend betrekking op het dupliceren, modificeren en vervolgens weer verspreiden van de software, niet op het gebruik ervan. Bij het uitwisselen van data via een protocol of een XML file of wat dan ook verspreid je de software niet, dus de GPL is niet van toepassing.

Tja, imho is menig andere license hier veel beter in dan de GPL, het enige wat de GPL meer biedt is dat menig developer krom moet gaan programmeren om maar niet rechtstreeks met de API in contact te komen.

De GPL is geboren vanuit een extremistische open source visie, die weliswaar lang niet altijd even praktisch is, maar waar niets "evil" aan is (en al helemaal niet zozeer dat het "uitgeroeid" zou moeten worden).

Tja, hetzelfde kan je zeggen van communisme, maar de praktijk is ook daar niet echt geweldig...

Niemand verplicht je jouw software op GPL software te baseren. En zolang je geen GPL-based software verspreidt, heb je sowieso nergens last van.

Dus wel, als ik een goede valuable toevoeging voor een GPL-programma zou schrijven / een GPL-programma wil integreren in mijn bestaande software en ik wil zelf niets onder GPL uitbrengen dan kom ik in de knoei, ik wens geen GPL te verspreiden, maar de GPL dwingt me om of dubbel te gaan liggen of mijn software GPL te maken.

[Herko_ter_Horst]

Gomez12 schreef op donderdag 17 december 2009 @ 01:16:
[...]

Yep, dat bedoelde ik ook. Daarom zei ik in 1e instantie ook : Jij maakt een GPL-interface die babbelt met de GPL-software API en je closed source software babbelt weer via je eigen opgestelde API met je GPL-interface et voila, je bent for all practical purposes om de GPL heen.

Kost je enkel 1 GPL interface bouwen.

Maar dan bedoel je dus iets anders met "GPL-interface", want als het een software API is, gaat je dit niet om de GPL heen helpen. Jouw tussen-API moet namelijk GPL zijn, want hij roept de oorspronkelijke API rechtstreeks aan = derivative work van een GPL library => GPL verplicht voor de tussen-API. De code die jouw tussen-API aanspreekt moet dus óók GPL zijn, want jouw tussen-API is GPL.

Tja, imho is menig andere license hier veel beter in dan de GPL, het enige wat de GPL meer biedt is dat menig developer krom moet gaan programmeren om maar niet rechtstreeks met de API in contact te komen.

Nee, dan begrijp je het verkeerd. GPL is niet hetzelfde als een willekeurig andere open source licentie. Alleen GPL is zo extreem in het afdwingen van zichzelf. Andere open source licenties staan meer toe, ook aan niet-open source software. De GPL heeft specifiek als doel de GPL-visie op open source/free software af te dwingen. Veel andere licenties hebben tot doel de software voor zoveel mogelijk mensen beschikbaar te maken. Er is geen andere licentie zo goed in het afdwingen van open source als de GPL. De GPL is gebaseerd op het idee dat closed source evil is, dus doen ze alles om te voorkomen dat iets wat GPL is ooit closed source kan worden.

Dus wel, als ik een goede valuable toevoeging voor een GPL-programma zou schrijven / een GPL-programma wil integreren in mijn bestaande software en ik wil zelf niets onder GPL uitbrengen dan kom ik in de knoei, ik wens geen GPL te verspreiden, maar de GPL dwingt me om of dubbel te gaan liggen of mijn software GPL te maken.

En wie dwingt je daar toe? Als jij een goede uitbreiding op een closed source programma hebt, krijg je het helemaal niet voor elkaar die toegevoegd te krijgen én (legaal) te verspreiden, tenzij je alle rechten op die software koopt. De prijs is dan geld. Jij kiest of het je dat waard is. Bij GPL is de prijs die je betaalt, dat je jouw software onder de GPL moet uitbrengen. Jij kiest of het je dat waard is.

Er zijn dus 2 opties:
- je wilt jouw software baseren op GPL software (blijkbaar omdat die iets oplost wat je niet zelf wilt maken of elders kunt krijgen) en vervolgens wil je de boel verspreiden. Dan heb je je te houden aan de voorwaarden van de GPL, dat is de prijs die je betaalt.
- je wilt alleen maar iets bijdragen aan een GPL software project. Wat is dan het probleem? Waarom zou je dat niet onder de GPL doen?

[ Voor 3% gewijzigd door Herko_ter_Horst op 17-12-2009 01:47 ]

[Vinnienerd]

Dus strikt gezien zou ik als ik een closed-source programma schrijf, wat dynamisch gelinkt wordt aan een onder GPL uitgegeven library, hiervan de source vrij moeten geven? Dat is toch idioot? En dat houdt toch nooit stand in de rechtszaal?

[Freeaqingme]

Waarom niet? Het is jouw keuze om dat te doen. Het is niet alsof iemand je dwingt dat te linken om vervolgens te verspreiden.

[Herko_ter_Horst]

Waarom is dat idioot? Jij maakt toch vrijwillig gebruik van die software?

Voor het recht (= licentie) om software te gebruiken, moet je "betalen".

Bij closed source software betaal je in geld (en vervolgens moet je je alsnog houden aan de licentieovereenkomst).

Bij open source software "betaal" je door het opvolgen van de eisen in de licentieovereenkomst.

Bij de GPL is één van die voorwaarden dat je de software die gebruik maakt van de GPL software ook weer onder de GPL moet uitbrengen. Wil je dat niet, dan kun je die GPL library niet gebruiken (overigens staat er in de GPL specifiek een uitzondering voor "System Libraries", zodat je wel closed source software kan runnen op een Linux-OS).

Ik zie niet in waarom dat idioot zou zijn.

[ Voor 12% gewijzigd door Herko_ter_Horst op 17-12-2009 01:56 ]

[Soultaker]

Herko_ter_Horst schreef op donderdag 17 december 2009 @ 01:52:
overigens staat er in de GPL specifiek een uitzondering voor "System Libraries", zodat je wel closed source software kan runnen op een Linux-OS

Is dat zo? Volgens mij is het meer het feit dat glibc onder de LGPL (niet de GPL) valt, waardoor dat mogelijk is. "System Libraries" worden als zodanig niet genoemd. Wel wordt er gesteld dat je de source code van system libraries niet hoeft mee te distribueren met je source code, maar dat vermindert niet de verplichting tot distribueren van je eigen broncode zodra je tegen een GPL'ed library linkt.

[curry684]

Vinnienerd schreef op donderdag 17 december 2009 @ 01:47:
Dus strikt gezien zou ik als ik een closed-source programma schrijf, wat dynamisch gelinkt wordt aan een onder GPL uitgegeven library, hiervan de source vrij moeten geven? Dat is toch idioot? En dat houdt toch nooit stand in de rechtszaal?

Nou uhm dat houdt wel stand hoor....

Zodra je niet meer met consumenten te maken hebt is international recht een groot festijn waarbij 'vrijheid van contract' het grondbeginsel is van alle afspraken: je mag alles afspreken wat je wil en als je er wederzijds mee akkoord gaat is het bindend. Punt.

[cariolive23]

TomTom is ook zo'n mooi voorbeeld: Ze hebben een applicatie geschreven en deze draait op Linux. Deze Linux-versie hebben ze echter zelf ook nog een beetje aangepast. In eerste instantie waren ze vergeten om deze aanpassingen te publiceren, maar na enig aandringen hebben ze dat toch gedaan. Daarmee voldoen ze dus weer aan de voorwaarden die GPL stelt. De code van hun navigatiesoftware, die hebben ze echter niet gepubliceerd, dat is ook niet nodig.

Overigens is het aardig dat een groepje programmeurs/it-ers over dit soort onderwerpen discussieert, het is toch handiger om hiervoor een jurist in de arm te nemen. Logica en wetgeving zijn twee totaal verschillende dingen...

[Herko_ter_Horst]

Soultaker schreef op donderdag 17 december 2009 @ 02:43:
[...]

Is dat zo? Volgens mij is het meer het feit dat glibc onder de LGPL (niet de GPL) valt, waardoor dat mogelijk is. "System Libraries" worden als zodanig niet genoemd. Wel wordt er gesteld dat je de source code van system libraries niet hoeft mee te distribueren met je source code, maar dat vermindert niet de verplichting tot distribueren van je eigen broncode zodra je tegen een GPL'ed library linkt.

Whoops, je hebt gelijk: dat je non-GPL software kan draaien op Linux, komt door de LGPL van die libraries, niet door die uitzondering in de GPL.

[Verwijderd]

Soultaker schreef op donderdag 17 december 2009 @ 02:43:
[...]

Is dat zo? Volgens mij is het meer het feit dat glibc onder de LGPL (niet de GPL) valt, waardoor dat mogelijk is. "System Libraries" worden als zodanig niet genoemd. Wel wordt er gesteld dat je de source code van system libraries niet hoeft mee te distribueren met je source code, maar dat vermindert niet de verplichting tot distribueren van je eigen broncode zodra je tegen een GPL'ed library linkt.

Maar bepaalde functionaliteit van die LGPL libraries is enkel mogelijk door te linken met de linux kernel, dus GPL code. De GPL licentie voorziet wel een uitzondering voor het linken 'System Libraries'. In de GPL licentie staat er beschreven wat er allemaal als broncode van je programma moet beschouwd worden.

In de GPLv3:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. 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. ...

In de GPLv2 is dit dus blijkbaar niet zo expliciet opgenomen, maar normaal is diezelfde regel van kracht.

[ Voor 25% gewijzigd door Verwijderd op 17-12-2009 10:03 ]

[MSalters]

Ik denk dat een heleboel mensen hier in de mist gaan omdat ze niet beseffen dat de GPL een distributielicentie is. Gebruik staat daar buiten. Je kunt dus ook zonder meer een GPL Linux kernel gebruiken met niet-GPL applicaties en andersom. En op dezelfde manier kun je dus ook een GPL plugin gebruiken voor Exchange. Het "virale" aspect zou pas optreden als Microsoft (als eigenaar van Exchange) zou besluiten om zo'n GPL plugin te distribueren in combinatie met Exchange.

[Gomez12]

Tja, echt simpel en eenduidig die GPL, ik snap niet dat sommige mensen hem moeilijk vinden.

@MSalters, dus als MS in Exchange 2011 een prut MTA inbouwt en gelijk op de verpakking zet dat je GPL MTA x op hun website kunt downloaden en onderwater is alle MS code gericht op GPL MTA x dan overtreed volgens jou MS geen enkele regel hoezeer en hoediep de code ook vervlochten is. Het wordt apart gedistribueerd dus is het ok?

Serieus, ik heb in dit hele topic nog geen eenduidige beschrijving gezien van wat je wel en niet mag doen met GPL software. Iedereen lijkt het weer anders uit te leggen, en soms zit er wel een viraal aspect in, soms ook weer niet...

Nee, als programmeur zie ik het echt al zitten om x tijd te steken in (betaalde) plugins te maken voor GPL-progs of gebruik te maken van GPL componenten in betaalde software.

Ik kan me nog genoeg discussies herinneren over NVidia drivers die wel/niet gebruikt zouden mogen worden in Linux. Nee, dan ben je lekker bezig denk ik dan...

[Herko_ter_Horst]

Er zijn maar twee criteria die de GPL überhaupt van toepassing maken:
- jouw software is een "derivative work" van de GPL software
- je wilt jouw software verspreiden

De moeilijkheid zit in "derivative work". Dit is een term uit het auteursrecht/copyright ("afgeleid werk" is de term die de Nederlandse Auteurswet gebruikt). Wat precies een "derivative work" is, is uiteindelijk aan een rechter om te bepalen. De GPL geeft voor een aantal situaties specifiek aan wat als een derivative work beschouwd moet worden. Grofweg claimt de GPL dat als jouw software onlosmakelijk (op code-niveau) verbonden is met GPL software, jouw software ook onder de GPL moet vallen. Voor de precieze regels, moet je echt de GPL zelf lezen en begrijpen in de context van het auteursrecht.

In elk geval is alleen maar gebruiken (zonder iets verder te verspreiden) geen probleem. Data uitwisselen via een extern mechanisme/protocol (files, streams, alles behalve de API van de library) is geen probleem. Lees ook eens de GPL FAQ, daarin staat voor heel veel specifieke situaties wat volgens de FSF de bedoeling is van de GPL (uiteraard beslist uiteindelijk de rechter of de licentie dat ook afdekt).

Jouw voorbeeld snijdt geen hout. Je kunt geen software bouwen die aansluit op de GPL code en via dezelfde code op een andere library (tenzij die andere library een kopie is van de GPL library, wat ook een derivative werk is en dus onder de GPL zou moeten vallen). Je hebt namelijk de header files/interfaces van de GPL library nodig om jouw software te kunnen compilen. Dus je kunt niet even de brakke proprietary MTA vervangen door een GPL MTA.

Dat jij geen gebruik wilt/kunt maken van GPL componenten in proprietary, closed source (dat is wat je bedoelt met "betaalde" neem ik aan?) software is DE BEDOELING van de GPL. Dat is waarom de GPL gemaakt is: ze willen GEEN proprietary software. Het "virale" karakter van GPL is dus ook echt zo bedoeld (maar is dus alleen van toepassing als je voldoet aan de bovenstaande twee voorwaarden en niet zomaar als je een GPL applicatie gebruikt o.i.d.).

De FSF heeft zelf slechts voor een beperkt aantal libraries de LGPL gekozen, omdat daar meer te winnen was dan met de GPL.

Helaas hebben veel open source projecten (in het verleden) gekozen voor de GPL, omdat dat de meest bekende open source licentie was/is. Dit zonder dat ze nou persé tegen proprietary software zijn. Een aantal projecten is later ook overgestapt op een meer liberale open source licentie.

Overigens staat niets je in de weg geld te verdienen met GPL software. Omdat je verplicht bent de source gratis te leveren, is de kans klein dat klanten bereid zullen zijn puur voor de licentie te betalen. Maar als je extra service, garantie of aanvullende diensten levert, is er best geld mee te verdienen.

[ Voor 20% gewijzigd door Herko_ter_Horst op 17-12-2009 14:04 ]

[MSalters]

Gomez12 schreef op donderdag 17 december 2009 @ 11:33:
Tja, echt simpel en eenduidig die GPL, ik snap niet dat sommige mensen hem moeilijk vinden.

@MSalters, dus als MS in Exchange 2011 een prut MTA inbouwt en gelijk op de verpakking zet dat je GPL MTA x op hun website kunt downloaden en onderwater is alle MS code gericht op GPL MTA x dan overtreed volgens jou MS geen enkele regel hoezeer en hoediep de code ook vervlochten is. Het wordt apart gedistribueerd dus is het ok?

Ja. En dat is nog met opzet ook. Je kunt die GPL MTA namelijk zo installeren, maar je kunt ook de code ervan krijgen, bestuderen, aanpassen, en dan installeren. Je hebt dus als gebruiker veel meer mogelijkheden. De GPL vervult dus z'n doel, uiteraard alleen voor het deel wat onder de GPL valt.

[MSalters]

Herko_ter_Horst schreef op donderdag 17 december 2009 @ 13:48:
Er zijn maar twee criteria die de GPL überhaupt van toepassing maken:
- jouw software is een "derivative work" van de GPL software
- je wilt jouw software verspreiden

De moeilijkheid zit in "derivative work". Dit is een term uit het auteursrecht/copyright ("afgeleid werk" is de term die de Nederlandse Auteurswet gebruikt). Wat precies een "derivative work" is, is uiteindelijk aan een rechter om te bepalen. De GPL geeft voor een aantal situaties specifiek aan wat als een derivative work beschouwd moet worden. Grofweg claimt de GPL dat als jouw software onlosmakelijk (op code-niveau) verbonden is met GPL software, jouw software ook onder de GPL moet vallen. Voor de precieze regels, moet je echt de GPL zelf lezen en begrijpen in de context van het auteursrecht.

Nu doe je alsof de regels voor "derivative work" c.q. "afgeleid werk" door de GPL bepaald worden. Dat kan natuurlijk niet; het is een wettelijk concept. En je kunt dus ook derivative works hebben van niet-GPL software; zelfs van boeken. Zo zijn een heleboel Wikipedia pagina's inmiddels afgeleide werken, omdat ze door meerdere auteurs bewerkt zijn.

De GPL definitie van "derivative work" en vooral "aggregate work" heeft evengoed wel juridische waarde. Je mag als verspreider van een aggregate work uitgaan van de GPL definitie daarvan, ook al zou het volgens een wettelijke regel eigenlijk een derivative work moeten heten. De GPL definitie is namelijk wél juridisch beperkend voor de GPL auteur, diegene die jou als verspreider zou kunnen aanklagen.

Overigens staat niets je in de weg geld te verdienen met GPL software. Omdat je verplicht bent de source gratis te leveren, is de kans klein dat klanten bereid zullen zijn puur voor de licentie te betalen. Maar als je extra service, garantie of aanvullende diensten levert, is er best geld mee te verdienen.

Denk je? Als een klant een software pakket wil dat X, Y en Z kan, en ik kan dat goedkoop maken door feature Z aan een bestaand GPL pakket toe te voegen, dan heb ik een goede kans om de opdracht te winnen. Ik ben namelijk goedkoper dan mijn concurrent die features X, Y en Z allemaal moet maken of kopen. Ja, mijn feature Z eindigt onder de GPL. Dat maakt mij niet uit, noch m'n klant. Want mijn klant is de enige die de binary krijgt, en dus ook de enige die de GPL rechten op de source van Z krijgt.

[ Voor 20% gewijzigd door MSalters op 17-12-2009 14:52 ]

[.oisyn]

Herko_ter_Horst schreef op donderdag 17 december 2009 @ 00:18:
Datauitwisseling van een GPL-programma valt NIET onder de GPL (zoals ik inmiddels al 2 keer eerder heb gezegd, zie ook - nogmaals - de FAQ entry over de output van een GPL programma).

Die output is niet interessant, het gaat juist om de input.

Voor de duidelijkheid: met interfaces bedoel ik dus de API van een softwarebibliotheek, en NIET een protocol-"interface", user-"interface", xml-"interface" of wat dan ook.

Een API is gemakkelijk om te zetten naar een protocol, zoals bijv. met XML-RPC. Dat zou dus betekenen dat als ik een GPL library pak, daar een XML-RPC server omheen bouw (die ook GPL moet zijn), dat ik dan vervolgens met een closed source client met die server kan en mag praten? Immers, het enige dat de GPL server app ontvangt is data.

MSalters schreef op donderdag 17 december 2009 @ 11:03:
Ik denk dat een heleboel mensen hier in de mist gaan omdat ze niet beseffen dat de GPL een distributielicentie is. Gebruik staat daar buiten. Je kunt dus ook zonder meer een GPL Linux kernel gebruiken met niet-GPL applicaties en andersom. En op dezelfde manier kun je dus ook een GPL plugin gebruiken voor Exchange. Het "virale" aspect zou pas optreden als Microsoft (als eigenaar van Exchange) zou besluiten om zo'n GPL plugin te distribueren in combinatie met Exchange.

Maar wanneer gaat dat dan precies op? Ik neem niet aan dat als ik een GPL programma en een closed source programma in een zipje stop die verder niets met elkaar doen, en dat distribueer, ik dan verplicht ben om de sourcecode van dat closed source programmaatje onder GPL te releasen.

[ Voor 34% gewijzigd door .oisyn op 17-12-2009 15:22 ]

[Gomez12]

MSalters schreef op donderdag 17 december 2009 @ 14:34:
[...]
Ja. En dat is nog met opzet ook. Je kunt die GPL MTA namelijk zo installeren, maar je kunt ook de code ervan krijgen, bestuderen, aanpassen, en dan installeren. Je hebt dus als gebruiker veel meer mogelijkheden. De GPL vervult dus z'n doel, uiteraard alleen voor het deel wat onder de GPL valt.

Ok, dus als ik het nog 1 stap verder breng :
- Ik herschrijf alle output van die MTA zodat er nergens meer de bekende naam staat, maar enkel Super MTA
- ik package die GPL MTA opnieuw ( inclusief alle originele readme's / licentie teksten etc verstopt in een dir ergens achter diep in de krochten van het FS ) zodat het meer binnen mijn installatie programma's blijft,
- ik geef de nieuwe package een nieuwe fancy naam ( Exchange Super MTA ),
- ik gooi de nieuwe package als optionele update in windows update,
- ik zwijg openlijk over het feit dat de nieuwe MTA GPL is ( in detail staat het uiteraard wel in de krochten van het FS beschreven )
- Als iemand om de code van de Super MTA vraagt dan kunnen ze die krijgen.

Dan blijf ik dus ook nog binnen de GPL?

Want afaik mag dit dus niet, terwijl ik volgens mij toch binnen de door jou gestelde regels blijf.

Voor zover ik weet heb ik nu een mogelijke implementatie van LGPL beschreven, maar komt bij GPL hier nog ergens het virale aspect erbij, maar zie ik niet waar.

MSalters schreef op donderdag 17 december 2009 @ 14:48:
[...]

Denk je? Als een klant een software pakket wil dat X, Y en Z kan, en ik kan dat goedkoop maken door feature Z aan een bestaand GPL pakket toe te voegen, dan heb ik een goede kans om de opdracht te winnen. Ik ben namelijk goedkoper dan mijn concurrent die features X, Y en Z allemaal moet maken of kopen. Ja, mijn feature Z eindigt onder de GPL. Dat maakt mij niet uit, noch m'n klant. Want mijn klant is de enige die de binary krijgt, en dus ook de enige die de GPL rechten op de source van Z krijgt.

Je extra service is hier Z en daar betaalt de klant voor, de klant betaalt in wezen niet voor X,Y.

En het problematische is dat er niets is wat die klant tegenhoud om het gratis op inet te zetten en al jouw toekomstige handel voor X,Y,Z te vernietigen

[Soultaker]

Programmeurs vinden de GPL vaak vervelend omdat de definitie van wat wel en niet mag afhangt van wanneer iets een afgeleid werk is; iets wat voor klassieke kunstwerken enigzins duidelijk gedefinieerd is maar voor programma's nog niet (ook omdat er weinig jurisprudentie over bestaat). Het is helaas een inherent fuzzy concept, en dat is juist wat programmeurs (die gewend zijn exact te denken) vervelend vinden.

Dat betekent niet dat er helemaal geen duidelijkheid is over hoe je programma's wel en niet kunt gebruiken. Meestal wil je ofwel een library linken in je applicatie of je wil de bestaande interface van een tool gebruiken zonder er tegen te linken (gcc, glpk, et cetera). In het eerste geval is er zeker sprake van een afgeleid werk, in het tweede geval niet.

.oisyn schreef op donderdag 17 december 2009 @ 15:18:
Een API is gemakkelijk om te zetten naar een protocol, zoals bijv. met XML-RPC. Dat zou dus betekenen dat als ik een GPL library pak, daar een XML-RPC server omheen bouw (die ook GPL moet zijn), dat ik dan vervolgens met een closed source client met die server kan en mag praten? Immers, het enige dat de GPL server app ontvangt is data.

Scherp gezien; dat klopt in principe. Een vergelijkbare (praktische) casus is die van MySQL: een GPL-gelicenseerde databaseserver. De client library (waar je applicatie tegen linkt) is ook gelicenseerd onder de GPL en dat betekent dat als je applicatie daarvan gebruik maakt, die ook onder de GPL beschikbaar moet komen.

Als alternatief daarvoor kun je ook een non-GPL-licentie krijgen voor het gebruik van de client libraries. In dat geval valt je applicatie níet onder de GPL omdat de client-library daar niet onder valt, ook al communiceer je (via de client library) net zo goed met een GPL-gelicenseerde server. De grens wordt in dat geval getrokken bij het dynamisch linken.

Maar wanneer gaat dat dan precies op? Ik neem niet aan dat als ik een GPL programma en een closed source programma in een zipje stop die verder niets met elkaar doen, en dat distribueer, ik dan verplicht ben om de sourcecode van dat closed source programmaatje onder GPL te releasen.

Als het closed-source programma linkt tegen een GPL-library (of vice versa) dan mag dat niet. Op zich is "linken" al dubieus (Merk op dat "linken" op zichzelf ook al dubieus is, omdat je technisch gezien bepaalde symbols uit bepaalde libraries kunt halen, zoals bv libglut, zonder daarbij aan te geven welke implementatie van die library je precies nodig hebt. Als je een GPL-gelicenseerde library mee distribueert, is het natuurlijk duidelijk dat dat niet kan.)

[Herko_ter_Horst]

MSalters schreef op donderdag 17 december 2009 @ 14:48:
[...]

Nu doe je alsof de regels voor "derivative work" c.q. "afgeleid werk" door de GPL bepaald worden. Dat kan natuurlijk niet; het is een wettelijk concept. En je kunt dus ook derivative works hebben van niet-GPL software; zelfs van boeken. Zo zijn een heleboel Wikipedia pagina's inmiddels afgeleide werken, omdat ze door meerdere auteurs bewerkt zijn.

De GPL definitie van "derivative work" en vooral "aggregate work" heeft evengoed wel juridische waarde. Je mag als verspreider van een aggregate work uitgaan van de GPL definitie daarvan, ook al zou het volgens een wettelijke regel eigenlijk een derivative work moeten heten. De GPL definitie is namelijk wél juridisch beperkend voor de GPL auteur, diegene die jou als verspreider zou kunnen aanklagen.

Ik doe helemaal niet of de GPL bepaalt wat een derivative work is, ik zeg nota bene expliciet dat het een begrip uit het auteursrecht is. De GPL zegt voor een aantal specifieke gevallen wat zij onder een derivative work verstaan, maar aangezien er geen allesomvattende definitie van derivative work bestaat, zal in onduidelijke gevallen de rechter hierover moeten oordelen.

.oisyn schreef:
Een API is gemakkelijk om te zetten naar een protocol, zoals bijv. met XML-RPC. Dat zou dus betekenen dat als ik een GPL library pak, daar een XML-RPC server omheen bouw (die ook GPL moet zijn), dat ik dan vervolgens met een closed source client met die server kan en mag praten? Immers, het enige dat de GPL server app ontvangt is data.

Als jij aan de ontvangende kant geen interfaces of header files o.i.d. uit de GPL library nodig hebt, dan mag dit inderdaad. Voor zover ik weet werkt XML-RPC echter op basis van dezelfde interfaces/headers (en mogelijk ook implementaties) aan beide zijden, dus zouden beide zijden onder de GPL vallen.

Gomez12 schreef:
Ok, dus als ik het nog 1 stap verder breng :
- Ik herschrijf alle output van die MTA zodat er nergens meer de bekende naam staat, maar enkel Super MTA
- ik package die GPL MTA opnieuw ( inclusief alle originele readme's / licentie teksten etc verstopt in een dir ergens achter diep in de krochten van het FS ) zodat het meer binnen mijn installatie programma's blijft,
- ik geef de nieuwe package een nieuwe fancy naam ( Exchange Super MTA ),
- ik gooi de nieuwe package als optionele update in windows update,
- ik zwijg openlijk over het feit dat de nieuwe MTA GPL is ( in detail staat het uiteraard wel in de krochten van het FS beschreven )
- Als iemand om de code van de Super MTA vraagt dan kunnen ze die krijgen.

Dan blijf ik dus ook nog binnen de GPL?

Ik kan dit voorbeeld niet goed volgen, ik weet niet wat je bedoelt met het veranderen van de naam of het veranderen van de packaging. Hoe je dat ding verspreidt is in elk geval niet van belang. Alles m.b.t. verstoppen in het filesysteem of uitbrengen via Windows Update is irrelevant.

Je kunt de GPL niet omzeilen door de library te verstoppen of door er over te zwijgen. Als je de code van de GPL library aanpast (bijv. om de naam te veranderen), moet je de wijzigingen uitbrengen onder GPL. Als jouw code gebruik maakt van de code in de GPL library moet je jouw code onder de GPL uitbrengen. Dat is het "virale" aspect.

[.oisyn]

Herko_ter_Horst schreef op donderdag 17 december 2009 @ 16:39:
Voor zover ik weet werkt XML-RPC echter op basis van dezelfde interfaces/headers (en mogelijk ook implementaties) aan beide zijden

Nee, XML-RPC is een protocol, meer niet. Je hebt idd tools die automatisch proxies genereren voor je code zodat het geheel transparant werkt, maar daar heb ik het niet over. Je hebt echter wel een goed punt, je zult de interface om moeten gooien zodat je de headers of metadata van het origineel niet hoeft te gebruiken.

[Gomez12]

Soultaker schreef op donderdag 17 december 2009 @ 16:28:
Programmeurs vinden de GPL vaak vervelend omdat de definitie van wat wel en niet mag afhangt van wanneer iets een afgeleid werk is; iets wat voor klassieke kunstwerken enigzins duidelijk gedefinieerd is maar voor programma's nog niet (ook omdat er weinig jurisprudentie over bestaat). Het is helaas een inherent fuzzy concept, en dat is juist wat programmeurs (die gewend zijn exact te denken) vervelend vinden.

Mwah niet alleen programmeurs zijn niet blij met een fuzzy definitie hoor, volgens mij is niemand er blij mee behalve de voorstanders van fud.
Onduidelijke concepten waarvan de gevolgen niet goed te overzien zijn vallen over het algemeen niet erg goed in het bedrijfsleven ( ja, als we dit handige componentje erin zetten dan kan het ons 6 maanden werk schelen, maar als we de voorwaarden verkeerd geintepreteerd hebben dan kunnen we over 2 maanden failliet zijn, nee naar een advocaat gaan heeft weinig nut, want het is een inherent fuzzy concept... Tja, daar moet ik echt mee aankomen bij mijn directeur )

Wat wel mag is je app ook onder GPL uitbrengen, wat niet mag is je app closed source hebben en dan tegen GPL code linken en dan heb je nog een giga-grijs tussenstuk.

Herko_ter_Horst schreef op donderdag 17 december 2009 @ 16:39:
[...]
Als jij aan de ontvangende kant geen interfaces of header files o.i.d. uit de GPL library nodig hebt, dan mag dit inderdaad. Voor zover ik weet werkt XML-RPC echter op basis van dezelfde interfaces/headers (en mogelijk ook implementaties) aan beide zijden, dus zouden beide zijden onder de GPL vallen.

XML-RPC is enkel een spec, je kan er zo je eigen implementatie voor maken.

[...]
Ik kan dit voorbeeld niet goed volgen, ik weet niet wat je bedoelt met het veranderen van de naam of het veranderen van de packaging. Hoe je dat ding verspreidt is in elk geval niet van belang. Alles m.b.t. verstoppen in het filesysteem of uitbrengen via Windows Update is irrelevant.

Je kunt de GPL niet omzeilen door de library te verstoppen of door er over te zwijgen. Als je de code van de GPL library aanpast (bijv. om de naam te veranderen), moet je de wijzigingen uitbrengen onder GPL. Als jouw code gebruik maakt van de code in de GPL library moet je jouw code onder de GPL uitbrengen. Dat is het "virale" aspect.

Simpel gezegd dan :
- Ik heb 1 closed source enterprise app uitgebracht met een bagger MTA maar wel met een plugin structuur voor het praten tegen een GPL MTA.
- Ik heb 1 GPL MTA waarvan ik allerlei moeite doe om de GPL kenmerken te verbergen en waarvan ik het voordoe alsof het enkel een update is

Uiteindelijk heb ik dan 1 closed source enterprise app waarin ik GPL componenten gebruik.
De componenten zijn dus nog steeds GPL alleen zwijg ik erover en heb ik ze ietwat gemodificeerd om ze iets beter te verbergen, maar de gemodificeerde componenten zijn en blijven GPL.
Mag ik dit doen volgens de GPL of niet?

Ik hoef niet te linken naar die GPL componenten, al het data-verkeer gebeurt via specs die die componenten gewoon standaard ondersteunen.

[Gomez12]

.oisyn schreef op donderdag 17 december 2009 @ 17:03:
[...]

Nee, XML-RPC is een protocol, meer niet. Je hebt idd tools die automatisch proxies genereren voor je code zodat het geheel transparant werkt, maar daar heb ik het niet over. Je hebt echter wel een goed punt, je zult de interface om moeten gooien zodat je de headers of metadata van het origineel niet hoeft te gebruiken.

Hangt enkel van de volgorde van programmeren af.

Als je eerst de GPL-kant maakt dan mag je die code niet meer hergebruiken aan je closed source kant.
Als je eerst de closed source kant maakt dan mag je die code wel weer forken naar een GPL-variant.

Elke wijziging aan de GPL-kant van je interface geeft je een probleem, elke wijziging aan de closed source kant van je interface is geen probleem ( gewoon opnieuw forken ).

Maar dit soort problemen zijn imho toch alleen maar theoretisch, ik kan me niet voorstellen dat iemand echt in de version control gaat napluizen of je niet ergens 1x een foutje gemaakt hebt als je ( / je bedrijf ) van alletwee de auteur bent.
Enkel externen die zelf code gaan aandragen om het GPL gedeelte te verbeteren zouden een probleem kunnen zijn ( maar dat is imho wel heel erg ver doorgetrokken )

[.oisyn]

Gomez12 schreef op donderdag 17 december 2009 @ 17:23:
[...]

Hangt enkel van de volgorde van programmeren af.

Als je eerst de GPL-kant maakt dan mag je die code niet meer hergebruiken aan je closed source kant.
Als je eerst de closed source kant maakt dan mag je die code wel weer forken naar een GPL-variant.

Dat is onzin. Als je zelf code schrijft die je releast onder GPL dan mag je die daarna gewoon closed source releasen. Het is immers je eigen werk, en jij mag bepalen welke licenties je eraan hangt. Met GPL overdraag je verder geen auteursrechten oid. Het *geheel* is een afgeleid werk. Jouw specifieke toevoegingen zonder het origineel zijn gewoon van jou. Maar ik zie niet in hoe je opmerking hier op van toepassing is.

Waar het om gaat is dat je de interface nodig hebt. Laten we een voorbeeld erbij nemen, dat praat makkelijker. Er is een GPL library FooLib met een functie genaamd Foo() dat iets doet. Dat is gereleased in een Foo.cpp met de implementatie en een Foo.h met de interface.

Nu wil je een closed source applicatie releasen dat gebruik maakt van FooLib, dus maak je een XML-RPC server om FooLib heen. Ook maak je een client om ermee te kunnen praten, en voor die client heb je natuurlijk ook een header nodig om de rest van je code mee te compilen. Foo.h uit FooLib kun je niet gebruiken, want die is GPL. Je zou de functie Bar() kunnen noemen en in Bar.h kunnen declareren. De rest van de code linkt dan gewoon met BarLib, en is geheel closed source.

[Nu is dit voorbeeld natuurlijk dermate simpel dat gewoon overtikken ook wel zal kunnen, in een wat gecompliceerdere API zul je denk ik wel wat meer moeten doen dan alleen de functienamen wijzigen. Je zou bijvoorbeeld de mysql C API in een OO jasje kunnen gieten om er zo omheen te komen.]

Voor de server heb je Bar.h helemaal niet nodig (wat jij wel lijkt te impliceren), dus die zal ook niet automatisch GPL worden. Maar, zoals boven al stond, ookal wordt ie dat wel dan nog maakt dat niet uit, want het is je eigen code die je, los van FooLib, gewoon mag gebruiken in closed source applicaties. Het is de combinatie met FooLib die het GPL maakt.

[ Voor 62% gewijzigd door .oisyn op 17-12-2009 17:52 ]

[.oisyn]

Soultaker schreef op donderdag 17 december 2009 @ 16:28:
Als het closed-source programma linkt tegen een GPL-library (of vice versa) dan mag dat niet. Op zich is "linken" al dubieus (Merk op dat "linken" op zichzelf ook al dubieus is, omdat je technisch gezien bepaalde symbols uit bepaalde libraries kunt halen, zoals bv libglut, zonder daarbij aan te geven welke implementatie van die library je precies nodig hebt. Als je een GPL-gelicenseerde library mee distribueert, is het natuurlijk duidelijk dat dat niet kan.)

Het idee was natuurlijk dat de twee files in de zipfile compleet ongerelateerd waren, maar je zegt dus dat dat mag, wat mij ook wel logisch leek.

Volgende punt. Nu heb je een closed source library die niet van jou is maar die je wel mag verspreiden. En je hebt een GPL programma dat je gebruik wilt laten maken van die library. Mag je de aanpassingen maken om die library te gebruiken, en daarvan de sourcecode releasen (dus niet de binary zelf)? En mag je die aanpassingen + origineel + closed source lib in een zipje stoppen en dát distribueren?

En als je daar dan een GCC installatie bij stopt (dat mocht immers volgens het antwoord op mijn eerste vraag), inclusief een batchfile dat de boel op de PC van de gebruiker linkt, mag het dan nog steeds?

[Soultaker]

.oisyn schreef op donderdag 17 december 2009 @ 18:01:
Het idee was natuurlijk dat de twee files in de zipfile compleet ongerelateerd waren, maar je zegt dus dat dat mag, wat mij ook wel logisch leek.

Ja, dit deel van de GPLv2 gaat daar over:

If identifiable sections of [a modified work] are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Zolang twee files dus "compleet ongerelateerd" zijn zou je ze wel tegelijk mogen distribueren.

Nu heb je een closed source library die niet van jou is maar die je wel mag verspreiden. En je hebt een GPL programma dat je gebruik wilt laten maken van die library. Mag je de aanpassingen maken om die library te gebruiken, en daarvan de sourcecode releasen (dus niet de binary zelf)?

Je mag sowieso de source code aanpassen en publiceren/distribueren onder de GPL. Maar als het GPL-programma de closed-source library nodig heeft, maar je die dus niet verspreiden, want dan vormen de twee een samenhangend afgeleid werk, en dat moet in het geheel onder de GPL vallen.

En mag je die aanpassingen + origineel + closed source lib in een zipje stoppen en dát distribueren? [..] En als je daar dan een GCC installatie bij stopt (dat mocht immers volgens het antwoord op mijn eerste vraag), inclusief een batchfile dat de boel op de PC van de gebruiker linkt, mag het dan nog steeds?

Dat is weer zo'n tricky case (waar je er nog wel meer van kunt aanhalen, vermoedelijk): als de batchfile, GPL programma en closed source library één geheel vormen, wat me hier aannemelijk lijkt aangezien je helemaal niets kunt uitvoeren zonder de boel te compileren en linken waarvoor je toch echt alledrie de componenten nodig hebt, dan moet je het geheel onder de voorwaarden van de GPL distribueren (en dat kan dus niet met de closed-source library).

Distributie in (GPL'ed) source code is op zichzelf geen vrijbrief om allerlei non-GPL libraries te gebruiken. (Een soortgelijke constructie kun je immers verzinnen met interpreted talen: stel je shipt een GPL'ed script met een GPL'ed interpreter en een non-GPL library; dan heb je eigenlijk dezelfde situatie.)

Het is een bekende gray area. Een gebruiker kan wel jouw broncode downloaden, een non-GPL library downloaden, en de boel compileren, linken en uitvoeren. Dat wordt ook wel eens gedaan. Maar als één werk distribueren kan waarschijnlijk niet.

Als je nog een gray area uit de praktijk wil: er zijn talloze scriptjes (zoals ook package managers die gebruiken) die als enige doel hebben om broncode te downloaden van diverse programma's, die te compileren en de boel te linken. Zo'n script zelf is niet afgeleid van GPL'ed code. De componenten worden afzonderlijk (onder hun eigen licentie) gedistribueerd. Dat wordt meestal gezien alsof het de eindgebruiker is die de boel combineert tot samenhangend werk (wat immers toegestaan is, zolang het resultaat niet verder gedistribueerd wordt) maar je zou ook kunnen beargumenteren dat degene die het script schrijft en publiceert een afgeleid werk produceert. Voor zover ik weet is dit nooit getest.

[ Voor 10% gewijzigd door Soultaker op 17-12-2009 20:54 ]

[MSalters]

Overigens, om GPL_FUD te vermijden, de grey areas waar we het hier hebben komen uit het auteursrecht, niet de GPL. Ze bestaan dus ook voor commerciele software. Lees maar eens de redistributieregels van Microsoft.

[Gomez12]

MSalters schreef op vrijdag 18 december 2009 @ 11:40:
Overigens, om GPL_FUD te vermijden, de grey areas waar we het hier hebben komen uit het auteursrecht, niet de GPL. Ze bestaan dus ook voor commerciele software. Lees maar eens de redistributieregels van Microsoft.

Imho komen de meeste grey areas niet vanuit het auteursrecht pur sang, maar meer vanuit het virale gedeelte van de GPL.

LGPL kent qua gebruik een stuk minder grey areas.
Als Stallman de GPL duidelijk had willen hebben had hij wmb de grey areas van wanneer een ander stuk programmatuur nou wel of niet GPL moet worden beter moeten specificeren.

Die grey areas zijn wmb de reden om professioneel geen GPL te gebruiken.
Bij bijna alle andere licenses is het duidelijk wanneer ik iets wel of niet mag gebruiken en de gevolgen zijn ook redelijk in te schatten. Bij GPL is in een grey area zitten gelijk spelen met je hele bedrijf...

[CAPSLOCK2000]

@ de oorspronkelijke vraag

Naar mijn mening maak je je zorgen om de verkeerde vragen.
De broncode GPL software mag je inderdaad niet geheim houden zoals dat gebruikelijk is bij eigendomssoftware. De vraag is of dat invloed heeft op jouw mogelijkheid om je software te verkopen.
Ik denk van niet.

Je bent _niet_ verplicht om je code aan de hele wereld te geven, alleen aan je klant. Zolang die klant jouw code niet doorgeeft kan niemand er aanspraak op maken. De meeste bedrijven die ik ken hebben wel wat anders aan hun hoofd dan hun concurrenten helpen met een website. Verder zijn de meeste bedrijven er niet eens toe in staat, al zouden ze willen, domweg omdat ze niet genoeg computer/programmeer kennis in huis hebben. Dat is precies de reden dat ze jouw betalen.

Stel nu dat het toch gebeurd dat iemand je software doorgeeft. Ik weet niet wat je precies schrijft, maar de meeste software is toch redelijk maatwerk. De kans is aanzienlijk dat de software aangepast moet worden voor een ander er iets mee kan. Wie kunnen ze daar heb beste voor inhuren? Precies, jijzelf, want jij bent degene die de code het beste kent.

PS.
BSD richt zich op programmeurs, GPL op gebruikers. Dat geeft een nogal andere benadering. Voor programmeurs is de BSD licentie veel fijner, maar voor gebruikers geeft GPL meer zekerheid. Als programmeur heeft GPL voornamelijk zin als je bang bent dat een ander je code gaat gebruiken zonder terug te geven. Via GPL kun je hem dan dwingen door een van z'n producten te kopen.
Gelukkig (of helaas) zijn de meeste programmeurs ook gebruikers. Sterker nog, je gebruikt veel meer software dan je ooit zal schrijven. Vandaar dat sommige programmeurs ook de voordelen van GPL zien.

[CAPSLOCK2000]

Gomez12 schreef op vrijdag 18 december 2009 @ 13:11:

Imho komen de meeste grey areas niet vanuit het auteursrecht pur sang, maar meer vanuit het virale gedeelte van de GPL.

GPL gebruikt het auteursrecht op een totaal andere manier dan oorspronkelijk voorzien, dat schuurt af en toe.

Als Stallman de GPL duidelijk had willen hebben had hij wmb de grey areas van wanneer een ander stuk programmatuur nou wel of niet GPL moet worden beter moeten specificeren.

Software is gewoon vaag. We hebben zelfs nog geen dekkende definitie van wat software nu precies wel en niet is. De hele definitie van een afgeleid werk is net zo relevant voor BSD software. Het grote verschil is dat de gevolgen voor BSD software veel kleiner zijn. Als je denkt dat jouw software afgeleid is van BSD software, dan knal je de naam van de oospronkelijke auteur er bij en klaar is kees. (enigzins versimpeld)

Die grey areas zijn wmb de reden om professioneel geen GPL te gebruiken.
Bij bijna alle andere licenses is het duidelijk wanneer ik iets wel of niet mag gebruiken en de gevolgen zijn ook redelijk in te schatten. Bij GPL is in een grey area zitten gelijk spelen met je hele bedrijf...

Alles is relatief. Er is volgens mij geen bedrijf meer in de Quote-500 dat geen gebruik maakt van GPL. Ieder groot software huis doet wel iets met GPL, zelfs Microsoft.

Het is ook niet zo dat als je het GPL schendt je direct je product en bedrijf kwijt bent. Dat is nog nooit gebeurd. Dusver is in eigenlijk alle gevallen een overeenkomst gesloten tussen de programeur en de overtreder. Voor zover ik weet hebben al die bedrijven gekozen voor het publiceren van hun broncode boven het stoppen met het verkopen van het product. De risico's van je broncode beschikbaarstellen vallen dus blijkbaar nogal mee.

[Gomez12]

CAPSLOCK2000 schreef op vrijdag 18 december 2009 @ 13:19:
Je bent _niet_ verplicht om je code aan de hele wereld te geven, alleen aan je klant. Zolang die klant jouw code niet doorgeeft kan niemand er aanspraak op maken. De meeste bedrijven die ik ken hebben wel wat anders aan hun hoofd dan hun concurrenten helpen met een website. Verder zijn de meeste bedrijven er niet eens toe in staat, al zouden ze willen, domweg omdat ze niet genoeg computer/programmeer kennis in huis hebben. Dat is precies de reden dat ze jouw betalen.

Stel nu dat het toch gebeurd dat iemand je software doorgeeft. Ik weet niet wat je precies schrijft, maar de meeste software is toch redelijk maatwerk. De kans is aanzienlijk dat de software aangepast moet worden voor een ander er iets mee kan. Wie kunnen ze daar heb beste voor inhuren? Precies, jijzelf, want jij bent degene die de code het beste kent.

Ik vermoed dat het toch wel iets sneller kan gaan dan jij hier beschrijft.
Jij maakt iets, half jaar later huurt het bedrijf een hobby-bob in omdat die goedkoper is dan jij. Hobby-bob heeft meer klanten et voila...

PS.
BSD richt zich op programmeurs, GPL op gebruikers. Dat geeft een nogal andere benadering. Voor programmeurs is de BSD licentie veel fijner, maar voor gebruikers geeft GPL meer zekerheid. Als programmeur heeft GPL voornamelijk zin als je bang bent dat een ander je code gaat gebruiken zonder terug te geven. Via GPL kun je hem dan dwingen door een van z'n producten te kopen.
Gelukkig (of helaas) zijn de meeste programmeurs ook gebruikers. Sterker nog, je gebruikt veel meer software dan je ooit zal schrijven. Vandaar dat sommige programmeurs ook de voordelen van GPL zien.

Waarom geeft de GPL aan een gebruiker meer zekerheid? Zijn software die hij gebruikt blijft het onder zo ongeveer elke licentie wel doen.

CAPSLOCK2000 schreef op vrijdag 18 december 2009 @ 13:33:
[...]
Alles is relatief. Er is volgens mij geen bedrijf meer in de Quote-500 dat geen gebruik maakt van GPL. Ieder groot software huis doet wel iets met GPL, zelfs Microsoft.

Bewust grootschalig gebruik zal je volgens mij toch zwaar tegenvallen hoor. Tuurlijk staan er routertjes met GPL-firmware oid. Tuurlijk zijn er enkele mensen die GPL-software op hun workstation hebben staan. Tuurlijk zal er ergens een nagios servertje draaien. Maar dan kan je net zo goed zeggen dat er illegale MP3's bij quote-500 bedrijven staan.

Het is ook niet zo dat als je het GPL schendt je direct je product en bedrijf kwijt bent. Dat is nog nooit gebeurd. Dusver is in eigenlijk alle gevallen een overeenkomst gesloten tussen de programeur en de overtreder. Voor zover ik weet hebben al die bedrijven gekozen voor het publiceren van hun broncode boven het stoppen met het verkopen van het product. De risico's van je broncode beschikbaarstellen vallen dus blijkbaar nogal mee.

Tja, voor zover ik weet ging het tot nu toe enkel maar om enkele randdingetjes.
Maar wat had er nou gebeurd als ipv de win7-iso downloader er GPL code gevonden was in win7 zelf.

Als de broncode van je core-product vrijgegeven moet worden dan heb je toch echt wel een giga-probleem hoor.

[cariolive23]

CAPSLOCK2000 schreef op vrijdag 18 december 2009 @ 13:19:
BSD richt zich op programmeurs, GPL op gebruikers. Dat geeft een nogal andere benadering. Voor programmeurs is de BSD licentie veel fijner, maar voor gebruikers geeft GPL meer zekerheid.

Waarom zou een lap code uitgegeven onder GPL voor gebruikers fijner zijn dan dezelfde lap code onder BSD?

Het zal aan mij liggen en ik ben zeker geen expert, maar dit vat ik even niet. Kun je dit verduidelijken?

[MSalters]

De gebruikers hebben bijvoorbeeld het voordeel dat de applicatie nog onderhouden kan worden als de originele leverancier failliet gaat en wordt ontbonden. In dat geval is de sourcecode van een applicatie onder BSD licentie gewoon weg. Heb je echter een GPL applicatie+source, dan kun je als klant(en) de applicatie zelf in onderhoud nemen.

[MSalters]

Gomez12 schreef op vrijdag 18 december 2009 @ 13:11:
[...]

Imho komen de meeste grey areas niet vanuit het auteursrecht pur sang, maar meer vanuit het virale gedeelte van de GPL. LGPL kent qua gebruik een stuk minder grey areas.

Dan mag jij die grey areas aanwijzen. Het enige grijze gebied wat ik nu zie, is de vraag was wat een "derived work" is. En dat is niet uniek aan de GPL. De GPL geeft zelfs een definitie, die als "affirmitive defence" kan dienen. Daarmee wordt het grijze gebied dus kleiner. De totale grootte van het grijze gebied blijft dus een opinie, maar het feit is evengoed dat de GPL minder grijze gebieden kent dan proprietary software.

En om nou te zeggen dat de LGPL minder grijze gebieden kent? Het auteursrecht kent tenminste de termen "samengesteld werk" en "afgeleid werk" uit de GPL. Maar "libraries" cq. "bibliotheken"? In het auteursrecht zijn dat organisaties die boeken uitlenen. Juist de LGPL gebruikt dus juridisch vage termen.

[Soultaker]

MSalters schreef op vrijdag 18 december 2009 @ 16:24:
De gebruikers hebben bijvoorbeeld het voordeel dat de applicatie nog onderhouden kan worden als de originele leverancier failliet gaat en wordt ontbonden.

Dat is onzin. Als je de BSD-gelicenseerde broncode hebt van die applicatie dan kan dat net zo goed.

Het probleem dat jij beschrijft ontstaat door het gebruik van een closed source applicatie. Natuurlijk kan die applicatie van BSD-gelicenseerde componenten gebruik maken (maar niet van GPL-gelicenseerde componenten) maar dat maakt het eindproduct niet BSD-gelicenseerd.

Als je als gebruiker de garantie wil dat je een applicatie aan je wensen kunt aanpassen, zonder medewerking van degene die het auteursrecht bezit, dan moet je zorgen dat je een open source applicatie gebruikt. Of die applicatie dan BSD-gelicenseerd of GPL-gelicenseerd is maakt voor de gebruiker geen fluit uit.

[cariolive23]

MSalters schreef op vrijdag 18 december 2009 @ 16:24:
De gebruikers hebben bijvoorbeeld het voordeel dat de applicatie nog onderhouden kan worden als de originele leverancier failliet gaat en wordt ontbonden. In dat geval is de sourcecode van een applicatie onder BSD licentie gewoon weg. Heb je echter een GPL applicatie+source, dan kun je als klant(en) de applicatie zelf in onderhoud nemen.

Sorry, maar waar heb je deze onzin vandaan? Waarom zou BSD-code ineens foetsie zijn? Dit is echt klinkklare onzin, raakt kant noch wal.

BSD is één van de meest vrije licenties, geeft je zo'n beetje de meeste vrijheid met broncode die je maar kunt bedenken. Ik ben geen jurist, laat staan specialist op het gebied van licenties, maar een licentie die zo'n beetje alles toestaat, laat niet zomaar broncode verdwijnen. En omdat alles en iedereen met de broncode aan de slag kan en mag, kan ook iedereen onderhoud op deze code plegen en er afgeleide werken van maken. Er verdwijnt dus helemaal niets bij een faillissement, iedereen kan verder met het product.

[CAPSLOCK2000]

BSD geeft je alleen de code.
GPL zorgt er ook voor dat je die code kunt gebruiken.

GPL heeft aanvullende eisen, zoals dat er geen patenten op mogen zitten en dat er ook een compiler beschikbaar moet zijn en dat je als gebruiker de broncode mag opeisen.
Een gebruiker van een BSD binary kan daar geen enkel recht aan ontlenen.


Er is nog een tweede belangrijk voordeel aan GPL, dat niet technisch is en (dus) moeilijker om hard te maken:
GPL schept een eerlijk speelveld en helpt de spelers eerlijk houden.

Bedrijven vertrouwen elkaar voor geen meter (en terecht). Veel bedrijven hun source code niet openbaren omdat ze bang zijn dat een concurrent een kleine aanpassing maakt (zonder de code te publiceren) waardoor het product veel beter wordt, en vervolgens met alle klanten gaat lopen. Niet dat dat in praktijk zo vaak gebeurd, maar ze zijn er wel allemaal bang voor. Het GPL biedt enige garanties dat niemand een programma inpikt en dat is een heel geruststellende gedachte.

[Soultaker]

CAPSLOCK2000 schreef op zaterdag 19 december 2009 @ 17:43:
Een gebruiker van een BSD binary kan daar geen enkel recht aan ontlenen.

Termen als BSD binary zijn onzinnige FUD. Een binary kan nooit BSD-gelicenseerd zijn, want de BSD licentie is een licentie voor broncode, net zoals de GPL en alle andere licenties. Als je BSD-gelicenseerde broncode van een applicatie hebt, dan kun je daar als gebruiker zonder intentie tot herdistribueren ongeveer hetzelfde mee doen als wanneer die applicatie GPL-gelicenseerd zou zijn. Het cruciale verschil treedt pas op als je een gewijzigde applicatie wil publiceren.

Je kunt dus bijvoorbeeld FreeBSD en RedHat Enterprise Linux vergelijken: beide projecten produceren een besturingssysteem en geven de broncode onder een open-source licentie vrij.

Een binary waar toevallig waar toevallig wat componenten inzitten waarvan de broncode onder een BSD-licentie beschikbaar is gemaakt, blijft gewoon een closed source applicatie. Zo is Google's zoekmachine ook een closed source applicatie, ook al draaien Google's servers op de Linux kernel (en waarschijnlijk nog wel meer GPL-gelicenseerde software). In beide gevallen heb je als eindgebruiker geen beschikking over de broncode. Een gebruiker van Google kan net zo min "rechten ontlenen" aan het gebruik van de zoekmachine als de gebruiker van ieder andere closed source applicatie.

[ Voor 5% gewijzigd door Soultaker op 19-12-2009 18:07 ]

[CAPSLOCK2000]

Soultaker schreef op zaterdag 19 december 2009 @ 18:05:
[...]

Termen als BSD binary zijn onzinnige FUD. Een binary kan nooit BSD-gelicenseerd zijn, want de BSD licentie is een licentie voor broncode, net zoals de GPL en alle andere licenties. Als je BSD-gelicenseerde broncode van een applicatie hebt, dan kun je daar als gebruiker zonder intentie tot herdistribueren ongeveer hetzelfde mee doen als wanneer die applicatie GPL-gelicenseerd zou zijn. Het cruciale verschil treedt pas op als je een gewijzigde applicatie wil publiceren.

Ik geef toe dat de term BSD binary wat kort door de bocht is en dat ik had moeten schrijven "een binary gecompileerd van sources onder de BSD licentie", maar dat is zo lang.

Nee hoor, er is wel degelijk een verschil. Als gebruiker van een GPL programma kun je van de leverancier van die binary de source eisen. Dat geldt niet voor BSD. Als je TV op BSD draait is dat mooi en daarmee basta. Als ie GPL draait kun je van de fabrikant eisen dat hij je alle source geeft.

Een binary waar toevallig waar toevallig wat componenten inzitten waarvan de broncode onder een BSD-licentie beschikbaar is gemaakt, blijft gewoon een closed source applicatie. Zo is Google's zoekmachine ook een closed source applicatie, ook al draaien Google's servers op de Linux kernel (en waarschijnlijk nog wel meer GPL-gelicenseerde software). In beide gevallen heb je als eindgebruiker geen beschikking over de broncode. Een gebruiker van Google kan net zo min "rechten ontlenen" aan het gebruik van de zoekmachine als de gebruiker van ieder andere closed source applicatie.

Wat precies een "gebruiker" is, is wat onduidelijk geworden als het om websites gaat. Het Affero GPL probeert daar wat aan te doen.

[Herko_ter_Horst]

Soultaker schreef op zaterdag 19 december 2009 @ 18:05:
[...]

Termen als BSD binary zijn onzinnige FUD. Een binary kan nooit BSD-gelicenseerd zijn, want de BSD licentie is een licentie voor broncode, net zoals de GPL en alle andere licenties.

Klinklare nonsense!

BSD, GPL en alle andere open source licenses zijn licenties op software^(*) , ongeacht of die software in executeerbare vorm, in source code, in gezongen vorm op een audio-tape of voor mijn part uitgehakt in een kleitablet wordt verspreid.

De BSD licentie is dus wel degelijk van toepassing op de binary. Als er dus BSD-gelicenseerde code in je TV zit, hoort er een copyrightmelding van de orginele maker en de BSD licentie zelf bij te zitten in de documentatie. Zo niet, dan maakt de fabrikant zich schuldig aan onrechtmatige verspreiding van die software.

Uit de BSD:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

(*) of nog algemener: werken die onder het auteursrecht vallen

[ Voor 44% gewijzigd door Herko_ter_Horst op 19-12-2009 22:52 ]

[Herko_ter_Horst]

cariolive23 schreef op zaterdag 19 december 2009 @ 09:43:
[...]

Sorry, maar waar heb je deze onzin vandaan? Waarom zou BSD-code ineens foetsie zijn? Dit is echt klinkklare onzin, raakt kant noch wal.

BSD is één van de meest vrije licenties, geeft je zo'n beetje de meeste vrijheid met broncode die je maar kunt bedenken. Ik ben geen jurist, laat staan specialist op het gebied van licenties, maar een licentie die zo'n beetje alles toestaat, laat niet zomaar broncode verdwijnen. En omdat alles en iedereen met de broncode aan de slag kan en mag, kan ook iedereen onderhoud op deze code plegen en er afgeleide werken van maken. Er verdwijnt dus helemaal niets bij een faillissement, iedereen kan verder met het product.

De enige eis van de BSD is dat de copyright notice en de BSD licentietekst zelf worden meegeleverd (en dat de naam van de maker niet wordt gebruikt om afgeleide producten aan te prijzen). Het meeleveren van de source code is dus géén vereiste. Als een bedrijf dus op de een of andere manier alle kopieen van de broncode in handen krijgt, kan het effectief de code wegmaken/voor zich houden, waarmee het effectief closed source zou worden. Bij de GPL kan dit niet.

Uiteraard is één kopie van de source code genoeg om deze controle te doorbreken en het open source karakter te behouden.

[cariolive23]

Herko_ter_Horst schreef op zaterdag 19 december 2009 @ 22:46:waarmee het effectief closed source zou worden.

Nu draai je de zaken om, BSD-code mag je vrij gebruiken in closed source software. Het is niet zo dat BSD-code in feite closed source is, tenzij de code beschikbaar is.

Daarnaast kies je zelf voor een product waar de code wel of niet van beschikbaar is. Dat is jouw eigen keuze en heeft niets te maken met welke licentie dan ook.

[Herko_ter_Horst]

cariolive23 schreef op maandag 21 december 2009 @ 08:19:
[...]

Nu draai je de zaken om, BSD-code mag je vrij gebruiken in closed source software. Het is niet zo dat BSD-code in feite closed source is, tenzij de code beschikbaar is.

Daarnaast kies je zelf voor een product waar de code wel of niet van beschikbaar is. Dat is jouw eigen keuze en heeft niets te maken met welke licentie dan ook.

Ik zeg nergens dat BSD closed source is, ik zeg dat (omdat er geen vereiste is om de source mee te leveren bij een binary distributie), een "kwaadwillende" partij het effectief closed source kan maken (door niemand ooit meer de source te geven), mits deze partij op de een of andere manier alle kopieen van de source in handen krijgt. Dit in tegenstelling tot GPL, die afdwingt dat een gebruiker toegang kan krijgen tot de source.

[cariolive23]

Kortom, je maakt zelf de verkeerde keuze. Je kiest zelf voor BSD-software waarvan de code niet beschikbaar is. Wiens fout is dat? Dit is vergelijkbaar met de keuze voor closed source software, ook dan heb je niet de beschikking over de source en dus kun je deze source ook niet onderhouden. Wanneer jij de boel wilt kunnen onderhouden, moet je de source hebben. Zorg er dan ook voor dat je die krijgt, anders wordt dit uiteraard een mislukking. Ga niet achteraf zeuren over het ontbreken van code wanneer je dat vooraf al wist, dat is wel erg goedkoop.

Komt bij dat theorie en praktijk hier wel heel ver van elkaar zijn verwijderd. Noem eens een succesvol product dat onder BSD-licentie wordt uitgegeven maar waarvan de code niet beschikbaar is. Ik ben benieuwd, ik ken ze niet.

[Herko_ter_Horst]

cariolive23 schreef op maandag 21 december 2009 @ 11:21:
Kortom, je maakt zelf de verkeerde keuze. Je kiest zelf voor BSD-software waarvan de code niet beschikbaar is. Wiens fout is dat? Dit is vergelijkbaar met de keuze voor closed source software, ook dan heb je niet de beschikking over de source en dus kun je deze source ook niet onderhouden. Wanneer jij de boel wilt kunnen onderhouden, moet je de source hebben. Zorg er dan ook voor dat je die krijgt, anders wordt dit uiteraard een mislukking. Ga niet achteraf zeuren over het ontbreken van code wanneer je dat vooraf al wist, dat is wel erg goedkoop.

Ik maak helemaal geen keuze, ik zeg alleen wat er mogelijk is bij de BSD. Dit in tegenstelling tot de GPL (want daar ging de discussie over). Dat het vergelijkbaar is met de keuze voor closed source is precies mijn punt: bij de BSD kan dit (in theorie) gebeuren, bij de GPL niet. Dat is namelijk één van de doelen van de GPL: open source tot in eeuwigheid afdwingen.

Komt bij dat theorie en praktijk hier wel heel ver van elkaar zijn verwijderd. Noem eens een succesvol product dat onder BSD-licentie wordt uitgegeven maar waarvan de code niet beschikbaar is. Ik ben benieuwd, ik ken ze niet.

Dat je ze niet kent, is niet gek, want je kunt er weinig meer aan zien van de buitenkant én gezien het toch al vrije karakter van de BSD, ligt het niet voor de hand dat de oorspronkelijke maker veel stennis gaat schoppen. Ik heb er geen onderzoek naar gedaan, maar het zou me niets verbazen dat als je in de krochten van Windows gaat graven, je BSD-gelicenseerde code tegenkomt die niet meer elders (als open source) te verkrijgen is.

[cariolive23]

Herko_ter_Horst schreef op maandag 21 december 2009 @ 12:24:
Ik heb er geen onderzoek naar gedaan, maar het zou me niets verbazen dat als je in de krochten van Windows gaat graven, je BSD-gelicenseerde code tegenkomt die niet meer elders (als open source) te verkrijgen is.

Ik weet wel zeker dat Windows gebruik maakt van code die is uitgegeven onder BSD-licentie (bron), Windows is echter niet uitgegeven onder BSD-licentie. Dit is dus weer zo'n voorbeeld van closed source die gebruik maakt van open source uitgegeven onder BSD-licentie. En omdat het dan gesloten is, kun je en hoef je hier zelf geen onderhoud op te plegen. Waar de oorspronkelijke code vandaan komt en waar deze beschikbaar is, is voor jou als gebruiker zelfs niet relevant. Jij kunt de broncode in Windows toch niet aanpassen, dus heb je maar vrij weinig aan de broncode uit product X die wordt gebruikt binnen Windows. Dat is een nadeel van closed source, niet van BSD.

[CAPSLOCK2000]

cariolive23 schreef op maandag 21 december 2009 @ 11:21:
Kortom, je maakt zelf de verkeerde keuze. Je kiest zelf voor BSD-software waarvan de code niet beschikbaar is. Wiens fout is dat? Dit is vergelijkbaar met de keuze voor closed source software, ook dan heb je niet de beschikking over de source en dus kun je deze source ook niet onderhouden. Wanneer jij de boel wilt kunnen onderhouden, moet je de source hebben. Zorg er dan ook voor dat je die krijgt, anders wordt dit uiteraard een mislukking. Ga niet achteraf zeuren over het ontbreken van code wanneer je dat vooraf al wist, dat is wel erg goedkoop.

Dan moet je wel van te voren gaan controleren of de source beschikbaar is en of er geen vreemde voorwaardes zijn toegevoegd. Voor een bekend programma als "SSH" durf ik dat nog wel te zeggen, maar niet voor een onbekende lib. Als het GPL is dan weet ik dat ik de volledige source kan krijgen en dat er geen extra voorwaardes aanhangen.

Een gewone gebruiker kan niet eens controleren of sources wel volledig zijn. Daar heb je een programmeur en/of een jurist voor nodig. Het GPL geeft gebruikers meer zekerheid.

Komt bij dat theorie en praktijk hier wel heel ver van elkaar zijn verwijderd. Noem eens een succesvol product dat onder BSD-licentie wordt uitgegeven maar waarvan de code niet beschikbaar is. Ik ben benieuwd, ik ken ze niet.

Voor angstige bedrijfsjuristen en managers maakt het niks of iets nog nooit is gebeurd, het gaat er om of het met hun werk zou kunnen gebeuren. Ik ben er van overtuigd dat de "open" methode de betere manier is om software te ontwikkelen. Ik weet ook dat er altijd bedrijven zullen zijn die proberen te profiteren van het werk van anderen. Bedrijven zijn bang dat er een slimme programmeur langs komt die 1 regel van hun programma verandert en er dan opeens miljoenen mee verdient zonder terug te delen.


De TCP/IP stack van hele oude versies van Windows NT is op BSD gebaseerd. Naar het schijnt zijn een paar van de basic netwerk-utillities (telnet en ftp ofzo) nog steeds gebaseerd op BSD code. Niet dat ik die sources zou willen (ik pak de originele BSD versie wel), maar ik kan me goed voorstellen dat anderen dat wel zouden willen.

[Gomez12]

CAPSLOCK2000 schreef op maandag 21 december 2009 @ 13:10:
[...]
Als het GPL is dan weet ik dat ik de volledige source kan krijgen en dat er geen extra voorwaardes aanhangen.

Een gewone gebruiker kan niet eens controleren of sources wel volledig zijn. Daar heb je een programmeur en/of een jurist voor nodig. Het GPL geeft gebruikers meer zekerheid.

Leuke stelling, maar 1 vraagje wat gebeurt er als de source er niet meer is of niet meer volledig is?

Gaat dan opeens de programmeur aangeklaagd oid worden omdat hij zelf zijn eigen sources niet meer ter jouwer beschikking kan stellen?

Geen kritiek, maar gewoon puur nieuwsgierige vraag. Als dat het sterke punt van GPL boven BSD is ben ik toch wel even benieuwd wat er nu daadwerkelijk gebeurd als het niet kan.

[cariolive23]

CAPSLOCK2000 schreef op maandag 21 december 2009 @ 13:10:
Een gewone gebruiker kan niet eens controleren of sources wel volledig zijn. Daar heb je een programmeur en/of een jurist voor nodig.

De gebruiker kan niet controleren of de sources wel volledig zijn, maar je verwacht wel dat deze gebruiker de source gaat aanpassen en onderhouden? Dat is waar deze discussie nu over lijkt te gaan. Die programmeur heb je dus toch al nodig.

Het GPL geeft gebruikers meer zekerheid.

Onzin, het geeft totaal geen extra zekerheid. En al helemaal niet voor de gebruiker, voor de gebruiker is er namelijk geen verschil tussen closed source, bsd of gpl. De gebruiker gebruikt de applicatie en gaat niet liggen rommelen in de code.

Ik weet ook dat er altijd bedrijven zullen zijn die proberen te profiteren van het werk van anderen.

Dat is juist het idee achter bsd, dat kan dan toch onmogelijk een probleem zijn?

Bedrijven zijn bang dat er een slimme programmeur langs komt die 1 regel van hun programma verandert en er dan opeens miljoenen mee verdient zonder terug te delen.

En wat dacht je van een programmeur die een regel GPL-code in een programma gebruikt? Dan moet opeens de code van het project worden vrijgegeven, kan echt iedereen met de code aan de haal en weet je zeker dat je er nooit meer iets aan kunt verdienen. Ja, met diensten, maar niet met de code. Dit geldt uiteraard ook voor anderen, iedereen kan diensten leveren voor een applicatie. Met vrij beschikbare code wordt dit nog eenvoudiger. GPL is wat dat betreft gevaarlijker voor bedrijven.

De TCP/IP stack van hele oude versies van Windows NT is op BSD gebaseerd. Naar het schijnt zijn een paar van de basic netwerk-utillities (telnet en ftp ofzo) nog steeds gebaseerd op BSD code. Niet dat ik die sources zou willen (ik pak de originele BSD versie wel), maar ik kan me goed voorstellen dat anderen dat wel zouden willen.

Windows is geen open source. Dat een onderdeel van Windows gebruik maakt van een stuk BSD-code, prachtig, maar daar heb jij niets aan. Althans, wanneer MS dit stuk heeft afgesloten voor de buitenwereld, dan heb jij daar niets aan. Gelukkig kun je de originele broncode pakken, kun je er zelf mee aan de slag gaan. En nee, daarmee kun je Windows niet gaan veranderen/verbeteren, dat is nu eenmaal een eigenschap van closed source.

[CAPSLOCK2000]

Gomez12 schreef op maandag 21 december 2009 @ 13:30:
Leuke stelling, maar 1 vraagje wat gebeurt er als de source er niet meer is of niet meer volledig is?

Gaat dan opeens de programmeur aangeklaagd oid worden omdat hij zelf zijn eigen sources niet meer ter jouwer beschikking kan stellen?

Geen kritiek, maar gewoon puur nieuwsgierige vraag. Als dat het sterke punt van GPL boven BSD is ben ik toch wel even benieuwd wat er nu daadwerkelijk gebeurd als het niet kan.

Ja, dan kun je de verspreider aanklagen. Dat heeft de programmeur zichzelf opgelegd op het moment hij voor het GPL koos. De werkelijkheid is alleen net wat complexer dan de samenvattingen die we hier bespreken. Het GPL biedt wat oplossingen.

Als je de source en de binary samen verspreidt is dat goed genoeg. Dan is het aan de gebruiker om die sources te bewaren. Als programmeur heb je dan geen verdere verplichtingen meer.

Ook zit er een tijdslimiet aan de verplichtingen. Uit mijn hoofd loopt die verplichting tot 3 jaar vanaf het moment dat je de binary verspreidt. De verplichting ligt ook bij de distributeur, en niet bij de programmeur. Als ik jouw een 15 jaar oude binary geef dan moet ik voor de source zorgen. Jij kan niet bij de oorspronkelijke programmeur gaan klagen, zijn verplichtingen zijn 12 jaar geleden al verlopen.

Als puntje bij paaltje komt is het dus mogelijk om de verspreider aan te klagen. Zo'n beetje iedere grote fabrikant van consumentenapparatuur is al eens aangeklaagd, vorige week nog 14 tegelijk (nieuws: Samsung, JVC en Western Digital aangeklaagd om schenden gplv2). Dusver is er altijd een oplossing gevonden zonder boetes.

[Herko_ter_Horst]

cariolive23 schreef op maandag 21 december 2009 @ 14:00:
[...]

De gebruiker kan niet controleren of de sources wel volledig zijn, maar je verwacht wel dat deze gebruiker de source gaat aanpassen en onderhouden? Dat is waar deze discussie nu over lijkt te gaan. Die programmeur heb je dus toch al nodig.

[...]

Onzin, het geeft totaal geen extra zekerheid. En al helemaal niet voor de gebruiker, voor de gebruiker is er namelijk geen verschil tussen closed source, bsd of gpl. De gebruiker gebruikt de applicatie en gaat niet liggen rommelen in de code.

Een "gewone" thuisgebruiker zal inderdaad niet zo snel iets met de code gaan doen. Maar wat als de "gebruiker" een bedrijf is dat van bepaalde technologie afhankelijk is? Mocht de leverancier omvallen of in andere handen overgaan, dan ben je toch wel blij met de garantie dat de technologie open source is en blijft, zodat je - als de nood aan de man komt - zelf het onderhoud op die code kan doen, of laten doen.

[...]

Dat is juist het idee achter bsd, dat kan dan toch onmogelijk een probleem zijn?

Dat het de oorspronkelijke ontwikkelaar niet uitmaakt, wil nog niet zeggen dat het gebruikers (zoals in het voorbeeld hierboven) niet uitmaakt.

[...]

En wat dacht je van een programmeur die een regel GPL-code in een programma gebruikt? Dan moet opeens de code van het project worden vrijgegeven, kan echt iedereen met de code aan de haal en weet je zeker dat je er nooit meer iets aan kunt verdienen. Ja, met diensten, maar niet met de code. Dit geldt uiteraard ook voor anderen, iedereen kan diensten leveren voor een applicatie. Met vrij beschikbare code wordt dit nog eenvoudiger. GPL is wat dat betreft gevaarlijker voor bedrijven.

Alsof het kopieren van één regel er toe leidt dat jouw werk een afgeleid werk wordt. GPL is wat dat betreft stricter omdat alles open juist het doel is wat de bedenkers van de GPL voor ogen hebben.

[cariolive23]

Geen idee wat ik fout doe, maar ik probeer nu al meerdere keren duidelijk te maken dat wanneer je zelf de code wilt (kunnen) onderhouden, je er zelf ook voor moet zorgen dat je die code in huis hebt. Waarom komt die boodschap nu niet over, wat doe ik fout?

Men doet voorkomen alsof BSD de code laat verdwijnen en GPL code op magische wijze doet opduiken. Beide is onzin, je moet er zelf voor zorgen dat je de code in huis hebt. Anders zul je altijd zien dat je de verkeerde versie hebt of juist helemaal niets hebt...

Alsof het kopieren van één regel er toe leidt dat jouw werk een afgeleid werk wordt.

Geen idee, misschien bij twee regels code? Of bij drie, of was het nu bij 4 regels? Waar ligt die grens en welke risico's wil je nemen? Met BSD loop je als leverancier geen risico's, er is namelijk helemaal geen verplichting om je eigen code te publiceren. Uiteraard mag het wel, het wordt ook zeer gewaardeerd, maar het moet niet.

En de gebruiker die kiest voor closed source, ook dat doe je helemaal zelf.

[CAPSLOCK2000]

cariolive23 schreef op maandag 21 december 2009 @ 14:00:

De gebruiker kan niet controleren of de sources wel volledig zijn, maar je verwacht wel dat deze gebruiker de source gaat aanpassen en onderhouden? Dat is waar deze discussie nu over lijkt te gaan. Die programmeur heb je dus toch al nodig.


Onzin, het geeft totaal geen extra zekerheid. En al helemaal niet voor de gebruiker, voor de gebruiker is er namelijk geen verschil tussen closed source, bsd of gpl. De gebruiker gebruikt de applicatie en gaat niet liggen rommelen in de code.

De meeste gebruikers zullen de source nooit aanpassen. De enkeling die dat wel wil huurt daar een programmeur voor in. (Een "gebruiker" kan ook een groot bedrijf zijn).

Bij BSD moet je van te voren bedenken dat je dat in de toekomst wel eens zou kunnen willen. Bij GPL heb je meer zekerheid. Als je bij je GPL software de source niet krijgt kun je de leverancier aanklagen, bij BSD kan dat niet. Je zou kunnen zeggen "Als je dat belangrijk vindt, dan moet je maar extra afspraken maken met de leverancier, zoals dat je alle sources krijgt, en dat het met een standaard compiler gebouwd kan worden". Dat kan, maar waarom zelf voorwaardes gaan opstellen als het GPL een kant en klaar setje goed doordachte voorwaardes levert.

Ik heb het al een paar keer geschreven, maar voor programmeurs zit er maar weinig verschil tussen GPL en BSD. Voor gebruikers is het verschil dat BSD je geen enkel recht geeft anders dan het draaien van de binary, terwijl GPL je verschillende rechten geeft om de source en binary te gebruiken. Zo kan het zijn dat op een BSD binary patenten zitten waardoor je het niet mag gebruiken. Een GPL binary beloofd dat er geen patenten op zitten.

[...]

Dat is juist het idee achter bsd, dat kan dan toch onmogelijk een probleem zijn?

Op zich niet, maar veel mensen/bedrijven zullen zich genaaid voelen als een concurrent geld verdient aan hun product zonder verbeteringen terug te delen en daarom durven ze niet aan Open Source te beginnen. Profiteren was misschien ook niet helemaal het juiste woord. Ik overwoog om "misbruik maken" te schrijven, maar aangezien de licentie het toestaat is het ook niet helemaal het juiste woord.

Stel nu dat er een slimme programmeur langs komt die Apache 100x zo snel maakt door 2 regels code aan te passen. Vervolgens noemt hij z'n product SuperApache, verkoopt het als closed source product voor E10 per stuk en verdient er miljoenen mee. Wed maar dat een hoop bedrijven die nu Apache sponsoren zeer geirriteerd zouden zijn. Dit voorbeeld is onwaarschijnlijk, maar zeker niet onmogelijk.

En wat dacht je van een programmeur die een regel GPL-code in een programma gebruikt? Dan moet opeens de code van het project worden vrijgegeven,

Dan had je die code maar niet moeten gebruiken. (Overigens geldt het niet bij 1 regel. Rechters hebben al lang vastgesteld dat 1 regel geen overtreding is, maar dat terzijde.) . Als je een paar regels van de Windows source code had gebruikt dan was je net zo zeer de pineut geweest.

kan echt iedereen met de code aan de haal en weet je zeker dat je er nooit meer iets aan kunt verdienen.
Ja, met diensten, maar niet met de code. Dit geldt uiteraard ook voor anderen, iedereen kan diensten leveren voor een applicatie. Met vrij beschikbare code wordt dit nog eenvoudiger. GPL is wat dat betreft gevaarlijker voor bedrijven.

99% van het geld komt toch al van diensten. Behalve Microsoft en wat game-studio's zijn er maar weinig bedrijven die hun geld verdienen aan licenties. Het allergrootste deel gaat uit naar ondersteuning.
Closed source programma's concurreren als totaalpakket. Je kiest niet alleen voor een binary, maar je kiest ook voor het bedrijf dat je gaat ondersteunen, want niemand anders kan je ondersteunen.

In de open-source wereld kun je het programmeren en ondersteunen uitbesteden aan verschillende bedrijven. Je kan zelfs halverwege beslissen om over te stappen naar een concurrent. Iedereen heeft toegang tot alle informatie en kan (in principe) alle diensten en ondersteuning leveren.

Wat is het voordeel voor de programmeur? Geen enkel, maar ik beweer dan ook al een tijdje dat GPL voor gebruikers is, niet voor programmeurs.

Het geeft natuurlijk wel vertrouwen aan je klanten als je al je broncode durt te publiceren. Daarmee zeg je "Kijk eens hoe netjes wij programmeren, en we zijn zo goed in de ondersteuning dat we niet bang zijn voor de concurrentie. Zelfs als onze concurrente de source hebben dan is onze service nog altijd beter!"

Windows is geen open source. Dat een onderdeel van Windows gebruik maakt van een stuk BSD-code, prachtig, maar daar heb jij niets aan. Althans, wanneer MS dit stuk heeft afgesloten voor de buitenwereld, dan heb jij daar niets aan. Gelukkig kun je de originele broncode pakken, kun je er zelf mee aan de slag gaan. En nee, daarmee kun je Windows niet gaan veranderen/verbeteren, dat is nu eenmaal een eigenschap van closed source.

Precies, als gebruiker heb ik er niks aan dat er stukken BSD code in Windows zitten. Als het GPL code was geweest had ik daar wel extra rechten aan kunnen ontlenen. Om de oorspronkelijke versie te gebruiken zal ik allereerst moeten weten welke code er gebruikt is. Verder zou ik ook wel de aanpassingen van Microsoft er bij willen hebben, want die oorspronkelijke sources zijn vast niet te compilen onder Windows.


Ten overvloede, voor techneuten die zelf software schrijven zijn de verschillen tussen BSD en GPL niet echt interessant. Voor gebruikers, managers en juristen is er wel degelijk een groot verschil. Voor verkopers van binaries is het GPL ronduit nadelig.

[cariolive23]

CAPSLOCK2000 schreef op maandag 21 december 2009 @ 15:42:
Stel nu dat er een slimme programmeur langs komt die Apache 100x zo snel maakt door 2 regels code aan te passen. Vervolgens noemt hij z'n product SuperApache, verkoopt het als closed source product voor E10 per stuk en verdient er miljoenen mee. Wed maar dat een hoop bedrijven die nu Apache sponsoren zeer geirriteerd zouden zijn. Dit voorbeeld is onwaarschijnlijk, maar zeker niet onmogelijk.

Een mooier voorbeeld had je niet kunnen geven! Apache HTTP Server wordt uitgeven onder de Apache Licence en dit is wat ik in de FAQ tegenkom:

I've made improvements to the Apache code; may I distribute the modified result?

Absolutely -- subject to the terms of the Apache license, of course. You can give your modified code away for free, or sell it, or keep it to yourself, or whatever you like. Just remember that the original code is still covered by the Apache license and you must comply with its terms. Even if you change every single line of the Apache code you're using, the result is still based on the Foundation's licensed code. You may distribute the result under a different license, but you need to acknowledge the use of the Foundation's software. To do otherwise would be stealing.

If you think your changes would be found useful by others, though, we do encourage you to submit them to the appropriate Apache project for possible inclusion.

Met andere woorden, jouw SuperApache kun je gewoon verkopen en grof geld aan verdienen zonder ook maar één regel code aan Apache retour te geven. En alle sponsors zijn hier van op de hoogte, zullen hier niet over gaan zeuren. Dit wisten ze vooraf, ze zijn niet helemaal gek.

En toch is Apache één van de mooiste projecten en mooiste producten.

[CAPSLOCK2000]

cariolive23 schreef op maandag 21 december 2009 @ 15:40:
Geen idee wat ik fout doe, maar ik probeer nu al meerdere keren duidelijk te maken dat wanneer je zelf de code wilt (kunnen) onderhouden, je er zelf ook voor moet zorgen dat je die code in huis hebt. Waarom komt die boodschap nu niet over, wat doe ik fout?

Men doet voorkomen alsof BSD de code laat verdwijnen en GPL code op magische wijze doet opduiken. Beide is onzin, je moet er zelf voor zorgen dat je de code in huis hebt. Anders zul je altijd zien dat je de verkeerde versie hebt of juist helemaal niets hebt.

Dat deel komt wel over. Onder BSD zal je zelf achter die source code aan moeten gaan, plus de controle dat je die code kan (compilers) en mag (patenten) gebruiken. Absolute zekerheid bestaat niet, maar GPL geeft meer zekerheid dan BSD dat je de code zonder problemen kunt gebruiken.

Geen idee, misschien bij twee regels code? Of bij drie, of was het nu bij 4 regels? Waar ligt die grens en welke risico's wil je nemen?

Dat "probleem" geldt ook voor ieder boek. Mag je 1 woord overnemen uit een ander boek? 2 woorden? 1 zin? en als die zin "ik hou ook van jouw" is, mag het dan wel? Er zijn richtlijnen, maar uiteindelijk beslist de rechter wat wel en niet mag.

Met BSD loop je als leverancier geen risico's, er is namelijk helemaal geen verplichting om je eigen code te publiceren. Uiteraard mag het wel, het wordt ook zeer gewaardeerd, maar het moet niet.

Jij denkt vanuit het oogpunt van de leverancier. Als gebruiker heb ik sch*t aan de leverancier maar gaat het om wat ik met een programma mag.

En de gebruiker die kiest voor closed source, ook dat doe je helemaal zelf.

Natuurlijk mag de gebruiker dat zelf kiezen, ik probeer te beargumenteren dat een slimme gebruiker de voorkeur geeft aan GPL software boven andere licenties. De rechten die het GPL geeft gaan ten koste van de programmeur en de eventuele verkoper, maar als gebruiker kies ik voor m'n eigen rechten, niet voor die van de programmeur/verkoper.

[cariolive23]

CAPSLOCK2000 schreef op maandag 21 december 2009 @ 15:58:ik probeer te beargumenteren dat een slimme gebruiker de voorkeur geeft aan GPL software boven andere licenties.

Ok, dan ben ik blijkbaar niet slim.

Maar jij evenmin, jij haalt Apache aan als ideaal voorbeeld van software waar geen afgeleiden van mogen worden gemaakt zonder dat de aangepaste code wordt vrijgegeven. Apache geeft zelf aan dat je geld mag verdienen aan aangepaste code en dat er geen enkele verplichting is om deze code vrij te geven. Jij slaat hier dus even een plankje mis.

[CAPSLOCK2000]

cariolive23 schreef op maandag 21 december 2009 @ 15:56:

Met andere woorden, jouw SuperApache kun je gewoon verkopen en grof geld aan verdienen zonder ook maar één regel code aan Apache retour te geven. En alle sponsors zijn hier van op de hoogte, zullen hier niet over gaan zeuren. Dit wisten ze vooraf, ze zijn niet helemaal gek.

En toch is Apache één van de mooiste projecten en mooiste producten.

Je weet niet hoeveel potentiele sponsoren hebben geweigerd omdat ze dit risico niet willen lopen.
Ik denk dat het in het geval van Apache wel mee valt, maar Apache is dan ook bij uitstek een voorbeeld van een programma dat gedragen is door techneuten. Verder is een webserver gebonden aan allerlei bestaande standaarden die niet snel veranderen omdat er miljoenen client-pc's van afhankelijk zijn. De kans dat een concurrent een kleine verbetering kan maken die grote gevolgen heeft zonder die verandering te publiceren is minimaal.

Ik denk dat op lange termijn de meeste bedrijven er wel achter zullen komen dat ze aangepaste software beter kunnen publiceren dan geheim houden, maar de meeste bedrijven gaan op korte termijn failliet. Als ik het eeuwige leven had zou ik ook zeggen "doe maar BSD, ooit komt het vanzelf wel goed". Maar dat heb ik niet, dus kies ik liever voor een licentie die een duuwtje in de goede richting geeft.

cariolive23 schreef op maandag 21 december 2009 @ 16:04:
Ok, dan ben ik blijkbaar niet slim.

Sorry, zo bedoelde ik het net, 't was niet mijn bedoeling iemand te beledigen.

Maar jij evenmin, jij haalt Apache aan als ideaal voorbeeld van software waar geen afgeleiden van mogen worden gemaakt zonder dat de aangepaste code wordt vrijgegeven. Apache geeft zelf aan dat je geld mag verdienen aan aangepaste code en dat er geen enkele verplichting is om deze code vrij te geven. Jij slaat hier dus even een plankje mis.

Ik heb het blijkbaar niet duidelijk genoeg opgeschreven, want ik noem Apache juist vanwege de BSD(achtige) licentie. Dat je er geld aan mag verdienen zonder de code terug te geven is precies waarom ik het noem.
Het mag, en de sponsoren weten dat; toch denk ik dat sommigen het niet leuk zouden vinden als iemand er grof geld mee zou verdienen.

[ Voor 25% gewijzigd door CAPSLOCK2000 op 21-12-2009 16:17 ]

[CAPSLOCK2000]

dubbel

[ Voor 98% gewijzigd door CAPSLOCK2000 op 21-12-2009 16:16 ]