OpenSSL wil verder onder Apache 2.0-licentie

Het OpenSSL-project wil overstappen van zijn eigen gebruikslicentie naar de Apache 2.0-licentie. Voor de overstap is de goedkeuring nodig van iedereen die als auteur mee heeft gewerkt aan de code van OpenSSL.

De bestaande licentie is volgens de organisatie achter OpenSSL inmiddels meer dan 20 jaar oud en zorgt voor onoverzichtelijke of zelfs onwerkbare situaties wanneer de opensource-software gebruikt wordt in bijvoorbeeld commerciële producten, of wanneer een andere ontwikkelaar een aangepaste versie wil publiceren. Vandaar dat het bestuur achter OpenSSL over wil stappen op Apache 2.0, een opensourcelicentie die veel gebruikt wordt, goed bekend is en ertoe moet bijdragen dat OpenSSL in de toekomst ook de meest gebruikte toolkit blijft voor ssl, tls en cryptografie.

The OpenSSL Project heeft voor de overstap de toestemming nodig van iedereen die als auteur genoteerd staat. Omdat het gaat om opensource-software waar iedereen aan mee mag werken en omdat OpenSSL sinds Heartbleed sterk aan populariteit heeft gewonnen, zijn er bijna 400 auteurs mee gemoeid. De organisatie heeft alle mailadressen in zijn bestand gecontacteerd met het verzoek om goedkeuring te geven voor de overstap van de huidige licentie, gebaseerd op die van voorganger SSLeay, naar Apache 2.0.

Volgens The Register is zwijgen echter instemmen en gaat het niet om 400 auteurs maar om rond de duizend. Theo de Raadt, oprichter van OpenBSD, oprichter van OpenSSL-fork LibreSSL en mede-ontwikkelaar aan OpenSSL, is het niet eens met de aanpak van het OpenSSL-bestuur. 'Ik maak me zorgen dat de rechten van de auteurs met de voeten getreden worden op deze manier. Ze krijgen geen andere keus dan hun werk overzetten naar deze licentie, die vermoedelijk uitgekozen is door grote bedrijven als The Linux Corporation, Intel en Oracle.'

Door Mark Hendrikman

Redacteur

25-03-2017 • 13:03

68 Linkedin Whatsapp

Submitter: Rafe

Reacties (68)

68
68
31
11
1
33
Wijzig sortering
Bij mij gaat de vlag uit.

De reden voor deze licentiewijziging is dat de huidige OpenSSL licentie incompatible is met de GPL licentie.

Waarom dan? Nou, de OpenSSL licentie is gebaseerd op de BSD 4-clause licentie, en bevat de tekst:

3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)"

Is dat erg? Wel als je software met de GPL licentie hebt die gebruik maakt van de OpenSSL library.

Waarom dan? Dan zet je toch bovenstaande credits ergens neer?

Nou, dat mag niet. Volgens de GPL-zealots is dit geen "credits" maar een "advertentie". En door te eisen dat je zo'n "advertisement clause" naleeft bij (re)distributie leg je beperkingen op aan de software. Dat mag, maar niet als de software gedistribueerd wordt onder de GPL. Immers, in de GPL staat:

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. [mijn nadruk - Freek]

Het is dus niet mogelijk om een GPL-gelicenceert programma te distribueren die gebruik maakt van de OpenSSL library. Je kan immers bij de distributie niet aan beide licenties tegelijk voldoen. Aparte distributie van library en programma mag van de GPL ook niet. Zelfs als het programma dynamisch linkt is met OpenSSL (en er geen letter OpenSSL code in de distributie van het programma zit). De FSF heeft het standpunt dat er ook dan sprake is van "derivative work". Dat is controversieel, maar in elk geval Debian volgt dit standpunt.

Nu is dit lang bekend (zie bijvoorbeeld mijn mail naar debian-legal in 2004), maar de OpenSSL ontwikkelaar stonden op het standpunt dat dit wel een erg stricte licentie-interpretatie was, en dat het allemaal wel goed kwam als je OpenSSL als "systeem library" zou zien (beetje dezelfde naiviteit als de Linux kernel, die wordt gedistribueerd onder de GPLv2-only licentie, en is NIET compatible met software die onder de "GPLv3 of hoger" licentie wordt gedistribueerd). Nee dus.

In de tussentijd is de halve OpenSSL library opnieuw geschreven (ja, alleen vanwege deze ene "advertentie" clausule), in GnuTLS. Echter, GnuTLS is nooit de drop-in replacement geweest van OpenSSL die het beoogde te zijn.

Ik ben erkentelijk dat de OpenSSL auteurshebbenden proberen dit recht te zetten. Ik hoop dat het ze lukt.

[Edit: enkele tikfouten verbeterd, standpunt Debian toegevoegd, URLs toegevoegd.]

