Open Source Licenses Vergelijking

Brief : deze gedetailleerde gids geeft u een effectieve vergelijking van Open Source-licenties. Met Open Source-licenties die hier worden uitgelegd, zou het u moeten helpen bij het kiezen van de juiste Open Source-licentie voor uw project.

Dus je werkt al een tijdje aan dat coole nieuwe project - en je bent nu klaar om de kritische stap te zetten van closed source naar open source .

Het lijkt niet veel meer werk dan het opschonen van de bronnen en de commit-geschiedenis voordat je je repository op GitHub of Bitbucket pusht ... totdat de kwestie van de licentie naar voren komt. Er zijn zoveel keuzes beschikbaar. Welke moet je kiezen? En heb je toch echt een licentie nodig?

Het korte antwoord op die laatste vraag is eenvoudig: ja, je hebt echt een licentie nodig. Wat betreft de licentie die u nodig hebt, ik kan zelfs een korter antwoord geven: het hangt ervan af .

Maar als je serieus bent over je project, wil je waarschijnlijk een beetje meer details. Dus lees vooruit - en onthoud: je betreedt nu het heilige oorlogsgebied!

Heb ik een licentie nodig? En wat is een licentie toch?

Een licentie is een officiële toestemming die door de eigenaar van een bepaald werk (de "licentieverlener") wordt verleend aan andere mensen (de "licentienemer") en bepaalt hoe de licentienemer het werk van de licentieverlener mag gebruiken.

Dit gebeurt in de vorm van een contract, waar beide partijen het mee eens moeten zijn. Tegenwoordig is de acceptatie nogal impliciet: alleen al door het gebruik van wat werk, is het bekend dat u akkoord gaat met de gebruikslicentie.

Gewoon om het denken duidelijk te maken, wanneer je je eigen werk vrijgeeft, ben jij de Licentiegever. En de licentiehouder, iedereen die uw code gebruikt. In grote lijnen omvat dit twee hoofdcategorieën: ontwikkelaars en eindgebruikers .

En om nog een paar woordenschattermen te repareren, door uw Werk aan te passen, creëert een Licentiehouder een zogenaamd Afgeleide Werk. Niet alle licenties zijn het echter eens als het gebruik van je werk in een groter werk dat laatste als een afgeleide werk kwalificeert of niet. Zoals u hieronder zult zien, pakken sommige licenties deze problemen specifiek aan.

Wat is het doel van de licentie?

In principe is de Licentie een manier voor de Licentiegever en de Licentienemer om overeenstemming te bereiken over de rechten en plichten van beide . De rechten en plichten die verbonden zijn aan een licentie kunnen alles zijn , tot de omvang van wat de wet toestaat . Een licentiegever kan bijvoorbeeld van de licentienemer verlangen dat hij haar naam opgeeft bij het gebruik van haar werk. Of kan autoriseren om haar werk te kopiëren, maar niet om het op enigerlei wijze te wijzigen. Of zelfs vereisen dat afgeleide werken worden vrijgegeven onder dezelfde voorwaarden als het oorspronkelijke werk.

Aan de andere kant is de licentie ook een manier om de licentienemer te beschermen. Door duidelijk te vermelden hoe hij je werk kan gebruiken, loopt hij niet het risico dat hij onverwachts vraagt ​​om royalty's of een andere vorm van compensatie voor het gebruik van je werk. Iets dat cruciaal is voor uw werkaanvaarding.

Dus de licentie beschermt je werk. Beschermt de licentiegever. Maar zal je ook beschermen. Ik bedoel jou persoonlijk . Bijvoorbeeld door de verantwoordelijkheid van de licentiegever voor mogelijke schade veroorzaakt door haar werk te beperken.

En wat als ik helemaal geen licentie gebruik?

Bij afwezigheid van een licentie die expliciet is gekoppeld aan een werk, is het "standaard" auteursrecht voor het rechtsgebied van de auteur van toepassing. Met andere woorden, beschouw nooit de "afwezigheid van licentie" als een impliciete verlening voor ons om te doen wat we willen met uw werk. Dit is precies het tegenovergestelde: u, de auteur, heeft zonder een specifieke licentie niet afstand gedaan van uw rechten zoals die door de wet zijn verleend.

