`````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 · Bijgewerkt door Priscilla F. Harmanus 🇳🇱

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

door David A. Wheeler · Released 2002-05-06, revised 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

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



4. Sommige GPL-incompatibele licenties moeten worden vermeden

Er zijn veel GPL-incompatibele licenties waarvan u, indien mogelijk, het vrijgeven van software moet vermijden. Hier zijn enkele voorbeelden:

  1. Vermijd de originele (“4-clause”) BSD license / (“4-clausule”) BSD licentie. De oorspronkelijke BSD licentie bevatte een clausule die nu de “obnoxious BSD advertising clause” / “onaangename BSD advertising clausule” wordt genoemd. Dit verklaarde dat:

    Al het advertentiemateriaal waarin de kenmerken (features) of het gebruik van
        deze software moet de volgende bevestiging weergeven:
          Dit product bevat software die is ontwikkeld (developed) door de Universiteit van
          California, Berkeley en zijn medewerkers (contributors."


    Dit maakte het onverenigbaar (incompatible) met de GPL, en introduceerde ook praktische problemen die werden opgemerkt door de FSF. Het probleem is dat wanneer code wordt samengevoegd (merged together) (en dat is het ook), en iedereen voegt zijn eigen naam toe (adds their own name) (en dat deden ze), mensen niet konden adverteren zonder mogelijk honderden mensen op te sommen - waardoor deze clausule volkomen onpraktisch was als de software werd geschaald. In juni 1999, na twee jaar discussies, heeft de University of California deze clausule geschrapt uit de licentie van BSD. Dus, dit is een verouderde licentie die niet langer mag worden gebruikt; gebruik in plaats daarvan licenties zoals de “new BSD” aka “modified BSD” or “3-clause BSD” license / “nieuwe BSD” oftewel “gewijzigde BSD” of “3-clausule BSD” licentie.
  2. Vermijd de “Academic Free License” (AFL). Er is beweerd dat de AFL een “compatibele upgrade” was van “licenties zoals de  BSD en MIT”, maar dit is een misleidende bewering; zoals de FSF opmerkt: “de gewijzigde (modified) BSD licentie en de X11 licentie (ook bekend als MIT) zijn GPL-compatibel, maar de AFL niet.” (tenminste versie 1.1 en 2.1 zijn incompatibel, en ik geloof dat AFL versie 3 ook incompatibel is). De AFL heeft een aantal mooie eigenschappen (some nice properties) vanuit juridisch oogpunt (a legal point of view), maar de GPL-incompatibiliteit is een ernstige tekortkoming (a serious failing) die deze voordelen (advantages) volledig in het gedrang brengt. Projecten zoals SHPTRANS hebben de AFL incompatibiliteit als een ernstig probleem aangemerkt, en hebben ervoor gekozen om de AFL om deze reden niet te gebruiken. Ooit hebben sommige mensen in de OSI de AFL aanbevolen, maar sinds 30 juli 2007 vermeldt de OSI de AFL licentie als  “redundant with more popular licenses” / “overtollig - overbodig met meer populaire licenties”, en neemt deze nadrukkelijk niet op bij “Licenses that are popular and widely used or with strong communities” / “Licenties die populair zijn en veelgebruikt of met sterke gemeenschappen”.
  3. Voor nu voorlopig, vermijd de “Common Public License” 1.0 (CPL), hoewel dit kan veranderen (may change). De CPL is lang niet zo populair als de GPL, LGPL, BSD-new, of MIT/X11 licenties, maar hij heeft meer toepassingen dan de meeste andere licenties. De CPL staat zelfs in de OSI lijst (OSI’s list) van “Licenties die populair zijn en veel worden gebruikt of met sterke gemeenschappen”. Enkele andere licenties, zoals de Eclipse licentie, zijn gebaseerd op (are based on) de CPL. Het is bekend (known) dat de CPL niet compatibel is met GPLv2, dus op dit moment is het waarschijnlijk het beste te vermijden. Echter,  het is mogelijk dat de CPL compatibel is met GPL versie 3, waardoor het veel smakelijker (palatible) zou worden en vergelijkbaar (similar) met de Apache 2.0 licentie (die incompatibel is met GPLv2 maar compatibel met GPLv3). Op dit moment, zou ik wachten tot er een langdurige juridische analyse is om de zaak op te lossen (I’d wait until there’s been lengthy legal analysis to settle the matter).
  4. Vermijd de “Open Software License” (OSL). Dit zou een sterk beschermende (strongly protective) licentie moeten zijn zoals de GPL. Maar het is niet compatibel met de GPL, en bijna niemand gebruikt deze licentie, dus dergelijke code kan niet worden gebruikt of worden gebruikt door de overgrote meerderheid van FLOSS projecten. De FSF is ook van mening dat de distributievoorwaarden (distribution terms) normale ontwikkelingsprocessen (normal development processes) illegaal maken, waardoor een ernstig praktisch probleem ontstaat. Nogmaals, ooit hebben sommige mensen in de OSI de OSL aanbevolen, maar vanaf 30 juli 2007 vermeldt de OSI de OSL licentie als zijnde in de categorie “Other/Miscellaneous licenses” / “Overige/Diverse licenties”, en neemt deze nadrukkelijk niet op bij “Licenties die populair zijn en veel worden gebruikt of bij sterke gemeenschappen”.
  5. Vermijd de “Artistic 1.0” licentie (van Perl). Hoewel bedoeld als een OSS licentie, is de Artistic 1.0 licentie een slecht gemaakte licentie (a poorly crafted license) die allerlei juridische problemen veroorzaakt (that creates all sorts of legal problems). De Free Software Foundation (FSF) zegt dat het geen vrije licentie is omdat de tekst vaag is en vatbaar voor verkeerde interpretatie (misinterpretatie). De Perl community, die het ontwikkelde (which developed it), was het eens met deze beoordeling (agreed with this assessment) en herschreef (rewrote) de Artistieke licentie (the Artistic license) om alle geïdentificeerde problemen op te lossen (resolve). De OSI heeft de licentie “vervangen/superseded”, en beveelt sterk  (recommending strongly) aan dat alle gebruikers (users) naar Artistic 2.0 gaan.. Fedora (een zeer populaire Linux distributie) staat niet langer projecten toe die Artistic 1.0 gebruiken, en voor Fedora 10 is het van plan om alle projecten te verwijderen die alleen de Artistic 1.0 licentie. Eigenlijk, is deze licentie waarschijnlijk compatibel met de GPL, maar het is zo moeilijk om erachter te komen wat het betekent dat ik hem hier opneem. Ik raad aan om de MIT or BSD-new licenties te gebruiken in plaats van de Artistieke licenties waar dat redelijkerwijs mogelijk is.
  6. Vermijd het gebruik van de “Creative Commons” licenties voor software. De Creative Commons FAQ zegt, “Creative Commons licenties zijn niet bedoeld (not intended) om op software van toepassing te zijn. Ze mogen niet worden gebruikt voor software... [ze maken zo nodig, geen onderscheid,] tussen object en broncode (source code)... We raden u ten zeerste aan om een ​​van de zeer goede software licenties te gebruiken die tegenwoordig [in plaats daarvan] beschikbaar zijn.” Jay Tuley’s “5 redenen om niet een CC licentie te kiezen voor code” legt meer uit. De debian-juridische Samenvatting van Creative Commons 2.0 licenties (the debian-legal Summary of Creative Commons 2.0 Licenses) beveelt auteurs die werken willen maken die compatibel zijn met Debian’s “Debian Richtlijnen voor Vrije Software” (“Debian Free Software Guidelines”)  aan om geen van de licenties te gebruiken in de Creative Commons licentiesuite; licenties met de “NonCommercial” of “NoDerivs” licentie elementen zijn fundamenteel incompatibel met FLOSS, auteurs die de Attribution 2.0 licentie gebruiken of van plan zijn te gebruiken, zouden een vergelijkbare Vrije Software licentie moeten overwegen, zoals een BSD of MIT-style licentie..., en Auteurs die de Attribution-ShareAlike 2.0 licentie gebruiken of van plan zijn te gebruiken, zouden een gelijkaardige Vrije Software licentie moeten overwegen, zoals de GNU General Public License [GPL]. De Creative Commons heeft de GPL en LGPL “verpakt” (The Creative Commons “wrapped” the GPL en LGPL) als u gebruik wilt maken van de Creative Commons search engine (zoekmachine).
  7. Vermijd de Mozilla Public License (MPL) versie 1.0, versie 1.1, en de Incompatible With Secondary Licenses clausule van versie 2.0. De Mozilla Public License (MPL) is oorspronkelijk gemaakt door Mozilla, maar de GPL-incompatibiliteit veroorzaakte zoveel problemen dat Mozilla uiteindelijk een nieuwe licentie voor hun werk kreeg onder een (drievoudige) GPL /LGPL/MPL triple licentie. Andere voormalige MPL gebruikers (MPL users) zoals Alfresco hebben de MPL verlaten (abandoned the MPL). Het is belangrijk op te merken dat zelfs de oorspronkelijke maker van MPL 1.0 en 1.1 het heeft opgegeven (abandoned it) als enige licentie (as their sole license), vanwege GPL-incompatibiliteit; dupliceer hun fout niet. Google vermeldt niet langer de MPL als een aanbevolen licentie (recommended license), hoewel ze dat ooit wel deden. Inderdaad, er was een tijd dat Google code geen MPL projecten accepteerde; Google code staat nu elke OSS licentie toe, maar bevat nog steeds niet de MPL als een aanbevolen licentie (recommended license). De meer recente MPL versie 2.0 is compatibel met de GPL, vanwege veel hard licentie analysewerk (due to a lot of hard license analysis work)... het compatibel maken van de MPL met de GPL was een van de belangrijkste (hoofd)redenen waarom de MPL werd bijgewerkt (updated). Echter, MPL versie 2.0 heeft een optionele  "Incompatibel Met secundaire licenties" clausule (optional "incompatible With secondary licenses" clause), en als u deze opneemt, is de software niet langer GPL-compatibel (dus neem die clausule niet op).
  8. Vermijd de CDDL. Deze Sun creatie is vergelijkbaar (similar) met de MPL. Toch gebruikt de oorspronkelijke maker van de MPL deze niet meer (exclusief), en de ervaring (the experience) van OpenSolaris leert (shows) dat de licentie een echt  struikelblok is (a real stumbling block). Op CDDL gebaseerde projecten (CDDL-based projects) hebben doorgaans een relatief kleine deelname (small levels of participation), en ik denk dat een belangrijke reden (key reason) de licentie is.
  9. Vermijd de “NASA Open Source Agreement” versie 1.3. Dit is een van die zeldzame gevallen (rare cases) waarin de OSI een licentie heeft geaccepteerd als een open source software licentie (volgens de open source definitie), maar de FSF heeft vastgesteld (determined) dat de licentie geen Vrije Software licentie is (volgens de Free Software definition). Het probleem is dat het vereist dat veranderingen uw “original creation/originele creatie” zijn. De ontwikkeling van FLOSS software (FLOSS software development) is afhankelijk van het combineren van code van derden (FLOSS software development depends on combining code from third parties), dus als dat letterlijk wordt geïnterpreteerd, zou deze overeenkomst (this agreement) praktisch al het echte werk verbieden (this agreement would prohibit practically all real work) en zou zeker GPL-incompatibel zijn. U kunt deze licentie het beste vermijden. NASA heeft me verteld dat ze bezig zijn deze licentie te wijzigen om deze dwaze beperking op te heffen (that they are in the process of changing this license to remove this silly restriction;); dat zou het beter maken, hoewel ik niet weet of hun resultaat GPL-compatibel zal zijn.


3. Andere projecten en licentie auteurs tonen aan dat GPL compatibiliteit belangrijk is

5. Overweeg GPL-incompatibiliteit zorgvuldig






       


Dit is een nieuwe webpagina

Bijgewerkt door — Priscilla F. Harmanus


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

 
Map
Info