Disclaimer: Sunt dezvoltator, nu avocat; aceste informații sunt considerate corecte, dar nu reprezintă consultanță juridică; dacă credeți că ceva este incorect, vă rog, scrieți un comentariu și vom rezolva împreună🔧

Până acum nu eram preocupat de licența pachetului npm. Puteam verifica licența dependenței imediate, dar niciodată nu am verificat dependențele de la terțe părți (de tranziție).

🚓 Și apoi am întâlnit băieți din departamentul juridic 🚓

Acum cred că dezvoltatorii ar trebui să aibă o înțelegere de bază a licențelor software pentru a avea un dialog constructiv cu echipele juridice din companiile lor. Această postare adună cunoștințe generale despre licențele Open-Source și cum se aplică la dependențele npm și la dezvoltarea Full-Stack JavaScript în general.

Să ne dăm seama când ar trebui să începeți să vă faceți griji în legătură cu licențele.

Când se declanșează cerințele de licență?

Dacă efectuați legarea cu biblioteci open source și apoi distribuiți software-ul rezultat, atunci software-ul dvs. trebuie să fie conform cu cerințele bibliotecilor legate.

Să privim mai îndeaproape legarea și distribuția aplicate aplicațiilor JavaScript.

Legăturarea

Utilizarea bibliotecilor de la terți înseamnă în mod normal legarea acestora:

  • Dacă vă grupați (de exemplu, cu webpack) codul cu pachete open source, aceasta se consideră legare statică
  • Dacă utilizați pachete open source în aplicația dvs. Node.JS (de ex. prin require) sau îl conectați la o pagină web prin intermediul unei etichete de script, este vorba de o legătură dinamică

Nota: atunci când construiți un pachet sau executați o aplicație Node.JS, efectuați același tip de legătură atât cu dependențele imediate (listate în package.json al dvs.), cât și cu cele tranzitive (listate în package.json al părților terțe). Licențele de dependență imediată și tranzitivă au același efect asupra software-ului dvs.

Aceasta nu era intuitiv pentru mine înainte 🤔

Distribuție

Simpla utilizare a bibliotecilor open source nu declanșează în mod necesar cerințe de licență. În mod normal, cerințele de licență sunt declanșate atunci când distribuiți software:

  • Transferul de software între angajații aceleiași companii nu este o distribuție
  • Când utilizatorii interacționează cu Node.JS app over network, nu este o distribuție pentru majoritatea licențelor open source; dar este o distribuție pentru licențele Network Protective cum ar fi AGPL
  • Punerea fișierelor JavaScript pe un server web public este o distribuție

Ce licență este ok

Majoritatea licențelor open source se încadrează, în general, într-unul din aceste tipuri:

  • Licențe de domeniu public și licențele permisive, cum ar fi MIT, care vă permit să faceți orice, în afară de a da în judecată autorul
  • Licențele copyleft sau de protecție, cum ar fi GPL, împiedică crearea de legături (a se vedea mai sus) cu software-ul proprietar; cazul limită este reprezentat de licențele de protecție a rețelei, cum ar fi Affero GPLv3, care se declanșează prin interacțiunea în rețea;
  • Între cele două de mai sus se află licențele slab protectoare, cum ar fi MPL, care au mai puține restricții pentru legarea dinamică (până când biblioteca se află în propriul fișier)

Să verificăm scenariile comune pentru un dezvoltator JavaScript:

Realizați o aplicație web

Cel mai probabil vă grupați toate fișierele, inclusiv bibliotecile într-un singur fișier JS și îl puneți pe un server web. Efectuați legarea și distribuția statică. Este bine să folosiți pachete cu licențe Permissive într-un pachet.

Dacă trebuie să folosiți un pachet cu licență Weakly Protective, cum ar fi MPL, aveți opțiunile:

  1. Încărcați biblioteca dintr-un fișier separat (de ex. prin intermediul tag-ului script)
  2. Aplicați o licență open source compatibilă pachetului dvs. (dar verificați comentariul de mai jos și discutați cu echipa dvs. juridică înainte)

Dacă pachetul dvs. nu are ✨proprietate intelectuală valoroasă✨, atunci a doua variantă ar trebui să fie bună. Nu cred că concurenții vor beneficia de pe urma codului dvs. ofuscat. Dar dacă pachetul conține o proprietate intelectuală valoroasă, atunci aplicarea licenței open source acordă o utilizare gratuită a acesteia.

Realizați o aplicațieNode.JS

În acest caz, în mod normal, conectați bibliotecile prin intermediul unui apel require(). Este o legătură dinamică. Este în regulă să folosiți licențe Permissive și chiar Weakly Protective. Doar asigurați-vă că pachetele rămân în propriile lor fișiere cu licențele respective.

Dacă oferiți doar SaaS și nu distribuiți în niciun alt mod, puteți folosi chiar și pachete cu licență Protective. Pentru multe licențe Protective, interacțiunea în rețea nu este o distribuție. Excepție fac licențele Network Protective, cum ar fi Affero GPLv3

Realizați un pachet NPM cu sursă deschisă

În mod normal, conectați dependențele părților terțe prin intermediul unui package.json. După cunoștințele mele, listarea dependențelor în package.json nu poate fi considerată ca fiind o legătură. Legătura va fi realizată de un dezvoltator de aplicații care va utiliza pachetul dvs. într-o etapă de construire sau de execuție.

Dacă nu doriți să derutați utilizatorii pachetului, asigurați-vă că toate dependențele (atât cele imediate, cât și cele tranzitive) au licențe compatibile cu licența pachetului dvs.

În mod normal, licențele dependențelor ar trebui să fie mai permisive sau să aibă același nivel de permisivitate ca și licența pachetului dumneavoastră.

De exemplu, dacă pachetul dumneavoastră are licența Apache 2.0 puteți folosi dependențe cu licență MIT și BSD. Dar nu ar trebui să utilizați dependențe cu licență MPL1.1 sau LGPLv3, deoarece acestea au un copyleft mai puternic.

O săgeată de la căsuța A la căsuța B înseamnă că puteți combina software cu aceste licențe; rezultatul combinat are efectiv licența lui B, eventual cu adăugiri de la A; imagine din lucrarea lui David A. Wheeler

Când trebuie să puneți pachete sau surse de la terți în pachetul NPM, nu uitați să enumerați licențele și drepturile de autor ale terților. Majoritatea licențelor open source necesită recunoașterea autorului.

De asemenea, este o bună practică să specificați o expresie SPDX validă în licența package.json. Cred că acest câmp trebuie să fie obligatoriu pentru publicarea pe npm.org.

Cum vă dați seama

Multe echipe încep să se gândească la licențe atunci când software-ul este gata de livrare. Am folosit utilitarul ScanCode pentru acest lucru. Acesta merge într-adevăr în fiecare dosar al proiectului dvs. și încearcă să detecteze fiecare licență sau drept de autor.

Captură de ecran din https://github.com/nexB/scancode-toolkit

Probabil că trebuie să folosiți acest instrument sau unul similar înainte de a vă distribui aplicația. Asigurați-vă că verificați suficient și nu prea mult:

    • instalați toate dependențele de producție înainte de a rula instrumentul
    • asigurați-vă că devDependencies nu sunt verificate de instrument; în mod normal, nu distribuiți cu dependențele de dezvoltare;

    Nota: dacă, la fel ca mine, vă uitați la licențele pachetelor după ce ați integrat pachetul în aplicația dumneavoastră, s-ar putea să vă aflați într-o situație dificilă.

    Executarea ScanCode chiar înainte de termenul limită; imagine din https://giphy.com

    Cum îți dai seama înainte de a fi prea târziu

    Mă întrebam, când este cel mai bun moment pentru a învăța despre licențele de dependență a pachetelor. Pentru mine, fluxul normal de descoperire a pachetelor este:

    🔍 Google 👉 npm.org 👉 GitHub 👉 👉 $ npm install

    Din păcate, npm.org nu se ocupă cu adevărat de dependențele tranzitive. Există instrumente web, cum ar fi http://npm.anvaka.com/; dar nu se potrivește cu fluxul meu de descoperire a pachetelor și tot uit să le folosesc. M-am gândit că cel mai bun moment pentru a afla despre dependențele pachetelor este atunci când tastați $ npm install <pkg>

    Acesta a fost gândul meu când am construit un instrument CLI numit npm-consider care analizează pachetul cu toate dependențele tranzitive înainte de a-l instala sau chiar de a-l descărca.

    https://github.com/delfrrr/npm-consider

    Pentru a vă salva o comandă, aceasta înfășoară $ npm install și are aceleași argumente. Dacă nu aveți probleme cu dependențele, alegeți doar Install și va rula npm install ca de obicei. Dacă sunteți îngrijorat alegeți Details și vedeți întregul arbore de dependențe:

    Afișarea detaliilor la instalarea unei componente a popularei biblioteci geospațiale Turf.js; rețineți că pachetul în sine are o licență Permissive, dar una dintre dependențele tranzitive are licență AGPL; nu se poate folosi cu adevărat pentru software proprietar;

    Cred că o astfel de funcționalitate trebuie să facă parte din npm CLI. Dacă sunteți de acord, vă rog să ⭐️ proiectul pe GitHub și voi împinge ideea mai departe.

    Surse

    Întregistrez sursele mele în cazul în care doriți să verificați de două ori concluziile mele:

    • Înțelegerea modelului de dependență npm
    • Licențiere open source: Ce ar trebui să știe fiecare tehnolog ar trebui să știe | Opensource.com
    • Diverse licențe și comentarii despre ele
    • Licența Free-Libre / Open Source Software (FLOSS) Slide
    • License Center | ifrOSS
    • Compararea licențelor de software liber și open-source – Wikipedia
    • Biblioteca (informatică) – Wikipedia

    Dacă articolul a fost util, vă rog 👏 și poate voi mai scrie unul 😀

    .