Tipuri de licențe Open Source. Diferența dintre diferitele tipuri de licențe open source
- Traducere
171 de cuvinte pe care orice programator ar trebui să le înțeleagă
Licența MIT este cea mai populară licență pentru software-ul open source. Iată una dintre lecturile ei, cu o analiză rând cu rând.Citirea licenței
Dacă sunteți un dezvoltator open source și nu ați citit această licență în detaliu - și are doar 171 de cuvinte - ar trebui. Mai ales dacă nu te ocupi zilnic de licențe. Marcați orice nu înțelegeți. Și voi repeta toate aceste cuvinte, în ordine și pe bucăți, alături de context și comentarii. În același timp, este important să ne imaginăm ca un întreg.Licența MIT (MIT)„Anul” „deținătorii drepturilor de autor”
Prin prezenta se acordă permisiunea, în mod gratuit, oricărei persoane care obține o copie a acestui software și a fișierelor de documentație asociate („Software-ul”), de a utiliza Software-ul fără restricții, inclusiv, fără limitare, drepturile de utilizare, copiere, modificare, îmbinare , să publice, să distribuie, să sublicențeze și/sau să vândă copii ale Software-ului și să permită persoanelor cărora le este furnizat Software-ul să facă acest lucru, sub rezerva următoarelor condiții:
Nota privind drepturile de autor de mai sus și această notificare de permisiune vor fi incluse în toate copiile sau părțile substanțiale ale Software-ului.
SOFTWARE-UL ESTE OFERIT „CA AȘA E”, FĂRĂ NICIUN FEL DE GARANȚIE, EXPRESĂ SAU IMPLICITĂ, INCLUSIV, DAR FĂRĂ A SE LIMITA LA GARANȚII DE VANTABILITATE, ADEPRENARE PENTRU UN ANUMIT SCOP ȘI NEÎNCĂLCARE. AUTORII SAU DEȚINĂTORII DE DREPTURI DE AUTOR NU VA FI RĂSPUNDĂTORI ÎN NICIO CAZ PENTRU ORICE RECLAMAȚIE, DAUNE SAU ALTĂ RESPONSABILITATE, CHIAR DIN O ACȚIUNE DE CONTRACT, DELICIT SAU ÎN ALTRE MOD, DERIVATE DIN, DIN SAU ÎN LEGĂTARE CU SOFTWARE-UL SAU ALTELE UTILIZARE SOFTWARE.
Licență MITDrepturi de autor „an” „proprietari de drepturi”
Această licență permite persoanelor care obțin o copie a software-ului și a documentației însoțitoare (denumite în continuare „Software”) să utilizeze Software-ul fără limitare, fără limitare, inclusiv dreptul nerestricționat de a utiliza, copia, modifica, îmbina, publica, distribui , sublicență și/sau vânzarea de copii ale Software-ului, precum și persoanelor cărora le este furnizat acest Software, sub rezerva următoarelor condiții:
SOFTWARE-UL ESTE OFERIT „CA AȘA ESTE”, FĂRĂ NICIUN FEL DE GARANȚIE, EXPLICITĂ SAU IMPLICITĂ, INCLUSIV, DAR FĂRĂ A SE LIMITA LA GARANȚII DE VANTABILITATE, ADECVENȚĂ PENTRU UN ANUMIT SCOP ȘI NEÎNCĂLCARE. AUTORII SAU DEȚINĂTORII DE DREPTURI DE AUTOR NU VA FI RĂSPUNDĂTORI ÎN NICIO CAZ PENTRU ORICE RECLAȚIUNE, DAUNE SAU ALTĂ RECLAȚIUNE, INCLUSIV CU CONTRACTUL, DELICIT SAU ALTRE, DERIVĂ DIN UTILIZAREA SOFTWARE-ULUI SAU A ALTE ACȚIUNI CU SOFTWARE.
Licența este împărțită în cinci paragrafe, dar este împărțită logic după cum urmează:
- Titlu
- Nume
- Drepturi de autor
- Permisiune
- Domeniul de aplicare
- Condiții
- Transferul licenței
- Declinarea garanțiilor
- Disclaimer
Titlu
Nume
„Licența MIT” nu este o singură licență, ci o familie de forme de licență influențate de stilul adoptat în produsele produse de Massachusetts Institute of Technology. S-a schimbat frecvent de-a lungul anilor, atât pentru proiectele care l-au folosit inițial, cât și ca model pentru alte proiecte. Proiectul Fedora menține o arhivă variante interesante licențe, cu opțiunile de licență stocate în text simplu, parcă minuni anatomice în formaldehidă, demonstrând cursul evoluției.
Din fericire, inițiativa open source Sursa deschisa Initiative și grupul Software Package Data eXchange au standardizat forma generală a licenței MIT și au numit-o „Licența MIT”. OSI a adoptat identificatori de șir pentru licențele comune sursa deschisa de la SPDX, iar abrevierea MIT implică în mod clar „licență MIT”. Dacă trebuie să vă distribuiți produsul conform condițiilor MIT, utilizați formularul standard de licență MIT.
Dar chiar dacă includeți liniile „Licența MIT” sau „SPDX:MIT” în fișierul LICENȚĂ, un cititor responsabil vă va verifica textul cu formularul standard, doar pentru a fi sigur. Multe forme diferite de licențe se numesc „Licența MIT”, dar diferă în detalii și, din cauza conceptului prea vag al „Licenței MIT”, mulți autori au fost tentați să adauge propria întorsătură textului. Exemplul canonic al unei schimbări atât de proaste, teribile și dezgustătoare este licența JSON, care adaugă „Programul trebuie folosit în scopuri bune, nu în scopuri rele” la licența MIT. Acest truc este foarte în spiritul lui Crockford. Dureri de cap îngrozitoare. Poate este o batjocură a avocaților. Au râs până la bancă.
Morala este: simpla scriere a „licenței MIT” este ambiguă. Oamenii vor înțelege, în general, la ce ați vrut să spuneți, dar veți economisi timp pentru toată lumea și pentru dvs., prin copierea textului licenței standard MIT în proiectul dvs.
Drepturi de autor
Drepturi de autor<год> <владельцы прав>
Înainte de a fi adoptată Legea privind drepturile de autor din 1976 în Statele Unite, erau necesari pași speciali, „cerințe formale”, pentru a asigura supraviețuirea unui drept de autor. Și dacă nu le-ai urmat, e dreptul tău să dai în judecată utilizare ilegală munca ta a fost limitată și uneori a dispărut cu totul. Una dintre cerințele formale a fost așa-numita. „notificare”: marcarea lucrării dvs. și alte acțiuni necesare pentru a notifica piața cu privire la o revendicare a drepturilor. Pictograma este simbolul standard pentru aceasta. ASCII nu avea o astfel de pictogramă, așa că o combinație a fost folosită în același scop.
Legea drepturilor de autor din 1976 a eliminat necesitatea formalităților. În SUA, deținătorii de drepturi sunt încă obligați să-și înregistreze lucrările înainte de procedurile judiciare, dar în practică acest lucru se face direct în fața instanței. Nu veți pierde dreptul de autor dacă pur și simplu ați uitat să îl declarați, să îl înregistrați, să trimiteți o copie la Biblioteca Congresului etc.
Dar chiar dacă aceste afirmații nu mai sunt necesare, ele sunt totuși destul de utile. Indicând anul în care a fost realizată o anumită lucrare și drepturile asupra acesteia, puteți clarifica imediat când aceste drepturi expiră și opera devine domeniul public. Identitățile autorilor sunt, de asemenea, utile - în SUA, legile tratează diferit autorii individuali și grupurile de autori. În afaceri, o companie se va gândi de două ori înainte de a utiliza software de la rivalul său, chiar dacă licența o permite. Dacă sperați că alții vă vor observa munca și doresc să o licențieze de la dvs., informațiile despre deținătorul drepturilor de autor vor fi, de asemenea, utile.
Nu există un loc pentru proprietarul drepturilor de autor în toate licențele. Licențe mai moderne, precum Apache 2.0 și GPL 3.0, publică texte de LICENȚĂ care trebuie copiate textual, iar apoi proprietarii lucrării trebuie indicați în comentarii și fișiere separate. Această abordare elimină modificările aduse textelor de licență și simplifică procesarea automată a acestora.
Licența MIT provine din lansări de cod efectuate de diverse instituții. Pentru astfel de eliberări, proprietarul drepturilor era doar institutul care eliberează codul. Alte instituții au adoptat aceste licențe, înlocuind MIT cu nume proprii, ceea ce a dus la existența licențelor generice. Alte licențe au trecut prin acest proces, cum ar fi Licența BSD de la Universitatea din California, care a fost inițial o licență cu patru clauze și este utilizată acum în variante cu trei și două clauze și Licența ISC pentru Consorțiul de Sisteme de Internet, un variantă a licenței MIT.
În fiecare caz, organizația s-a identificat drept proprietarul drepturilor și a profitat de capacitățile „muncă pentru închiriere”, ceea ce i-a permis să-și păstreze drepturile asupra muncii prestate de angajați și contractori. Aceste reguli, în general, nu se aplică muncii pe care angajații și antreprenorii le execută din proprie inițiativă. De asemenea, nu se aplică grupurilor distribuite de oameni care lucrează împreună și care își oferă voluntar codul. Pentru fundațiile care rulează proiecte precum Apache Foundation și Eclipse Foundation care acceptă cod de la diverse surse, asta ridică o problemă. Fondurile s-au ocupat de obicei de acest lucru folosind o licență de casă care pretinde un singur deținător de drepturi - Apache CLA și Eclipse CLA - pentru a obține drepturi de la finanțatori. Colectarea drepturilor într-un singur loc este și mai importantă pentru toate tipurile de licențe „copyleft”, cum ar fi GPL, care transferă responsabilitatea diseminării valorilor software-ului liber către proprietarii drepturilor de autor.
Astăzi, multe proiecte, chiar și cele care nu gestionează mai mulți furnizori de coduri, folosesc licențe MIT. SPDX și OSI au contribuit la aceasta prin standardizarea formularelor de licență care nu se refereau la o anumită persoană sau un grup de persoane cu drepturi. Ca urmare, majoritatea autorilor pur și simplu își scriu numele în anunțul de copyright și, uneori, includ și anul.
Proprietarul inițial al codului își păstrează drepturile asupra lucrării sale. Dar, în timp ce licențele asemănătoare MIT oferă altora drepturile de a construi și de a schimba software-ul, creând ceea ce se numește „operă derivată”, ele nu oferă autorului original capacitatea de a deține ceea ce au creat alți oameni. Toți cei care au contribuit își păstrează drepturile asupra părții sale din munca desfășurată în baza codului existent.
Majoritatea proiectelor nu se deranjează să-i convingă pe participanți să fie de acord cu licența, cu atât mai puțin să semneze documente privind distribuirea drepturilor. Acest lucru este naiv, dar de înțeles. În ciuda presupunerii dezvoltatorilor că, trimițând cereri de extragere către GitHub, primesc automat anumite drepturi de a distribui proiectul conform scrisorii de licență, nu există astfel de reguli în Statele Unite. Valoarea implicită este protecția drepturilor de autor, mai degrabă decât permisiunile de transfer de licență.
Pentru a reduce decalajul dintre transferurile de drepturi legalizate și documentate și absența oricărei documente, unele proiecte acceptă Certificatul de origine al dezvoltatorului, o declarație standard la care dezvoltatorii se referă folosind metaetichete Signed-Off-By. DCO a fost conceput pentru a dezvolta un nucleu Linux care a evoluat din nucleul Unix al SCO. DCO face o treabă bună documentând procesul prin care fiecare linie de Linux a apărut prin intermediul oamenilor care au contribuit la ea. Și, deși nu este o licență, oferă o mulțime de dovezi bune că acele care și-au trimis codul la proiect intenționau ca acesta să fie distribuit împreună cu proiectul și ca utilizatorii să-l folosească sub licența existentă a nucleului. Nucleul menține, de asemenea, un fișier CREDITS care poate fi citit de om, care listează toate persoanele care au contribuit, cu nume, apartenența, zona de contribuție și alte date.
Permisiune
Această licență permite persoanelor care obțin o copie a acestui software și a documentației însoțitoare (denumite în continuare „Software”) să
Ideea licenței MIT este că este, după cum probabil ați ghicit, o licență. În general, o licență este o permisiune pe care o persoană sau entitate– licențiatorul – permite altuia – titularul licenței – să facă ceva care altfel ar putea fi contestat în instanță. Licența MIT este o promisiune de a nu da în judecată.
Uneori legea separă o licență și o promisiune în transferul unei licențe. Dacă cineva își încalcă promisiunea de a vă acorda o licență, îl puteți da în judecată pentru că și-a încălcat promisiunea, dar este posibil să nu obțineți niciodată licența. În această propoziție [ V versiune în limba englezăîn acest scop se folosește arhaismul „prin prezenta” - cca. traducere] clarifică faptul că textul acestei licențe în sine vă oferă deja o licență, și nu doar o promisiune de a o transfera.
Și, în timp ce multe licențe dau permisiunea pentru o anumită licență numită, licența MIT este o „licență publică”. Licențele publice dau permisiunea tuturor, de ex. – către societate. Aceasta este una dintre cele trei idei grozave din spatele licențelor open source. Licența MIT profită de această idee oferind o licență tuturor „persoanelor care obțin o copie a software-ului”.
Identificarea unui concept între paranteze și ghilimele („Definiție”) este o modalitate standard de definire a termenilor o anumită valoareîn actele legale. Părțile vor putea folosi acești termeni în procedurile judiciare.
Domeniul de aplicare
utilizați software-ul gratuit, fără restricții,
Aceste cuvinte, din punctul de vedere al licențiatului, sunt cele mai importante dintre toate cuvintele din licența MIT. Principalele probleme asociate cu drepturile sunt posibilitatea de a fi urmărit penal pentru încălcarea dreptului de autor și încălcarea brevetului. Niciunul dintre aceste domenii de drept nu folosește cuvintele „utilizare gratuită”. Ca urmare, instanța se va întreba în mod necesar ce se înțelege prin această definiție. Instanța va constata că această descriere este în mod deliberat prea largă și nelimitată. Acesta permite titularului de licență să reziste oricărei pretenții din partea licențiatorului că nu a dat permisiunea pentru o anumită utilizare a software-ului.
inclusiv dreptul nerestricționat de a utiliza, copia, modifica, îmbina, publica, distribui, sublicență și/sau vinde copii ale Software-ului, precum și persoanelor cărora le este furnizat Software-ul,
Nu există texte legale perfecte care să fie complet lipsite de ambiguitate sau complet de înțeles. Nu crede dacă cineva îți spune altfel. Această parte a licenței este cea mai puțin avansată.
În primul rând, „inclusiv dreptul nelimitat” este un exemplu despre cum să nu scrieți texte legale. Există variații ale acestei formulări:
- inclusiv, fără limitare;
- inclusiv, fără limitare, generalizări ale celor de mai sus;
- incluzand dar fara a se limita la;
Toate sunt scrise cu un singur scop și niciunul dintre ele nu-l atinge. Avocații care le folosesc vor să mănânce peștele și să nu eșueze. În licența MIT, ele înseamnă o încercare de a furniza anumite exemple de „utilizare a software-ului” – „utilizare, copiere, modificare” etc. – fără a implica faptul că software-ul poate fi utilizat doar într-unul dintre modurile enumerate. Problema este că dacă o astfel de licență este prezentată în instanță, atunci instanța va trebui să stabilească sensul acestor termeni pentru a înțelege licența. Dacă instanța dorește să înțeleagă ce înseamnă „utilizarea software-ului”, nu va putea „nevedea” exemplele de utilizare specificate în licență. Aș spune că cel mai bine este să scrieți în licență „pentru a utiliza software-ul fără restricții”. De asemenea, este mai scurt.
În al doilea rând, termenii enumerați sunt un amestec. Unele dintre acestea sunt acoperite de legile privind drepturile de autor și brevetele, iar altele nu.
- utilizare găsit în Codul Statelor Unite ale Americii, articolul 35, paragraful 271 (a) în lista lucrurilor pentru care acesta din urmă poate da în judecată fără permisiunea titularului brevetului
- copie aflat în Cod, articolul 17, paragraful 106, în lista legii dreptului de autor
- schimba, publica, îmbina nu apare nici în legea dreptului de autor sau a brevetelor.
- distribui găsite în legea dreptului de autor.
- sublicenţă- Acest termen general legea asupra proprietate intelectuală. Înseamnă dreptul altora de a-și da propriile licențe pentru parțial sau lista plina ceea ce le permiți să facă. Această clauză este neobișnuită pentru licențele deschise. Abordarea normală este directă, atunci când toți cei care primesc o copie a software-ului primesc și o licență direct de la proprietar.
- vinde- cuvântul este hibrid. Este similar cu vânzările menționate în legea brevetelor, dar se referă la vânzarea de copii, ca în legea dreptului de autor. În termeni de drept de autor este mai aproape de „distribuție”, dar legea drepturilor de autor nu menționează vânzări.
- precum și persoanele cărora le este furnizat acest Software– această frază pare o repetare inutilă a „sublicențelor”. De asemenea, nu este necesar în măsura în care persoanele care primesc copii ale software-ului primesc imediat o licență.
Trei condiții de licență
sub rezerva următoarelor condiții
Există întotdeauna o captură - și MIT are chiar trei dintre ele!
Dacă nu respectați condițiile, nu veți primi permisiunea. Prin urmare, teoretic, în acest caz ai putea fi dat în judecată, cel mai probabil în temeiul legii dreptului de autor.
Utilizarea valorii software-ului pentru a motiva licențiatul să se conformeze, chiar dacă nu a plătit pentru licență, este a doua mare idee a software-ului open source. Acesta din urmă, care nu a fost inclus în licența MIT, se bazează pe condiții de licență - licențe precum Licența publică GNU utilizează condiții pentru a controla modul în care cei care schimbă pot licenția și distribui versiunile modificate.
Transferul licenței
Nota privind drepturile de autor de mai sus și acești termeni și condiții trebuie să fie incluse în toate copiile sau părțile semnificative ale Software-ului.
Dacă oferiți cuiva o copie a software-ului, trebuie să includeți textul licenței în acesta și puteți adăuga orice notificări privind drepturile de autor. Acest lucru servește mai multor scopuri:
- Spune altora că au permisiuni pentru software-ul cu licență publică. Acest caracteristica cheie modele licențiate direct, în care fiecare utilizator primește o licență direct de la deținătorul drepturilor.
- Oferă o idee despre autorul software-ului, astfel încât să fie clar cine trebuie să fie umplut cu complimente, faimă și donații.
- Oferă declinarea garanțiilor și limitarea răspunderii.
Aceste condiții, din păcate, sunt prost îndeplinite. Aproape fiecare licență open source are astfel de termeni. Creatorii de software de sistem și instalabil realizează adesea că trebuie să afișeze un fișier cu informații despre licență pe ecran și să includă copii ale licenței în biblioteci și componente. Fondurile care gestionează proiecte învață aceste practici. Dar dezvoltatorii web se pare că nu au fost anunțați. Nu există iertare pentru ei.
Declinarea garanțiilor
SOFTWARE-UL ESTE OFERIT „CA AȘA ESTE”, FĂRĂ NICIUN FEL DE GARANȚIE, EXPLICITĂ SAU IMPLICITĂ, INCLUSIV, DAR FĂRĂ A SE LIMITA LA GARANȚII DE VANTABILITATE, ADECVENȚĂ PENTRU UN ANUMIT SCOP ȘI NEÎNCĂLCARE.
Aproape toate statele din SUA sunt obligate prin lege să respecte o versiune a Codului Comercial Uniform, un set de legi care reglementează tranzacțiile comerciale. Articolul 2 din CDU se referă la contractele de vânzare de mărfuri, de la mașini uzate achiziționate la licitație până la furnizarea de produse chimice industriale către fabrici.
Anumite reguli UCC sunt obligatorii și se aplică întotdeauna. Alții descriu doar starea „implicit” - cu excepția cazului în care vânzătorii și cumpărătorii scriu ceva diferit în acord. Printre aceste reguli „implicite” se numără garanțiile, adică promisiunile de la vânzători către cumpărători cu privire la calitatea și potrivirea de utilizare a produselor.
Există o dezbatere despre dacă licențele publice precum MIT sunt contracte - acorduri la care licențiații și licențiatorii pot fi forțați - sau pur și simplu licențe care pot avea condiții atașate. Există puțin mai puțină dezbatere despre dacă software-ul este un produs și, prin urmare, este supus jurisdicției UCC. Însă licențiatorii nu au nicio dispută cu privire la răspundere: nimeni nu dorește să fie dat în judecată dacă software-ul pe care îl distribuie se întrerupe, provoacă probleme, nu funcționează sau se manifestă în alt mod negativ. Acesta este exact opusul a ceea ce descriu cele trei reguli implicite de garanție:
- Valabilitatea comercială, conform secțiunii 2-314, este o promisiune că produsul - software-ul - va fi de o calitate cel puțin medie, ambalat și etichetat corespunzător și potrivit scopului. utilizare normală. Această regulă se aplică doar dealerilor de software – adică celor care le vând și care se consideră a fi specialiști în acest domeniu.
- Adecvarea pentru un anumit scop, în conformitate cu secțiunea 2-315, se aplică atunci când vânzătorul știe că cumpărătorul se așteaptă ca bunurile să fie potrivite pentru un anumit scop.
- Fără impediment de brevet – Nu este inclus în UCC, dar este folosit în mod obișnuit în legile contractelor. Protejează cumpărătorul în cazul în care se constată că produsul achiziționat încalcă drepturile intelectuale ale altcuiva.
Avocații s-au înșelat de mult că prin scrierea textului cu MAJUSCULE, îndeplinesc cerința de vizibilitate. Este gresit. Literele mari deseori împing cititorul departe în loc să le atragă atenția. Dar majoritatea licențelor open source pun această parte cu majuscule, deoarece este cea mai evidentă modalitate de a scoate în evidență textul din fișierele text simplu. Aș fi preferat să folosesc asteriscuri sau altă artă ASCII, dar acel tren a plecat deja.
Disclaimer
AUTORII SAU DEȚINĂTORII DE DREPTURI DE AUTOR NU VA FI RĂSPUNDĂTORI ÎN NICIO CAZ PENTRU ORICE RECLAȚIUNE, DAUNE SAU ALTĂ RECLAȚIUNE, INCLUSIV CU CONTRACTUL, DELICIT SAU ALTRE, DERIVĂ DIN UTILIZAREA SOFTWARE-ULUI SAU A ALTE ACȚIUNI CU SOFTWARE.
Licența MIT oferă software gratuit, dar legea nu presupune că cei care primesc licență gratuită oamenii își pierd dreptul la un proces dacă ceva nu merge bine și licențiatorul este găsit vinovat. Limitările de răspundere, cum ar fi licențele, servesc, de asemenea, drept promisiuni de a nu merge în instanță - doar în acest caz protejează licențiatorii de licențiați.
În mod obișnuit, instanțele vor citi cu atenție clauzele de declinare a garanțiilor, deoarece pot ajuta la transferarea riscului de la o parte la alta. Pentru a oferi oamenilor posibilitatea de a se apăra în orice cazuri posibile instanțele interpretează aceste renunțări împotriva persoanei pe care o protejează. Adesea, instanțele refuză să le ia în considerare dacă astfel de condiții sunt situate undeva adânc în contract și nu sunt evidențiate. Prin urmare, avocații sunt obișnuiți să le scrie cu majuscule.
Limitarea răspunderii, printre altele, limitează și suma de bani pentru care licențiatul poate fi dat în judecată. Pentru licențele deschise, această limită este întotdeauna zero. Licențele comerciale includ adesea sume care sunt multipli ale taxelor de licență plătite în ultimele 12 luni.
Această secțiune enumeră acele tipuri de activități legale pe care licențiatorul nu le poate folosi. La fel ca multe forme juridice, această licență menționează încălcări ale contractului și delicte. Regulile delictuale se referă la săvârșirea de fapte care dau naștere la despăgubiri. Dacă dai peste cineva pe drum în timp ce trimiți mesaje, ai comis un delict. Dacă compania dvs. a vândut căști defecte care au ars urechile oamenilor, a comis un delict. Dacă contractul nu exclude în mod explicit pretențiile delictuale, instanțele vor profita uneori de aceasta. Licența MIT prevede „prin alte cerințe” pentru a exclude orice cerințe exotice.
Expresia " DERIVATE DIN UTILIZAREA SOFTWARE-ULUI SAU A ALTE ACȚIUNI CU SOFTWARE-UL" este un tic nervos caracteristic fricii dobândite a avocatului pentru siguranța lui. Ideea este că orice reclamație legată de acest software este acoperită de limitări și excepții. Cu toate acestea, utilizarea software-ului este complet inclusă în „alte acțiuni” cu software-ul . [ licența originală specifică trei opțiuni pentru evenimente „care decurg din”, „în legătură cu”, „utilizare” - adică „decurg din”, „în legătură cu” și „când se utilizează”, care, de fapt, se dublează reciproc , care provoacă plângeri din partea autorului articolului - cca. traducere] Cu toate acestea, un astfel de limbaj este folosit în milioane de alte licențe.
Concluzie
Dar toate aceste afirmații nu sunt prea mari. Licența MIT este un clasic legal. Ea lucrează. Nu este un panaceu pentru toate bolile software, în special pentru litigiile privind brevetele. Dar astfel de licențe au servit bine și servesc unui scop specific - eliminarea regulilor implicite incomode în drepturile de autor, vânzări și contracte - cu set minim instrumente juridice. In contextul subiecte informatice vitalitatea ei este uimitoare. A supraviețuit și va supraviețui majorității software-ului care a fost licențiat în baza acestuia. Se poate doar ghici câte decenii va continua să funcționeze. Acest lucru este benefic în special pentru cei care nu își permit să angajeze avocați.Am văzut că licența MIT este un set de definiții definite și standardizate care aduce ordine în haosul variațiilor aleatorii ale licențelor adoptate de diferite organizații.
Am văzut cum abordarea ei asupra problemelor de atribuire și de drepturi de autor influențează practica managementului drepturilor de proprietate în organizațiile academice și comerciale.
deschis prin Adăugați etichete
1) Licență MIT
Licența MIT a fost dezvoltată de Massachusetts Institute of Technology (MIT) și este considerată o licență academică, ceea ce înseamnă că este acceptată pentru uz științific. Pe site-ul GNU se numește licență Expat. În plus, sistemul XFree86 este distribuit și sub licența MIT, doar că în acest caz a fost numit Licența X11 pe site-ul GNU.
2) Licență BSD
Licența BSD a apărut la începutul anilor 1980 special pentru distribuție sistem de operare BSD. Există trei versiuni ale textului acestei licențe:
1. Licență BSD originală sau licență BSD cu patru clauze.
2. Licență BSD modificată („Licență BSD nouă” pe site-ul OSI) sau licență BSD cu trei clauze.
3. Intel Corporation „BSD+Patent License” – conceput special pentru modificarea și distribuirea de programe care pot fi protejate de brevetele de software Intel. Această licență nu este aprobată de Open Source Initiative sau de FSF.
Prima licență BSD a constat din 4 clauze:
1. Redistribuirea codului sursă trebuie să păstreze notificarea de mai sus privind drepturile de autor, această listă de condiții și următoarea declinare a răspunderii.
2. Când este redistribuit cod binar Notificarea de mai sus privind drepturile de autor, această listă de condiții și următoarea declinare a răspunderii trebuie reproduse în documentația și/sau în alte materiale furnizate odată cu distribuția.
3. Toate materialele publicitare care menționează caracteristicile sau utilizarea acestui program trebuie să includă următoarea notificare: „Acest produs include software dezvoltat de Universitatea din California, Berkeley și donatorii săi”.
4. Nici numele Universității și nici numele angajaților acesteia nu pot fi folosite ca susținere sau promovare a produselor bazate pe acest software fără permisiunea prealabilă scrisă.
Dar în 1999, din cauza cererii populare, a treia clauză a fost eliminată ca „convenție de publicitate BSD enervantă”, deoarece sisteme complexe, folosind codul multor programe, uneori trebuia să deruleze până la o duzină de pagini de publicitate. Rezultatul a fost licența BSD cu trei clauze modificată, care este acum licența principală.
În plus, site-ul web GNU oferă o altă licență cu două clauze, „Licența FreeBSD”, care constă numai din primele două clauze ale licenței BSD. Același site GNU recomandă să nu denumească această licență „licență BSD” pentru a evita provocarea confuziei.
3) Licență GPL
Licență publică generală GNU Licență GNU sau GNU Open License Agreement) este cea mai populară licență de software gratuit creată de Proiectul GNU. Prima versiune a GPL a fost lansată în 1988, dar a fost revizuită ulterior și versiunea 2 a GPL a fost lansată în iunie 1991, care este încă standardul. GPL oferă destinatari programe de calculator următoarele drepturi sau „libertăți”:
- libertatea de a rula programul în orice scop;
- libertatea de a studia modul de funcționare a programului și de a-l modifica (o condiție prealabilă pentru aceasta este accesul la codul sursă);
- libertatea de a distribui copii;
- libertatea de a îmbunătăți programul și de a lansa îmbunătățiri în acces public(o condiție prealabilă pentru aceasta este accesul la codul sursă).
Pe 16 ianuarie 2006, prima schiță a licenței a fost prezentată la prima conferință internațională GPL 3, desfășurată la MIT. Desigur, GPL 3 s-a dovedit a fi mai lung și mai complex decât GPL 2.
Aproape imediat după asta Linus Torvaldsși-a exprimat dezamăgirea față de licența GPLv3, spunând că nu a văzut nicio modificare fundamentală în aceasta care ar putea determina o actualizare a licenței Nucleul Linux. GPLv3 s-a opus și de Andrew Morton, unul dintre principalii dezvoltatori ai sistemului de operare. sisteme Linux, David Woodhouse, Dave Jones și o serie de alți experți. În opinia lor, versiunea prezentată de GPLv3 avea nevoie de îmbunătățiri serioase.
Al doilea proiect a apărut pe 27 iulie, după ce au avut loc conferințe internaționale în Statele Unite, Brazilia și Spania, iar peste o mie de propuneri au fost transmise sistemului de comentarii FSF. Drept urmare, au fost făcute destul de multe corecții, dar acestea se referă în principal la nuanțe și probleme minore.
Iată câteva dintre inovațiile pe care le aduce GPLv3:
- Prima versiune a GPLv3 a interzis complet utilizarea controalelor drepturi digitale(Digital Restriction Management, DRM), de exemplu, a spus următoarele: „DRM este în mod fundamental incompatibil cu intenția GPL și limitează sever libertatea utilizatorilor; prin urmare, GPL asigură că software-ul lansat sub această licență nu va fi niciodată supus restricțiilor digitale și nu va face niciodată același lucru cu alt software sau conținut digital.” Cu toate acestea, în cea de-a doua versiune a licenței, formularea a devenit mai neutră, iar termenul DRM în sine nici măcar nu a fost menționat în text.
- Acum este posibilă extinderea licenței cu unele cerințe suplimentare (de exemplu, cerința de a indica dreptul de autor al produsului original în toate cele modificate). Astfel de completări ar trebui să ajute în chestiuni de compatibilitate a GPL cu alte licențe gratuite.
- Utilizarea brevetelor este reglementată. După cum se precizează în proiectul GPLv3: „...fiecare program este amenințat în mod constant de brevetele de software. Dorim să reducem pericolul cu care se confruntă software-ul liber atunci când redistribuitorii ocolesc în mod individual aceleași brevete, făcând astfel software-ul proprietar. Pentru a opri aceste acțiuni, The GPL reduce acest pericol, stipulând că orice brevet trebuie să fie liber de utilizat pentru toată lumea sau să nu fie licențiat nimănui.”
- S-a adăugat o clauză care permite distribuirea unui program GPL prin rețele peer-to-peer, precum BitTorrent, fără a accepta o licență și, în consecință, fără a furniza codul sursă al software-ului.
4) Licență LGPL
Licența GNU Lesser General Public License (GNU LGPL pe scurt) a fost creată special pentru a permite bibliotecilor să fie conectate cu programe distribuite sub alte licențe. Licența publică generală a bibliotecii GNU a apărut în același timp cu licența GPL 2, așa că a primit și versiunea numărul 2, pentru a indica faptul că cele două licențe sunt complementare. Numerele versiunilor s-au diferențiat în 1999, când a fost lansată versiunea LGPL 2.1, care a fost redenumită Licență publică generală mai mică pentru a clarifica locația sa în filozofia GNU.
Este de remarcat faptul că, odată cu cea de-a doua versiune a GPL 3, a apărut prima versiune a LGPL 3, dezvoltată ca caz special GPL 3 prin aplicarea secțiunii Termeni suplimentari.
5) Licență de viclenie
Constă din GNU GPL cu adăugarea unei clauze speciale care oferă drepturi de conectare nerestricționate cu software non-liber. Ca urmare, nu este strict copyleft, dar este compatibil cu GNU GPL.
6) Licență Apache
O licență non-copyleft sub care este distribuit binecunoscutul server Apache. Vă permite să modificați și să distribuiți programe atât în formă open source, cât și în formă binară. Pe lângă drepturile asupra produsului software în sine (de utilizare, modificare, distribuire), licența necesită transferul brevetelor însoțitoare. O contramăsură este prevăzută în cazul unor pretenții legale împotriva dezvoltatorului de software distribuit sub licența Apache - în acest caz, persoana care face astfel de revendicări pierde automat drepturile ce i-au fost atribuite în legătură cu programul sau brevetele aferente.
7) Licență publică comună (CPL)
IBM a formulat această licență pentru a-și distribui produsele.
Particularitatea acestei licențe este că permite dezvoltatorilor să schimbe codul sursă și să-l folosească produse comerciale. Chiar și Microsoft și-a lansat produsul sub această licență - Windows Installer XML.
8) Licență Mozilla (Licență publică Mozilla, MPL)
O licență greoaie care nu implementează copylefting strict. Are unele restricții complexe care îl fac incompatibil cu GNU GPL. De exemplu, un modul care face obiectul GPL nu poate fi legat în mod legal cu un modul care face obiectul MPL.
9) Licență SPL
Licența publică Sun (SPL) este echivalentă cu MPL cu modificări foarte minore, cum ar fi schimbarea numelui companiei din Netscape în Sun Microsystems. Puteți vedea diferențele exacte dintre MPL și SPL în două forme: pentru hackeri (www.netbeans.org/about/legal/mpl-spl-hdiff.html).
Lasă comentariul tău!
Subiectul licențelor gratuite, deschise și, la prima vedere, neobișnuite, a căpătat un nou sens. Pentru a înțelege ce s-a schimbat în reglementare, trebuie mai întâi să determinați care sunt diferitele licențe: shrink-wrap, click-wrap, browse-wrap, licențe gratuite și open-source, precum și noi tipuri de licențe, în sensul că acestea va fi consacrat în partea a patra a Codului civil Federația Rusă.
În primul rând, este necesar să se familiarizeze cu istoria dezvoltării conceptelor juridice pentru utilizarea programelor de calculator (în continuare, pentru comoditate, vor fi folosiți termenii „program” și „software”). Problema necesității reglementare legală utilizarea programelor a necesitat o soluție, mai ales după ce programele au devenit disponibile unui număr mare de oameni, iar producătorii au început să sufere pierderi din cauza copierii programelor achiziționate de utilizatori. Pentru producătorii din SUA, aceasta a devenit o problemă reală și datorită existenței așa-numitei doctrine de primă vânzare, formulată de Curtea Supremă a SUA în decizia Bobbs-Merill Co. v. Strauss. Această doctrină a fost apoi consacrată în Legea drepturilor de autor din 1909 și a fost rafinată în continuare în Legea drepturilor de autor din 1976 (17 U.S.C. § 109(a)), stabilind că proprietarul legal al unei anumite copii (adică o copie a unui rezultat al activitate intelectuală protejată prin drepturi de autor) sau o altă persoană cu autoritate are dreptul să vândă sau să dispună în alt mod de această copie.
Odată cu apariția programelor distribuite pe scară largă pe CD-uri (distribuții), deținătorii de drepturi de autor au început să se teamă că astfel de distribuții vor fi revândute de cumpărători (pe baza doctrinei primei vânzări). În acest sens, a apărut ideea de a plasa textul acordului de licență (care reglementează tipurile de utilizare a programului) pe ambalajul produselor software cu condiția ca consumatorul, prin ruperea hârtiei de ambalaj (înveliș), să-și exprime acordul. respectă termenii acestui acord și, prin urmare, încheie un acord cu deținătorul drepturilor de autor al software-ului. Un astfel de acord definește puterile părților și, de asemenea, limitează dreptul cumpărătorului de a dispune de program (în termeni de revânzare). Aceste acorduri se numesc acorduri shrink-wrap. În esență, companiile de software din SUA, invocând § 109(d) că doctrina primei vânzări nu poate fi aplicată atunci când proprietatea este absentă, au inclus utilizări permise pe hârtia de ambalaj, subliniind că software-ul este „licențiat, nu vândut”. , nevândut). Această teză de licență a fost confirmată în Timothy S. Vernor v. Autodesk, Inc. Reclamantul (Timothy Vernor) a scos la vânzare pe eBay discurile cu programul AutoCAD pe care l-a achiziționat, pentru care a început să primească avertismente de la deținătorul drepturilor de autor. După închiderea forțată a contului său eB ay, a mers în instanță, crezând că nu a comis nicio infracțiune, deoarece nu a scos ambalajul, nu a instalat discul și nu a putut să se familiarizeze cu termenii licenței. Curtea de Apel din SUA pentru al nouălea circuit a indicat că cumpărătorul unui CD cu un program dobândește dreptul de proprietate asupra mass-media, și nu programul ca atare, prin urmare, pentru a determina drepturile cumpărătorului, trebuie să se consulte textul din licență, care indică dreptul exclusiv de a distribui programul, care aparține numai organizației deținătoare a drepturilor de autor sau unei organizații autorizate să vândă.
Următoarea etapă în dezvoltarea licențelor software au fost așa-numitele acorduri click-wrap, adică acorduri, a căror acceptare se face prin clic. Dacă utilizatorul dorește să folosească funcționalitatea oferită online, trebuie să mute cursorul în caseta „Accept” și să facă clic pe OK. În SUA, valabilitatea unor astfel de acorduri a fost confirmată și în decizia Hughes v. McMenanon: „...Dacă instanțele recunosc termenii licențelor shrink-wrap ca fiind validi, atunci termenii acordurilor click-wrap ar trebui recunoscuți ca atare, mai ales că consimțământul utilizatorului este mai pronunțat.”
În lumea modernă a tehnologiei, totul este automatizat, îmbunătățit și simplificat. Această tendință s-a reflectat și în modalitățile de încheiere a acordurilor de licență: au apărut licențe de browse-wrap, care sunt termeni de utilizare clickabili ai site-ului plasat pe site, dar utilizatorul nu este de acord în mod expres cu acestea (nu există o fereastră separată în care utilizatorul ar bifa caseta) acord cu termenii de utilizare). Regulile în sine prevăd că vizualizarea sau utilizarea în alt mod a site-ului implică acordul cu acești termeni.
A. I. Savelyev subliniază că, de regulă, toate condițiile prevăzute în regulile de utilizare a site-ului pot fi împărțite în informaționale și de reglementare. De exemplu, termenii de utilizare ai site-ului Amazon.com conțin și procedura de depunere a reclamațiilor pentru încălcarea drepturilor de autor, procedura de revizuire a produselor și interdicții privind uz comercial informațiile postate pe site și utilizarea roboților pentru a colecta informații de pe site.
Este necesar să se ia în considerare problema momentului în care, în cazul utilizării licențelor click-wrap și browse-wrap, contractul este considerat încheiat. Cerințele pentru forma contractului sunt cuprinse în art. 434 din Codul civil al Federației Ruse, iar o justificare adecvată pentru metoda de încheiere a unui acord este în paragraful 3 al art. 438 din Codul civil al Federației Ruse: acceptarea unei oferte prin acțiuni implicite. Din octombrie 2014 va intra în vigoare noua ediție a clauzei 5 a Art. 1286 din Codul civil al Federației Ruse, care introduce o procedură simplificată pentru încheierea unui acord de licență pentru utilizarea programelor de calculator și a bazelor de date. Un acord de licență încheiat într-o manieră simplificată este un acord de adeziune, ai cărui termeni pot fi precizați pe copia achiziționată a unui program de calculator sau a unei baze de date sau pe ambalajul unei astfel de copii, precum și în formă electronică.
Există un alt nivel de licențe caracterizat de anumite specificități - licențe gratuite. Majoritatea programelor open source sunt, de asemenea, gratuite. Pentru a înțelege ce sunt licențele libere și deschise, este necesar să ne uităm la istoria dezvoltării lor. La mijlocul anilor 1980. s-au dezvoltat două mișcări ideologice paralele: pentru software liber (Free Software Foundation, FSF, condusă de Richard Stallman) și pentru crearea și distribuirea de software open source (OSI, ai cărui ideologi au fost Bruce Perens și Eric Raymond).
Richard Stallman, care a fost pionier în mișcarea software-ului liber, a văzut că una dintre sarcinile dezvoltatorilor de software este rezistența monopolului software-ului proprietar. În 1985, Stallman a fondat FSF, a publicat Manifestul GNU (subliniind ideea Licenței Publice Generale, GPL) și a dezvoltat sistemul de operare GNU GPL. Mesajul principal al filozofiei sale a fost distribuirea software-ului în condiții de libertate deplină (care devine nu un privilegiu, ci mai degrabă o obligație!). GPL, numită în mod obișnuit „licență copyleft” (însemnând că orice copie a unui program bazat pe un program licențiat conform GPL trebuie să fie gratuită), este discutată în articolul de mai jos.
Cam în aceiași ani, a început o mișcare de integrare a software-ului open source în afaceri. În 1997, a fost publicată The Cathedral and the Bazaar (abreviat CatB) despre metodele de dezvoltare software, care analizau modelele „catedrală” și „bazar”. Modelul „catedrală” implică faptul că codul sursă devine disponibil după lansarea programului, iar în timpul procesului de dezvoltare, numai dezvoltatorii de proiecte au acces la cod. Modelul „bazar” presupune dezvoltarea codului pe Internet „la vedere” și cu o posibilă participare a publicului, ceea ce este mai progresiv din punctul de vedere al scriitorului de eseuri, deoarece „cu destui ochi, toate bug-urile sunt superficiale” ”. În 1998, Eric Raymond și Bruce Perens au fondat OSI (Open Source Initiative).
În zilele noastre, când sunt menționate licențe libere sau software liber, acestea înseamnă software open source și invers. Cu toate acestea, o diferență mai există, deși la nivelul filozofiei ambelor mișcări. Software-ul liber este neapărat open source și, în plus, există patru libertăți:
lansa;
studiază și modifică;
distribuie copii ale programului original;
distribuie versiuni modificate.
OSI are propriile criterii de definire a software-ului open source, constând din zece puncte (definiția OS) și prezentate pe site-ul web al organizației:
programul trebuie să fie distribuit gratuit (nu trebuie să implice nicio remunerație);
programul trebuie să includă codul sursă;
programul trebuie să permită modificări;
nicio discriminare împotriva persoanelor sau a grupurilor;
nicio discriminare în raport cu domeniile de activitate (licența nu ar trebui să interzică utilizarea programului într-o anumită zonă de activitate);
drepturile asociate programului trebuie să se aplice tuturor celor cărora le este distribuit;
distribuirea unui program ca parte a oricărui program produs software nu ar trebui să depindă de distribuția produsului software în sine;
licența nu trebuie să restricționeze alt software;
licența trebuie să fie neutră din punct de vedere tehnologic.
OSI certifică licențele pentru a se asigura că îndeplinesc condițiile specificate. Numai licențele care îndeplinesc aceste cerințe și sunt certificate de OSI pot fi numite licență open-source. O listă cu astfel de licențe aprobate de OSI este indicată pe site-ul web OSI.
Este imperativ ca orice utilizator al software-ului să înțeleagă exact în ce condiții poate fi utilizat. Deoarece software-ul open source este dezvoltat prin colaborarea distribuită a multor participanți și poate fi folosit ulterior în scopuri comerciale, codul este pus la dispoziția publicului, împreună cu licențele care îl guvernează. Majoritatea proiectelor de software open source au un „depozitiv de încredere”, o sursă web specifică de unde poate fi obținută „versiunea oficială” a programului. Numai creatorii pot schimba programul. În același timp, utilizatorii pot trimite mesaje de eroare, inclusiv direct către depozit. Cu toate acestea, principala diferență este că utilizatorul însuși poate face orice modificări. Din nou, este un ciclu: cu cât un program devine mai capabil, cu atât mai mulți utilizatori îl folosesc și, în cele din urmă, utilizatorul (sau setul de utilizatori) devine utilizator ca dezvoltator.
Apare o întrebare rezonabilă: de ce o licență de utilizare gratuită sau de ce o licență care vă permite în mod evident să faceți tot ce doriți cu software-ul? Deoarece software-ul provine din America, reglementările privind drepturile de autor impun utilizatorilor să obțină permisiunea deținătorului drepturilor de autor înainte de a rula programul. Astfel, orice software furnizat pentru utilizare de către un număr nedeterminat de persoane trebuie să fie însoțit de o licență (adică condiții explicite de utilizare ulterioară).
Cea mai faimoasă găzduire a proiectelor gratuite este GitHub, a cărui echipă a lansat un nou site web în 2013, C hooseAL icense.com, pentru a simplifica decizia de alegere a unei anumite licențe la crearea unui depozit de cod. Site-ul web descrie pe scurt caracteristicile principalelor licențe deschise. Pe pagina principală pentru înregistrarea unui nou depozit în GitHub a apărut un formular de selecție a licenței care vă permite să generați automat un fișier cu tipul de licență selectat, astfel încât să nu fie nevoie să copiați manual termenii licenței. O astfel de automatizare a fost, de asemenea, necesară deoarece codul a fost adesea postat fără o licență explicită, ceea ce în mod oficial nu a făcut posibilă utilizarea codului în proiecte fără acordul autorului.
În ciuda diferențelor de filozofie dintre FSF și OSI, ambele ideologii au aceeași abordare a open-source, astfel încât granițele dintre licențele libere și software-ul open source sunt neclare. FOSS și FLOSS sunt utilizate pe scară largă (singura diferență este prezența literei L), ceea ce înseamnă Free/Libre și Open-Source Software - software open source gratuit. Această categorie include atât software gratuit, cât și software open source. ÎN Limba engleză cuvântul Liber înseamnă atât „liber”, cât și „liber”, de unde și termenul FOSS ( Gratuit și Software cu sursă deschisă) a fost inclus cuvântul Libre (în franceză „gratuit”) pentru a sublinia că vorbim despre software liber.
După ce am stabilit că diferențele de ideologie nu afectează sensul general, procedura de acordare a licențelor și utilizarea software-ului, vom folosi în continuare termenul „licențe libere”.
Licențele sunt împărțite în două grupe principale: licențe permisive care conțin un minim de condiții (BSD, MIT, Apache) și licențe reciproce (licențe reciproce, copyleft), impunând obligația de a distribui modificările programului în aceleași condiții în care originalul programul a fost distribuit (GPL, LGPL, MPL). Caracteristicile tuturor licențelor gratuite includ următoarele:
licențele sunt standardizate (GNU, CC, Apache, Mozilla);
numele contractului sau acordului la termenii la care utilizatorul se alătură conține o indicație a subiectului însuși (GNU GPL, LGPL);
Nu puteți modifica condițiile de utilizare, le puteți accepta ca atare (ca atare);
licenta este irevocabila.
Pentru o idee mai clară a celor mai cunoscute licențe sub care este distribuit codul, trebuie să vă familiarizați cu termenii acestora.
Cea mai simplă și, din punct de vedere istoric, prima licență gratuită utilizată în prezent este licența sistemului de operare. BSD (Berkley Software Distributie Licență) - a apărut la începutul anilor 1980. Au existat trei versiuni ale licenței. Licența originală („vechiul BSD” sau „BSD cu 4 clauze”) se numește așa deoarece conținea, pe lângă condițiile de menținere a notificării privind drepturile de autor și cerința pentru o licență pe hârtie, și o indicație a necesității de a menționa universitate dacă caracteristicile programului au fost publicate în materiale publicitare (clauză publicitară). „Noul BSD” („BSD modificat” sau „BSD cu trei clauze”) nu mai conține clauza publicitară oneroasă. Licența oferă libertate deplină de a distribui codul, în orice condiții, cu textele sursă sau fără ele și îi pasă doar de protejarea numelui onest al organizației autorului. Licențele de tip BSD sunt licențe permisive deoarece nu necesită utilizarea aceleiași licențe pentru versiunile din aval. Licența conține un set standard de termeni care furnizează programul „ca atare”, fără nicio garanție, excluzând răspunderea pentru orice daune care ar putea fi cauzate de program.
Licență MIT (Massachusetts institut de Tehnologie) este similar ca conținut cu licența BSD, dar conține un limbaj care permite sublicențarea (adică drepturile fiecărui utilizator ulterior sunt acordate celui precedent, nu celui original).
Licență Apache 2.0 (Apache Software fundație) permite ca lucrările derivate să fie distribuite sub diferite licențe și, de asemenea, permite dezvoltatorilor să decidă singuri dacă să păstreze produsul rezultat gratuit și open source. Singura condiție impusă de licența Apache este ca destinatarul să fie informat că codul sursă este utilizat. Astfel, spre deosebire de licențele copyleft, destinatarul unei versiuni modificate nu primește neapărat toate drepturile acordate inițial de licența Apache.
Când distribuiți software, trebuie să plasați următoarele fișiere la directorul rădăcină: licență - un fișier care conține o copie a textului licenței Apache; notice este un fișier text care listează toate bibliotecile licențiate sub Apache, împreună cu numele creatorilor acestora.
În timpul procesului de dezvoltare, toate aceste licențe au suferit anumite modificări, care în cele din urmă le-au făcut aplicabile universal (au fost eliminate condițiile inutile, au fost adăugate cele necesare). Licența a urmat o cale similară. Mozilla (Mozilla Public Licență , MPL), însă, având în vedere că inițial a fost întocmit de avocați, totul a fost formulat în ea mai logic. Dacă este distribuit un fișier care conține codul original sau modificările aduse anterior acestuia, fișierele rezultate sunt licențiate conform condițiilor MPL. Produsul complet poate fi distribuit sub orice licență. Licența specifică două tipuri de autori: autorul original și cei care au contribuit la completarea acestui cod (contributor). Astfel, licența nu limitează utilizarea software-ului în diverse produse și garanții dezvoltare ulterioară proiect.
Istoria Proiectului GNU a început în 1984, când Richard Stallman a decis să creeze software care să fie distribuit și modificat în mod liber. Ca urmare, toate condițiile de utilizare pe care Stallman le-a considerat necesare au fost exprimate în licență GPL (General Public Licență) . Utilizatorul are dreptul de a copia, modifica și distribui codul sursă, distribuie versiuni compilate care conțin atât codul modificat, cât și codul sursă. În același timp, toate copiile distribuite trebuie să conțină o notificare privind drepturile de autor și nicio garanție pentru software, toate versiunile modificate sunt supuse termenilor GPL, toate versiunile compilate trebuie să fie însoțite de codul sursă sau să conțină o indicație a realității. disponibilitatea codului (ofertă viabilă). De exemplu, o indicație că codul este dezvăluit oricărei persoane la prima sa cerere. Conform termenilor licenței, fiecărui nou licențiat i se acordă drepturi direct de la licențiatorul original, ceea ce înseamnă că toți utilizatorii intră într-o relație direct cu Free Software Foundation (FSF).
GPL a dat naștere la anumite mituri cu privire la strictețea aplicării sale. Se crede că, dacă cineva a modificat software-ul conform GPL, atunci el este obligat să pună software-ul disponibil. De fapt, dacă nu există niciun scop de a distribui software-ul, atunci nu este nevoie să facem public software-ul derivat.
La un moment dat, s-a pus întrebarea cu privire la legalitatea condiției privind necesitatea de a subordona un program creat pe baza GPL termenilor aceleiași licențe. Instanțele americane au convenit că GPL nu încalcă legile antitrust. În decizia Wallace v. Judecătorul FSF Daniel Tinder a subliniat că „GPL promovează, mai degrabă decât împiedică, libera concurență și distribuția de programe de calculator”. Reclamanta a solicitat instanței de judecată stabilirea unei acțiuni în încetare împotriva utilizării GPL din cauza faptului că termenii licenței impun restricții asupra circulației comerciale, pretinzând stabilirea unor prețuri fixe pentru software. Astfel, potrivit reclamantei, a existat o încălcare a legislației antimonopol (Sherman Act). Drept urmare, instanța nu a constatat încălcări și, de fapt, prin decizia sa a făcut doar să întărească legitimitatea condițiilor de licență.
Licențele gratuite există de mult timp în străinătate și, în ciuda acestui fapt, încă apar dispute legale. În Rusia, discuțiile pe tema folosirii licențelor gratuite, fie că au avânt, fie că se estompează, au loc de câțiva ani.
În 2011, în cadrul mesei rotunde „„Licențe gratuite” sau auto-restricționare a drepturilor?” La Școala Rusă de Drept Privat (RSLP), a avut loc o discuție despre soarta licențelor libere în Rusia. Masa rotundă a cuprins amendamentele propuse la acel moment la partea a patra a Codului civil al Federației Ruse (exprimate la masa rotundă de către membru grup de lucru V. Kalyatin) și contraargumente ale avocatului IBM A. Savelyev, care a luat poziția că nu este nevoie de o reglementare specială a licențelor libere. Potrivit lui A. Savelyev (punerile sale sunt prezentate mai detaliat în monografia „Licențele software în Rusia: legislație și practică”), modelul de licențe libere este destul de aplicabil în cadrul legislației ruse.
În cele din urmă, au fost adoptate modificări la partea a patra a Codului civil al Federației Ruse Lege federala Nr. 35 din 12 martie 2014 „Cu privire la modificările la părțile unu, doi și patru ale Codului civil al Federației Ruse și anumite acte legislative ale Federației Ruse”. În contextul acestui articol, următoarele modificări sunt esențiale: revizuirea și adăugarea dispozițiilor privind licențele wrap (clauza 5 a articolului 1286 din Codul civil al Federației Ruse); introducerea de dispoziții privind licențele deschise (articolul 1286.1 din Codul civil al Federației Ruse); introducerea unei noi metode de dispoziție a dreptului exclusiv asupra unei opere de știință, literatură sau artă sau asupra unui obiect de drepturi conexe - o declarație publică care oferă oricărei persoane posibilitatea de a utiliza gratuit rezultatul drepturilor intelectuale în condițiile determinate de deținătorul drepturilor de autor și în perioada specificată de acesta (clauza 5 a articolului 1233 din Codul civil al Federației Ruse) .
Este necesar să se analizeze inovațiile Codului civil al Federației Ruse pentru a le compara cu instituțiile străine de licențe gratuite. Pe în prezent clauza 5 art. 1286 din Codul civil al Federației Ruse prevede că încheierea de acorduri de licență care acordă dreptul de a utiliza un program de calculator sau o bază de date este permisă prin încheierea unui acord de aderare între fiecare utilizator și deținătorul dreptului de autor corespunzător, ai cărui termeni sunt stabiliți la copia achiziționată a unui astfel de program sau bază de date sau de pe ambalajul acestei copii. Începerea utilizării de către utilizator a unor astfel de programe sau baze de date, așa cum sunt definite în acești termeni și condiții, constituie consimțământul acestuia de a încheia un contract. De la 1 octombrie 2014, alin.5 al art. 1286 din Codul civil al Federației Ruse este menționat într-o nouă ediție. Editorii articolului oferă un algoritm pentru încheierea unui contract de licență într-o manieră simplificată, extinzând lista de opțiuni pentru prezentarea condițiilor și subliniind posibilitatea existenței condițiilor în formă electronică.
De asemenea, de la 1 octombrie 2014, art. 1286.1, în paragraful 1 al cărui concept este definit licență deschisă, care se prezumă a fi gratuită dacă nu se prevede altfel. În cazul în care perioada de valabilitate a unei licențe deschise nu este determinată, în ceea ce privește programele de calculator și bazele de date contractul se consideră încheiat pe întreaga perioadă de valabilitate a dreptului exclusiv, iar în ceea ce privește alte tipuri de lucrări - pentru cinci ani. În plus, modificările aduse Codului civil al Federației Ruse definesc răspunderea pentru încălcarea termenilor licențelor deschise, inclusiv permițând autorului să solicite aplicarea unor măsuri pentru a proteja dreptul exclusiv al contravenientului în conformitate cu art. 1252 din Codul civil al Federației Ruse.
La 1 ianuarie 2015, clauza 5 a art. 1233 din Codul civil al Federației Ruse, care prevede o declarație publică cu privire la posibilitatea utilizării gratuite a unei opere. În esență, se introduce o nouă modalitate de a dispune de drepturile exclusive. Deținătorul drepturilor de autor poate face public o declarație cu privire la oferirea oricăror persoane a oportunității de a utiliza gratuit o operă de știință, literatură sau artă care îi aparține sau un obiect de drepturi conexe, în condițiile determinate de acesta și pentru o perioadă specificată de acesta. . Mai mult, legiuitorul reglementează și procedura de depunere a cererii: prin postarea acesteia pe site-ul oficial al organului executiv federal. Nu este încă clar care organism va furniza site-ul și va menține cumva registrul. În orice caz, mecanismul art. va fi utilizat pentru programele de calculator. 1286.1 Cod civil al Federației Ruse. Conținutul conceptului de licență deschisă conform Codului civil al Federației Ruse nu este identic cu conceptul de licență open-source. Artă. 1286.1 din Codul civil al Federației Ruse își extinde efectul asupra operelor de știință, literatură sau artă, programe de calculator și baze de date, în timp ce licențele open-source reglementează numai domeniul de utilizare a programelor de calculator. Codul civil numește licențiatorul și licențiatul ca părți, iar în licențele open-source pot exista un autor original, un autor al unui produs derivat și un utilizator. Un mecanism auxiliar important introdus de modificările la Codul civil al Federației Ruse este clauza 3 a art. 1266 din Codul civil al Federației Ruse, stabilind în legătură cu clauza 2 a art. 1286.1 din Codul civil al Federației Ruse și clauza 5 din art. 1233 din Codul civil al Federației Ruse posibilitatea de a-ți da consimțământul pentru a face modificări, abrevieri și completări la munca ta în viitor, pentru a-i furniza ilustrații și explicații, dacă este necesar (corectarea erorilor, clarificarea sau adăugarea de informații faptice, etc.), cu condiția ca aceasta să nu fie denaturată intenția autorului și să nu fie încălcată integritatea percepției operei.
În concluzie, aș dori să remarc că inovațiile în legislația civilă sunt evaluate ambiguu. Dacă noua versiune a art. 1286 din Codul civil al Federației Ruse și introducerea art. 1286.1 din Codul civil al Federației Ruse poate fi evaluat pozitiv în siguranță, apoi pentru a evalua clauza 5 din art. 1233 din Codul civil al Federației Ruse va dura timp. Practica va arăta dacă metoda propusă de înstrăinare a dreptului prin publicarea unei declarații va fi solicitată sau dacă acest design va rămâne doar pe hârtie.
Legea federală nr. 35-FZ din 12 martie 2014 „Cu privire la modificările la părțile unu, două și patru ale Codului civil al Federației Ruse și anumite acte legislative ale Federației Ruse” // SPS „Consultant Plus”.
Savelyev A.I. Licențierea software-ului în Rusia: legislație și practică. - M.: Infotropik Media, 2012. - P. 183.
Savelev A. I. Comerț electronicîn Rusia fără semnătură digitală: iluzie sau realitate? // Buletin de Drept Civil 2013, Nr. 3 // SPS „Consultant Plus”.
În zilele noastre, software-ul liber a devenit deja răspândit în domeniul tehnologie avansata. Aceasta are o cantitate mare dovezi. Din ce în ce mai multe companii își caută proiectele deschise, accelerând și mai mult ritmul de creștere a acestei culturi.
Avem tendința de a numi toate produsele open source cu un singur termen, pentru a le considera ca o singură categorie. Acest lucru este mai convenabil, dar aceasta este doar o simplificare. Conceptul fundamental de open source este înțeles de toată lumea, dar drepturile, responsabilitățile și privilegiile părților sunt interpretate diferit. Acest lucru se reflectă în licențele de software liber. În acest articol vom analiza principalele tipuri de licențe gratuite și cât de populare sunt acestea.
Una dintre cele mai comune licențe software este licența GNU GPL. Esența sa este reciprocitatea. Licența necesită ca, dacă codul este schimbat, atunci toate modificările trebuie publicate și disponibile pentru toată lumea. Aceasta se numește copyleft. Dar există și alte tipuri de licențe care sunt construite în jurul libertății pentru dezvoltator. Astfel de licențe impun restricții minime utilizatorilor și nu necesită reciprocitate din partea dezvoltatorilor. Ambele tipuri de licențe sunt gratuite, singura diferență este ceea ce rămâne liber.
În ultimul deceniu, mai mult de două treimi din proiectele open source au fost distribuite sub licență GPL. S-ar putea presupune că aceasta este licența implicită, dar în ultimii câțiva ani această licență a căzut din favor și este înlocuită cu licențe permisive.
Dacă comparăm ponderea fiecărei licențe în funcție de ratingul Black Duck luna aceasta față de ianuarie 2010, diferența este destul de evidentă:
În acest clasament, GPLv2 rămâne cel mai popular, dar și-a pierdut mai mult de jumătate din popularitate, de la 46% la 19%. În aceeași perioadă, licența permisivă a MIT a crescut de la o cotă de 8% la 29%. Licența Apache 2.0 a crescut de la 5% la 15%.
Se poate presupune că, dacă în 2007 vorbeam despre software liber, ne referim la licența GPL copyleft, în timp ce acum Fawkes s-a mutat către permisive MIT și Apache. Acest lucru nu înseamnă că licențele copyleft devin mai puțin importante, ci doar că dezvoltatorii din zilele noastre preferă licențele permisive. Iată concluziile pe care le putem trage din acest grafic:
Consolidare. Acestea sunt primele 10 licențe după popularitate pentru 2010 și 2016, toate, cu excepția a trei, au scăzut în popularitate. Licența GPL a scăzut cel mai mult, în timp ce Apache și MIT au crescut, despre asta s-a discutat deja. Dar este de remarcat faptul că licența BSD destul de populară, dimpotrivă, a scăzut. Aceeași tendință se aplică și licenței ISC. În prezent, doar câteva licențe sunt cele mai populare și poate că în curând vom vedea o consolidare între mai multe licențe.
Alegere binară. Din punct de vedere istoric, aveți trei opțiuni principale de licență: copyleft, permisiv și mijloc. Licențele medii includ LGPLv2.1 (4), LGPLv3 (2), EPL (1), MPLv1.1 (<1), CDDL (<1) и CDDLv1.1 (<1) они имеют общую долю порядка 7-8%. Теперь все больше и больше выбор сводится к копилефт или разрешающим лицензиям.
Fara licenta. Oricât de mult am vorbi despre licențe deschise, mai există depozite de proiecte deschise cu cod care nu folosește niciuna dintre licențe. În timp, procentul de depozite licențiate scade:
Există multe explicații pentru acest fenomen, de exemplu, indiferența dezvoltatorilor. Dar toate programele open source fără licență nu sunt software open source și asta e rău.
Licențe de bază pentru software gratuit
Acum să facem o scurtă descriere pentru fiecare licență din rating, astfel încât să puteți înțelege care sunt acestea:
Licență publică generală GNU. Standuri pentru licență publică generală. A fost dezvoltat în 1988 ca parte a Proiectului GNU. Principiul licenței, așa cum sa menționat deja, toate modificările codului trebuie publicate. Programul nu poate fi inclus în software-ul proprietar, dar poate fi distribuit gratuit între utilizatori, studiat și îmbunătățit, sub rezerva publicării îmbunătățirilor. În timpul dezvoltării, au fost lansate trei versiuni - GPLv1, GPLv2 și GPLv3, în care restricțiile licenței GPL pentru software-ul proprietar au fost ușor slăbite.
Licență MIT. Aceasta este o licență dezvoltată de Massachusetts Institute of Technology (MIT). Aceasta este o licență permisivă, ceea ce înseamnă că, deși este redistribuibilă liber, software-ul poate fi utilizat ca parte a programelor proprietare.
Licență Apache 2.0. Aceasta este o altă licență permisivă. Pe lângă faptul că permit distribuirea completă gratuită a produsului, programele pot fi încorporate în software-ul proprietar. Dar nu puteți schimba numele și toate informațiile despre modificări și licență trebuie incluse în fișiere.
Licență artistică este o licență gratuită dezvoltată de Fundația Perl. Aceasta este o licență copyleft, necesită ca toate modificările să fie publicate, iar modificările efectuate trebuie descrise în fișiere.
Licențiat BSD 2.0. Licență software de la Universitatea din Berkeley. Licența este foarte asemănătoare cu MIT, iar software-ul poate fi, de asemenea, integrat în proiecte proprietare. Dar aici nu puteți folosi numele original al proiectului gratuit.
Licență Code Project Open 1.0.2. Aceasta este o licență publicată de comunitatea de dezvoltatori The Code Project. Vă permite să utilizați codul sursă și programele în sine în scopuri comerciale, codul poate fi modificat și inclus în alte proiecte.
Licență publică Mozilla (MPL) 1.1. Această licență a fost dezvoltată de Netscape și îmbunătățită de Fundația Mozilla. Utilizarea codului în proiectele proprietare este permisă, dar codul modificat trebuie să fie licențiat conform MPL.
Licență publică Microsoft (MS-PL) este o licență gratuită care oferă dreptul de a utiliza, distribui și modifica codul. Dar atunci când distribuiți, trebuie să păstrați informațiile privind drepturile de autor.
Conceptul diferențelor dintre principalele licențe de software liber într-o diagramă:
concluzii
În acest articol, am analizat principalele tipuri de licențe gratuite, precum și unele dintre cele mai populare licențe și procentul de utilizare a acestora. Sper că această informație v-a fost de folos.
Un scurt videoclip pe tema licențelor gratuite și a licenței GPL:
