`````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/30 · 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


6. Licentie proliferatie beschouwd als schadelijk

De proliferatie van licenties wordt als schadelijk beschouwd
Inderdaad, de wildgroei van FLOSS licenties (the proliferation of FLOSS licenses) in het algemeen (in general) wordt door velen gezien/geïdentificeerd als een probleem dat moet worden opgelost (to be resolved). Het was een probleem (an issue) dat werd opgemerkt in HP Vice President Martin Fink’s LinuxWorld 2005 address, en anderen steunden deze mening, zoals Groklaw. Klanten (Customers) vinden een lange lijst met licenties volkomen verbijsterend; het is moeilijk om erachter te komen wat legaal kan worden gecombineerd, en bedrijven (corporations) kunnen gemakkelijk grote sommen geld uitgeven aan juridisch advies (legal advice) als ze moeten beginnen met het onderzoeken van meer dan de eerste paar licenties. Zoals opgemerkt in Serdar Yegulalp’s “The Open Source Licensing Implosion” (InformationWeek, Aug 8, 2008), “Het is niet alleen dat er “te veel open source licenties” zijn, maar dat de consequenties voor het op een vlotte manier creëren van nieuwe eindelijk concreet worden... Het was gemakkelijker om weg te komen met een brede wildgroei aan licenties toen open source nog een relatief zeldzame en exotische vogelvariant was in de software-bestiarium. Nu open source een (hijgend) mainstream fenomeen aan het worden is, gebruik je een van de minder gangbare/gebruikelijke licenties (the less-common licenses) of het bedenken met een van je eigen werken vaker wel dan niet... Het zijn niet de programmeurs die zullen bepalen (determine) wat/welke open source licenties de beste zijn -- het zijn de softwareconsumenten (software consumers). Zij zullen degenen zijn die het bos van vergunningen beperken tot een paar goed gesnoeide en onderhouden bomen. Het is beter voor ons allemaal om niet te verdwalen onder hen.”

Dit is geen nieuwe waarneming of observatie; Bruce Perens merkte in 1999 op, “Schrijf geen nieuwe licentie als het mogelijk is om een ​​van de hier vermelde licenties te gebruiken. De verspreiding van veel verschillende en incompatibele licenties gaat ten koste van Open Source software, omdat fragmenten van het ene programma niet kunnen worden gebruikt in een ander programma met een incompatibele licentie.” Eric S. Raymond’s Software Release Practice HOWTO stelt sterk (als een kop!) “Schrijf niet je eigen licentie als je die mogelijk kunt vermijden,” en hij suggereert dat ontwikkelaars (developers) “een van de standaard licenties gebruiken die staan op de OSI site ​​als enigszins mogelijk.”

Als je twijfelt of de proliferatie van licenties een probleem kan zijn, kijk dan eens naar de licentierichtlijnen van Fedora en de licentiepagina van Fedora (just look at Fedora’s Licensing Guidelines and Fedora’s Licensing page) - ze stellen complexe licentiering documentatie op die elektronisch kan worden vastgelegd (recorded) en geanalyseerd, alleen om de licentienaleving te verzekeren (just to assure license compliance). Ze kijken ook specifiek of een licentie GPLv2 en GPLv3 compatibel is, wat duidelijk het belang van GPL compatibiliteit aantoont.

De klacht van Fink (Fink’s complaint) zorgde voor enige verbetering (improvement), bijvoorbeeld Intel heeft publiekelijk zijn eigen FLOSS licentie opgegeven, zodat in plaats daarvan standaardlicenties zouden worden gebruikt. Het Open Source Initiative’s License Proliferation Committee Report, een groep die van start ging na de opmerkingen van Fink (kicked off after Fink’s comments), raadde aan om dit aan te pakken door licenties te categoriseren. Het is niet verwonderlijk dat de categorie “Licenses that are popular and widely used or with strong communities” de MIT/X, BSD-new, LGPL, en GPL licenties omvatte. Hun volledige lijst, vanaf 19-09-2006, was Apache License 2.0, nieuwe en vereenvoudigde (simplified) BSD licenties, GPL, LGPL, MIT, MPL, CDDL, CPL 1.0, en Eclipse Public License (EPL). Zelfs deze lijst is te lang; de MPL, CDDL, CPL, en EPL hebben een verbazend klein aantal projecten dat er gebruik van maakt (a vanishingly small numbers of projects that use them).

Evenzo, John Cowan’s FLOSS license wizard (vanaf augustus 2008) raadt slechts enkele FLOSS licenties aan, afhankelijk van uw doeleinden. De enige FLOSS licenties die het zal aanbevelen zijn de GPLv3, LGPLv3, revised BSD (herzien), en Apache 2.0 licenties.

Op 14 augustus 2008, David A. Wheeler deed een snelle check van Google Code, en ontdekte dat ze alleen de volgende licenties toestaan: Apache 2.0, Artistic/GPL, GPLv2, GPLv3, LGPL, MIT, en new BSD. Merk op dat ze allemaal GPL-compatibel zijn (Apache 2.0 is alleen compatibel met GPLv3, maar niet met GPLv2). Zoals hierboven vermeld, accepteerden ze ooit de GPL-incompatibele MPL 1.1, maar niet langer.

InformationWeek's “The Open Source Licensing Implosion” van augustus 2008 merkt terecht op dat “de gevolgen/consequenties voor het vrolijk creëren van nieuwe [FLOSS licenties] eindelijk concreet worden [voor velen]... de overgrote meerderheid (the vast majority) van open source producten die er zijn, gebruiken een klein handvol licenties... De rest zijn meestal outriders of afgeleiden (derivatives)... Het was gemakkelijker om weg te komen met een brede wildgroei aan licenties toen open source nog een relatief zeldzame en exotische variëteit was... Nu open source (snik) een algemeen fenomeen, het gebruik van een van de minder gebruikelijke licenties of het bedenken van [uw eigen licentie] werkt vaker tegen u wel dan niet... [gemeenschappen zullen zich zorgen maken/communities will be concerned] als u een licentie gebruikt dat niet een soort van gegeven openbare shakedown heeft gekregen... zullen softwareconsumenten het woud van licenties verkleinen tot een paar goed gesnoeide en onderhouden bomen. Het is beter voor ons allemaal om niet onder hen te verdwalen.”


5. Overweeg GPL incompatibiliteit zorgvuldig

7. Andere dingen om te overwegen








Dit is een nieuwe webpagina

Bijgewerkt door — Priscilla F. Harmanus


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

 
Map
Info