Über 10 % der Python-Pakete auf PyPI werden ohne Lizenz veröffentlicht

Stellen Sie sich vor, Sie installieren ein beliebiges Python-Paket von PyPI. Mit einer Wahrscheinlichkeit von 13,5 % enthält das Paket keine Lizenzangaben. Da eine typische Python-Anwendung nicht selten Hunderte Abhängigkeiten und Unterabhängigkeiten umfasst, ist die Wahrscheinlichkeit sehr hoch, dass Sie nicht lizenzierte Code verwenden. Je nach Kontext können die Folgen der Verwendung nicht lizenzierter Software von unbedeutend bis katastrophal reichen. Zugegeben, das ist eine große Spannbreite. Deshalb gehen wir in diesem Beitrag näher auf das Thema ein.

Was ist PyPI?

PyPI ist das am häufigsten genutzte zentrale Repository für Python-Pakete und wird von der Python Software Foundation erstellt und gepflegt. Der Zugriff erfolgt üblicherweise über Paketverwaltungstools wie pip, mit denen Python-Bibliotheken und -Apps heruntergeladen und installiert werden. Vergleichbare Paket-Repositories gibt es auch für andere Programmiersprachen, etwa npm für Javascript, RubyGems.org für Ruby und crates.io für Rust.

Hintergrund

Snyk analysiert die Abhängigkeiten von Softwareprojekten und findet Probleme wie Sicherheitslücken und ungünstige Lizenzen. Zu diesem Zweck wurde ich kürzlich damit beauftragt, sämtliche Metadaten zu Paketen und veröffentlichten Versionen von PyPI abzurufen, einschließlich der Lizenzangaben. Auf Grundlage dieser Daten habe ich die Lizenzsituation aller Python-Pakete auf PyPI untersucht.

Im Folgenden finden Sie einige zentrale Erkenntnisse aus dieser Analyse, Empfehlungen dazu und eine Beschreibung der verwendeten Methoden.

Wie sieht die Lizenzsituation im Python-Ökosystem aus?

Zunächst ein kurzer Haftungsausschluss: Ich bin kein Anwalt. Ich bin ein erfahrener Softwareentwickler mit einem gewissen Verständnis für Softwarelizenzen, aber kein Experte auf diesem Gebiet. Die folgenden Ausführungen stellen keine Rechtsberatung dar. Wenn Sie eine solche benötigen, sollten Sie sich an einen Anwalt wenden!

Lizenztypen

Grundsätzlich lassen sich fast alle Open-Source-Softwarelizenzen in einige wenige übergeordnete Kategorien einteilen:

• Die „Copyleft“-Lizenzen sind vergleichsweise restriktiv. Dazu gehören die bekannte GPL-Lizenz, ihre zahlreichen Varianten und ähnliche Lizenzen. Sie erlauben die Nutzung der Software für praktisch jeden Zweck, verlangen aber, dass alle von Ihnen vorgenommenen Änderungen ebenfalls öffentlich zugänglich gemacht werden. Darüber hinaus fordern einige der „stärkeren“ Copyleft-Lizenzen unter bestimmten Umständen, dass auch Code, der solche lizenzierte Software nutzt, öffentlich zugänglich gemacht wird.

• Die „permissiven“ Lizenzen hingegen erlauben es, die Software zu ändern, ohne diese Änderungen veröffentlichen zu müssen. Zudem sind sie in der Regel deutlich einfacher und enthalten weniger Einschränkungen.

• Am anderen Ende des Spektrums stehen „Public-Domain“-Lizenzen, die der Nutzung im Allgemeinen keinerlei Einschränkungen auferlegen.

Weitere Informationen zu Copyleft- und permissiven Lizenzen finden Sie in einem früheren Beitrag zu diesem Thema in unserem Blog.

In den letzten Jahren sind mehrere „schwache Copyleft“-Lizenzen entstanden. Sie sind vor allem für Softwarebibliotheken gedacht und ermöglichen deren Nutzung mit weniger oder gar keinen Einschränkungen für die Software, die sie verwendet. Weitere Informationen zum Unterschied zwischen „schwachem“ und „starkem“ Copyleft finden Sie im entsprechenden Abschnitt des Wikipedia-Artikels.

Es ist auch möglich, wenn auch nicht empfehlenswert, keine Lizenz anzugeben. Meistens geschieht das aus Versehen oder Unkenntnis, in einigen seltenen Fällen jedoch absichtlich. Ohne Lizenz unterliegt die Nutzung der Software einfach dem Urheberrecht (des jeweiligen Landes!) sowie anderen Rechtsgebieten wie dem Patentrecht.

Aufschlüsselung der Lizenztypen

Sehen wir uns die auf PyPI verwendeten Lizenztypen an:

Aus diesen Daten geht Folgendes hervor:

• Die meisten Pakete auf PyPI, 64 %, stehen unter einer „permissiven“ Lizenz, etwa MIT, Apache 2.0 oder einer BSD-Lizenz mit 2 oder 3 Klauseln.

• 18,5 % stehen unter einer „starken Copyleft“-Lizenz wie GPL oder AGPL.

• 3 % stehen unter einer „schwachen Copyleft“-Lizenz wie LGPL oder MPL.

• Nur 1 % stehen unter einer „Public-Domain“-Lizenz wie CC0, WTFPL oder Unlicense.

• 13,5 % enthalten keinerlei Lizenzangaben.

Das ist nicht überraschend, denn ähnliche Trends sind auch auf GitHub und in Paket-Repositories für andere Programmiersprachen zu beobachten.

Die häufigsten Lizenzen für Python-Pakete

Vier Lizenzen prägen PyPI: MIT, BSD-2-Clause, GPL-3.0 und Apache-2.0.

Auch viele andere Lizenzen sind weit verbreitet (sie werden von mindestens 100 Paketen verwendet). Zwei davon sind einzigartig für das Python-Ökosystem: die Python Software Foundation License (PSF) und die Zope Public License (ZPL).

Was Sie JETZT tun sollten!

Angesichts der Lizenzsituation bei Python-Paketen auf PyPI empfehle ich dringend Folgendes:

• Prüfen Sie, ob Sie direkt oder indirekt Software verwenden, die unter „Copyleft“-Lizenzen steht, und stellen Sie sicher, dass Ihnen die Auswirkungen auf Ihren Code bewusst sind.

  1. Wenn Sie proprietären Code (also keinen Open-Source-Code) schreiben, kann dies erhebliche rechtliche Risiken mit sich bringen – insbesondere bei den „starken Copyleft“-Lizenzen, unter denen mehr als 18 % der PyPI-Pakete stehen.

  2. Wenn Sie Open-Source-Software entwickeln, könnte das bedeuten, dass Sie Ihren Code unter ähnlichen Lizenzbedingungen veröffentlichen müssen.

• Prüfen Sie, ob bei einer Ihrer Abhängigkeiten die Lizenz fehlt.

  1. Wenn Sie eine solche Abhängigkeit ändern müssen oder dies vielleicht in Zukunft tun müssen, ist das nach dem Urheberrecht möglicherweise nicht zulässig.

  2. Wahrscheinlich wird in künftigen Versionen solcher Abhängigkeiten eine Lizenz ergänzt. Welcher Lizenztyp das sein wird, lässt sich nicht sicher vorhersagen.

• Richten Sie ein automatisiertes Tool ein, das die Lizenzen Ihrer Abhängigkeiten regelmäßig oder kontinuierlich überprüft.

  1. Im Laufe eines Projekts werden häufig Abhängigkeiten hinzugefügt und geändert.

  2. Abhängigkeiten können ihre Lizenz zwischen Versionen ändern. Ein Versions-Upgrade kann daher auch eine Lizenzänderung mit sich bringen.

Weiterführende Informationen

Wir haben das Thema gerade erst angerissen. Lizenzen könnten wichtiger für Sie sein, als Sie denken – informieren Sie sich also ausführlicher! Empfehlenswert sind unter anderem folgende Themen:

• Mehrfachlizenzierung (etwa 500 Pakete auf PyPI stehen unter mehreren Lizenzen)

• Lizenzkompatibilität

• Software ohne Lizenz

• Überblick über und Erläuterung der gängigen permissiven Lizenzen

• Die rechtliche Seite von Open Source, insbesondere der Abschnitt zur Auswahl einer Lizenz für Ihre Software.

Methodik

Hier finden Sie einige Details zur Datenerhebung und Analyse.

Zunächst habe ich die Metadaten aller Pakete und aller ihrer veröffentlichten Versionen auf PyPI gesammelt. Die Erhebung erfolgte über mehrere Tage Anfang August 2018. Damals gab es auf PyPI fast 150.000 Pakete.

Anschließend habe ich für jede Version jedes Pakets die Lizenzangaben aus den Feldern „license“ und „classifiers“ extrahiert. Diese habe ich in einer einzigen Datenstruktur zusammengeführt und die Versionen nach einer Auslegung gemäß semantischer Versionierung sortiert.

Als Nächstes habe ich die Lizenzdaten bereinigt und normalisiert. Dabei habe ich auf einer bei Snyk verwendeten Version eines SPDX-Lizenz-Normalisierers aufgebaut. Ich habe den Normalisierer schrittweise verbessert, damit er einen größeren Anteil der Lizenzen korrekt erkennt, und anschließend manuell eine umfangreiche Zuordnungstabelle für die vielen Sonderfälle erstellt.

Danach habe ich die 18 % der Pakete ohne Lizenz untersucht. Zu diesem Zeitpunkt hatte ich mir die Dateien in den jeweiligen Releases noch nicht angesehen. Ich wählte nach dem Zufallsprinzip 50 Pakete ohne Lizenz aus, lud deren neueste Releases herunter und suchte nach Lizenzangaben. Nach dieser Recherche teilte ich die Pakete in fünf Kategorien ein:

Nur die Pakete in der Kategorie „Licensed“ haben tatsächlich eine Lizenz. Die meisten Pakete in den Kategorien „training“, „throwaway“ und „placeholder“ enthielten jedoch Code und könnten durchaus als Abhängigkeit verwendet werden – absichtlich oder versehentlich (etwa aufgrund eines Tippfehlers). Daher hielt ich es für angemessen, diese als echte Pakete ohne Lizenz zu betrachten. Ausgehend von dieser Stichprobe schätzte ich, dass etwa 18 % × 72 % = 13,5 % der PyPI-Pakete keine Lizenz haben.

Es ist erwähnenswert, dass ich keine vergleichbare Analyse für lizenzierte Pakete auf PyPI durchgeführt habe. Wahrscheinlich gibt es viele „training“-, „throwaway“- und „placeholder“-Pakete, die eine Lizenz angeben. Daher wäre die Annahme, dass nur etwa 18 % × 28 % = 5 % der „echten“ PyPI-Pakete keine Lizenz haben, als konservative Schätzung vermutlich stark unzutreffend. Leider hatte ich keine Zeit für eine solche Analyse und habe mich daher auf die oben beschriebene Untersuchung beschränkt.

Wenn Sie Fragen oder Anmerkungen haben, freue ich mich, von Ihnen zu hören! Schreiben Sie mir auf Twitter unter @taleinat.