Ghidul dezvoltatorului pentru licențe cu sursă deschisă

Nu toate licențele open-source sunt la fel. Unele dintre ele obligă furnizorul de software să acorde licențe de brevet utilizatorilor și dezvoltatorilor de software. Alte licențe obligă dezvoltatorul care utilizează produsul sau biblioteca licențiat să ofere codul sursă al acestui produs sau bibliotecă în aceleași condiții. Alții pur și simplu dau codul, fără nicio garanție de niciun fel sau orice fel de îngrijorare. În acest articol voi încerca să evidențiez principalele diferențe dintre cele mai utilizate licențe open-source din perspectiva unui utilizator de software și a unui dezvoltator de software.

Când în 1984 Richard Stallman a început proiectul GNU pentru crearea unui sistem de operare liber, el a recuperat ideea că software-ul ar trebui să fie împărtășit între dezvoltatori, ingineri și utilizatori; și ar trebui să fie capabili să-l îmbunătățească într-un mod colaborativ, în același mod în care se face de obicei știința.

Această opțiune a contrastat cu conceptul obișnuit de software cu licență ales de majoritatea corporațiilor de software și dezvoltatorilor pentru distribuirea și vânzarea programelor lor. Astăzi, mai mult de treizeci de ani mai târziu, software-ul open-source continuă încet să cucerească sectoare largi ale industriei noastre: Linux, Android, Apache și Git sunt exemple de produse open-source de vârf în categoriile lor.

Software cu sursă deschisă sau liber?

În acest articol, voi folosi termenii „open-source” și „gratuit” ca sinonime în timp ce mă refer la software sau licențe. După părerea mea, ambii termeni exprimă aceeași idee. „Open-source” îl exprimă într-un mod practic și tehnic, iar utilizarea „Free” pune accentul într-un sens filozofic și politic al conceptului.

Din păcate, cuvântul „free” în engleză, pe lângă faptul că este adjectivul asociat cu „libertate”, înseamnă și „fără cost”. Acesta este motivul pentru care de obicei prefer să spun „open-source”.

Proprietăți comune ale software-ului open-source

Presupun că aveți deja o idee aproximativă despre ce este software-ul open-source. Dar, pe măsură ce vom vorbi despre detaliile diferitelor licențe, mai întâi trebuie să vorbim despre proprietățile specifice care definesc software-ul open-source.

În primul rând: nu sunt avocat, iar acesta nu este un sfat juridic. În caz de îndoială, vă rugăm să consultați textul propriu-zis al licențelor despre care vorbesc și la consilierul dumneavoastră juridic.

Toate programele cu sursă deschisă, conform Open Source Initiative, sunt distribuite sub o licență care oferă utilizatorilor și dezvoltatorilor săi (deținătorii de licență) anumite drepturi. Lista completă poate fi consultată în Definiția Open Source, dar iată un rezumat de bază:

1. Redistribuirea gratuită a software-ului: software-ul poate fi vândut sau oferit ca produs sau inclus într-un pachet software. Acest lucru se poate face fără plata unor redevențe.
2. Codul sursă al software-ului licențiat fie este inclus în distribuție, fie cel puțin există mijloace bine mediatizate de obținere a codului sursă. Acest cod sursă este utilizabil pentru dezvoltarea versiunilor modificate ale software-ului.
3. Crearea de lucrări derivate este permisă, iar licența le permite să fie distribuite în aceleași condiții și licență ca și software-ul original. În funcție de licența software-ului original, în unele cazuri aceste lucrări derivate trebuie să fie diferențiate de software-ul original prin schimbarea numelui sau a numărului de versiune sau pot fi distribuite doar sub formă de corecții de cod sursă.
4. Software-ul poate fi folosit de orice persoană sau grup de oameni și în orice domeniu de activitate, fără limitări.

Dar trebuie să rețineți că licențele software vorbesc doar despre utilizarea sau distribuirea permisiunilor acordate de deținătorii drepturilor de autor. Licențele open-source vă pot permite să redistribuiți liber software-ul sau lucrările derivate, dar această alocație poate fi, de asemenea, restricționată în unele țări în care exportul de software criptografic este interzis. Într-un mod similar, licențele open-source vă permit să utilizați software-ul în orice scop, dar asta nu înseamnă că vă permit să accesați o bancă folosind software-ul cu licență open-source. Patentele software sunt un alt exemplu în acest sens: unele licențe open-source acordă permisiuni de utilizare liberă a brevetelor, dar nu toate.

Deci, putem folosi un software open-source în dezvoltarea unui produs sau proiect? Practic, depinde de licența software-ului utilizat și de licența dorită pentru produsul final. Diferitele licențe contează și atunci când doriți să publicați propriul cod ca open-source și decideți ce licență ar trebui să utilizați.

Copyleft

Un concept destul de interesant despre licențele open-source este ceea ce se numește de obicei copyleft, opusul dreptului de autor. În cazul în care drepturile de autor sunt utilizate pentru a proteja proprietatea intelectuală (inclusiv software-ul) împotriva copierii sau distribuirii, copyleft-ul este utilizat pentru a se asigura că proprietatea intelectuală și software-ul cu sursă deschisă pot fi copiate sau distribuite ca sursă deschisă.

În funcție de puterea sa, există două tipuri de copyleft:

• Copyleft puternic: atunci când lucrările derivate din alte lucrări cu licență copyleft puternic, sau legate de aceste lucrări, trebuie să aibă în continuare licențe copyleft puternice, sau chiar exact aceeași licență. Adică, acele lucrări open-source nu pot fi închise în viitor.
• Copyleft slab: atunci când lucrările care utilizează lucrări licențiate cu copyleft slab sau sunt legate la acesta, pot fi licențiate sub alte licențe, chiar și licențe cu sursă închisă. În acest caz, copyleft-ul afectează numai lucrarea originală cu licență copyleft slabă.

Există, de asemenea, licențe open-source fără copyleft: pur și simplu nu le pasă de deschiderea viitoare a software-ului derivat.

Permisivitatea

După permisivitatea lor, licențele pot fi clasificate și în:

• Licențe stricte: atunci când nu puteți combina software puternic cu licență cu sursă închisă sau chiar cu software cu licență mai permisiv.
• Licențe permisive: când produsele pot fi de obicei combinate cu software cu sursă închisă sau cu o licență cu sursă totală deschisă.

De obicei, licențele copyleft puternice sunt, de asemenea, stricte, iar licențele copyleft slabe sunt mai permisive, dar nu trebuie să fie așa.

Diferențele de licențe open-source

Există multe licențe open-source. Open Source Initiative a aprobat deja peste 80 dintre ele. Unele sunt redundante și ar putea fi considerate echivalente cu altele. Altele sunt specifice intereselor editorului de software (cum ar fi licența NASA) sau pentru un anumit mediu sau scop (cum ar fi licența pentru comunitatea educațională sau licența pentru font deschis).

Această proliferare de licențe se bazează pe termeni specifici din licență care, adăugate la proprietățile de bază open-source, permit sau interzice alte utilizări. Exemple de aceste condiții suplimentare pot include:

• Tip de copyleft: slab sau puternic sau inexistent.
• Tip de permisivitate: permisiv sau strict.
• Obligația de a adăuga o notificare de copyright în codul sursă sau în interfața cu utilizatorul.
• Acordarea automată a brevetului licențiaților.
• Considerând drept licențiați nu numai părțile cărora le este distribuit software-ul, ci și utilizatorii software-ului (astfel încât persoanele care utilizează un serviciu în cloud care utilizează acest tip de software open-source ar trebui să aibă posibilitatea de a descărca codul sursă al software-ul)

Problema amestecării codului cu diferite licențe

Conform a ceea ce am spus deja, unele licențe sunt permisive, permițând utilizatorilor să combine codul cu cod sursă diferit (poate cu condiții suplimentare). Acest caz ar permite amestecarea acestui tip de software cu licență open-source cu software cu sursă închisă. Un exemplu de acest tip de licență este licența MIT.

Altele sunt mai restrictive, astfel încât codul sursă poate fi combinat doar cu cod care este licențiat într-un mod similar, iar rezultatul final trebuie să fie licențiat cu aceeași licență originală. Un exemplu de acest tip de licență este General Public License (GPL).

