Sammenligning af Open Source Licenses [Guide]

Brief: Denne detaljerede vejledning giver dig en effektiv Open Source-licenser sammenligning. Med Open Source-licenser forklaret her, bør det hjælpe dig med at vælge den rigtige Open Source-licens til dit projekt.

Så du arbejder i et koldt nyt projekt i et stykke tid - og du er nu klar til at gøre det kritiske træk fra lukket kilde til open source.

Det virker ikke meget mere arbejde end at rense kilderne og begivenhedshistorikken, før du trykker på dit lager GitHub or Bitbucket... ... indtil spørgsmålet om licensen popper ud. Der er så mange valgmuligheder. Hvilken man skal vælge? Og gør du det virkelig behøver en licens alligevel?

Det korte svar på det sidste spørgsmål er let: Ja, du virkelig har brug for en licens. Som om hvilken licens du har brug for, kan jeg endda lave et kortere svar: det afhænger.

Men hvis du er seriøs om dit projekt, vil du sandsynligvis have lidt mere detaljer. Så læs videre - og husk: du går ind i det hellige krigsområde nu!

Har jeg brug for en licens? Og hvad er en licens alligevel?

En licens er en officiel tilladelse udstedt af ejeren af ​​noget arbejde ("licensgiver") til andre personer ("licenstageren") og styrer hvordan licenstageren har lov til at bruge licensgiverens arbejde.

Dette har form af en kontrakt, som begge parter er enige om. I dag er accepten ret implicit: lige ved ved brug af noget arbejde, er du anset for at være enig med dens brugslicens.

Bare for at gøre det klart, når du frigiver din egen arbejde er licensgiveren dig. Og licenstageren, nogen ved hjælp af din kode. Generelt omfatter dette to hovedkategorier: udviklere og slutbrugere.

Og for at ordne nogle få ordforrådssæt, ved ændre dit arbejde, en licenshaver skaber det der kaldes et afledt arbejde. Ikke alle licenser er enige om, hvis brug af dit arbejde i et større arbejde vil kvalificere det sidstnævnte som et afledt arbejde eller ej. Som du vil se nedenfor, adresserer nogle licenser specifikt disse problemer.

Hvad er formålet med licensen?

Grundlæggende er Licensen en måde for Licensgiveren og Licenstageren at blive enige om rettigheder og forpligtelser of både af dem. Disse rettigheder og forpligtelser i forbindelse med en licens kan være noget - op til omfanget af hvad loven tillader. For eksempel kan en Licensgiver kræve, at Licenstageren citerer sit navn, når hun bruger sit arbejde. Eller kan give tilladelse til at kopiere sit arbejde, men ikke at ændre det på nogen måde. Eller endda kræve afledt arbejde frigives på samme vilkår som det originale arbejde.

På den anden side er licensen en måde at beskytte licenstageren på. Ved at tydeligt angive, hvordan han kan bruge dit arbejde, er han ikke i fare for at se dig uventet bede om royalties eller en anden form for kompensation for at have brugt dit arbejde. Noget der er afgørende for dit arbejde vedtagelse.

Så vil licensen beskytte dit arbejde. Vil beskytte Licensgiveren. Men vil også beskytte dig. Jeg mener dig, personligt. For eksempel ved at begrænse Licensgiverens ansvar for potentielle skader forårsaget af hendes arbejde.

Og hvad hvis jeg slet ikke bruger nogen licens?

I mangel af en licens, der er udtrykkeligt forbundet med et arbejde, gælder "standard" ophavsret til forfatterens jurisdiktion. Med andre ord, aldrig overveje "fravær af licens" som et implicit tilskud for os at gøre hvad vi vil med dit arbejde. Dette er det nøjagtige modsatte: Uden nogen specifik licens har du, forfatteren, ikke frafaldet nogen af ​​dine rettigheder som loven giver.

Men husk altid en licens styrer rettigheder og forpligtelser. Har du nogensinde spekuleret på, hvorfor så mange licenstekst indeholder en ansvarsfraskrivelse, der er skrevet i ALLE OMFATTET BILLEDER om garantierne med et produkt - eller oftere manglende garanti? Dette er til beskytte ejeren af ​​arbejdet imod implicitte garantier eller brugerforudsætninger. Det sidste, du vil have, er at blive sagsøgt som følge af at du frigiver dit arbejde open source!

Kan jeg bruge en brugerdefineret licens?

Ja du kan. Men det skal du nok ikke.

