Disclaimer: ik ben een ontwikkelaar, geen jurist; deze informatie wordt geacht correct te zijn, maar is geen juridisch advies; als je denkt dat iets niet correct is, schrijf dan een commentaar en we zullen het samen oplossen🔧

Voorheen was ik niet bezorgd over de licentie van npm package. Ik kon de licentie van de directe afhankelijkheid controleren, maar nooit die van de derde partij (overgangs) afhankelijkheden.

🚓 En toen ontmoette ik jongens van de juridische afdeling 🚓

Ik geloof nu dat ontwikkelaars een basiskennis van softwarelicenties moeten hebben om een constructieve dialoog met juridische teams in hun bedrijven te hebben. Deze post verzamelt een algemene kennis over Open-Source licenties en hoe het van toepassing is op npm afhankelijkheden en Full-Stack JavaScript ontwikkeling in het algemeen.

Laten we uitzoeken wanneer je moet beginnen je zorgen te maken over licenties.

Wanneer worden licentie-eisen getriggerd?

Als u een koppeling uitvoert met open source-bibliotheken en vervolgens de resulterende software distribueert, moet uw software voldoen aan de vereisten van gekoppelde bibliotheken.

Laten we het koppelen en distribueren eens nader bekijken, toegepast op JavaScript-apps.

Linking

Het gebruik van 3rd party libraries betekent normaal gesproken dat ze gekoppeld moeten worden:

  • Als u uw code bundelt (d.w.z. met webpack) met open source packages telt dit als static linking
  • Als u open source packages gebruikt in uw Node.JS app (d.w.z. via require) of verbindt het met een webpagina via script tag, is het dynamisch linken

Note: bij het bouwen van een bundel of het draaien van Node.JS app voer je hetzelfde type linking uit met zowel immediate (vermeld in je package.json) als transitive (vermeld in 3rd party package.json) dependencies. Onmiddellijke en transitieve afhankelijkheden licenties hebben hetzelfde effect op uw software.

Dit was niet intuïtief voor mij voordat 🤔

Distributie

Het gebruik van open source bibliotheken hoeft niet noodzakelijkerwijs leiden tot licentie-eisen. Normaal gesproken worden licentievereisten geactiveerd wanneer u software distribueert:

  • Het overdragen van software tussen werknemers van hetzelfde bedrijf is geen distributie
  • Wanneer gebruikers via een netwerk communiceren met uw Node.JS app over het netwerk, is het geen distributie voor de meeste open source licenties; maar het is een distributie voor Network Protective licenties zoals AGPL
  • Het plaatsen van JavaScript bestanden op een publieke webserver is een distributie

Welke licentie is ok

De meeste open source licenties vallen over het algemeen in een van deze types:

  • Public Domain en Permissive licenties zoals MIT die je alles toestaan behalve de auteur aanklagen
  • Copyleft of Protective licenties zoals GPL verhinderen het linken (zie boven) met proprietary software; het randgeval is Network Protective licenties zoals Affero GPLv3 die triggert door interactie over netwerk;
  • Daartussenin zitten zwak beschermende licenties zoals MPL die minder beperkingen hebben voor dynamisch linken (totdat de bibliotheek in een eigen bestand staat)

Laten we eens kijken naar veel voorkomende scenario’s voor een JavaScript ontwikkelaar:

U maakt een web app

Waarschijnlijk bundelt u al uw bestanden, inclusief bibliotheken in één JS-bestand en zet dat op een webserver. U voert statische koppeling en distributie uit. Het is prima om pakketten met Permissive-licenties in een bundel te gebruiken.

Als u een pakket met een zwak beschermende licentie zoals MPL moet gebruiken, hebt u opties:

  1. Laad de bibliotheek vanuit een apart bestand (d.w.z. via script tag)
  2. Gebruik een compatibele open source licentie voor uw bundel (maar controleer commentaar hieronder en praat eerst met uw juridische team)

Als uw bundel geen ✨waardevol intellectueel eigendom✨ heeft, dan zou de tweede prima moeten zijn. Ik geloof niet dat concurrenten zullen profiteren van uw versluierde code. Maar als de bundel wel waardevol intellectueel eigendom bevat, dan is het toepassen van een open source licentie een vrij gebruik ervan.

U maakt eenNode.JS app

In dit geval verbindt u normaal gesproken bibliotheken via een require() call. Het is een dynamische koppeling. Het is prima om Permissive en zelfs Weakly Protective licenties te gebruiken. Zorg er alleen voor dat pakketten in hun eigen bestanden blijven met de respectievelijke licenties.

Als je alleen SaaS aanbiedt en je distribueert niet op een andere manier, dan kun je zelfs pakketten met een Protective licentie gebruiken. Voor veel Protective-licenties geldt dat interactie met het netwerk geen distributie is. De uitzondering hierop zijn Netwerk Protective licenties zoals Affero GPLv3

U maakt een Open Source NPM pakket

Normaal gesproken verbindt u 3rd party dependencies via een package.json. Voor zover ik weet, kan het vermelden van afhankelijkheden in package.json niet worden beschouwd als linken. Koppelen wordt uitgevoerd door een app-ontwikkelaar die uw pakket zal gebruiken in een build- of run-fase.

Als u pakketgebruikers niet wilt verwarren, zorg er dan voor dat alle afhankelijkheden (zowel onmiddellijke als transitieve) compatibele licenties hebben met uw pakketlicentie.

Typisch gezien zouden afhankelijkheidslicenties toleranter moeten zijn of hetzelfde niveau van tolerantie moeten hebben als je pakketlicentie.

Bijv. als je pakket licentie Apache 2.0 heeft, kun je afhankelijkheden gebruiken met MIT en BSD licentie. Maar je moet niet gebruiken afhankelijkheden met MPL1.1 of LGPLv3 licentie, omdat ze hebben sterkere auteursplicht.

Een pijl van vakje A naar vakje B betekent dat u software met deze licenties kunt combineren; het gecombineerde resultaat heeft in feite de licentie van B, eventueel met toevoegingen van A; afbeelding uit het werk van David A. Wheeler

Wanneer je bundels of broncodes van derde partijen in NPM-pakketten moet stoppen, vergeet dan niet om de licenties en copyrights van derde partijen op te sommen. De meeste open source-licenties vereisen erkenning van de auteur.

Ook is het een goed gebruik om een geldige SPDX-expressie op te geven in je package.json-licentie. Ik geloof dat dit veld verplicht moet zijn voor publicatie op npm.org.

Hoe je het uitzoekt

Veel teams beginnen na te denken over licenties als de software klaar is om te verzenden. Ik heb het ScanCode hulpprogramma hiervoor gebruikt. Het gaat echt naar elke map van je project en probeert elke licentie of copyright te detecteren.

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

Je moet waarschijnlijk deze of een vergelijkbare tool gebruiken voordat je je app distribueert. Zorg ervoor dat u voldoende controleert en niet te veel:

  • Installeer al uw productie-afhankelijkheden voordat u de tool uitvoert
  • Zorg ervoor dat devDependencies niet door de tool worden gecontroleerd; normaal gesproken distribueert u niet met uw ontwikkelingsafhankelijkheden;

Note: als u, zoals ik, naar pakketlicenties kijkt nadat u het pakket in uw app hebt geïntegreerd, kunt u in een lastige situatie terechtkomen.

ScanCode uitvoeren vlak voor deadline; afbeelding uit https://giphy.com

Hoe kom je erachter voor het te laat is

Ik vroeg me af wanneer het beste moment is om je te verdiepen in pakketafhankelijke licenties. Voor mij is de normale stroom van het ontdekken van pakketten:

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

Helaas pakt npm.org transitieve afhankelijkheden niet echt aan. Er zijn webtools zoals http://npm.anvaka.com/; maar het past niet in mijn package discovery flow en ik vergeet steeds om het te gebruiken. Ik dacht dat het beste moment om te leren over pakketafhankelijkheden is wanneer je $ npm install <pkg>

Dat was mijn gedachte toen ik een CLI-tool genaamd npm-consider bouwde die pakketten met alle transitieve afhankelijkheden analyseert voordat je het installeert of zelfs downloadt.

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

Om je een commando uit te sparen, het wrapped $ npm install en heeft dezelfde argumenten. Als je geen problemen hebt met afhankelijkheden, kies dan Install en het zal npm install zoals gewoonlijk uitvoeren. Als u zich zorgen maakt, kiest u Details en ziet u de hele afhankelijkheidsstructuur:

Toont details bij het installeren van component van populaire geospatiale bibliotheek Turf.js; merk op dat het pakket zelf een Permissive-licentie heeft, maar dat een van de transitieve afhankelijkheden een AGPL-licentie heeft; je kunt het niet echt gebruiken voor propriëtaire software;

Ik ben van mening dat een dergelijke functionaliteit onderdeel moet zijn van npm CLI. Als u het ermee eens bent, ⭐️ project op GitHub en ik zal het idee vooruit duwen.

Bronnen

Ik vermeld mijn bronnen voor het geval u mijn conclusies wilt dubbelchecken:

  • Inzicht in het npm-afhankelijkheidsmodel
  • Open source-licenties: Wat elke technoloog zou moeten weten | Opensource.com
  • Various Licenses and Comments about Them
  • The Free-Libre / Open Source Software (FLOSS) License Slide
  • License Center | ifrOSS
  • Comparison of free and open-source software licenses – Wikipedia
  • Library (computing) – Wikipedia

Als het artikel nuttig was, graag 👏 en misschien schrijf ik er nog een 😀