Maar onthoud altijd dat een licentie de rechten en plichten regelt. Heb je je ooit afgevraagd waarom zoveel licentietekst een disclaimer bevat die is geschreven in ALLE HOOFDLETTERS over de garanties bij een product - of vaker de afwezigheid van garantie? Dit is om de eigenaar van het werk te beschermen tegen impliciete garanties of veronderstellingen van gebruikers. Het laatste wat je wilt is vervolgd worden als een gevolg van het open-source vrijgeven van je werk!

Kan ik een aangepaste licentie gebruiken?

Ja, dat kan. Maar dat zou u waarschijnlijk niet moeten doen.

Als een contract kan een licentie niet (in de meeste jurisdicties? Allemaal?) Voorrang hebben boven de territoriale wetten. Vandaar de moeilijkheid om de licentierechten in een geglobaliseerde wereld af te dwingen. Het zou waarschijnlijk gemakkelijker (ik bedoel, minder moeilijk) zijn om een ​​"standaard" licentie voor een rechter te verdedigen. Dergelijke gevallen zijn zelfs al in verschillende rechtsgebieden verdedigd en kunnen als precedent worden aangehaald. Het is duidelijk dat iets niet mogelijk is met een aangepaste licentie.

Aanvullend kunnen aangepaste licenties (soms de bijnaam Vanity Licenses) incompatibiliteit met andere licenties creëren, wat resulteert in een slechte compatibiliteit van uw werk in juridische zin.

Mag ik verschillende licenties gebruiken?

Ja. Multi-licensing - met name Dual-licensing - is niet zo ongewoon. Dit geldt vooral als je een bedrijf wilt opbouwen rond je gratis werk. In dat geval zal uw project waarschijnlijk worden vrijgegeven, zowel onder een FOSS-licentie als een commerciële licentie.

Een ander gebruik van multi-licensing is om de compatibiliteit te vergroten, door uw werk te laten combineren met werken die onder verschillende voorwaarden zijn gepubliceerd of om te voldoen aan verschillende gebruikersbehoeften of -vereisten. Dit is een reden waarom sommige projecten worden vrijgegeven onder verschillende FOSS-licenties.

Maar wees gewaarschuwd: niet alle licenties zijn samen compatibel! Nogmaals, ik zou je ontmoedigen om het wiel opnieuw uit te vinden door bij bekende compatibele licenties te blijven als je die kant op wilt.

Kan ik de licentie "later" wijzigen?

Ja. De houder van het auteursrecht is verantwoordelijk voor de licentievoorwaarden. Het is vrij eenvoudig om de licentie te wijzigen zolang u de enige bijdrager bent. Maar om een ​​extreem voorbeeld te geven, als Linus Torvald de Linux Kernel onder een andere licentie zou willen vrijgeven, zou hij waarschijnlijk eerst de instemming van de duizenden bijdragers aan dat project nodig hebben. Iets onmogelijk in de praktijk.

Voor een meer redelijk groot project kan het worden gedaan. En in feite was het zoals je zult zien in enkele voorbeelden hieronder.

Welke Open Source-licentie moet ik gebruiken?

Oké, nu ben je ervan overtuigd dat je een standaardlicentie moet gebruiken. Maar welke te kiezen? De uiteindelijke keuze is aan u. En er zijn zeer goed gemaakte comparators beschikbaar op het internet om u te helpen bij uw keuze. Gewoon om mijn favorieten te citeren:

  • //oss.ly/licdif
  • //choosealicense.com/ / //choosealicense.com/appendix/
  • //opensource.org/licenses
  • //tldrlegal.com/

Maar zoals altijd met juridische zaken, zal het definitieve antwoord zijn om de gezaghebbende tekst van de licentie te lezen - en te begrijpen. Dat kan de hulp van een professionele advocaat vereisen. Iets wat ik niet ben.

Maar wat ik wel kan doen, is u een introductie geven van de meest voorkomende licenties om uw eerste stappen te zetten.

GNU General Public License (GPL)

De GPL is een van de populairste Open Source-licenties. Het komt in verschillende versies - maar voor een nieuw project, zou je de meest recente moeten overwegen, wat de GPL 3 is ten tijde van dit schrijven.