At være en kontrakt, kan en licens ikke (i de fleste jurisdiktioner? Alle af dem) have forrang over de territoriale love. Derfor er det vanskeligt at håndhæve licensrettighederne i en globaliseret verden. Det ville nok være lettere (jeg mener, mindre vanskeligt) at forsvare en "standard" licens før en dommer. Faktisk er sådanne sager allerede blevet forsvaret i flere jurisdiktioner og kan nævnes som præcedens. Det er selvfølgelig noget, der ikke kan gøres med en brugerdefineret licens.

I tillæg er brugerdefinerede licenser (undertiden vednavnet Vanity Licenses) kan skabe uforeneligheder med andre licenser, hvilket resulterer i en dårlig kompatibilitet af dit arbejde lovligt.

Må jeg bruge flere licenser?

Ja. Multi-licensiering - især Dual-licensing - er ikke så usædvanligt. Dette gælder især, når du vil bygge en virksomhed omkring dit gratis arbejde. I så fald vil dit projekt sandsynligvis blive frigivet både under en FOSS-licens og en kommerciel licens.

En anden brug af multi-licensiering er at øge kompatibiliteten ved at lade dit arbejde kombineres med værker, der udgives under forskellige vilkår eller for at opfylde forskellige brugers behov eller krav. Dette er en grund til, at noget projekt frigives under flere FOSS-licenser.

Men vær advaret: ikke alle licenser er kompatible sammen! Endnu engang vil jeg fraråde dig fra at genopfinde hjulet ved at opholde sig med velkendte kompatible licenser, hvis du vil gå på den måde.

Kan jeg ændre licensen "senere"?

Ja. Indehaveren af ​​ophavsret er ansvarlig for licensbetingelserne. Det er ret nemt at ændre Licensen, så længe du er den eneste bidragyder. Men for at tage et ekstremt eksempel, hvis Linus Torvald ønsker at frigive Linux-kernen under en anden licens, ville han sandsynligvis først beherske aftalen med de tusindvis af bidragydere til projektet. Noget umuligt i praksis.

For et mere rimeligt dimensioneret projekt kan det gøres. Og faktisk var det som du vil se i nogle eksempler nedenfor.

Hvilken Open Source-licens skal jeg bruge?

Ok, nu er du overbevist om, at du skal bruge en standardlicens. Men hvilken skal man vælge? Det endelige valg er op til dig. Og der er meget godt lavet komparatorer tilgængelige på nettet for at hjælpe dig efter eget valg. Bare for at citere mine favoritter:

Men som altid med juridiske anliggender vil det endelige svar være at læse - og forstå - den autoritative tekst af Licensen. Det kan kræve hjælp fra en professionel advokat. Noget jeg ikke er.

Men hvad jeg kan gøre er at give dig en introduktion til de mest almindelige licenser for at guide dine første trin.

GNU General Public License (GPL)

GPL er en af ​​de mest populære Open Source-licenser. Den kommer i flere versioner - men for et nyt projekt skal du overveje det nyeste, hvilket er GPL 3 på tidspunktet for denne skrivning.

Støtte til en stærk copyleft, GPL er nok den mest beskyttende fri software licens. Noget det kan roses eller kritiseres for afhængigt af dit synspunkt. Kernekonceptet bag GPL-væsenet enhver Afledt arbejde skal også frigives under GPL.

  • Stærk copyleft
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgivere kan ændre arbejdet.
  • Licensgivere skal frigive kilden sammen med afledt arbejde.
  • Afledt arbejde skal frigives på samme vilkår.

Populære projekter

GPL er den naturlige licens til projekterne fra Free Software Foundation. Herunder GNU værktøjer kernen i ethvert Linux-system. Store projekter - så meget desto mere kommercielle dem - har tendens til at bruge GPL i forbindelse med en eller flere andre licenser.

  • Inkscape (Vector tegning): GPLv2
  • Drupal (Web Content Management System): GPLv2
  • MariaDB (Databaser): GPL v2
  • MySQL (Databaser): GPL og Commercial License
  • Qt (platforme på tværs af platforme): LGPL, GPL og Commercial - afhængigt af moduler og serviceaftale

GNU Lesser General Public License (LGPL)

GPL er meget restriktiv i den forstand, at det tvinger ethvert afledt arbejde til at blive frigivet open source på samme vilkår. Dette er især en bekymring for biblioteker - som er byggesten til større software: ved at frigive et bibliotek under GPL, vil du tvinge enhver ansøgning ved brug af at biblioteket skal frigives som GPL også. Noget LGPL adresser.

For biblioteker, FSF skelner mellem tre sager:

  • Dit bibliotek implementerer en standard, som konkurrerer med en ikke-fri standard. I så fald vil bred vedtagelse af dit bibliotek hjælpe Freeware software årsagen. FSF foreslår den ret tilladte Apache-licens for den sag (beskrevet senere i den artikel).
  • Dit bibliotek implementerer en standard, der allerede er implementeret af andre biblioteker. I så fald er der ingen fordel for fri software årsagen til at opgive copyleft helt. Så anbefaler FSF LGPL.
  • Endelig, hvis dit bibliotek gør ikke konkurrere med andre biblioteker eller andre standarder, FSF anbefaler GPL.

FSF-argumenterne er for det meste etiske og filosofiske. I praksis kan udviklere have andre bekymringer. Især hvis de planlægger at udvikle en virksomhed baseret på det licenserede arbejde. Endnu en gang kan to-licensiering være en mulighed at overveje.

  • Svag copyleft (bundet til dynamisk forbundet bibliotek)
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgivere kan ændre arbejdet.
  • Licensgivere skal frigive kilden sammen med afledt arbejde.
  • hvis du ændre Arbejdet, dig skal frigive det ændrede arbejde under de samme vilkår.
  • hvis du brug Arbejdet, du behøver ikke at frigive det afledte arbejde under de samme vilkår.

Populære projekter

  • OpenOffice.org 3 (office suite): LGPLv3 - men Apache OpenOffice 4 skiftet til Apache License 2.0.
  • GTK +, GIMP Toolkit (GUI værktøjssæt): LGPLv2.1
  • CUPS (platformeudskrivningssystem): GPL eller LGPLv2 med en undtagelse for Apples operativsystemer - afhængigt af komponenterne.
  • WineHQ (Windows-kompatibilitetslag): LGPLv2.1
  • GNU Aspell (Stavekontrol): LGPLv2.1

Eclipse Public License (EPL 1.0)

Med en svagere copyleft end LGPL er Eclipse-licens mere forretningsmæssig, da det tillader underlicensiering og opbygning af software lavet af EPL og ikke-EPL (selv proprietær) licenseret kode, forudsat at ikke-EPL-koden er en "Separat modul [s] af software".

Derudover tilføjer EPL ekstra beskyttelse for EPL-kodebidragerne i tilfælde af retssager / skader forårsaget af et kommercielt tilbud, herunder dette arbejde.

  • Svag copyleft (bundet til software "modul")
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgiverne kan ændre arbejdet.
  • Hvis du ændre Arbejdet, dig skal frigive det ændrede arbejde under de samme vilkår.
  • Hvis du brug Arbejdet, du behøver ikke at frigive det afledte arbejde under de samme vilkår.
  • Kommercielle distributører af softwaren skal forsvare eller kompensere oprindelige EPL-bidragsydere fra retssager / skader forårsaget af det kommercielle tilbud.

Populære projekter

Naturligvis er EPL den naturlige licens til Eclipse Foundation-projekterne. Herunder den populære Eclipse IDE. Men det fik en vis popularitet ud over det - især i Java-verdenen:

  • Clojure (Programmeringssprog)
  • Graphviz (Graf visualisering pakke)
  • Anløbsbro (Application server): dobbelt licens EPL1.0 / Apache License 2.0 siden Jetty 7
  • JUnit (Java-enhedstestramme)

Mozilla Public License (MPL)

Mozilla Public License er licens, der bruges til software udviklet af Mozilla Foundation. Men det er bestemt ikke begrænset til dette område. MPL sigter mod at være et kompromisstrin mellem strenge licenser (som GPL) og tilladelseslicenser (som MIT-licensen).

I MPL er "licensenheden" kildefilen. Licensgivere må ikke begrænse brugerrettighederne og adgangen til nogen fil omfattet af MPL. Men det samme projekt kan også indeholde proprietære ikke-MPL-licenserede filer. Det resulterende projekt kan frigives under enhver licens, forudsat at der gives adgang til de MPL-licenserede filer.

  • Svag copyleft (bundet til individuelle filer)
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgivere kan ændre arbejdet.
  • Licensgivere skal levere passende tilskrivning til arbejdet.
  • Licensgivere kan omfordele afledt arbejde under forskellige vilkår
  • Licensgivere kan ikke relicense MPL-licenseret kilde
  • Licensgivere skal distribuere MPL-licenseret kildekode sammen med deres afledte arbejde.

Populære projekter

  • Mozilla Firefox (webbrowser), Mozilla Thunderbird (e-mail-klient): MPL
  • LibreOffice (kontor suite): MPL2.0
  • H2 Database Engine (database): MPL2.0 og Eclipse License 1.0
  • Cairo (2D grafisk motor): MPL 1.1 eller LGPLv2.1

Apache License 2.0 (ASL 2.0)

Med ASL kommer vi ind i rige eftergivende gratis licenser. Men selv FSF foreslår Apache License i nogle tilfælde. Apache-licensen er lovlig, da den ikke kræver det enhver Afledt Arbejde, der skal distribueres på samme vilkår. Det er med andre ord en licens, der ikke er copyleft.