Poate doriți să combinați codul licențiat cu două licențe open-source restrictive diferite. Folosind libertatea open-source de a utiliza software-ul așa cum doriți, puteți face acest lucru. Dar programul final nu poate fi redistribuit, deoarece ar trebui distribuit sub două licențe care nu sunt compatibile între ele.

Un exemplu al acestei situații a fost ZFS. ZFS este un sistem de fișiere foarte avansat și inovator care a fost inclus în OpenSolaris în 2005. Este un software open-source licențiat în conformitate cu termenii Common Development and Distribution License (CDDL). Deși este un cod open-source, nu poate fi integrat în kernel-ul Linux, deoarece codul sursă Linux este distribuit în conformitate cu termenii General Public License, o altă licență restrictivă open-source. Binarele nucleului Linux compilate cu suport ZFS nu pot fi distribuite din cauza conflictului de licență.

Aceste tipuri de conflicte pot fi rezolvate numai dacă toți proprietarii unuia dintre programele open-source sunt de acord să schimbe licența sau să adauge termeni de excepție în licența software. De exemplu: o mulțime de programe cu licență GPL sunt conectate cu biblioteca OpenSSL. Distribuția bibliotecii OpenSSL este licențiată, necesitând o expresie să apară în materialul publicitar și în orice redistribuire. Aceste condiții suplimentare nu sunt compatibile cu GPL și, din această cauză, dezvoltatorii de produse GPL care utilizează OpenSSL au inclus o excepție în licența lor, care permite în mod specific conectarea cu OpenSSL.

Caracteristici diferențiate ale licențelor open-source

Acum voi încerca să analizez cele mai populare licențe open-source, remarcându-le caracteristicile diferențiale, cu un mic ghid despre când să le folosesc sau nu. Le-am sortat de la mai mult la mai puțin utilizate, conform bazei de cunoștințe Black Duck.

Licență publică generală GNU (GPL)

GPL este cea mai populară licență open-source. A fost creat de FSF ca licență pentru proiectul GNU și este, de asemenea, licența kernel-ului Linux.

Caracteristicile sale diferențiale:

• Copyleft puternic.
• Licență foarte strictă.
• De obicei, se numește licență „virală”: dacă vă conectați codul la o altă bucată de cod licențiată conform GPL și doriți să distribuiți rezultatele, întregul produs trebuie să fie licențiat GPL.
• Este, de asemenea, o licență „înglobatoare”: dacă dezvoltați un software și doriți să-l acordați licență conform GPL, îl puteți conecta sau include alt software open-source, atâta timp cât acest software are o licență compatibilă cu GPL. Nu necesită nicio obligație care nu este cerută de GPL.

De obicei, textul de licență utilizat include textul care spune că software-ul este distribuit în conformitate cu termenii versiunii GPL N (sau orice versiune ulterioară).

În prezent, există două versiuni de licență GPL în uz: v2 și v3. Versiunea 3 a fost lansată în 2007 pentru a rezolva unele probleme care au apărut de la lansarea versiunii 2 în 1991.

GPL v3 include unele clauze și termeni suplimentari, abordând reglementările de compatibilitate cu alte licențe open-source, obligând licențele de brevet, definind condițiile de utilizare a software-ului cu licență GPL ca firmware în aparate și luând în considerare concepte precum managementul drepturilor digitale.

Licență MIT

Licența open-source cunoscută de obicei sub numele de MIT License, aka X11, este o licență foarte permisivă, non-copyleft, care permite tuturor să folosească, practic, codul astfel licențiat pentru orice doriți, atâta timp cât păstrați mesajul privind drepturile de autor și să știți că software-ul vine fără garanție de niciun fel.

Această licență este foarte populară și este folosită de mai multe proiecte precum X Window System, Ruby on Rails, jQuery sau Node.js.

Este compatibil cu GPL, așa că puteți combina codul cu licență MIT în software-ul GPL.

Licență Apache 2.0

Licența Apache a fost creată de Apache Software Foundation (ASF) ca licență pentru serverul său HTTP Apache.

La fel ca Licența MIT, este o licență foarte permisivă, fără copyleft, care permite utilizarea software-ului în orice scop, distribuirea acestuia, modificarea și distribuirea lucrărilor derivate din acesta fără a se preocupa de redevențe. Principala sa diferență față de licența MIT sunt:

• Folosind Licența Apache, autorii software-ului acordă licențe de brevet oricărui utilizator sau distribuitor al codului. Aceste licențe de brevet se aplică oricărui brevet care, fiind licențiabil de către oricare dintre autorii software-ului, ar fi încălcat de fragmentul de cod pe care l-au creat.
• Licența Apache a cerut ca părțile nemodificate din lucrările derivate să păstreze Licența.
• În fiecare fișier licențiat, orice notificare originală privind drepturile de autor, brevetele, mărcile comerciale sau atribuirea trebuie păstrată.
• În fiecare modificare a fișierului licențiat, trebuie să existe o notificare care să ateste că au fost făcute modificări în fișier.
• Dacă software-ul cu licență Apache include un fișier NOTICE, acest fișier și conținutul său trebuie păstrate în toate lucrările derivate.
• Dacă cineva trimite intenționat o contribuție pentru un software cu licență Apache autorilor săi, această contribuție poate fi utilizată automat sub Licența Apache.

Această licență este interesantă din cauza licenței automate de brevet și a clauzei privind depunerea contribuțiilor.

Este compatibil cu GPL, așa că puteți combina codul licențiat Apache în software-ul GPL.

Licență BSD

Există 3 licențe BSD diferite. Toate sunt licențe foarte permisive fără copyleft.

Licența BSD cu două clauze (sau Licența BSD simplificată) este total echivalentă cu Licența MIT care a fost explicată anterior.

Licența BSD cu 3 clauze (sau Licența BSD Nouă) adaugă o clauză, specificând că nici numele deținătorului drepturilor de autor, nici numele colaboratorilor săi nu pot fi folosite pentru a susține sau promova produse derivate din software fără o permisiune scrisă prealabilă specifică. Această versiune este compatibilă cu GPL, permițându-vă să amestecați codul licențiat BSD cu 3 clauze în software-ul GPL.

Licența BSD cu 4 clauze (sau Licența BSD originală) adaugă o altă clauză, specificând că toate materialele publicitare care menționează caracteristicile sau utilizarea software-ului trebuie să afișeze o confirmare care să spună că produsul include software dezvoltat de deținătorul drepturilor de autor. Această licență BSD cu 4 clauze nu este compatibilă cu GPL. Codul cu această licență nu poate fi relicențiat în conformitate cu termenii GPL, deoarece a patra clauză adaugă o cerință care nu este necesară în GPL.

GNU Lesser General Public License (LGPL)

LGPL a fost creat de FSF ca o modificare a GPL cu un copyleft mai slab, permițând conectarea software-ului cu licență LGPL cu orice alt software. La origini, LGPL a reprezentat „Licența publică generală a bibliotecii”, dar ulterior și-a luat numele actual „Licență publică generală mai mică” pentru opinia FSF care spune că toate programele ar trebui să fie gratuite și, din această cauză, LGPL nu ar trebui să fie utilizat în general.

Puteți lega codul sursă închisă cu o bibliotecă sau software LGPL și puteți distribui rezultatele finale atâta timp cât:

• Furnizați codul sursă al părții LGPLed, cu toate modificările pe care le-ați făcut.
• Orice utilizator cu cunoștințe suficiente este capabil să înlocuiască partea LGPL a programului cu o versiune modificată. Acest lucru se poate face distribuind partea LGPLed a programului ca o bibliotecă dinamică (DLL în Windows, .so în Linux/Unix) sau oferind codul obiect al părții non-LGPL a programului.

LGPL v3 este compatibil cu GPLv3, așa că puteți introduce codul LGPLv3 în software-ul GPL.

Licență artistică

Licența artistică, în versiunea sa actuală 2.0, este o licență open-source permisivă, fără copyleft, similară cu licența MIT.

Principala diferență dintre licența MIT și Licența artistică este că aceasta din urmă impune ca orice modificare adusă codului să fie precizată în mod clar.

Această licență este folosită aproape exclusiv în comunitatea Perl.

Actuala licență artistică 2.0 este compatibilă cu GPL: puteți combina codul cu licență artistică în software-ul GPL.

Licență publică Microsoft (MS-PL)

Licența publică Microsoft a fost creată în 2008 de această companie ca una dintre licențele open-source create de Shared Source Initiative.

Este o licență copyleft strictă, slabă: permite crearea și distribuirea de programe cu sursă închisă cu cod MS-PLed, dar obligă să folosească MS-PL ca licență pentru lucrări derivate dacă acestea sunt distribuite în cod sursă.

Personal cred că această licență este puțin perversă și contrară spiritului open-source, permițând închiderea codului, astfel încât, într-un fel, deținătorului drepturilor de autor să nu-i pasă de ce poți face tu cu software-ul, dar nu poți. partajați codul pentru a fi amestecat cu alt cod sursă copyleft. Deci, într-un alt fel, deținătorului drepturilor de autor chiar îi pasă de ceea ce poți face și nu vrea să folosești codul din motive precum îmbunătățirea Linux.

MS-PL este incompatibil cu GPL.

Licență publică Eclipse (EPL)

Licența publică Eclipse este licența creată de Fundația Eclipse pentru mediul lor de dezvoltare integrat. Este o licență restrictivă și slab copyleft, similară în multe privințe cu LGPL. De asemenea, include clauze pentru acordarea automată a licenței de brevet.

EPL este incompatibil cu GPL.

Licență publică Mozilla (MPL)

Licența publică Mozilla versiunea 2.0 este o licență permisivă cu copyleft slab creată de Fundația Mozilla pentru produsele sale.

Am putea considera această licență ca fiind similară cu LGPL, dar cu principala diferență că MPL permite, de asemenea, legarea statică a bucăților de cod MPLed în software-ul cu sursă închisă.

MPL, în versiunea sa actuală 2.0, este compatibil cu GPL. Acest lucru nu este valabil pentru versiunile anterioare ale MPL.

Licență comună de dezvoltare și distribuție (CDDL)

CDDL este o licență permisivă cu copyleft slab creată de Sun (acum Oracle) pe baza MPL versiunea 1.1. Practic, are aceleași proprietăți ca MPL. Termenii acestuia au fost clarificați, dar nu au fost modificați substanțial.

CDDL este licența open-source aleasă de Sun (acum Oracle) pentru multe dintre produsele sale, precum OpenSolaris sau NetBeans, printre altele.

Deoarece această licență a fost bazată pe MPLv1.1, această licență nu este compatibilă cu GPL, așa că nu puteți combina sursa cu licență CDDL într-un software cu licență GPL. Mulți oameni spun că acest lucru a fost intenționat, așa că codul sursă OpenSolaris nu poate fi introdus în kernel-ul Linux.

Licență publică generală GNU Affero (AGPL)

AGPL este o versiune a GPL cu copyleft și mai puternic și mai restrictiv. Obliga sa furnizeze codul sursa al aplicatiei nu numai persoanelor care primesc o copie a software-ului, ci si persoanelor care folosesc acest software printr-o retea de calculatoare.

Această licență a fost creată de FSF pentru a oferi dezvoltatorilor mijloacele pentru a evita închiderea practică a software-ului open source atunci când este executat în servere de rețea sau în cloud, deoarece GPL nu poate forța furnizorii de servicii să ofere cod sursă utilizatorilor. . În acest caz, software-ul nu este distribuit.

AGPLv3 este compatibil cu GPL3. Puteți introduce codul AGPLv3 în codul GPLv3, atâta timp cât rezultatul final este licențiat sub AGPLv3.

Licență ISC

Licența ISC este o licență permisivă de software liber scrisă de Internet Software Consortium (ISC). Este echivalent din punct de vedere funcțional cu licențele BSD și MIT cu două clauze, după eliminarea unui limbaj care a fost considerat inutil.

Folosit inițial pentru lansările software proprii ale ISC, de atunci a devenit licența preferată a OpenBSD (începând cu iunie 2003), printre alte proiecte.

Este compatibil cu GPL: puteți combina codul cu licență ISC în software-ul GPL.

Licență reciprocă Microsoft (MS-RL)

Licența reciprocă Microsoft a fost creată în 2008 de această companie ca una dintre licențele open-source create de Shared Source Initiative.

Este similar cu MS-PL explicat mai înainte, dar are copyleft ceva mai puternic, asemănător cu condițiile LGPL, CDDL și EPL. Este necesar ca, dacă amestecați codul cu codul sursă cu licență MS-RL și doriți să distribuiți rezultatele finale, cel puțin partea originală cu licență MS-RL trebuie să fie în continuare licențiată cu această licență.

