|

LilyPond, LilyPond Snippets und die GPL: Über schlechte Nebenwirkungen

Dieser Artikel beschreibt, warum es suboptimal ist, Lilyond-Snippets unter den Bedingungen der GPL zu verbreiten, selbst wenn man – wie ich es tue – gerne Freie und Open-Source-Software erstellt, verteilt und verwendet.

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:

  1. 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.
  2. 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.
  3. 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).
  4. 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:

  1. In einem LilyPond Snippets Repository werden bereits wiederverwendbare Snippets gehostet. Laut LSR fallen all diese Snippets in die ‚Public Domain‘ [⇒ 5]
  2. 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 dieses 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 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?

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].

Aber ja, 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ück zu fordern. Denn das kommt dann meist so, ganz von allein und freiwillig.


2 Anmerkungen zu “LilyPond, LilyPond Snippets und die GPL: Über schlechte Nebenwirkungen”

  1. Carl Sorensen sagt:

    I believe you are misinterpreting the GPL license as it applies to LilyPond output.

    PDF files are not software, but output from software.

    Similarly, MIDI files are not software, but output from software.

    gcc is licensed under GPL3. Using gcc to compile your program does not require you to distribute your program under GPL terms, because your work is *NOT* a derivative work. Instead, your work is separate work that is created using the tools provided in gcc.

    Can you find a single reference in any of the FSF discussion of the GPL that indicates the output of a GPL program is covered by the GPL?

    Here are two questions and answers from the FSF GPL FAQ[1] that indicate the output is only covered by the GPL if the output has a verbatim copy of the program. This is not the case for any LSR snippet of which I am aware.

    Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free? (#GPLOutput)
    In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program. If the user uses your program to enter or convert her own data, the copyright on the output belongs to her, not you. More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from.

    So the only way you have a say in the use of the output is if substantial parts of the output are copied (more or less) from text in your program. For instance, part of the output of Bison (see above) would be covered by the GNU GPL, if we had not made an exception in this specific case.

    You could artificially make a program copy certain text into its output even if there is no technical reason to do so. But if that copied text serves no practical purpose, the user could simply delete that text from the output and use only the rest. Then he would not have to obey the conditions on redistribution of the copied text.

    In what cases is the output of a GPL program covered by the GPL too? (#WhatCaseIsOutputGPL)
    The output of a program is not, in general, covered by the copyright on the code of the program. So the license of the code of the program does not apply to the output, whether you pipe it into a file, make a screenshot, screencast, or video.

    The exception would be when the program displays a full screen of text and/or art that comes from the program. Then the copyright on that text and/or art covers the output. Programs that output audio, such as video games, would also fit into this exception.

    If the art/music is under the GPL, then the GPL applies when you copy it no matter how you copy it. However, fair use may still apply.

    Keep in mind that some programs, particularly video games, can have artwork/audio that is licensed separately from the underlying GPLed game. In such cases, the license on the artwork/audio would dictate the terms under which video/streaming may occur. See also: Can I use the GPL for something other than software?

    I do not think the issue you are concerned about is a problem.

    Carl Sorensen

    1. https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL

  2. Karsten Reincke sagt:

    Many thanks for your exhaustive answer!

    Although your comment contains an important hint, it also passes the core of my argumentation:

    You compare GCC and LilyPond. And you conclude, that – like in case of the GPL licensed GCC where the copyleft effect does not cover its output (the compiled program), – also in case of the GPL licensed LilyPond the copyleft effect does not cover its output (the picture/pdf). Unfortunately, that’s not my point:

    I am not arguing that my LilyPond work (or a snippet) is covered by the GPL because it is ‚executed‘ by LilyPond. I argue that my code is covered by the GPL if I use (include or copy) a GPL licensed LilyPond snippet. And if it is covered, then in accordance with the GPL §6 (title: „Conveying Non-Source Forms“) also the compiled version is covered by the GPL. (BTW: even a picture is binary code which still must be interpreted).

    Nevertheless, your comment contains the important hint, that the FSF does not want that the output is covered by the strong copyleft effect of its programs.

    I would be happy if the statement you quoted would be judicially approved! But as long as we do not have such a legal descision there is a great risk that my scientific and artistical music work can freely be used due to the fact that I used a GPL licensed snippet for creating the music scores – a risk, which I don’t want to take.

    But even if I agreed with your position, then we both still have to conclude, that we can only distribute/hand-over our LilyPond code under the terms of the GPL, if our code used a GPL licensed snippet. And even this is a strong side effect.

    with best regards Karsten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

46 + = 56

Diese Site verwendet Cookies. (Details)

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen