Haftungsausschluss: Ich bin ein Entwickler, kein Anwalt; diese Informationen sind vermutlich korrekt, aber keine Rechtsberatung; wenn Sie denken, dass etwas falsch ist, schreiben Sie bitte einen Kommentar und wir werden es gemeinsam korrigieren🔧

Früher war ich nicht besorgt über die Lizenz von npm-Paketen. Ich konnte die Lizenz der unmittelbaren Abhängigkeit prüfen, aber nie die von Drittparteien (Übergangsabhängigkeiten).

🚓 Und dann traf ich Leute aus der Rechtsabteilung 🚓

Ich glaube jetzt, dass Entwickler ein grundlegendes Verständnis der Softwarelizenzierung haben sollten, um einen konstruktiven Dialog mit den Rechtsteams in ihren Unternehmen zu führen. Dieser Beitrag sammelt ein allgemeines Wissen über Open-Source-Lizenzen und wie es sich auf npm-Abhängigkeiten und Full-Stack-JavaScript-Entwicklung im Allgemeinen bezieht.

Lassen Sie uns herausfinden, wann Sie anfangen sollten, sich über Lizenzen Gedanken zu machen.

Wann werden Lizenzanforderungen ausgelöst?

Wenn Sie eine Verknüpfung mit Open-Source-Bibliotheken vornehmen und die daraus resultierende Software weitergeben, muss Ihre Software mit den Anforderungen der verknüpften Bibliotheken konform sein.

Lassen Sie uns die Verknüpfung und Weitergabe bei JavaScript-Anwendungen näher betrachten.

Verknüpfung

Die Verwendung von Bibliotheken von Drittanbietern bedeutet normalerweise, dass sie verlinkt werden:

  • Wenn Sie Ihren Code mit Open-Source-Paketen bündeln (z.B. mit Webpack), zählt dies als statische Verknüpfung
  • Wenn Sie Open-Source-Pakete in Ihrer Node.JS-App verwenden (z.B.. via require) oder verbinden Sie es mit einer Webseite via Skript-Tag, ist es dynamisches Linking

Hinweis: Wenn Sie ein Bundle erstellen oder eine Node.JS-Applikation ausführen, führen Sie die gleiche Art von Linking sowohl mit unmittelbaren (aufgelistet in Ihrer package.json) als auch mit transitiven (aufgelistet in der package.json eines Drittanbieters) Abhängigkeiten durch. Unmittelbare und transitive Abhängigkeitslizenzen haben den gleichen Effekt auf Ihre Software.

Das war mir vorher nicht klar 🤔

Distribution

Die Verwendung von Open-Source-Bibliotheken löst nicht unbedingt Lizenzanforderungen aus. Normalerweise werden Lizenzanforderungen ausgelöst, wenn Sie Software verteilen:

  • Die Übertragung von Software zwischen Mitarbeitern desselben Unternehmens ist keine Verteilung
  • Wenn Benutzer mit Ihrer Node.JS-App über das Netzwerk interagieren, ist das für die meisten Open-Source-Lizenzen keine Weitergabe; für netzwerkschützende Lizenzen wie AGPL ist es jedoch eine Weitergabe
  • Das Einstellen von JavaScript-Dateien auf einen öffentlichen Webserver ist eine Weitergabe

Welche Lizenz ist in Ordnung

Die meisten Open-Source-Lizenzen fallen im Allgemeinen in einen dieser Typen:

  • Public-Domain- und Permissive-Lizenzen wie MIT, die alles erlauben, außer den Autor zu verklagen
  • Copyleft- oder Schutzlizenzen wie GPL verhindern die Verknüpfung (siehe oben) mit proprietärer Software; der Grenzfall sind Netzwerkschutzlizenzen wie Affero GPLv3, die durch Interaktion über das Netzwerk ausgelöst werden;
  • Zwischen den beiden oben genannten liegen schwach schützende Lizenzen wie MPL, die weniger Einschränkungen für dynamisches Linken haben (bis die Bibliothek in einer eigenen Datei steht)

Lassen Sie uns die üblichen Szenarien für einen JavaScript-Entwickler überprüfen:

Sie erstellen eine Webanwendung

Wahrscheinlich bündeln Sie alle Ihre Dateien, einschließlich der Bibliotheken, in einer JS-Datei und legen sie auf einen Webserver. Sie führen statisches Linken und Verteilen durch. Es ist in Ordnung, Pakete mit permissiven Lizenzen in einem Bundle zu verwenden.

Wenn Sie ein Paket mit einer schwach schützenden Lizenz wie MPL verwenden müssen, haben Sie folgende Möglichkeiten:

  1. Laden Sie die Bibliothek aus einer separaten Datei (z.B.. über Skript-Tag)
  2. Wenden Sie eine kompatible Open-Source-Lizenz auf Ihr Paket an (aber prüfen Sie den Kommentar unten und sprechen Sie vorher mit Ihrer Rechtsabteilung)

Wenn Ihr Paket kein ✨wertvolles geistiges Eigentum✨ hat, dann sollte die zweite Option in Ordnung sein. Ich glaube nicht, dass Konkurrenten von Ihrem verschleierten Code profitieren werden. Aber wenn das Paket wertvolles geistiges Eigentum enthält, dann gewährt die Anwendung der Open-Source-Lizenz die freie Nutzung davon.

Sie machen eineNode.JS-App

In diesem Fall binden Sie normalerweise Bibliotheken über einen require()-Aufruf ein. Es ist ein dynamisches Linking. Es ist in Ordnung, Permissive und sogar Weakly Protective Lizenzen zu verwenden. Stellen Sie nur sicher, dass die Pakete in ihren eigenen Dateien mit den entsprechenden Lizenzen bleiben.

Wenn Sie nur SaaS anbieten und nicht auf andere Weise verteilen, können Sie sogar Pakete mit einer Schutzlizenz verwenden. Bei vielen Schutzlizenzen ist die Interaktion im Netzwerk keine Weitergabe. Die Ausnahme sind Netzwerk-Schutzlizenzen wie Affero GPLv3

Sie erstellen ein Open-Source-NPM-Paket

Normalerweise verbinden Sie Abhängigkeiten von Dritten über eine package.json. Soweit ich weiß, kann die Auflistung von Abhängigkeiten in package.json nicht als Verknüpfung betrachtet werden. Die Verknüpfung wird von einem App-Entwickler durchgeführt, der Ihr Paket in einer Build- oder Run-Phase verwendet.

Wenn Sie die Paketnutzer nicht verwirren wollen, stellen Sie sicher, dass alle Abhängigkeiten (sowohl unmittelbare als auch transitive) kompatible Lizenzen mit Ihrer Paketlizenz haben.

Typischerweise sollten die Lizenzen der Abhängigkeiten freizügiger oder genauso freizügig sein wie die Lizenz Ihres Pakets.

Wenn Ihr Paket zum Beispiel die Apache 2.0 Lizenz hat, können Sie Abhängigkeiten mit MIT und BSD Lizenz verwenden. Aber Sie sollten keine Abhängigkeiten mit MPL1.1 oder LGPLv3 Lizenz verwenden, da diese ein stärkeres Copyleft haben.

Ein Pfeil von Kästchen A zu Kästchen B bedeutet, dass man Software mit diesen Lizenzen kombinieren kann; das kombinierte Ergebnis hat effektiv die Lizenz von B, möglicherweise mit Ergänzungen von A; Bild aus der Arbeit von David A. Wheeler

Wenn Sie Bundles oder Quellen von Drittanbietern in ein NPM-Paket einbinden müssen, vergessen Sie nicht, die Lizenzen und Copyrights der Drittanbieter anzugeben. Die meisten Open-Source-Lizenzen verlangen die Nennung des Autors.

Es ist auch eine gute Praxis, einen gültigen SPDX-Ausdruck in der package.json-Lizenz anzugeben. Ich glaube, dass dieses Feld für die Veröffentlichung auf npm.org.

Wie man es herausfindet

Viele Teams fangen an, über Lizenzen nachzudenken, wenn die Software bereit zur Auslieferung ist. Ich habe dafür das Dienstprogramm ScanCode verwendet. Es geht wirklich in jeden Ordner deines Projekts und versucht, jede Lizenz oder jedes Copyright zu erkennen.

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

Dieses oder ein ähnliches Tool musst du wahrscheinlich verwenden, bevor du deine App verteilst. Stellen Sie sicher, dass Sie genug und nicht zu viel prüfen:

  • Installieren Sie alle Ihre Produktionsabhängigkeiten, bevor Sie das Tool ausführen
  • Stellen Sie sicher, dass devDependencies nicht vom Tool geprüft werden; normalerweise verteilen Sie nicht mit Ihren Entwicklungsabhängigkeiten;

Hinweis: Wenn Sie, wie ich, nach der Integration von Paketen in Ihre App nach Paketlizenzen suchen, könnten Sie sich in einer schwierigen Situation befinden.

Mit ScanCode kurz vor der Deadline; Bild aus https://giphy.com

Wie man es herausfindet, bevor es zu spät ist

Ich habe mich gefragt, wann der beste Zeitpunkt ist, um etwas über Paketabhängigkeitslizenzen zu erfahren. Für mich ist der normale Ablauf beim Entdecken von Paketen:

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

Leider geht npm.org nicht wirklich auf transitive Abhängigkeiten ein. Es gibt Webtools wie http://npm.anvaka.com/, aber es passt nicht in meinen Paketfindungsfluss und ich vergesse immer wieder, es zu benutzen. Ich dachte, der beste Moment, um etwas über Paketabhängigkeiten zu lernen, ist, wenn man $ npm install <pkg>

Das war mein Gedanke, als ich ein CLI-Tool namens npm-consider entwickelte, das Pakete mit allen transitiven Abhängigkeiten analysiert, bevor es installiert oder sogar heruntergeladen wird.

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

Um Ihnen einen Befehl zu ersparen, umhüllt es $ npm install und hat die gleichen Argumente. Wenn Sie mit den Abhängigkeiten einverstanden sind, wählen Sie einfach Install und es wird wie üblich npm install ausgeführt. Wenn Sie sich Sorgen machen, wählen Sie Details und sehen Sie den gesamten Abhängigkeitsbaum:

Anzeigen von Details bei der Installation einer Komponente der beliebten Geospatial-Bibliothek Turf.js; beachten Sie, dass das Paket selbst eine Permissive-Lizenz hat, aber eine der transitiven Abhängigkeiten hat eine AGPL-Lizenz; Sie können es nicht wirklich für proprietäre Software verwenden;

Ich glaube, dass solche Funktionalität Teil von npm CLI sein muss. Wenn du zustimmst, bitte ⭐️ Projekt auf GitHub und ich werde die Idee vorantreiben.

Quellen

Ich liste meine Quellen auf, falls du meine Schlussfolgerungen überprüfen willst:

  • Understanding the npm dependency model
  • Open source licensing: Was jeder Technologe wissen sollte | Opensource.com
  • Verschiedene Lizenzen und Kommentare dazu
  • Die Free-Libre / Open Source Software (FLOSS) Lizenz Folie
  • License Center | ifrOSS
  • Vergleich von freien und Open-Source-Softwarelizenzen – Wikipedia
  • Bibliothek (Computing) – Wikipedia

Wenn der Artikel hilfreich war, bitte 👏 und vielleicht schreibe ich noch einen 😀