Dienstag war kein guter Tag für die JavaScript-Welt. Denn so manch Entwickler staunte nicht schlecht, als sich sein JavaScript-Projekt nicht mehr zusammenbauen ließ. Grund dafür: Eine kleine JavaScript-Bibliothek namens left-pad wurde vom Autor aus dem Node Package Manager gelöscht.
Was ist NPM?
Der Node Package Manager (NPM) wurde einst für die JavaScript-Umgebung node.js ins Leben gerufen und ist ein System, bei dem JavaScript-Entwickler ihre Open Source-Bibliotheken registrieren können. Einmal auf NPM, können dann andere Entwickler diese Bibliotheken relativ einfach für eigene Projekte nutzen. Und weil NPM so praktisch ist, wird es inzwischen nicht nur für node.js-Projekte auf dem Server, sondern auch für die JavaScript-Entwicklung im Browser eingesetzt.
Eines dieser Pakete auf NPM war das Paket left-pad, was im Prinzip nicht mehr ist als ein 11-zeiliger Code-Schnipsel ist. Ein Schnipsel allerdings, den scheinbar viele Programmierer brauchten und deshalb in ihrer eigenen Bibliotheken via NPM eingebunden haben, die dann wieder in größeren Anwendungen genutzt werden. So kommen tausende von Projekten zustande, die direkt oder indirekt von left-pad abhängen.
Als nun left-pad Anfang der Woche plötzlich vom Autor aus NPM gelöscht wurde, brach daher das Chaos in der JavaScript-Community aus.
Am Anfang war ein Markenstreit
Doch wie kam es eigentlich dazu? Der Grund ist ein Streit zwischen dem Messenger Kik und Azer Koçulu, dem Autor von left-pad und einem Paket namens „kik„. Letzteres, so befand der Messenger Kik, könnte Verwirrung auslösen, da sie selbst auch planten, eine Open Source-Bibliothek zu veröffentlichen. Sie schrieben daher an Azer und baten ihn, auch aufgrund von Trademark-Regelungen, sein Paket umzubenennen. Doch Azer Koçulu verneinte.
Kik wandte sich dann an NPM Inc., die Firma, die das NPM-Repository hostet. Wie NPM Inc.-Mitgründer Isaac Z. Schlueter hier erklärt, haben sie daraufhin ihre Package Name Dispute Policy bemüht und auf dieser Grundlage entschieden, den Paketnamen dem Messenger zukommen zu lassen.
Azer Koçulu wollte das nicht auf sich sitzen lassen und hat all seine 273 Pakete von NPM entfernt, weil er meinte, dass NPM privates Land sei und er ja Open Source mache, um die „Macht dem Volke“ zu geben und eben nicht Firmen wie NPM Inc. oder Kik.
Das Resultat dieser Entscheidung war, wie gesagt, verheerend und das Problem wurde erst durch die Wiederveröffentlichung von left-pad durch einen anderen Autor gelöst (denn wenn ein Paket entfernt wird, wird der Name auch wieder frei).
Hat NPM Inc. richtig gehandelt?
In seinem Blogpost stellt Isaac nochmal seine Sicht der Dinge klar, nämlich dass
- es bei der Entscheidung nicht um das Markenrecht ging, sondern rein nach der Dispute Resolution gehandelt wurde.
- NPM das Paket left-pad nicht gestohlen habe, da die Lizenz des Pakets ausdrücklich eine Wiederveröffentlichung erlaubt
- sowohl Kik ihre neue Bibliothek hätten veröffentlichen können als auch Benutzer des alten kik-Pakets keine Beeinträchtigungen erfahren hätten, wenn Azer nichts getan hätte
Im Endeffekt besagt die Dispute Policy aber nur, dass NPM Inc. selbst eine Entscheidung fällt, wenn beide Parteien nicht innerhalb von ca. 4 Wochen zu einer eigenen Einigung kommen. Nach welchen Kriterien dann aber genau entschieden wird, ist dort leider nicht festgehalten. Das könnte man vielleicht noch verbessern oder zumindest im Nachhinein dokumentieren.
Eines aber lernt NPM aus diesem Debakel: Die Möglichkeit, einfach all seine Pakete aus dem Index zu nehmen, ist eine schlechte Idee. Hier wird also wahrscheinlich demnächst nachgebessert werden.
Meines Erachtens gibt es aber noch ein weiteres Problem: Man kann ein neues Paket unter gleichem Namen hochladen, wenn der Autor das alte Paket gelöscht hat. Wenn es sich bei dem neuen Paket um Malware handelt und ein Entwickler nicht aufpasst, hat man plötzlich eine Sicherheitslücke im eigenen Projekt. Auch hier sollte man vielleicht noch nachbessern.
Was die Aufstellung von NPM als private Firma betrifft, kann man ebenfalls Bauchschmerzen haben. Das Python-Pendant PyPI z.B. wird von der Python Software Foundation betrieben (war vorher aber auch in privater Hand, wenn ich mich recht erinnere). Das gibt der Community zumindest theoretisch mehr Mitspracherecht.
Hat Kik richtig gehandelt?
Trademark ist natürlich Trademark und auch wenn ich kein Anwalt bin, so weiß ich doch, dass man ein Trademark auch verteidigen muss. Denn sonst verliert man die Marke. So kann man das auch in diesem Fall sehen und Mike Roberts von Kik schreibt das ja auch genau so in einer Mail an Azer. Ob die Anfrage allerdings jetzt so freundlich formuliert ist, wie er meint, sei mal dahingestellt:
We don’t mean to be a dick about it, but it’s a registered Trademark in most countries around the world and if you actually release an open source project called kik, our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that — and we’d have no choice but to do all that because you have to enforce trademarks or you lose them.
Das hätte man sicher auch anders formulieren können, wobei aber auch Azer nicht gerade kompromissbereit war:
Sorry, I’m building an open source project with that name.
Mit ein bisschen mehr Wohlwollen von beiden Seiten hätte man die Situation sicherlich verhindern können.
Eine Frage, die sich mir allerdings noch stellt (bin ja kein Anwalt): Wie problematisch ist es für eine Marke, wenn eine Open Source-Bibliothek den gleichen Namen trägt? Schliesslich gibt es ja auch Bibliotheken, die z.B. die Twitter-API nutzen und „twitter“ heissen, aber nicht von Twitter veröffentlicht worden sind. Oder wie in diesem Fall, wo sich „kik“ ja mehr an „Kickstarter“ anlehnt und etwas ganz anderes macht als einen Messenger-Dienst zu implementieren.
Was lernt die JavaScript-Community daraus?
Interessanterweise führt dieser Vorfall zu viel weitreichenderen Diskussionen als nur NPM in der JavaScript-Welt. Da geht es dann nämlich plötzlich um das Paket left-pad selbst, das ja aus nur 11 Zeilen besteht. So fragt sich David Haney, wieso dazu überhaupt eine Bibliothek genutzt werden muss. Man hätte das ja als Entwickler auch schnell selbst implementieren können. Er analysierte daraufhin auch noch weitere Projekte auf NPM und fand solche, die aus nur 4 Zeilen oder gar nur 1 Zeile Code bestehen. Der 1-Zeiler hat dabei fast 1 Million Downloads pro Tag.
Er fragt daher, ob man denn verlernt habe zu programmieren oder ob man es als Job eines Entwicklers ansehe, die kleinstmögliche Anzahl von Code-Zeilen selbst geschrieben zu haben. Eine wilde Diskussion auf Hacker News ist die Folge.
Go- und JavaScript-Programmierer Felix Geisendörfer sieht allerdings nicht die Entwickler selbst als die Schuldigen an, sondern die Entscheidung von node.js, eine möglichst kleine Standard-Library haben zu wollen. Unix-Ansatz halt. Wäre ein left-pad standardmäßig dabei, wäre ja eine solche Abhängigkeit gar nicht nötig.
Und auch ECMAScript (sozusagen der offizielle Name von JavaScript) sei Teil des Problems, denn die kommen ja mit überhaupt keiner Standard-Library daher (stimmt nicht so ganz, aber es ist wenig und fest in die Sprache integriert). Historisch bedingt ist das auch kein Wunder, war sie doch zunächst nur als kleine Browser-Sprache konzipiert. Hätte man aber natürlich inzwischen ändern können.
Oh, and perhaps it would be even better if this challenge was picked up our #ecma overloards. They're the ultimative origin of no stdlib.
— Felix Geisendörfer (@felixge) March 24, 2016
Laut Antworten auf seinen Tweet sind aber sowohl node.js als auch ECMAScript dabei, selbst ein leftpad nativ zu implementieren. Insofern würde zumindest diese Abhängigkeit in Zukunft nicht mehr nötig sein.
Beim aktuellen Fall hätte dies geholfen, aber es gibt bestimmt noch weitere populäre Pakete, die vielleicht nicht ganz so klein sind, aber bei Löschung eine ähnliche Auswirkung hätten.
Das aktuelle Problem ist gelöst, aber die Diskussionen halten noch an. Und dass ein eher kleiner Markenstreit solche Auswirkung hat, hätte ich auch nicht gedacht. Aber manchmal braucht es vielleicht ein Gewitter, damit man danach klarer sehen kann.