Ondersteund door een sterke copyleft is de GPL waarschijnlijk de meest beschermende gratis softwarelicentie. Iets wat het kan worden geprezen of bekritiseerd voor afhankelijk van uw standpunt. Het kernconcept achter de GPL als eender welk afgeleide werk moet ook onder de GPL worden vrijgegeven.

  • Sterke copyleft
  • Het werk is geschikt voor commercieel gebruik.
  • Licentiehouders kunnen het werk aanpassen.
  • Licentiehouders moeten de bron vrijgeven naast Afgeleide werken.
  • Afgeleide werken moeten onder dezelfde voorwaarden worden vrijgegeven.

Populaire projecten

De GPL is de natuurlijke licentie voor de projecten van de Free Software Foundation. De GNU-tools opnemen in het hart van elk Linux-systeem. Grote projecten - a fortiori commerciële - hebben de neiging om de GPL te gebruiken in combinatie met een of meerdere andere licenties.

  • Inkscape (vectortekening): GPLv2
  • Drupal (Web Content Management System): GPLv2
  • MariaDB (Databases): GPL v2
  • MySQL (databases): GPL en commerciële licentie
  • Qt (platformonafhankelijk toepassingsraamwerk): LGPL, GPL en Commercial - afhankelijk van het niveau van modules en serviceovereenkomsten

GNU Lesser General Public License (LGPL)

De GPL is zeer restrictief in de zin dat alle afgeleide werken onder dezelfde voorwaarden worden vrijgegeven voor open source. Dit is met name een zorg voor bibliotheken - die bouwstenen zijn voor grotere software: door een bibliotheek onder de GPL vrij te geven, dwing je alle applicaties die die bibliotheek gebruiken om ook als GPL te worden vrijgegeven. Iets wat de LGPL aanpakt.

Voor bibliotheken onderscheidt de FSF drie gevallen:

  • Uw bibliotheek implementeert een standaard die concurreert met een niet-vrije standaard. In dat geval zal een brede acceptatie van uw bibliotheek de Vrije Software helpen. De FSF suggereert de nogal permissieve Apache-licentie voor die zaak (verderop in dat artikel beschreven).
  • Uw bibliotheek implementeert een standaard die al door andere bibliotheken is geïmplementeerd. In dat geval is er geen voordeel voor de Free Software-reden om de auteursplicht geheel te verlaten. Dus de FSF beveelt de LGPL aan.
  • Ten slotte, als uw bibliotheek niet concurreert met andere bibliotheken of andere normen, beveelt de FSF de GPL aan.

De FSF-argumenten zijn meestal ethisch en filosofisch. In de praktijk kunnen ontwikkelaars andere zorgen hebben. Vooral als ze van plan zijn om een ​​bedrijf te ontwikkelen op basis van het werk met een licentie. Nogmaals, dual-licensing kan een optie zijn om te overwegen.

  • Zwak copyleft (gebonden aan dynamisch gekoppelde bibliotheek)
  • Het werk is geschikt voor commercieel gebruik.
  • Licentiehouders kunnen het werk aanpassen.
  • Licentiehouders moeten de bron vrijgeven naast Afgeleide werken.
  • als u het werk wijzigt, moet u het gewijzigde werk onder dezelfde voorwaarden vrijgeven.
  • als je het Werk gebruikt, hoef je het Afgeleide Werk niet onder dezelfde voorwaarden vrij te geven.

Populaire projecten

  • OpenOffice.org 3 (kantoorsuite): LGPLv3 - maar Apache OpenOffice 4 stapte over naar Apache License 2.0.
  • GTK +, de GIMP Toolkit (GUI toolkit): LGPLv2.1
  • CUPS (platformonafhankelijk afdruksysteem): GPL of LGPLv2 met uitzondering voor Apple-besturingssystemen - afhankelijk van de componenten.
  • WineHQ (Windows-compatibiliteitslaag): LGPLv2.1
  • GNU Aspell (Spellingcontrole): LGPLv2.1

Eclipse Public License (EPL 1.0)

Met een zwakker auteursplicht dan de LGPL, is de Eclipse-licentie zakelijker omdat het sublicentie en bouwen van software mogelijk maakt gemaakt van EPL en niet-EPL (zelfs eigen) gelicentieerde code, op voorwaarde dat de niet-EPL-code een "afzonderlijke" is module [s] van software " .

Bovendien voegt de EPL extra bescherming toe voor de EPL-code-bijdragers in het geval van rechtszaken / schade veroorzaakt door een commercieel aanbod inclusief dat werk.

  • Zwak copyleft (gebonden aan software "module")
  • Het werk is geschikt voor commercieel gebruik.
  • De licentiehouders kunnen het werk aanpassen.
  • Als u het werk aanpast, moet u het gewijzigde werk onder dezelfde voorwaarden vrijgeven.
  • Als u het werk gebruikt, hoeft u _din_het afgeleide werk niet onder dezelfde voorwaarden vrij te geven.
  • Commerciële distributeurs van de software moeten originele EPL-bijdragers verdedigen of compenseren voor rechtszaken / schade veroorzaakt door het commerciële aanbod.

Populaire projecten

Vanzelfsprekend is de EPL de natuurlijke licentie voor de projecten van de Eclipse Foundation. Inclusief de populaire Eclipse IDE. Maar het kreeg wat meer populariteit dan dat - vooral in de Java-wereld:

  • Clojure (programmeertaal)
  • Graphviz (Graph visualisatie pakket)
  • Jetty (applicatieserver): dubbele licentie EPL1.0 / Apache License 2.0 sinds Jetty 7
  • JUnit (kader voor het testen van Java-eenheden)

Mozilla Public License (MPL)

De Mozilla Public License is een licentie die wordt gebruikt voor software die is ontwikkeld door de Mozilla-stichting. Maar het is zeker niet beperkt tot dat gebied. De MPL streeft ernaar een compromis te zijn tussen strikte licenties (zoals de GPL) en permissieve licenties (zoals de MIT-licentie).

In de MPL is de "licentie-eenheid" het bronbestand. Licentiegevers mogen de gebruikersrechten en toegang tot elk bestand dat onder de MPL valt niet beperken. Maar hetzelfde project kan ook niet-MPL-gelicentieerde bestanden bevatten. Het resulterende project kan onder elke licentie worden vrijgegeven, op voorwaarde dat toegang tot de MPL-licentiebestanden wordt verleend.

  • Zwak copyleft (gebonden aan individuele bestanden)
  • Het werk is geschikt voor commercieel gebruik.
  • Licentiehouders kunnen het werk aanpassen.
  • Licentiehouders moeten de juiste attributie voor het Werk verstrekken.
  • Licentiehouders mogen Derivative Work onder verschillende voorwaarden herdistribueren
  • Licentiehouders kunnen geen door MPL gelicentieerde bron overbrengen
  • Licentiehouders moeten MPL-gelicentieerde broncode verspreiden naast hun Afgeleide Werk.

Populaire projecten

  • Mozilla Firefox (webbrowser), Mozilla Thunderbird (e-mailclient): MPL
  • LibreOffice (kantoorsuite): MPL2.0
  • H2 Database Engine (database): MPL2.0 en Eclipse License 1.0
  • Cairo (2D grafische engine): MPL 1.1 of LGPLv2.1

Apache License 2.0 (ASL 2.0)

Met de ASL gaan we het rijk van vrije licenties in. Maar zelfs de FSF suggereert in sommige gevallen de Apache-licentie. De Apache-licentie is vrijblijvend omdat er geen afgeleide werken hoeven te worden gedistribueerd onder dezelfde voorwaarden. Met andere woorden, dit is een niet-auteursplichtige licentie.

De ASL is de enige licentie die wordt gebruikt voor projecten van de Apache Software Foundation. Wordt beschouwd als bedrijfsvriendelijk, heeft het wijdverspreide goedkeuring buiten die organisatie bereikt. Het is niet ongebruikelijk dat projecten van ondernemingsklasse worden vrijgegeven onder de ASL.

  • Non-copyleft
  • Het werk is geschikt voor commercieel gebruik.
  • Licentiehouders kunnen het werk aanpassen.
  • Licentiehouders moeten de juiste attributie voor het Werk verstrekken.
  • Licentiehouders mogen Derivative Work onder verschillende voorwaarden herdistribueren.
  • Licentiehouders hoeven de broncode niet naast hun Afgeleide Werk te verspreiden.

Populaire projecten

  • Android (besturingssysteem): ASL 2.0 met enkele uitzonderingen (met name met betrekking tot de Linux-kernel)
  • Apache httpd (webserver): ASL 2.0
  • Apache Spark (Cluster computing framework): ASL 2.0
  • Spring Framework (Framework voor op Java gebaseerde bedrijfstoepassingen): ASL 2.0