ASL er den eneste licens, der anvendes til projekter fra Apache Software Foundation. Betragtes som forretningsvenlig, har den fået en bred vedtagelse uden for den pågældende organisation. Det er ikke ualmindeligt at se virksomhedskvalitet projekter, der skal frigives under ASL.

  • Ikke-copyleft
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgivere kan ændre arbejdet.
  • Licensgivere skal levere passende tilskrivning til arbejdet.
  • Licensgivere kan omfordele afledt arbejde under forskellige vilkår.
  • Licensgivere behøver ikke at distribuere kildekoden sammen med deres afledte arbejde.

Populære projekter

  • Android (operativsystem): ASL 2.0 med nogle undtagelser (især vedrørende Linux-kernen)
  • Apache httpd (Webserver): ASL 2.0
  • Apache Spark (Cluster computing framework): ASL 2.0
  • Spring Framework (Rammer til Java-baserede virksomhedsapplikationer): ASL 2.0

MIT License

Denne er en meget populær licens. Selv nok den mest populære. Ved at lægge meget få begrænsninger på genbrug, kan MIT-licensen let forbindes med andre licenser, fra GPL til proprietære licenser.

  • Ikke-copyleft
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgivere kan ændre arbejdet.
  • Licensgivere skal levere passende tilskrivning til arbejdet.
  • Licensgivere kan omfordele afledt arbejde under forskellige vilkår
  • Licensgivere behøver ikke at distribuere kildekoden sammen med deres afledte arbejde.

Populære projekter

  • node.js (JavaScript runtime miljø): MIT Licens
  • jQuery (JavaScript-bibliotek på klientsiden): MIT-licens (indtil 2012, dual-license MIT / GPL)
  • Atom (tekstredigerer): MIT-licens
  • AngularJS (JavaScript Application Framework): MIT Licens
  • SQLAlchemy (SQL værktøjssæt og Object Relational Mapper til Python): MIT-licens

BSD-licenser

BSD-licens leveres i tre varianter. Den oprindelige 4-klausul Licens, den "reviderede" 3-klausul Licens og den "forenklede" 2-klausul Licens. Alt i ånd er meget tæt på MIT-licensen. Og der er faktisk meget lidt praktiske forskelle mellem 2-klausulen BSD License & MIT License.

3- og 4-klausul BSD-licenser tilføjer flere krav vedrørende navnegenbrug og reklame. Dette er noget at overveje, hvis du vil beskytte dit produkt eller dit mærke.

  • Ikke-copyleft
  • Arbejdet er velegnet til kommerciel brug.
  • Licensgivere kan ændre arbejdet.
  • Licensgivere skal levere passende tilskrivning til arbejdet.
  • Licensgivere kan omfordele afledt arbejde under forskellige vilkår.
  • Licensgivere behøver ikke at distribuere kildekoden sammen med deres afledte arbejde.
  • Licensgivere kan ikke bruge det oprindelige Forfatternavn eller varemærke til at godkende afledt arbejde (3- og 4-klausul BSD)
  • Licensgivere skal anerkende den oprindelige Forfatter i alle reklamematerialer, der omtaler funktioner eller brug af Work (4-klausul BSD)

Populære projekter

  • Django (web ramework): 3-klausul BSD
  • Omfor (datalager): 3-klausul BSD
  • Rubin (programmeringssprog): 2-klausul BSD og brugerdefineret licens
  • Nginx (Webserver): 2-klausul BSD
  • NetBSD (Operativsystem): 2-klausul BSD - 4-klausul BSD til 2008

Det sidste ord på Open Source-licenser

Hvis du kommer så langt, tillykke! Du forstår det nu, licensering er virkelig en enorm og komplekst emne. Men det er værd at tage tid til at vælge den rigtige licens til dit projekt - og gøre det valg tidligt. Det kan spare dig mange problemer senere, så du kan bruge din tid og energi til at arbejde på dit projekt i stedet for at beskæftige sig med problemer med ophavsret eller juridisk kompatibilitet.

Selvom jeg har gjort mit bedste for at gøre dette emne tilgængeligt, er det ikke altid nemt at opsummere de forskellige licensers finesser. Og ud over de få store licenser, der præsenteres her, er der snesevis af andre mere eller mindre almindeligt anvendte.

Så tøv ikke med at bruge kommentarsektionen nedenfor for at fortælle os hvad der er DIN foretrukne licens og hvorfor. Eller for at nævne nogle vigtige egenskaber, jeg måske har glemt!

Kilde

Giv en kommentar

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.