Disclaimer: Olen kehittäjä, en lakimies; näiden tietojen uskotaan olevan oikeita, mutta ne eivät ole oikeudellista neuvontaa; jos mielestäsi jokin on väärin, kirjoita kommentti, niin korjaamme sen yhdessä🔧

Ennen en ollut huolissani npm-paketin lisenssistä. Pystyin tarkistamaan välittömän riippuvuuden lisenssin, mutta en koskaan tarkistanut kolmannen osapuolen (siirtymävaiheen) riippuvuuksia.

🚓 Ja sitten tapasin kaverit lakiosastolta 🚓

Olen nyt sitä mieltä, että kehittäjillä pitäisi olla perusymmärrys ohjelmistojen lisensoinnista, jotta he pystyisivät rakentavaan vuoropuheluun yritystensä lakitiimien kanssa. Tähän postaukseen on koottu yleistietoa avoimen lähdekoodin lisensseistä ja siitä, miten se soveltuu npm-riippuvuuksiin ja Full-Stack JavaScript -kehitykseen yleensä.

Kerrataanpa, milloin kannattaa alkaa huolehtia lisensseistä.

Milloin lisenssivaatimukset käynnistyvät?

Jos suoritat linkittämisen avoimen lähdekoodin kirjastojen kanssa ja sen jälkeen jaat tuloksena syntyvää ohjelmistoa, ohjelmistosi on oltava linkitettyjen kirjastojen vaatimusten mukainen.

Katsotaanpa tarkemmin linkittämistä ja jakelua sovellettuna JavaScript-sovelluksiin.

Linkitys

Kolmannen osapuolen kirjastojen käyttäminen tarkoittaa yleensä niiden linkittämistä:

  • Jos niputat (esim. webpackin avulla) koodisi avoimen lähdekoodin pakettien kanssa, se lasketaan staattiseksi linkittämiseksi
  • Jos käytät avoimen lähdekoodin paketteja Node.JS-sovelluksessasi (esim. require:n kautta) tai yhdistät sen verkkosivuun skriptitunnisteen avulla, se on dynaamista linkittämistä

Huomaa: kun rakennat pakettia tai suoritat Node.JS-sovellusta, suoritat samantyyppisen linkittämisen sekä välittömien (lueteltu omassa package.json:ssa) että siirtyvien (lueteltu kolmannen osapuolen package.json:ssa) riippuvuuksien kanssa. Välittömien ja transitiivisten riippuvuuksien lisensseillä on sama vaikutus ohjelmistoosi.

Tämä ei ollut minulle intuitiivista ennen 🤔

Jakelu

Vain avoimen lähdekoodin kirjastojen käyttäminen ei välttämättä aiheuta lisenssivaatimuksia. Normaalisti lisenssivaatimukset laukeavat, kun jakelet ohjelmistoa:

  • Ohjelmiston siirtäminen saman yrityksen työntekijöiden välillä ei ole jakelua
  • Kun käyttäjät ovat vuorovaikutuksessa Node.JS-sovelluksen kanssa verkon kautta, se ei ole jakelua useimpien avoimen lähdekoodin lisenssien osalta; mutta se on jakelua verkon suojaavien lisenssien, kuten AGPL:n, osalta
  • Javaskriptitiedostojen laittaminen julkiselle web-palvelimelle on jakelua

Mikä lisenssi on kunnossa

Suurin osa avoimen lähdekoodin lisensseistä kuuluu yleensä johonkin näistä tyypeistä:

  • Public Domain- ja Permissive-lisenssit, kuten MIT, jotka sallivat sinun tehdä mitä tahansa paitsi haastaa tekijä oikeuteen
  • Copyleft- tai Protective-lisenssit, kuten GPL, estävät linkittämisen (ks. edellä) omistusoikeudellisten ohjelmistojen kanssa; ääripäänä ovat Network Protective-lisenssit, kuten Affero GPLv3, jotka laukeavat vuorovaikutuksesta verkon yli;
  • Kahden edellä mainitun välissä ovat heikosti suojaavat lisenssit, kuten MPL, joilla on vähemmän rajoituksia dynaamiselle linkittämiselle (kunnes kirjasto on omassa tiedostossaan)

Tarkistetaan JavaScript-kehittäjän yleiset skenaariot:

Olet tekemässä web-sovellusta

Todennäköisesti niputat kaikki tiedostosi, kirjastot mukaan lukien, yhteen JS-tiedostoon ja laitat sen web-palvelimelle. Suoritat staattisen linkityksen ja jakelun. On hyvä käyttää nipussa paketteja, joilla on Permissive-lisenssi.

Jos haluat käyttää pakettia, jolla on Weakly Protective-lisenssi, kuten MPL, sinulla on vaihtoehtoja:

  1. Lataat kirjaston erillisestä tiedostosta (esim. skriptitunnisteen kautta)
  2. Valtaa yhteensopiva avoimen lähdekoodin lisenssi pakettiisi (mutta tarkista alla oleva kommentti ja keskustele lakitiimisi kanssa ennen sitä)

Jos paketissasi ei ole ✨arvokasta henkistä omaisuutta✨, niin jälkimmäisen pitäisi onnistua. En usko, että kilpailijat hyötyvät hämärtyneestä koodistasi. Mutta jos nippu sisältää arvokasta henkistä omaisuutta, niin avoimen lähdekoodin lisenssin soveltaminen myöntää sen vapaan käytön.

Olet tekemässäNode.JS-sovellusta

Tässä tapauksessa tavallisesti kytket kirjastot require()-kutsun kautta. Se on dynaamista linkittämistä. On hienoa käyttää Permissive ja jopa Weakly Protective -lisenssejä. Varmista vain, että paketit pysyvät omissa tiedostoissaan vastaavilla lisensseillä.

Jos tarjoat vain SaaS-palvelua etkä levitä sitä millään muulla tavalla, voit käyttää jopa paketteja Protective-lisenssillä. Monien Protective-lisenssien kohdalla verkkovuorovaikutus ei ole jakelua. Poikkeuksena ovat Verkkosuojalisenssit, kuten Affero GPLv3

Tuotat avoimen lähdekoodin NPM-paketin

Normaalisti liität kolmannen osapuolen riippuvuudet package.jsonin kautta. Tietääkseni riippuvuuksien listaamista package.jsoniin ei voida pitää linkittämisenä. Linkittämisen suorittaa sovelluskehittäjä, joka käyttää pakettiasi build- tai run-vaiheessa.

Jos et halua hämmentää paketin käyttäjiä, varmista, että kaikilla riippuvuuksilla (sekä välittömillä että siirtyvillä) on yhteensopivat lisenssit pakettisi lisenssin kanssa.

Tyypillisesti riippuvuuksien lisenssien tulisi olla sallivampia tai samantasoisia kuin pakettisi lisenssi.

Jos pakettisi lisenssi on esimerkiksi Apache 2.0, voit käyttää riippuvuuksia MIT- ja BSD-lisenssillä. Mutta sinun ei pitäisi käyttää riippuvuuksia MPL1.1- tai LGPLv3-lisenssillä, koska niillä on vahvempi copyleft.

Nuoli laatikosta A laatikkoon B tarkoittaa, että voit yhdistellä ohjelmistoja, joilla on nämä lisenssit; yhdistetyllä lopputuloksella on tosiasiassa B:n lisenssi, mahdollisesti lisäyksillä A:n lisenssistä; kuva David A:n työstä. Wheeler

Kun haluat laittaa nippuja tai kolmannen osapuolen lähdekoodia NPM-pakettiin, älä unohda luetella kolmannen osapuolen lisenssejä ja tekijänoikeuksia. Useimmat avoimen lähdekoodin lisenssit edellyttävät tekijän mainitsemista.

On myös hyvä käytäntö määritellä kelvollinen SPDX-lauseke paketti.json-lisenssissä. Uskon, että tämän kentän on oltava pakollinen julkaistavaksi npm.orgissa.

Miten se selvitetään

Monet tiimit alkavat miettiä lisenssejä, kun ohjelmisto on valmis toimitettavaksi. Olen käyttänyt tähän ScanCode-apuohjelmaa. Se tosiaan käy läpi projektisi jokaisen kansion ja yrittää havaita jokaisen lisenssin tai tekijänoikeuden.

Kuvakaappaus osoitteesta: https://github.com/nexB/scancode-toolkit

Valvottavasti joudut käyttämään kyseistä tai muuta vastaavaa työkalua, ennen kuin voit jakelussa levittää sovelluksesi. Varmista, että tarkistat tarpeeksi etkä liikaa:

  • asenna kaikki tuotantoriippuvuudet ennen työkalun suorittamista
  • varmista, että työkalu ei tarkista devDependencies-rajoitteita; normaalisti et jakele kehitysriippuvuuksiesi kanssa;

Huomautus: jos minun laillani tarkastelet pakettien lisenssejä sen jälkeen, kun olet integroinut paketin sovellukseesi, saatat joutua hankalaan tilanteeseen.

Käynnistän ScanCoden juuri ennen deadlinea; kuva lähteestä https://giphy.com

Miten otat selvää, ennen kuin on liian myöhäistä

Minua mietityttääkin, milloin on paras aika perehtyä pakettien pakettiriippuvuuslisensseihin. Minulle normaali pakettien löytämisen kulku on:

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

Valitettavasti npm.org ei oikein käsittele transitiivisia riippuvuuksia. On olemassa verkkotyökaluja, kuten http://npm.anvaka.com/; mutta se ei sovi minun pakettien löytämisvirtaukseeni ja unohdan jatkuvasti käyttää sitä. Ajattelin, että paras hetki oppia pakettiriippuvuuksista on, kun kirjoitat $ npm install <pkg>

Se oli ajatukseni, kun rakensin CLI-työkalun nimeltä npm-consider, joka analysoi paketin kaikkine transitiivisine riippuvuuksineen ennen sen asentamista tai edes lataamista.

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

Säästääkseni yhden komennon säästääkseni, se kietoo $ npm installin ja sillä on samat argumentit. Jos olet sinut riippuvuuksien kanssa, valitse vain Install ja se suorittaa npm installin normaalisti. Jos olet huolissasi valitse Details ja näet koko riippuvuuspuun:

Näyttää yksityiskohtia, kun asennetaan suositun geospatiaalisen kirjaston komponentti Turf.js; huomaa, että itse paketilla on Permissive-lisenssi, mutta yhdellä siirtyvistä riippuvuuksista on AGPL-lisenssi; sitä ei voi oikeastaan käyttää proprietary-ohjelmistoihin;

Olen sitä mieltä, että tällaisen toiminnallisuuden on oltava osa npm CLI:tä. Jos olet samaa mieltä, ole hyvä ⭐️ projekti GitHubissa, niin vien ideaa eteenpäin.

Lähteet

Luettelen lähteeni siltä varalta, että haluat tuplatarkastaa johtopäätökseni:

  • Npm-riippuvuusmallin ymmärtäminen
  • Avoimen lähdekoodin lisensointi: What every technologist should know | Opensource.com
  • Various Licenses and Comments about Them
  • The Free-Libre / Open Source Software (FLOSS) License Slide
  • License Center | ifrOSS
  • Vapaiden ja avoimen lähdekoodin ohjelmistolisenssien vertailu – Wikipedia
  • Kirjasto (tietojenkäsittely) – Wikipedia

Jos artikkelista oli apua, kiitos 👏 ja ehkäpä kirjoitan vielä yhden 😀