MIT-licentie

Deze is een erg populaire licentie. Zelfs waarschijnlijk de meest populaire. Door heel weinig beperkingen te stellen aan hergebruik, kan de MIT-licentie gemakkelijk worden gekoppeld aan andere licenties, van de GPL tot eigen licenties.

  • Non-copyleft
  • Het werk is geschikt voor commercieel gebruik.
  • Licentiehouders kunnen het werk aanpassen.
  • Licentiehouders moeten de juiste attributie voor het Werk verstrekken.
  • Licentiehouders mogen Derivative Work onder verschillende voorwaarden herdistribueren
  • Licentiehouders hoeven de broncode niet naast hun Afgeleide Werk te verspreiden.

Populaire projecten

  • node.js (JavaScript runtime-omgeving): MIT-licentie
  • jQuery (client-side JavaScript-bibliotheek): MIT-licentie (tot 2012, MIT / GPL met dubbele licentie)
  • Atom (teksteditor): MIT-licentie
  • AngularJS (JavaScript-toepassingsraamwerk): MIT-licentie
  • SQLAlchemy (SQL-toolkit en Object Relational Mapper voor Python): MIT-licentie

BSD-licenties

BSD-licentie komt in drie smaken. De originele 4-clausule licentie, de "herziene" 3-clausule licentie en de "vereenvoudigde" 2-clausule licentie. Alles komt in de geest erg dicht bij de MIT-licentie. En inderdaad, er zijn erg weinig praktische verschillen tussen de BSD-licentie met 2 codes en de MIT-licentie.

3- en 4-clausule BSD-licenties voegen meer vereisten toe met betrekking tot naamhergebruik en reclame. Dit is iets om te overwegen als u uw product of merknaam wilt beschermen.

  • Non-copyleft
  • Het werk is geschikt voor commercieel gebruik.
  • Licentiehouders kunnen het werk aanpassen.
  • Licentiehouders moeten de juiste attributie voor het Werk verstrekken.
  • Licentiehouders mogen Derivative Work onder verschillende voorwaarden herdistribueren.
  • Licentiehouders hoeven de broncode niet naast hun Afgeleide Werk te verspreiden.
  • Licentiehouders kunnen de oorspronkelijke auteursnaam of het handelsmerk niet gebruiken om Derivative Work te onderschrijven (3- en 4-component BSD)
  • Licentienemers moeten de oorspronkelijke auteur in alle reclamemateriaal dat functies of gebruik van het werk vermeldt (4-clausule BSD) erkennen

Populaire projecten

  • Django (web-ramework): 3-component BSD
  • Redis (gegevensopslag): BSD met 3 codes
  • Ruby (programmeertaal): 2-clausule BSD en aangepaste licentie
  • Nginx (webserver): BSD met 2 codes
  • NetBSD (Besturingssysteem): BSD-4-component BSD tot 2008

Het laatste woord over Open Source-licenties

Als je zover komt, gefeliciteerd! U begrijpt het nu, licentiëren is echt een enorm en complex onderwerp. Maar het is de moeite waard om de juiste licentie voor uw project te kiezen - en die keuze vroegtijdig te maken. Het kan u later veel problemen besparen, zodat u uw tijd en energie aan uw project kunt besteden in plaats van het omgaan met auteursrechtelijke of juridische compatibiliteitsproblemen.

Zelfs als ik mijn best heb gedaan om dat onderwerp toegankelijk te maken, is het niet altijd gemakkelijk om de subtiliteiten van de verschillende licenties samen te vatten. En afgezien van de weinige grote licenties die hier worden gepresenteerd, zijn er tientallen andere min of meer vaak gebruikt.

Dus, aarzel niet om de commentaarsectie hieronder te gebruiken om ons te vertellen wat UW voorkeurslicentie is en waarom. Of om een ​​paar belangrijke kenmerken te noemen die ik misschien vergeten ben!

Aanbevolen

Personaliseer Grub om een ​​betere ervaring met Linux te krijgen
2019
Alfaversie van de nieuwe Skype-client voor Linux is nu verkrijgbaar
2019
MyStory: Hoe ik Linux gebruik op een 13-jarige laptop
2019