Nu este compatibil cu GPL.

Domeniu public (CC0)

Potrivit Wikipedia, „operele din domeniul public sunt acelea ale căror drepturi de proprietate intelectuală au expirat, au fost decăzute sau sunt inaplicabile”. Dedicând o lucrare domeniului public, autorul renunță la toate drepturile sale asupra acesteia conform legii dreptului de autor.

Există mai multe proiecte software în Public Domain, de exemplu SQLite, biblioteca care implementează un motor de baze de date SQL încorporabil și simplu, care este inclus în mai multe alte proiecte, cum ar fi proiecte Mozilla, Android etc.

Există multe modalități de a dedica o bucată de software domeniului public. Creative Commons a creat CC0 Public Domain Dedication, o modalitate universală de a oferi o lucrare în domeniul public. FSF recomandă utilizarea acestui text pentru dedicarea software-ului domeniului public.

Lucrările aflate în domeniul public sunt compatibile cu orice licență cu sursă deschisă sau închisă și pot fi combinate cu orice alt software.

Licențiere multiplă

Există unele software open-source care au licență dublă sau chiar triplă. Aceasta înseamnă că o persoană care primește acest software cu licențe multiple poate alege sub ce licență dorește să-l distribuie. Deoarece fiecare licență acordă permisiuni diferite și impune obligații diferite, trebuie făcută o selecție pentru alegerea licenței care răspunde cel mai bine nevoilor.

Acesta este un caz obișnuit pentru unele biblioteci. De exemplu, NSS este o bibliotecă creată de Mozilla care implementează suport SSL/TLS, printre alte caracteristici legate de securitate. Este triplu licență sub licențe MPL, GPL și LGPL.

Vă rugăm, alegeți o licență

Mulți oameni publică cod pe platforme ca GitHub fără nicio licență scrisă. Nimeni nu ar trebui să folosească acel cod. Nu avem nicio idee ce permisiuni avem pentru a-l folosi. Dacă îl folosești, poți fi dat în judecată pentru asta. E ca și cum acești oameni ne tachinau spunând „Hei, uite ce am făcut! Cool, nu-i așa? Dar nu o poți folosi, am vrut doar să îți arăt!”.

Te rog nu fi unul dintre ei. Dacă încărcați codul pe GitHub sau pe site-uri publice similare, permiteți altora să-l folosească și să-l îmbunătățească. Dacă nu vrei să te gândești mult, iată recomandările mele:

• Dacă doriți să rămâneți simplu și permisiv, permițând fiecăruia să facă ceea ce vrea cu codul dvs., atâta timp cât vă oferă atribuirea înapoi și nu vă trag la răspundere, utilizați Licența MIT.
• Dacă doriți să păstrați permisivitatea, permițând fiecăruia să facă ceea ce vrea cu codul dvs., dar enumerarea cu înțelepciune a drepturilor conform legii dreptului de autor și acordarea acestor drepturi, împreună cu acordarea explicită a drepturilor de brevet de la colaboratori către utilizatori, utilizați Licența Apache 2.0 .

• Dacă vă pasă de partajarea modificărilor și nu doriți ca codul dvs. să fie utilizat în dezvoltări închise (nici în produse software închise, nici în dispozitive hardware închise), utilizați GPL v3.

  • Dacă nu vă pasă de posibilitatea ca software-ul dvs. să fie folosit într-un aparat închis, utilizați GPL v2. Dar vă rugăm să folosiți propoziția „sau orice versiune ulterioară”, astfel încât codul dvs. să poată fi folosit și în proiecte GPLv3.
  • Dacă nu vă pasă de posibilitatea ca software-ul dvs. să fie folosit în software închis, atâta timp cât software-ul dvs. sau partea care îl folosește continuă să fie open-source în aceleași condiții, utilizați LGPL v3.
  • Dacă doriți ca toți cei care vă folosesc software-ul printr-o rețea să aibă dreptul de a obține codul sursă, utilizați AGPL v3.

După toate acestea, s-ar putea să fii epuizat de toate aceste prostii aproape-legale. Dar știi ce? Este nevoie. Pentru că fără licență, nu aveți drepturi de utilizare sau distribuire a vreunui cod.