Lizenzkonformität Musikwissenschaft Open-Source

GPL lizenzierte LilyPond-Snippets — und ihre Nebenwirkungen

2019-10-29 / 2023-08-03 von Karsten Reincke | 2 Kommentare zu GPL lizenzierte LilyPond-Snippets — und ihre Nebenwirkungen

Dieser Artikel geht ungewollten Seiteneffekten nach: Er beschreibt, warum es suboptimal ist, GPL lizenzierte LilyPond-Snippets zu distribuieren, selbst wenn man — wie ich es tue — gerne Freie- und Open-Source-Software erstellt, verteilt und verwendet. Der Seiteneffekt ist überraschenderweise der Copyleft-Effekt der GPL:

[ de | en ]

Beginnen wir mit einigen hoffentlich unbestrittenen Punkten: Das Programm ‘LilyPond’ ist unter der GPLv3 lizenziert [⇒ 1]. Es will “schöne Noten erstellen” [⇒ 2]. Zu diesem Zweck nimmt es eine Datei, die die darzustellenden Noten beschreibt, und zwar in einer LilyPond spezifischen Beschreibungssprache. Und es erzeugt daraus den eigentlichen Notentext — als PDF, PNG etc:

LilyPond is a compiled system: it is run on a text file describing the music. The resulting output is viewed on-screen or printed. In some ways, LilyPond is more similar to a programming language than graphical score editing software. [⇒ 3]

Die LilyPond-Beschreibungssprache ist also eine Programmiersprache (ausgeführt und interpretiert vom Programm LilyPond). Das Schreiben von Musik für LilyPond ist Programmierung. LilyPond ist ein Programmiersystem wie PHP‑, PYTHON- oder BASH: Der Interpreter (die PHP‑, Python‑, Bash- oder eben die LilyPond-Engine) nimmt ihren Eingabecode und erzeugt daraus eine neue Ausgabe. Solche (Open Source-basierten) Engines werden häufig unter anderen Lizenzen freigegeben als der Programmiercode, den sie ausführen. Beispielsweise ist PHP unter der PHP-Lizenz lizenziert, es gibt jedoch viele PHP-Programme, die unter der MIT‑, der BSD- oder sogar der LGPL-Lizenz lizenziert sind.

Dass dem auch bei LilyPond so ist, zeigt das LilyPond-Repository [⇒ 4]:

Es enthält die Datei COPYING, die eine Kopie der GPLv3 ist.
Es enthält eine Datei mit dem Namen LICENSE, die besagt, dass LilyPond unter der GPLv3 lizenziert sei.
Es enthält eine Datei mit dem Namen LICENSE.Documentation, aus der hervorgeht, dass alle Dokumenteingaben unter die GNU Free Documentation License fallen, allerdings mit Ausnahme der Dateien im Verzeichnis ’snippets’, diese seien ‘Public Domain’.

Daraus können wir Folgendes ableiten:

LilyPond selbst ist unter den Bedingungen der GPL lizenziert: Sie dürfen es ausführen, untersuchen, modifizieren und weitergeben. Wenn Sie jedoch eine (geänderte) Instanz weitergeben, müssen Sie ihrem ‘Paket’ den Lizenztext, eine Liste der Urheberrechtsinhaber, den Quellcode und einige andere Compliance Artefakte hinzufügen.
Die GPLv2/v3 sagt nirgendwo, dass die Eingabedateien (in unserem Fall: die LilyPond encodierten Noten) oder die Ausgabedateien (in unserem Fall: pdf, png, …) ebenfalls unter den Bedingungen der GPLv3 verteilt werden müssen.
Außerdem verlangen die LilyPond-Urheberrechtsinhaber an keiner Stelle, dass die Eingabe- und Ausgabedateien auch unter der GPL freizugeben sind (was sie — dem Vorbild einiger Codegeneratoren folgend — hätten tun könnten).
Darüber hinaus wissen und akzeptieren die Urheberrechtsinhaber von LilyPond nachweisbar, dass die LilyPond-Eingabedateien nicht automatisch durch den “Starken Copyleft Effekt” der GPL erfasst werden. Andernfalls hätten sie keine Snippets in ihr Repository einbetten und zugleich sagen sagen können, dass diese Public Domain seien.

So können wir allgemein folgern, dass die LilyPond-Eingabe- und Ausgabedateien aus der Sicht von LilyPond und seinen Entwicklern anders lizensiert werden dürfen, als LilyPond selbst.

Welche Lizenz sollte man also für seine LilyPond-Schnipsel wählen? Es gibt zwei Vorbilder:

In einem LilyPond Snippets Repository werden bereits wiederverwendbare Snippets gehostet. Laut LSR fallen all diese Snippets in die ‘Public Domain’ [⇒ 5]
Angeboten wird ferner eine ‘Open LilyPond Library’. [⇒ 6] Deren Homepage ist größtenteils ein Website-Skelett. Es heißt dort nur, “openLilyLib” sei eine Erweiterungsbibliothek für die Musiknotationssoftware GNU LilyPond. [⇒ 7] Unter der Github Organisation “openlilylib” findet man dann das zentrale Repository “oll-core”, das sich als “the heart of openLilyLib” vorstellt und allgemeine Funktionen anbietet, die jedes “openLilyLib”-Paket verwenden müsse. [⇒ 8]

Obwohl dieses openLilyLib Repository keine Datei mit dem Namen COPYING (mit dem Text der GPL als Inhalt) und auch keine Datei LICENSE oder LICENSING enthält, sagt der Header der zentralen Quellcodedatei package.ily klar, dass “openLilyLib’ freie Software sei und unter den Bedingungen der GNU General Public License weitergegeben und / oder modifiziert werden könne [⇒ 9]. Dies drückt den Willen der Entwickler und der Copyright Owner aus, der von allen Benutzern der openLilyLib respektiert werden muss.

Leider hat das Model, GPLv3 lizensierte LilyPond-Schnipsel anzubieten, hat einige sehr unattraktive und schmerzhafte Folgen:

Wir wissen bereits, dass der LilyPond-Code selbst Software ist. Solche Schnipsel werden mit dem Befehl include "ABC.ly" in den Hauptcode eingebunden. Oder sie werden in den eigenen LilyPond-Musikcode hineinkopiert. Beides triggert den Starken Copyleft-Effekt der GPL [⇒ A, §5]: Wenn ich einen Teil des GPL-lizenzierten Codes mittels eines Funktionsaufrufes von meinem Code aus verwende (anstatt diesen Code selbst zu schreiben) oder wenn meine Datei den Fremdcode gar selbst enthält, dann hängt meine Arbeit von dieser GPL-lizenzierten Vorarbeit ab und ich muss meinen Code auch unter den Bedingungen der GPL verbreiten, unabhängig davon, ob ich meine Arbeit als Quellcode [⇒ A, §5] oder in Form von kompilierten Ergebnissen [⇒ A, §6] verbreite.

Jetzt kann man die unangenehmen Konsequenzen geradezu riechen. Wenn ich meine Musiknoten mit der LilyPond-Sprache beschreibe und dabei ein GPL-lizenziertes Snippet verwende, muss ich meine Musiknoten auch unter den Bedingungen der GPL verbreiten, und zwar unabhängig davon, ob ich sie als Bilder / PDFs oder LilyPond-Code weitergebe. Durch die Verteilung unter der GPL gewähre ich dann konsequenterweise jedem, der meine Ergebnisse bekommt, das Recht, sie zu verwenden, zu studieren, zu modifizieren und neu zu verteilen. Und was bedeutet es, Musiknoten zu verwenden? Natürlich! Es bedeutet insbesondere auch, die Musik zu spielen.

Wenn Sie also ein GPL-lizenziertes LilyPond-Snippet zum Erstellen Ihrer eigenen LilyPond-Musikdatei verwenden — sei es als ‘inkludierte’ Datei, sei per Copy&Past -, haben all diejenigen, die Ihre Noten erhalten — egal, in welcher Form -, das Recht, Ihre Musik zu spielen (oder sonst wie zu verwenden) — ohne weitere Nachfrage und zu jedem Zweck.

Um es klar zusagen: Natürlich hat jeder Autor das Recht, seine Arbeit unter eine beliebige Lizenz zu stellen. Und die Benutzer seiner Arbeit müssen die Anforderungen der gewählten Lizenz erfüllen. Das ist unstrittig und der Kern der ganzen Free Software World. Kein Zweifel.

Die Frage ist allerdings, was dann diejenigen tun können, die ihre Nutzer nicht solch radikale Konsequenzen aufbürden wollen?

Sie könnten ihre Snippets / Libs zum ersten unter den Bedingungen der LGPL verbreiten. [⇒ B] Aufgrund des Schwachen Copyleft-Effekts der LGPL [⇒ B, §2/§4] dürfen die Benutzer dann ihren eigenen Code / ihre eigene Musik unter den ihnen gemäßen Bedingungen verbreiten.

Das hat aber auch einen — wahrscheinlich unerwünschten — Nebeneffekt: Wenn ich ein Musikstück auf Basis eines LGPL-lizenzierten Snippets geschrieben habe, muss ich — auch wenn ich meinen Notentext nur als Bild oder PDF verteile- zusätzlich auch den Code, den Lizenztext selbst, eine Liste der Urheberrechtsinhaber [⇒ B, §4] und einige andere Compliance-Artefakte verteilen — und zwar zusammen mit meinem Notentext . Eine einfache Verteilung meiner Arbeit ohne diese Compliance-Artefakte wäre schlicht ein Lizenzverstoß. Egal wie sinnig oder unsinnig man den Mehraufwand einschätzte!

Alternativ könnten Sie in dem Dokument, mit dem Sie Ihr Snippet lizensieren, ausdrücklich darauf hinweisen, dass die Verbreitung der Musik in Form von Bildern / PDFs NICHT die Anforderungen der LGPL entsprechen müsse (also den Copyleft-Effekt nicht triggere).

Die Lizenz durch Exzeptions ‘aufzuweichen’, ist mittlerweile üblich. Es ist jedoch immer besser, eine sprachlich passende Lizenz zu verwenden, als hinzuzufügen, dass der Lizenztext in gewisser Hinsicht nicht meine, wie er besage.

Ferner könnten Sie den LilyPond-Code unter jeder anderen zulässigen Open Source-Lizenz verteilen.

Aber auch diese Lizenzen zwingen uns, Compliance-Artefakte zusammen mit unserer Musik zu verbreiten (im Falle der Apache‑2.0‑Lizenz zum Beispiel wäre das z.B. der Lizenztext selbst und die NOTICE-Datei des Pakets [⇒ C §4].

Schließlich könnten Sie die Snippets unter den Bedingungen einer der Creative Commons-Lizenzen verbreiten. [⇒ D]

Je nach Wahl der Attribute würden Sie selbst festlegen, wie die Nutzer Ihnen Respekt zollen sollten (BY), welche Rechte er übernehmen muss (SA) oder ob er womöglich gar nichts tun muss (CC0).

Schließlich könnten Sie Ihre Snippets zu ‘Public Domain Software erklären’.

Dann gäben Sie aber Ihre Urheberrechte vollständig auf. Ihre Arbeit dürfte formal nicht einmal mehr auf Sie als Copyrightowner bzw. Autor verweisen. Diesen Weg wählt der LSR [⇒ 5]. Leider taugt dieses Verfahren nur im anglo-amerikanischen Rechtsraum, im europäischen gibt es keine “public domain”.

Was also sollen wir als Autoren tun, die wir mit unseren Snippets anderen die Arbeit mit LilyPond erleichtern wollen? Es gibt drei Wege:

Ich denke, der beste Weg besteht darin, diese Snippets unter den Bedingungen der MIT-Lizenz zu verbreiten. Diese permissive Lizenz ist so klein, dass sie zusammen mit der Copyright-Zeile buchstäblich in den Quellcode integriert werden kann, sodass er literal bereits alle Compliance-Artefakte enthält: “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” [⇒ E]
Die zweite fast gleichwertige Methode bestünde darin, die Snippets unter einer Creative Commons Lizenz zu verteilen. Allerdings bürdet nur die CC0 dem Nutzer keine ‘lästigen’ Pflichten auf [⇒ F].
Der dritte Weg ist der, den ich bei harmonyli.ly verwendet habe: die Duallizenzierung

Allerdings: wenn wir so vorgehen, können wir nicht mehr erzwingen, dass unsere Nutzer ihre Verbesserungen mit der Community teilen. Aber seien wir ehrlich: Sind unsere Snippets so wichtig, dass wir sie besonders schützen müssen? Ich denke, dass es manchmal besser ist, einfach so zu geben, ohne etwas zurückzufordern. Denn das kommt dann meist so, ganz von allein und freiwillig.

Und in welchem Zusammenhang …

… steht das mit einer systematischen Erfüllung von FOSS-Lizenzen? Nun, dazu müssen wir halt auch politische Konnotationen bedenken, konzeptionelle und kontextuelle Aspekte analysieren — einzeln oder gemeinsam auf Konferenzen. Wir müssen konkrete Fälle und allgemeine Nebenwirkungen durchdenken, für Software, Bilder oder Dokumente. Wir müssen Trends benennen und Leitfäden erstellen. Vornehmlich aber müssen wir die Automatisierung der Lizenzerfüllung vorantreiben, unser Lizenzwissen frei zur Verfügung stellen, es in kleinere Tools gießen und in größere Systeme einbringen: Denn FOSS lebt von der Freiheit durch Lizenzerfüllung, im Großen und im Kleinen.

Im Übrigen: Männer sind mitgemeint.

Und in welchem Zusammenhang …

Carl Sorensen

Karsten Reincke