`````Cybercrime en Cyber Security Nederland
PRISCILLA F. HARMANUS OVER ONDERZOEK INFORMATIE VEILIGHEID EN VITALE INFRASTRUCTUUR IN DE DIGITALE OVERHEID

Home » Digitale overheid » Actueel » Onderwerpen » Bijdrage » Contact

2021/01/29

Maak Uw Open Source Software GPL-Compatibel. Of Anders.

Door David A. Wheeler · Uitgebracht 2002-05-06, herzien 2014-02-16

Alle hyperlinks die naar een andere website leiden, hebben deze mooie groene kleur: voorbeeld link

/gpl-compatibility/ ✏️WIKI

1. Introductie » 2. GPL-incompatibele licenties riskeren een gebrek aan ondersteuning/support (GPL meest populair) » 3. Andere projecten en auteurs van licentie tonen aan dat GPL compatibiliteit belangrijk is » 4. Sommige GPL-incompatibele licenties moeten worden vermeden » 5. Overweeg GPL incompatibiliteit zorgvuldig » 6. Licentie proliferatie beschouwd als schadelijk » 7. Andere dingen om te overwegen » 8. Een gerelateerd probleem: Gebruik de standaardlicentie (CC-BY-SA) voor andere werken » 9. Maak uw FLOSS software GPL-compatibel » 10. Bijlage A: The Cautionary Tale of XFree86 » 11. Bijlage B: Informatie over de GPL en andere Licenties » 12. Bijlage C: GNU projecten niet onder een copyleft licentie

Onderstaande tekst is vertaald vanuit het Engels (bron dwheeler.com) naar het Nederlands door Priscilla Harmanus


3. Andere projecten en licentie auteurs laten zien dat GPL compatibiliteit belangrijk is

Wilt u meer bewijs dat GPL compatibiliteit belangrijk is? Verschillende grote, spraakmakende FLOSS projecten hebben vaak-pijnlijke veranderingen ondergaan om zichzelf GPL-compatibel te maken, en hetzelfde geldt voor organisaties die licenties schrijven:

  1. De veelgebruikte Python taal (Programming language) onderging grote licentiewijzigingen in 2001, zodat versie 2.1 en later GPL-compatibel zouden zijn.
  2. De populaire teksteditor vim werd GPL-compatibel, na een lange juridische discussie. Het tijdschrift Linux Journal heeft vim meerdere keren bekroond als de populairste editor, dus dit is geen obscuur programma.
  3. Mozilla onderging ook opnieuw een complex herlicentieschema (a complex relicensing scheme) om vermeende onverenigbaarheden (incompatibilities) tussen hun oudere licenties (met name de MPL) en de GPL op te lossen. Zoals hieronder wordt besproken, hebben ze uiteindelijk hun MPL licentie herschreven om deze GPL-compatibel te maken.
  4. Zope is ook overgestapt van hun “Zope Public License version 1” (die GPL-incompatibel was) naar een GPL-compatibele licentie.
  5. De University of California in Berkeley bracht een grote hoeveelheid code uit (de Berkeley Software Distribution, BSD) die de basis werd van de verschillende *BSD systemen. De oorspronkelijke BSD licentie bevatte een lastige advertentievereiste die niet compatibel was met GPL. Na vele verzoeken (inclusief aantekeningen dat de licentie niet compatibel was met GPL), besloot Berkeley de licentie in 1999 te wijzigen, waardoor deze code GPL-compatibel werd (de FSF heeft een pagina die de originele BSD-advertentieclausule vanuit hun perspectief bespreekt).
  6. Apache veranderde hun licentie naar “versie 2.0”, en een van hun doelen was om “compatibel te zijn met andere open source licenties, zoals de GPL”. Helaas, gelooft de Apache Software Foundation (ASF) dat Apache License versie 2.0 compatibel is met de GPL versie 2, terwijl het juridische team van de Free Software Foundation beweert dat Apache License versie 2.0 niet GPL-compatibel is. Sinds die tijd werken de FSF en Apache Software Foundation samen en is bekend dat GPL versie 3 compatibel is met de Apache-licentieversie 2.0 (Apache-medeoprichter/co-founder Brian Behlendorf is verheugd over de compatibiliteit van de Apache 2.0 / GPLv3-licentie). Deze lange geschiedenis maakt duidelijk dat beide partijen geloven dat GPL-compatibiliteit een belangrijk voordeel is in een FLOSS-licentie. http://apache.org/foundation/records/minutes/2002/board_minutes_2002_08_21.txt
  7. De toolkit Qt (de basis van KDE) had oorspronkelijk een GPL-incompatibele licentie. De eigenaren hebben nu een dubbele licentie voor Qt met de GPL, zodat Qt GPL-compatibel is.
  8. Zoals opgemerkt in de geschiedenis van Wine, heeft de “geschiedenis van licenties” van het WINE project tot veel discussies geleid. Het WINE project had oorspronkelijk de oude BSD-licentie, een GPL-incompatibele licentie; deze incompatibiliteit met de GPL bracht de ontwikkelaars ertoe om in januari 2000 over te schakelen naar de GPL-compatibele X11-licentie. Veel ontwikkelaars uitten hun bezorgdheid over de toe-eigening van de code door commerciële entiteiten, dus in maart 2002 kwamen de ontwikkelaars overeen Wine over te schakelen naar de LGPL licentie. Het “ReWind” project is gemaakt voor degenen die een codebase met X11-licentie wilden, maar de meeste ontwikkelaars besloten hun inspanningen te concentreren op synchronisatie met de LGPL’ed Wine, en de overgrote meerderheid van de ontwikkeling en nieuwe functies verschijnen daar als eerste. Het Wine project meldt dat kort na het veranderen van de licentie naar de LGPL, de ontwikkeling sneller begon op te lopen (er begonnen meer patches te verschijnen, de leider Alexandre deed meer CVS-commits en er werd gemeld dat meer applicaties werkten).
  9. Alfresco heeft hun enterprise content management programma opnieuw gelicentieerd van de MPL naar de GPL (beide FLOSS-licenties, maar MPL-versies vóór 2.0 zijn GPL-incompatibel). Stephen Shankland’s artikel over Alfresco meldt dat Matt Asay (Alfresco’s vice-president van marketing) zegt dat verhuizen naar de GPL een aantal belemmeringen wegneemt en Alfresco in staat stelt om gemakkelijk te integreren met andere GPL-projecten. Het citeert ook 451 Group-analist Raven Zachary die zegt dat: “Alfresco's gebruik van de GPL licentie voor zijn Community Editie zorgt voor mogelijk grotere bijdragen van de gemeenschap vanwege de bekendheid van de licentie en gevestigde normen.”
  10. Drie Franse publieke onderzoeksorganisaties lanceerden een project dat nieuwe Vrije Softwarelicenties schreven die in overeenstemming waren met de Franse wetgeving: CeCILL, CeCILL-B en CeCILL-C. Ze vonden GPL-compatibiliteit belangrijk, zelfs bij het maken van nieuwe licenties. De CeCILL licentie lijkt sterk op de GPL en is expliciet compatibel met de GPL. De CeCILL Veelgestelde Vragen (FAQ) (van de auteurs) zegt, “CeCILL is niettemin compatibel met de GNU GPL: wanneer software onder CeCILL wordt geïntegreerd met software onder de GPL, kan het resulterende werk worden verspreid onder de GNU GPL.” Merk op dat de FSF het ermee eens is dat de CeCILL compatibel is met de GPL.
  11. In juni 2010 gaf Google een nieuwe licentie voor hun WebM-implementatie van de VP8 multimedia codec, deels omdat de oude licentie GPLv3 en GPLv2 incompatibel was.
  12. Eind 2011 heeft de Mozilla-stichting (The Mozilla Foundation) de MPL versie 2.0 licentie uitgebracht en een van de belangrijkste wijzigingen is dat de nieuwe MPL GPL-compatibel is (zie ook de FSF verklaring over de MPL).
  13. In december 2012 werd aangekondigd dat de European Union's "EUPL" open source licentie (van de Europese Unie) zal worden bijgewerkt om compatibel te worden met GPLv3. Een rapport zei dat "de belangrijkste reden om de licentie bij te werken het wegnemen van belemmeringen [voor] het gebruik van software waarvoor een licentie is verleend onder de EUPL is", en dat "het expliciet compatibel maken met de GPLv3 de interoperabiliteit zou moeten vergroten".
  14. In 2014 werd Plan 9 vrijgegeven van de Lucent Public License naar GPL versie 2. Aangenomen wordt dat de Lucent licentie GPL-incompatibel is.


Meerdere grote projecten ondergaan geen pijnlijke licentiewijzigingen (license changes), tenzij ze daar een reden voor hebben. De GPL is zo populair dat GPL compatibiliteit nu een belangrijke vereiste is in een licentie. Eirik Eng, president van Trolltech (eigenaar van Qt), legde de acties van Trolltech uit door te zeggen: “de laatste tijd wordt de GPL steeds meer gebruikt voor nieuw geopende broncode [software].” In het artikel “Init vervangen door Upstart” wordt opgemerkt dat toen de auteurs aan hun “Upstart” project begonnen, ze naar bestaande systemen keken als uitgangspunt, en dat Sun’s SMF en Apple’s programma ‘launchd’   “onmiddellijk werden uitgesloten vanwege licentieproblemen. Het was belangrijk voor ons dat de oplossing onomstreden vrij was, zodat andere distributies het zouden overnemen; velen hadden deze al afgewezen om redenen van incompatibiliteit met GPL.”

Het Solaris-besturingssysteem van Sun (Sun’s Solaris operating system) is uitgebracht onder de CDDL, een GPL-incompatibele FLOSS licentie. Sun heeft natuurlijk het volste recht om hun software vrij te geven onder welke licentie dan ook (binnen de wet), natuurlijk. Echter, Groklaw’s 2005 artikel “Sun Responds to Criticism of CDDL” wordt echter gesteld dat, omdat de CDDL niet GPL-compatibel is, Sun de steun van de gemeenschap die het hoopt te vergaren, niet zal krijgen door het gebruik van de CDDL. Het artikel voorspelt dat “Het resultaat echter zal zijn dat Linux zich sneller zal blijven ontwikkelen en de licentie van Sun en de code ervan zal begraven... Het staat Sun vrij om zich daarvan af te sluiten, als het dat wil, maar het zal oogsten wat het zaait. Als ze zouden denken dat de wereld de GPL zou laten vallen en in plaats daarvan de CDDL zou adopteren, vertrouw ik erop dat ze nu beseffen dat dit niet zal gebeuren... Ik betwijfel ten zeerste dat elke licentie die niet compatibel is met GPL/LGPL, op grote schaal zal worden overgenomen.” Dat was een opmerkelijk nauwkeurige voorspelling. In 2008, merkte Theodore Ts’o op dat “Open Solaris [er niet in geslaagd is om een ​​Open Source ontwikkelingsgemeenschap (development community) te ontwikkelen]... vanuit zakelijk oogpunt, vraag ik me af of Sun echt in staat zal zijn om hun Solaris engineering team te ondersteunen als als ze al het echte werk doen bij hunzelf... Met Linux, hebben we het grote voordeel dat kernel verbeteringen (kernel improvements) afkomstig zijn van meerdere bedrijven in het ecosysteem, in plaats van te worden betaald door één bedrijf... het is niet duidelijk hoe Sun hun Solaris engineeringkosten rechtvaardigt voor hun aandeelhouders (shareholders).” Inderdaad, Emily Ratliff deed een paar berekeningen en ontdekte dat “Linus [Torvalds] meer patches [voor Linux] krijgt terwijl hij zijn tanden poetst dan OpenSolaris in een week”. Het falen van Solaris (Solaris’ failure) om een ​​bredere ontwikkelingsgemeenschap te krijgen, werd een belangrijk Slashdot-discussieonderwerp in april 2008 toen Roy Fielding aftrad (redesigned). Dit onvermogen om een ​​community te krijgen wordt zeker veroorzaakt door meer dan licentieproblemen, maar licentie-incompatibiliteiten lijken deel uit te maken van het verhaal, zoals Michael Dolan opmerkte in 2008.

In november 2006 kondigde Sun aan dat ze hun implementatie van Java zouden uitbrengen. De licentie? De GPL, samen met een paar LGPL-like-exceptions (LGPL-achtige-uitzonderingen) voor hun library (bibliotheek) - en niet de CDDL, die ze eerder hadden gebruikt in de Solaris release. Toen het vertrouwen van een gemeenschap of community van belang was, een GPL-compatibele licentie werd gekozen.

Hier is meer bewijs: sommige projecten die probeerden over te schakelen van een GPL-compatibele licentie naar een GPL-incompatibele licentie, zijn gesplitst (forked), waarbij hun oorspronkelijke leiders in wezen uit hun ambt zijn verwijderd, (essentially removed from office). Een “fork” is een poging om een ​​concurrerend project te creëren door te kopiëren van een bestaand project en ontwikkelaars/developers en gebruikers/users te overtuigen om in plaats daarvan over te schakelen naar het concurrerende project (to switch to the competing project instead). Forks in de FLOSS wereld zijn in wezen als een “motie van wantrouwen (vote of no confidence)” in een parlement. De mogelijkheid om een ​​fork te hebben is een belangrijke waarborg in FLOSS, omdat de mogelijkheid om te "vorken" (forking / to fork) voorkomt (prevents) dat leiders tiranniek worden. Maar vorken (forks) slagen zelden; de situatie moet opmerkelijk slecht zijn om ervoor te zorgen dat de overgrote meerderheid van ontwikkelaars/developers en distributeurs overschakelt naar iets anders. (Ik heb het niet over version control branches/versiebeheer-branches, die soms forks worden genoemd, vooral met git; er moet een intentie zijn om ervoor te zorgen dat mensen het vorige project niet meer gebruiken, en in plaats daarvan overschakelen of switchen naar het nieuwe project. Rick Moen heeft een artikel over forking , als je meer details wilt.) Toch zijn er succesvolle forks veroorzaakt doordat de projectleider probeerde een GPL-incompatibele licentie op te leggen aan anderen. Dat is overtuigend bewijs dat GPL-compatibiliteit van cruciaal belang is voor andere ontwikkelaars (developers) en gebruikers (users).

XFree86 is misschien wel het bekendste-voorbeeld van een fork die wordt veroorzaakt door een poging om licenties te wijzigen. Het XFree86 project leidde historisch gezien de ontwikkeling van een populaire X server, en traditioneel gebruikte de overgrote meerderheid van de code de eenvoudige “MIT/X” open source licentie die GPL-compatibel is. De XFree86 president, David Dawes, besloot in 2004 om de XFree86 licentie te veranderen in een licentie die niet GPL-compatibel was, voornamelijk om ontwikkelaars/developers meer krediet te geven. Het probleem was geen krediet te geven; het probleem was de incompatibiliteit met GPL. Deze poging tot verandering leidde tot een massale uittocht van XFree86, aangezien bijna alle ontwikkelaars/developers en gebruikers/users XFree86 onmiddellijk verlieten. Zie mijn appendix op XFree86 voor meer gedetailleerde informatie hierover.

Volker Lendecke van Samba verklaarde dat voor eventuele rechtsmiddelen van de Europese Commissie (European Commission remedies) met betrekking tot de vrijgave van gegevens door Microsoft (Microsoft’s release of data) het gebruik van een GPL-compatibele licentie vereist is. Dus zelfs data releases (dataversies) - niet alleen software code (softwarecode) - worden onderzocht (examined) om te zien of ze GPL-compatibel zijn.

Meer recent, in 2011, moesten het Amerikaanse ministerie van Justitie (The US Department) en het Duitse federale kartelbureau CPTN (een houdstermaatschappij die eigendom is van Microsoft Inc., Oracle Corp., Apple Inc. en EMC Corp.) de manier veranderen waarop ze de softwarepatenten van Novell verwierven, dat de open source community wordt beschermd, en in het bijzonder de Wall Street Journal meldde dat “alle verworven patenten onder de GNU General Public License (GPL) vallen”. Hierdoor lijkt het erop dat een vereiste zal zijn dat patenten moeten worden verleend voor gebruik op elk programma dat is vrijgegeven onder de GPL... maar misschien niet voor programma's die niet compatibel zijn met de GPL.


2. GPL-incompatibele licenties riskeren gebrek aan ondersteuning/support (GPL meest populair)

4. Sommige GPL-incompatibele licenties moeten worden vermeden






Dit is een nieuwe webpagina

Bijgewerkt door — Priscilla F. Harmanus


Home » Digitale overheid » Actueel » Onderwerpen » Bijdrage » Contact

 
Map
Info