[Reactie gewijzigd door MacFreek op 26 maart 2017 23:33]

Een aanpassing van de licentie is zeker welkom, het is enkel jammer dat ze niet voor een vrijere licentie gaan zoals ISC, op die mannier bleven ze compatibel met andere OpenSSL forks zoals LibreSSL en los je ook die compatibiliteitsproblemen op.

Ook de manier waarop laat de wensen over: "Als je niet antwoordt op de mail gaan we er van uit dat je geen bezwaren hebt".
Dat kan toch niet?

Theo heeft al een gelijkaardige mail rondgestuurd om gcc van licentie te veranderen...
Ook de manier waarop laat de wensen over: "Als je niet antwoordt op de mail gaan we er van uit dat je geen bezwaren hebt".
Dat kan toch niet?
Even cynisch: Het mag misschien niet, maar het kan wel.

Het is vrij simpel: ze kondigen het aan, mocht iemand bezwaar maken, dan doen ze het niet. De kans is wel heel erg klein dat iemand geen bezwaar maakt, en dan toch een rechtzaak begint.

En als niemand een rechtzaak begint, dan kan het blijkbaar gewoon.

Iets minder cynisch: het is een pragmatische benadering die op gespannen voet staat met de zeer principiële standpunten van mensen als Richard Stallman en Theo de Raadt.

Ik ben wel blij met deze pragmatische benadering. Dan kunnen we het tenminste hebben over de zaken die wel van belang zijn. Want (technische) bezwaren heb ik genoeg tegen de OpenSSL library (geef mij maar iets als NaCL, ook al is diens auteur, Dan Bernstein, wellicht net zo principieel als bovenstaande heren).
Nu kun je dan wel verwijtend naar OpenSSL kijken, maar primair is dat toch een GPL probleem en geen BSD-licentie probleem. BSD staat (zelfs met die 4'de clause) bekend als een erg vrije licentie die erg compatible is, terwijl GPL berucht is om z'n incompabiliteit met andere Open-Source licenties. Er is niet voor niets een GPL-light: de Lesser GPL aka LGPL.
Dat is dan verkeerd overgekomen. Ik verwijt OpenSSL niets. Mijn enige verwijt is dat de opstellers van de GPL nog altijd te weinig doen om de incompatibiliteitsproblemen onder de aandacht te brengen bij gebruikers (de programmeurs). Kijk hoe ze actief de GPL pushen en de LGPL afraden. Licentie incompatibiliteit is bij de meeste programmeurs niet voldoende bekend. Hoeveel mensen die dit lezen zullen weten dat GPLv3 incompatible is met GPLv2? Ik denk niet veel.
Mijn enige verwijt is dat de opstellers van de GPL nog altijd te weinig doen om de incompatibiliteitsproblemen onder de aandacht te brengen
Komt doordat Stallman vooral een hacktivist is en niet echt een programmeur. Net zoals die regel van hem: 'free as in free speech, not as in free beer'. Klopt gewoon helemaal niks van maar ja wat doe je ertegen. Hij kiest ervoor die mythe te blijven verspreiden.

Het was de GNU van Stallman die Linux ineens 'GNU Linux' begon te noemen... Linus zelf vindt dat belachelijk. Het past wel een beetje in de GPL filosofie. Of het is GPL of het wordt GPL Bwuhahaha. Linus heeft ook regelmatig hard uitgehaald naar de copyleft beweging. Hij heeft een haat-liefde verhouding ermee.
I personally think this arguing for lawyering has become a nasty
festering disease, and the SFC and Bradley Kuhn has been the Typhoid
Mary spreading the disease.

The most shining moment for the SFC - hey, it's the lead-in on the
wikipedia page - was the GPL compliance enforcement for BusyBox.

And let us not kid ourselves. That may be the shining moment for SFC,
but it was *not* a shining moment for BusyBox.

I'm not aware of anybody but the lawyers and crazy people that were
happy about how the BusyBox situation ended up. Please pipe up if you
actually know differently. All it resulted in was a huge amount of
bickering, and both individual and commercial developers and users
fleeing in droves. Botht he original maintainer and the maintainer
that started the lawsuits ended up publicly saying it was a disaster.

So I think the whole GPL enforcement issue is absolutely something
that should be discussed, but it should be discussed with the working
title

"Lawyers: poisonous to openness, poisonous to community, poisonous to
projects".
(bron)

Buiten Linux zijn er ook niet zo gek veel interessante projecten onder de GPL uitgegeven. Gelukkig want voor mij als dev is het waardeloos als je de GPL er aan hangt. Gewoon veel teveel haken en ogen voor iets wat zgn 'vrije software' voor moet stellen.

[Reactie gewijzigd door OddesE op 28 maart 2017 09:22]

De licentie van de OpenSSL code staat toch volledig los van de code van de mogelijke GPL software die de OpenSSL functies aanroept? Het lijkt mij erg raar als de GPL ook opeens gaat gelden voor alle regels code die je in je software hebt, zeker als die gebruikte code al onder een andere licentie is vrijgegeven.
Dat is juist precies wat de gpl doet: als je code combineerde met gpl code moet het geheel onder de gpl verspreid worden. Als je dat niet wilt moet je de gpl code er maar niet in stoppen...
Alleen als je software gaat verspreiden, wat de GPL niet dwingt je te doen. Voor bijvoorbeeld een SaaS is dat dus geen probleem. Mocht je dat als auteur niet fijn vinden, moet je naar de AGPL kijken.
Je mist voor een SaaS nou net het belangrijkste deel :
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
En persoonlijk ken ik geen SaaS model waarin het publiek niet te maken krijgt met de gemodificeerde versie
SaaS-gebruik is geen verspreiding (source of gecompileerd) volgens de GPL, maar een gemodificeerde versie die je prive mag gebruiken zonder je veranderingen te openbaren. Dit staat bekend als de 'ASP loophole'. In de GPLv3 staat:
Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
De GNU schrijft er zelf over:
But suppose the program is mainly useful on servers. When D modifies the program, he might very likely run it on his own server and never release copies. Then you would never get a copy of the source code of his version, so you would never have the chance to include his changes in your version. You may not like that outcome. Using the GNU Affero GPL avoids that outcome.

[Reactie gewijzigd door Rafe op 29 maart 2017 18:34]

Hoe kan je nou als niet-auteur de licentie van een bepaald stuk software zomaar veranderen, je hebt het toch niet gemaakt?
De twee stukken software samen worden een 'derived work'.

Deze term komt uit de copyright wetgeving en gaat er over wanneer een werk nog wel onder het copyright valt en wanneer niet meer. Pak ik jouw boek maar verander ik één zin, dan is het nieuwe werk een 'derived' (afgeleid) werk en blijft het oorspronkelijke copyright gelden.

Wat de GPL doet is afdwingen: ja, je krijgt een kopie van ons copyright (copyleft), maar alleen als je afgeleide werken ook onder de GPL publiceert.

Problemen hiermee:
Wanneer is het een derived work? Feitelijk weet je het pas zeker als je het aan de rechter vraagt => onzekerheid
Voeg je twee werken samen, waar wordt het samengestelde werk dan van afgeleid? De GPL stelt: altijd van de GPL => incompatibiliteit
Ah op die manier. Ik zou zeggen dat het gebruiken van een library niet het "samenvoegen" van twee werken is. Je gebruikt alleen de code als een library, maar je veranderd de library verder niet, de source files van die library blijven hetzelfde. Dan zou ik zeggen dat er dan ook geen derived work word gemaakt van de library en je dus de copyright van beiden los van elkaar moet zien.

Maar blijkbaar hebben veel slimmere mensen dan ik hier al jaren over gediscussieerd, in ieder geval een goede reden om dus geen GPL licentie te gebruiken, IMHO.
Vandaar ook de LGPL. Die noemt het FSF nu zelf de Lesser GPL, maar stond oorspronkelijk voor Library GPL. De LPGL heeft die eis niet en dat maakt het leven een stuk makkelijker.

Maar even filosofisch... wat is het verschil tussen een library en een application? Het hebben van een main() functie? Want daar staat meestal niet veel in....
Maakt op zich niet uit of het een library of een applicatie is. Het gaat er mij om dat je een bestand binnenhaalt met daarin code waar iemand anders copyright op heeft en die onder een bepaalde licentie heeft vrijgegeven. Dan vind ik het raar dat er een licentie is die de bestaande licentie over code waarover je geen copyright hebt kan veranderen.
Dat kan die licentie ook niet. Dan heb je dus een probleem.
Bijvoorbeeld stel je gebruikt een library van Microsoft en een die onder de GPL is uitgegeven, dan kun jij natuurlijk niet de library van MS ineens onder de GPL gaan hangen. Dus betekent dat dat de twee niet samen kunnen gaan.

Daarom hoor je ook zoveel verhalen over de incompatibiliteit van de GPL. De eis van wederkerigheid ('quid pro quo') klinkt heel redelijk maar in de praktijk blijkt hij vaak verdomd lastig. En dat wordt alleen maar erger want software wordt steeds meer gebouwd door hele verzamelingen libraries aan elkaar te knopen. De tijd dat alle code in een applicatie door slechts één bedrijf of individu geschreven werden is echt voorbij. En dus wordt compatibiliteit, niet alleen technisch, maar dus ook juridisch, steeds belangrijker.
Op die fiets! Bedankt voor de uitleg :)
Als je het niet kan veranderen, moet je het ook niet gaan meeverspreiden.
hmm de apache licence is ook niet heilig, dan krijg je zometeen zo enorm veel wildgroei dat je er ook niets mee aan hebt, bovendien biedt het geen mogelijkheden om commeciele toepassingen ook commercieel te houden (lees: bedrijven een bijdrage te vragen voor gebruik in niet-open-toepassingen. dat is zowiso iets dat me al jaren een doorn in het oog is,

alles MOET opensource, of erger nog alles moet gratis, maar de kosten dekken, ho maar... juist zo, juist op deze manier maak je het gratis en uiterst gemakkelijk voor bedrijven om dik te verdienen over de rug van de gemeenschap.

juist in iets als openssl zou ik verwachten dat je licenties probeert te verkopen van bijv 0.1 ct per verkocht device. of 0,001ct per verkochte software licentie. op die manier kun je grotere bedrijven vragen om bij te dragen in de ontwikkelkosten, tegelijk kunnen ze er voor kiezen hun code opensource te maken en onder de licentiekosten uit te komen, maar tegelijk dragen ze dan dus weer code bij .... zaken als 'de linux kernel, openssl, apache webserver etc zouden daar allemaal baat bij hebben.
Anoniem: 26306
@i-chat25 maart 2017 13:32
Wat je zegt over de Apache 2.0 license is niet waar. Hij is ongeveer net zo vrij als de BSD license, dus je kunt er prima gebruik van maken en toch zelf geld verdienen met je eigen software. Die hoeft niet eens open source te zijn. Het is niet zoals de GPLv3 license dat alles ermee getaint wordt.

Grote bedrijven dragen al bij in ontwikkelkosten. Vaak wordt er werk gesponsord dat vervolgens wordt teruggegeven aan de community. Het doel van zulke bedrijven zal niet zijn dat ze zelf unieke dingen kunnen doen met encryptie. Het doel zal zijn dat ze niet zelf dit soort foutgevoelige code te schrijven.

Ik vraag me echter wel af hoe serieus de mening van Theo de Raadt gehoord moet worden in deze. Ik vermoed dat het niet veel uitmaakt wat voor nieuws er is over OpenSSL, hij doet altijd zijn best weer even zijn gal te spuwen.
Hij heeft wel degelijk een punt als hij zegt dat geen reactie geven iets anders is dan toestemmen. In de mail die OpenSSL heeft ingestuurd staat dat ze bij het uitblijven van een reactie ervan uitgaan dat de persoon geen bezwaar heeft. Dat is simpelweg niet juridisch houdbaar.

Wat De Raadt denkt over de Apache 2.0-licentie is in dit geval minder relevant inderdaad, het artikel legt hier teveel nadruk op, terwijl zijn andere punt veel belangrijker is.
Wat is het verschil tussen de Apache 2.0 en BSD licenties eigenlijk precies?
Voornamelijk de patent clausule: je kan bij de Apache 2 license niet 'sneaky' software open-sourcen en vervolgens bij het gebruik door anderen ineens geld gaan vragen voor patenten op die software.

Daarnaast is de Apache 2 license een stuk meer tekst, waardoor er ook zaken zijn bepaald over merkenrecht en duidelijk laten zien dat je iets hebt gewijzigd.
Dat kan je vinden, maar het er gaat uiteindelijk om wat de schrijvers van de code ervan vinden. Als die akkoord zijn met gratis code waar iedereen van kan profiteren (ook grote bedrijven) dan is dat natuurlijk hun goed recht.

In de praktijk wordt de code voor Linux en de andere grote open source projecten al jarenlang voornamelijk geschreven door developers van grote bedrijven. Er wordt niet geld verdiend 'over de rug van de community', die grote bedrijven *zijn* grotendeels de community.

[Reactie gewijzigd door Dreamvoid op 25 maart 2017 13:26]

nu heb je het vooral over zaken als linux waar de kernel verplicht gpl is, en dat heeft ook zo zijn (grote) nadelen, immers kan het nu niet gebruikt worden in bepaalde setups, bij een kernel zijn daar nog wegen omheen (veel bedrijven koppelen hun propretaire code extern aan die kernel en omzeilen zo het copyright, anderen zoeken (en soms vinden) andere wegen eromheen, feit wordt dan dat er hele hordes bedrijven niet bijdragen.

dat er een paar zijn die het wel doen (intel, oracle - deels) ibm en anderen, maakt het nog niet dat je kunt zeggen dat er niet belachelijk veel gefreeloaded wordt tot op het punt dat het ook voor bedrijven als intel op een gegeven punt niet meer ineressant is om bij te blijven dragen.
Voor particulieren en MKB kan linux/opensource natuurlijk een enorme kosten besparing zijn (op de lange termijn). Of ik dat onder de noemer gratis meerijden zou plaatsen, lijkt mij wat on fair. De maatschappelijke waarde van linux/opensource is enorm. Daar komt MS Windows niet eens in de buurt.

Je moet er soms veel tijd insteken of een expert inhuren. Maar als je het goed doet heb je er vele jaren plezier van een opensource "setup". Moet er niet aan denken dat we nog Microsoft/Oracle/Netware servers, email, etc. zouden hebben draaien. De backend is bij ons in bijna geheel opensource/linux.
Er zijn ook miljoenen kleine freelancers die bij elkaar miljarden verdienen met open source - ik durf wel te stellen dat bijna elke Tweaker met een IT-baan geld verdient aan open source, terwijl er maar een klein deel ook actief meeontwikkelt. Het is m.i. erg misleidend om specifiek 'grote bedrijven' eruit te lichten.

Het 'teveel freeloaders' verhaal ligt ook veel genuanceerder - als je als bedrijf (of individu) de opensource software naar tevredenheid gebruikt zonder dat je tegen bugs of performance problemen aanloopt, waarom zou je dan gaan lopen coden? Dat is de realiteit voor duizenden bedrijven, van groot tot klein.

Het zijn degenen die tegen de grenzen van Linux/etc aanlopen, nieuwe features/hardware willen toevoegen of een specifieke bug vinden die hun rechtstreeks geld kost, die aan het coden slaan. Het voortborduren op bestaande open source code is in vrijwel alle gevallen een stuk goedkoper dan alles helemaal zelf 'from scratch' lopen doen, en zo gaat de trein continu vooruit.

[Reactie gewijzigd door Dreamvoid op 25 maart 2017 14:15]

Ik vraag me af wat de toegevoegde waarde van die opmerking over de praktijk is. Die bedrijven investeren dus willens en wetens tijd en geld in bepaalde software die onder een bepaalde licentie uitkomt. Ik neem het ze echt niet kwalijk dat ze het systeem naar hun hand willen zetten, echt niet, ik vind wel dat de opmerking in relatie tot dit niet correct is. Als ze er issues mee hebben dan ontwikkelen ze zelf maar een goed alternatief. Het is niet alsof Intel daar bijvoorbeeld niet de resources voor zou hebben.
Wees blij dat er juist een beweging is om alles gratis en open te delen. Moeten we als een gemeenschap dan naar een gesloten systeem waar ontwikkeling en innovatie geremd worden door het te verbergen achter bedrijfsgeheimen, copyright, licenties, patenten en paywalls?
je leest mijn comment verkeerd, juist opensource is belangrijk voor innovatie, maar of die code nu open is of niet, hij moet wel worden betaald, geauditeerd, gedocumenteerd, gepatched. daar zijn constant middelen voor nodig. bedrijven als intel zien dat in, maar hoeveel bedrijven zijn er in het verleden al niet aangepakt omdat ze een of andere FOSS0licentie schonden, of die stelselmatig weigeren om hun broncode tijdig en compleet openbaar te maken.

de hele opensourcewereld zou er bij gebaat zijn als iedereen bijdroeg, en iedereen die niet wil, die moet dan maar gewoon betalen, net zoals ze bij bijv Microsoft hadden moeten doen.

de miljarden die er jaarlijks van zulke licenties afkomstig waren zouden juist de linuxen en BSD's van deze wereld enorm helpen. nu is het wachten tot je eindelijk door een intel wordt opgemerkt, als de trolls ze niet voorzijn
Tsja, maar vertel dat aan die miljard+ Android gebruikers dat er van hen allemaal verwacht wordt dat ze actief meedevelopen aan het project, en dat ze anders maar een Windows of Apple telefoon moeten kopen.

[Reactie gewijzigd door Dreamvoid op 25 maart 2017 14:00]

Nee, want die gebruikers hebben voor Android betaald middels het kopen van een mobiel abonnement + telefoon. Bedrijven binnen de Open Handset Foundation, zoals Google, krijgt hierdoor geld binnen en kunnen verder bijdragen aan de ontwikkeling aan onder andere de Linux kernel. Dat geldt eveneens voor wat betreft de volgende opmerking van @batjes over modems (en routers).
Of iedereen die thuis een modem heeft staan.
Anoniem: 20901
@i-chat25 maart 2017 17:09
Zou het niet handiger zijn dat je grote bedrijven laat bijdragen in de ontwikkelkosten in de vorm van ontwikkeling?
Hoezo kostendekkend? Alle mensen werken er vrijwillig aan mee (of werken er tijdens werktijd vanuit het bedrijf aan). De nieuwe licentie is dus vrijer en meer up to date.
Tja, en wat moet het bestuur doen als een auteur niet reageert? Zolang de tijd om te reageren lang genoeg is en er in die tijd regelmatig een herinnering gestuurd wordt, vind ik het logisch dat er gesteld wordt, zwijgen is toestemmen.
Tja, en wat moet het bestuur doen als een auteur niet reageert?
....
zwijgen is toestemmen.
En dat gaat volledig in tegen het auteursrecht/copyrights, daar krijgt de auteur het monopoly om te bepalen wat er met z'n werken gedaan mag worden en voor de gebruikers daarvan enkele voorwaarden aan gebruik en uitzonderingen die geen inbreuk vormen. Zwijgen is toestemmen staat daar haaks op.

Wat er moet gebeuren bij het uitblijven van reactie is het stukje code herschrijven op een manier die geen inbreuk maakt op de niet reageerende auteur.
En als dat niet kan? immers kun je niet zomaar elk stukje code herschrijven op een manier dat het geen inbreuk maakt.
Ik ben met je eens als het over de complete code gaat van 1 auteur, maar dit gaat over code waar 100den mensen aan meegewerkt hebben, en jij dus 'maar' een radertje in het grote geheel bent. Als jij er niet voor gezorgd hebt dat je goed bereikbaar bent (door bv up to date houden van je email) of dat je gewoonweg niet reageert omdat je geen zin hebt (of misschien ben je wel dood), dan vind ik wel dat 'zwijgen is toestemmen' op gaat (mits de periode om te reageren dus ruim genoeg is en in die tijd ook regelmatig reminders zijn gestuurd).
Als je mensen/bedrijven gaat verplichten om te betalen is het hele idee van vrijheid weg, het is dan ook Free als in freedom niet free als in prijs ;)

De ontwikkelaar zelf bepaald of deze de software verkoopt of gratis weggeeft, bij verkoop is de koper vrij om er volgens alles mee te doen, deze mag de software ook weer (door)verkopen. Alleen is deze dan wel verplicht om elke wijziging free beschikbaar te stellen (aan de koper).

Je kan dit misschien oneerlijk vinden, maar is het eigenlijk heel normaal. Het hele (software) licentie model is daarin tegen is vrij opmerkelijk! Je hebt al betaald en vervolgens mag je nog is gaan betalen voor elke keer dat je het gebruikt, als je een auto koopt en die door wilt verkopen hoef je toch ook geen deel aan de dealer te betalen?

Oracle spant (spande?) de kroon, je moet voor de zelfde software apart betalen per CPU kern, en dat terwijl het precies de zelfde software is. Een beperking op de hoeveelheid gebruikers is dan nog begrijpelijk omdat je dit kan vergelijken met een fysiek iets dat maar door een persoon per kan worden gebruikt.

En dan mag je het nog niet eens aanpassen, want het is closed-source!

Het is misschien netter dat ze een deel van inkomsten delen, maar dit verplichten gaat wel erg ver.
Daarnaast kunnen ze er misschien geld mee verdienen, maar bij open-source heeft niemand langer het alleen recht, en kan "iedereen" geld verdienen met deze software en niet alleen één partij.

Verschillende voormalige Amerikaanse presidenten hebben grote contributies geleverd ten behoeven van het volk, Washington (of Jefferson. ik weet even niet meer) heeft verschillende uitvindingen gemaakt, die vervolgens laten patenteren en vrijgegeven voor het volk, een andere doneerde zijn landgoed en historische bezittingen voor een museum. Zij vonden het belangrijker dat de mensheid hier gebruik van kon maken dan dat er winst mee werd behaald. Nicola Tesla verscheurde een licentie contract over zijn uitvinding van de AC motor zodat het bedrijf eindelijk kon produceren (hij had hier schatrijk mee kunnen worden! maar stierf arm), omdat deze mensen namelijk geloofde dat het doel zelf belangrijker was dan hun eigen gewin.

En die zelfde ideologie zie je ook in verschillende open-source projecten, mensen willen het delen omdat ze daarmee andere helpen. En ja daar word ook misbruik van gemaakt, maar dat zegt meer van die mensen/bedrijven. Een open-source licentie maakt het juridisch makkelijker om deze vrijbuiters te verplichten de wijzigingen alsnog vrij te geven.

Met uitzondering van AGPL en de Contributor license agreement waarmee de hoofdontwikkelaar nog altijd het alleen recht heeft, dit is gewoon een wassen neus. Ja het is open-source maar niet iedereen heeft zelfde vrijheid en mogelijkheden, want anders zouden ze immers geen betaalde extra's kunnen aanbieden O-) (elk gebruik staat gelijk aan distributie en verplicht dus tot vrijgaven van de broncode).

Voor grote projecten met flinke kosten is dit verliesmodel uiteraard een groot probleem, uiteindelijk zal het project kopje ondergaan, de ontwikkeling stagneert of word door een commerciële partij overgenomen. Maar de software zelf zal altijd open-source blijven, en kan nog altijd door iedereen die toegang heeft worden doorontwikkeld. En blijft die vrijheid voor altijd bestaan :Y)
Ik vind die open source licenses die je rechten over een stuk code laat behouden zo raar, als je meedraagt aan open source hoort in mijn ogen je code rechtenvrij te zijn of de rechten bij de beheerders van het project liggen. Dan is er namelijk duidelijkheid.
Het is niet de licentie die je de rechten laat behouden maar de wet. Die wijst gewoon het ultieme recht als het gaat om code, het copyright, toe aan de auteur. Die geeft de code vervolgens weg (doneert deze) onder een licentie. Maar hij blijft copyrighthouder van zijn eigen code en kan die dus ook aan een ander project geven bijvoorbeeld. Doen alle copyrighthouders dat dan kunnen ze de volledige code onder een andere licentie hangen.

Het is vooral de GPL die hier veel problemen mee heeft omdat die een soort lock-in heeft (ironisch genoeg precies datgene waar ze zo fel tegen zijn). Bijv. BSD, MIT en Apache license hebben dit allemaal niet.
Het is vooral de GPL die hier veel problemen mee heeft omdat die een soort lock-in heeft (ironisch genoeg precies datgene waar ze zo fel tegen zijn)
Dat is een zeer eenzijdige opmerking. Ja GPL wil dat spul GPL blijft, je kan dat zien als een lockin. Maar hte is ook een voorwaarde die ervoor zorgt dat op GPL gebaseerde code (patches/uitbreidingen) open blijft en niet achter een closedsource binary verdwijnt. Als je met dat laatste problemen hebt, dien je dus gewoon geen GPL-ed code te gebruiken voor je afgeleide spul.
Het is niet een zeer eenzijdige opmerking maar een objectief feit. GPL heeft wel een lock-in effect, Apache license niet.

Wat beter is laat ik aan jou over om over te oordelen.
Veel open source producten werken ook op die manier, om het beheersbaar te houden. Maar in de "oertijd" van de open source producten was dat nog niet gebruikelijk.
En daarom is dus aanpassing van de licentie 'nodig', zeker bij zo'n basis protocol.
'Ik maak me zorgen dat de rechten van de auteurs met de voeten getreden worden op deze manier. Ze krijgen geen andere keus dan hun werk overzetten naar deze licentie, die vermoedelijk uitgekozen is door grote bedrijven als The Linux Corporation, Intel en Oracle.'
Ik snap wat je zegt, Theo, maar Open Source is niet alleen jouw feestje. Auteurs kunnen er niet mee instemmen en hun code zal vervolgens niet mee gaan maar herschreven worden. Mocht de community het er niet mee eens zijn, kan het project altijd geforked worden (en jij van iedereen weet precies hoe dat werkt).

Heb je iedereen geconsulteerd toen je besloot LibreSSL te forken?

[Reactie gewijzigd door JackBol op 25 maart 2017 17:51]

Iedereen die ooit aan OpenSSL heeft bijgedragen deed dit onder de toen geldende licentie. LibreSSL houdt zich aan de voorwaarden van die licentie, dus er hoefde niemand geconsulteerd te worden.

OpenSSL daarentegen wil naar een licentie die incompatibel is met de oude, vandaar dat ze juridisch verplicht zijn om iedereen die heeft bijgedragen toestemming te vragen.
Kunnen we de naam, Theo de Raadt altijd met het font comic sans weer geven?

Wat ik mij afvraag, hoe lang is code nog van jouw? Vanaf het moment dat jij met en stukje code bijdraagt aan een project tot wanneer is en blijft dit jouw code?

Is het terecht, dat als je in 1998 code hebt bij gedragen, dat je daar vandaag de dag nog rechten uit kunt ontleden?
Als het antwoord tot de dood van de maker is, hoe kan een project dan weten wanneer iemand dood is?
Typically, the duration of a copyright spans the author's life plus 50 to 100 years (that is, copyright typically expires 50 to 100 years after the author dies, depending on the jurisdiction).
https://en.wikipedia.org/wiki/Copyright
Is dat niet wat te lang voor wat code?
Of hebben we straks echt problemen in de opensource gemeenschap?
Is dat niet wat te lang voor wat code?
Voor andere zaken waarschijnlijk ook.
Of hebben we straks echt problemen in de opensource gemeenschap?
Als je daar geen rekening mee houdt wel. Daarom hebben sommige projecten Contribution License Agreements.
Anderen gebruiken bijvoorbeeld GPL 2+ of 3+.
De GPL licentie (en blijkbaar dus ook de oude OpenSSL licentie) heeft daar een probleem mee. De Apache licentie niet. Waarom? Omdat de GPL afdwingt dat alle code onder de GPL blijft vallen. Hierdoor kun je er niet onderuit, *tenzij je het copyright hebt*. Het copyright gaat namelijk boven de licentie. Probleem is dat het copyright verdeeld ligt over honderden of zelfs duizenden mensen. De Apache licentie legt zo'n restrictie niet op; de code mag gewoon onder een andere licentie verstrekt worden zolang er maar een copyright statement van Apache + disclaimer bij zit.
In Duitsland bestaat dacht ik ook het concept dat copyright kan verwateren. Als bvb code over tijd dusdanig gewijzigd is dat het werk van 1 auteur al tal van keren is aangepast.
Anoniem: 890159
25 maart 2017 13:35
En stel dat er een aantal auteurs tegen stemt? Dat is bij zo'n aantal haast onvermijdelijk. Wordt hun code dan herschreven (met kans op weer nieuwe bugs) of gaat het hele feest dan niet door?
Dat eerste EN het tweede tijdelijk denk ik zo.
Precies om deze reden is veel van de code al lang herschreven. Dat is de GnuTLS library.
Anoniem: 26306
@MacFreek26 maart 2017 10:27
Met LGPL licentie. Als je een alternatief wilt, is mbed TLS ook een optie. Die library is al beschikbaar onder Apache 2.0 license. Als je dan toch al overstapt op iets anders, doe het dan ook meteen goed, denk ik dan.
Juist, als je de overstap goed doet pak dan inderdaad de LGPL :Y)
Anoniem: 26306
@Dorank26 maart 2017 15:50
Zonder argumentatie is dat gewoon een troll. Leg eens uit waarom ik als gebruiker van een library liever een LGPL dan een Apache 2.0 of BSD licentie zou zien? De laatste twee laten me veel meer vrij.
Tuurlijk is het een troll, je doet immers precies hetzelfde, je leek immers Apache2.0 beter te vinden dan LGPL zonder enige toelichting.

Het verschil tussen LGPL en Apache/BSD is dat de laatste zoals je al aangeeft de gebruiker vrijlaten om de afgeleide (in breede zin) onvrij te maken. LGPL staat je toe om er gebruik van te maken in (als bv dependencies op een LGPL-ed library ) om onvrije software, maar aanpassingen als direct afgeleide (patches/uitbreidingen) van de LGPL-ed code zijn verplicht vrij te blijven.

Ik ben voor vrije software en geef dan ook de voorkeur aan een license die ervoor zorgt dat de software vrij blijft. In mijn opinie is LGPL dus beter.

Tevreden zo?
Anoniem: 26306
@Dorank26 maart 2017 17:25
Kortom, software met een BSD of Apache 2.0 license leggen je minder restricties op dan software met ene (L)GPL license. En als je een LGPL library gebruikt heeft dat eigenlijk geen enkel voordeel boven die minder beperkende licenses.

Het is wat mij betreft dus beter om weg te blijven bij GPL als gebruiker. Of het nu open source of closed source is, voor commercieel gebruik of juist niet, voor werk of voor privé, met BSD en/of Apache licenses loop je veel minder risico.

Overigens schrijf ik praktisch alles onder 2-clause BSD license omdat het mij niet boeit als iemand anders er geld mee verdient. De door mij geschreven code blijft juist vrij om te gebruiken. Meer voorwaarden maken minder vrij, ongeacht welke verdere definities je daarvoor wilt gebruiken.
Meer voorwaarden maken minder vrij, ongeacht welke verdere definities je daarvoor wilt gebruiken.
Precies! Daarom gebruik ik Creative Commons en MIT (CC-BY soms als ik er wat credits voor wil :)

Ik vind de GPL houding nogal dogmatisch. Stel dat al die andere licenties dezelfde soort clausules zouden hebben... zaten we nu met tientallen code eilandjes omdat de code van de ene niet onder de license van de andere kan etc. Pfff lekker fijn hoor.

FSF claimed een beetje het alleenrecht op free software wat mij betreft want alles moet GPL worden... Dus als ik twee projecten samenvoeg, GPL en Apache licensed... dan moet het eindproduct altijd GPL licensed worden... mmmm. Not. Cool.
"The Linux Corporation" -- Ehm... wat? 8)7
In het originele artikel staat uiteraard gewoon "Linux Foundation".
Maar maak je geen illusies... Er zitten naast Linus vrijwel allemaal grote bedrijven in...

Zie het als de software industrie die willen dat Linus lekker doorwerkt aan Linux en daar een budget voor geregeld hebben.
En dan moetn opensource simpeler te maintainen zijn ... de PUR van zo'n licentie lijkt precies nog moeilijker dan die van de grote vendors ... :(
Ja, veel makkelijker natuurlijk als er gewoon helemaal niets mag 8)7

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee