Disclaimer: fejlesztő vagyok, nem jogász; ezeket az információkat helyesnek tartom, de nem jogi tanácsadás; ha úgy gondolod, hogy valami helytelen, kérlek, írj egy megjegyzést, és együtt kijavítjuk🔧

Korábban nem foglalkoztam az npm csomag licencével. A közvetlen függőségek licencét tudtam ellenőrizni, de a harmadik féltől származó (átmeneti) függőségeket soha nem ellenőriztem.

🚓 Aztán találkoztam a jogi osztályon dolgozó srácokkal 🚓

Most úgy gondolom, hogy a fejlesztőknek alapvető ismeretekkel kell rendelkezniük a szoftverlicencekről, hogy konstruktív párbeszédet folytathassanak a cégük jogi csapatával. Ez a bejegyzés összegyűjti az általános ismereteket a nyílt forráskódú licencekről, és arról, hogy ez hogyan vonatkozik az npm függőségekre és általában a Full-Stack JavaScript fejlesztésre.

Lássuk, mikor kell elkezdeni aggódni a licencek miatt.

Mikor lépnek életbe a licenckövetelmények?

Ha nyílt forráskódú könyvtárakkal végzi a linkelést, majd az így kapott szoftvert terjeszti, akkor a szoftverének meg kell felelnie a linkelt könyvtárakra vonatkozó követelményeknek.

Nézzük meg közelebbről a JavaScript-alkalmazásokra alkalmazott linkelést és terjesztést.

Linkelés

A harmadik féltől származó könyvtárak használata általában azok linkelését jelenti:

  • Ha nyílt forrású csomagokkal csomagolja (pl. webpackkel) a kódját, az statikus linkelésnek számít
  • Ha nyílt forrású csomagot használ a Node.JS alkalmazásában (pl. require segítségével) vagy egy weblaphoz kapcsolod script taggel, az dinamikus linkelésnek számít

Megjegyzés: amikor egy csomagot építesz vagy Node.JS alkalmazást futtatsz, ugyanolyan típusú linkelést végzel mind az azonnali (a package.json-ban felsorolt), mind a tranzitív (a 3rd party package.json-ban felsorolt) függőségekkel. Az azonnali és tranzitív függőségi licencek ugyanolyan hatással vannak a szoftveredre.

Ez korábban nem volt intuitív számomra 🤔

Disztribúció

A nyílt forráskódú könyvtárak használata nem feltétlenül vált ki licenckövetelményeket. Normális esetben a licenckövetelményeket akkor váltja ki, ha szoftvereket terjeszt:

  • A szoftverek átadása ugyanazon vállalat alkalmazottai között nem minősül terjesztésnek
  • Ha a felhasználók interakcióba lépnek a Node.JS alkalmazással hálózaton keresztül, az nem terjesztés a legtöbb nyílt forráskódú licenc esetében; de terjesztésnek minősül az olyan hálózatvédő licencek esetében, mint az AGPL
  • A JavaScript fájlok nyilvános webszerverre helyezése terjesztés

Melyik licenc oké

A legtöbb nyílt forráskódú licenc általában az alábbi típusok egyikébe esik:

  • Public Domain és Permissive licencek, mint a MIT, amelyek bármit megengednek, kivéve, hogy bepereljük a szerzőt
  • Copyleft vagy Protective licencek, mint a GPL, megakadályozzák a tulajdonosi szoftverekkel való összekapcsolást (lásd fent); a szélsőséges eset a Network Protective licencek, mint az Affero GPLv3, amelyek a hálózaton keresztüli interakcióval váltják ki;
  • A fenti kettő között vannak a gyengén védett licencek, mint az MPL, amelyek kevésbé korlátozzák a dinamikus linkelést (amíg a könyvtár saját fájlban van)

Nézzük meg a JavaScript-fejlesztő számára gyakori forgatókönyveket:

Egy webes alkalmazást készítesz

Nagy valószínűséggel az összes fájlt, beleértve a könyvtárakat is, egy JS fájlba csomagolod és felteszed a webszerverre. Statikus linkelést és terjesztést végzel. Rendben van, ha megengedő licenccel rendelkező csomagokat használsz egy csomagban.

Ha gyengén védett licenccel rendelkező csomagot kell használnod, mint például az MPL, akkor vannak lehetőségeid:

  1. Letöltöd a könyvtárat külön fájlból (pl. via script tag)
  2. Kompatibilis nyílt forráskódú licencet alkalmazz a csomagodra (de nézd meg az alábbi megjegyzést, és előtte beszélj a jogi csapatoddal)

Ha a csomagodnak nincs ✨értékes szellemi tulajdona✨, akkor a másodiknak jónak kell lennie. Nem hiszem, hogy a versenytársak hasznot húznak az elhomályosított kódodból. De ha a csomag értékes szellemi tulajdont tartalmaz, akkor a nyílt forráskódú licenc alkalmazása biztosítja annak szabad használatát.

EgyNode.JS alkalmazást készítesz

Ez esetben általában a könyvtárakat require() hívással kapcsolod be. Ez egy dinamikus összekapcsolás. Permissive és még Weakly Protective licenceket is nyugodtan használhatsz. Csak győződjön meg róla, hogy a csomagok a saját fájljaikban maradnak a megfelelő licencekkel.

Ha csak SaaS szolgáltatást nyújt, és semmilyen más módon nem terjeszti, akkor akár Protective licencű csomagokat is használhat. Sok Protective licenc esetében a hálózati interakció nem terjesztés. Kivételt képeznek a Network Protective licencek, mint például az Affero GPLv3

Egy nyílt forráskódú NPM csomagot készítesz

Normális esetben a harmadik fél függőségeit egy package.json-on keresztül csatlakoztatod. Legjobb tudomásom szerint a függőségek felsorolása a package.jsonban nem tekinthető összekapcsolásnak. Az összekapcsolást egy alkalmazásfejlesztő végzi, aki a csomagodat fogja használni a build vagy run szakaszban.

Ha nem akarod összezavarni a csomag felhasználóit, győződj meg róla, hogy minden függőség (közvetlen és tranzitív) kompatibilis licenccel rendelkezik a csomagod licencével.

Tipikusan a függőségi licenceknek megengedőbbnek vagy ugyanolyan megengedőnek kell lenniük, mint a csomag licencének.

Ha például a csomagjának Apache 2.0 licenc van, akkor használhat MIT és BSD licenccel rendelkező függőségeket is. De nem szabad MPL1.1 vagy LGPLv3 licenccel rendelkező függőséget használni, mert ezek erősebb copyleft-tel rendelkeznek.

Az A dobozból a B dobozba mutató nyíl azt jelenti, hogy ezekkel a licencekkel rendelkező szoftverek kombinálhatók; a kombinált eredmény ténylegesen a B licencével rendelkezik, esetleg A-tól származó kiegészítésekkel; a kép David A munkájából származik. Wheeler

Ha csomagokat vagy harmadik féltől származó forrásokat kell NPM-csomagba helyeznie, ne felejtse el felsorolni a harmadik fél licenceit és szerzői jogait. A legtöbb nyílt forráskódú licenc megköveteli a szerző elismerését.

Ezeken kívül jó gyakorlat, ha a package.json licencben megad egy érvényes SPDX-kifejezést. Úgy vélem, ennek a mezőnek kötelezőnek kell lennie az npm.org-on való közzétételhez.

Hogyan találja ki

Néhány csapat akkor kezd el gondolkodni a licenceken, amikor a szoftver már készen áll a szállításra. Én a ScanCode segédprogramot használom erre. Ez tényleg végigmegy a projekted minden mappáján, és megpróbál felismerni minden licencet vagy szerzői jogot.

Screenshot from https://github.com/nexB/scancode-toolkit

Ezzel vagy hasonló eszközzel valószínűleg az alkalmazás terjesztése előtt kell dolgoznod. Győződj meg róla, hogy eleget és nem túl sokat ellenőrzöl:

  • installáld az összes termelési függőségedet az eszköz futtatása előtt
  • győződj meg róla, hogy a devDependencies-t nem ellenőrzi az eszköz; általában nem a fejlesztési függőségeiddel együtt terjeszted;

Megjegyzés: ha, mint én, azután nézel utána a csomaglicenceknek, miután integráltad a csomagot az alkalmazásodba, nehéz helyzetbe kerülhetsz.

A ScanCode futtatása közvetlenül a határidő előtt; kép a https://giphy.com

Hogyan találd ki, mielőtt túl késő lenne

Azt szeretném tudni, hogy mikor a legjobb idő a csomagfüggőségi licencek megismerésére. Számomra a csomagok felfedezésének normális folyamata a következő:

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

Sajnos az npm.org nem igazán foglalkozik a tranzitív függőségekkel. Vannak webes eszközök, mint a http://npm.anvaka.com/; de ez nem illik az én csomagfeltárási folyamatomhoz, és folyton elfelejtem használni. Úgy gondoltam, hogy a legjobb pillanat a csomagfüggőségek megismerésére az, amikor beírod a $ npm install <pkg>

Ez volt a gondolatom, amikor építettem egy npm-consider nevű CLI eszközt, amely elemzi a csomagot az összes tranzitív függőséggel, mielőtt telepítené vagy akár letöltené.

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

Hogy egy parancsot megspóroljak neked, ez a $ npm install-t csomagolja és ugyanazokkal az argumentumokkal rendelkezik. Ha nincs gondod a függőségekkel, csak válaszd az Install parancsot, és a szokásos módon lefuttatja az npm install-t. Ha aggódsz, válaszd a Details-t és lásd a teljes függőségi fát:

Showing details when installing component of popular geospatial library Turf.js; vegye figyelembe, hogy maga a csomag Permissive licenccel rendelkezik, de az egyik tranzitív függőség AGPL licenccel rendelkezik; nem igazán használhatja saját szoftverekhez;

Hiszem, hogy az ilyen funkciónak az npm CLI része kell, hogy legyen. Ha egyetértesz, kérlek ⭐️ projekt a GitHubon, és én előremozdítom az ötletet.

Források

Felsorolom a forrásaimat, ha esetleg kétszer is ellenőrizni szeretnéd a következtetéseimet:

  • Understanding the npm dependency model
  • Open source licensing: Amit minden technológusnak tudnia kell | Opensource.com
  • Változatos licencek és megjegyzések róluk
  • A szabad/nyílt forráskódú szoftverek (FLOSS) licencének diája
  • License Center | ifrOSS
  • Comparison of free and open-source software licences – Wikipedia
  • Library (computing) – Wikipedia

Ha a cikk hasznos volt, kérlek 👏 és lehet, hogy írok még egyet 😀