Musikwissenschaftlerinnen haben es schwer — auch wenn sie LaTeX-Texte mit Notenbeispielen und Harmonieanalysen verfeinern wollen. Dieser Artikel fasst eine Untersuchung zum Thema LaTeX und Musikwissenschaft zusammen, die unter der Hand zu einer selbstreferentiellen Anleitung geworden ist.

Ansinnen

Am Anfang wollte ich eine musikwissenschaftliche Arbeit schreiben. Wie geisteswissenschaftliche Texte mit LaTeX entstehen, hatte ich schon systematisch erprobt.((Prinzipiell möglich sind sogar Fußnoten in WordPress und HTML)) Die Ergebnisse sind in das Tool ‘proScientia.ltx’ eingeflossen; eine frühere Version firmierte unter ‘myCsrf’. Deren Sinn hatte ich in einem Tutorial dokumentiert und demonstriert.

Allerdings wusste ich damit noch nicht, wie man Musikbeispiele mit Open-Source-Tools generiert und in LaTeX-Texte integriert. Es gab bisher keine Sichtung dazu, ob und wie das mit freier Software umzusetzen wäre. Eine erste grobe Internetrecherche brachte eine Fülle an Tools und Methoden zu Tage — aber keine richtige Anleitung, keine Erklärung, welche Tools man wie man besten zusammenstöpselt, und schon gar kein Tutorial, ob und wie man mit freier Software Noten und Harmonieanalysen verknüpfen könnte.

Also stellte ich meine eigentliche Aufgabe hintan und analysierte zuerst das Thema LaTeX und Musikwissenschaft: Ich wollte vorher die dafür beste Methode kennengelernt haben, um nicht unterwegs feststellen zu müssen, aufs falsche Pferd gesetzt zu haben. Diese Untersuchung ist in ein umfangreiches Dokument eingeflossen: Es behandelt kleine Tools, beschreibt mögliche Backends, leuchtet Frontends aus, untersucht Konverter und liefert schließlich eine Wegekarte möglicher Kombinationen.

Wie üblich habe ich den Quellcode für diese Untersuchung zum Thema Musikwissenschaft mit LaTeX als Open-Source-Software veröffentlicht, das PDF-Kompilat Musikwissenschaft mit LaTeX steht online ebenfalls bereit. Der Witz ist, dass Verbindung von Untersuchung, PDF-Ergebnis und Quellen damit unter der Hand zu einer selbstreferentiellen Anleitung geworden ist, die einsehbar macht, was sie vorzeigt. Dieser kleine Artikel fasst wesentliche Ergebnisse der Untersuchung zusammen.

Backends

Es gibt drei Backendsysteme, über die frau Musikbeispiele in LaTeX-Texte einbetten kann: die ABC‑, die MusixTeX- und die LilyPond-Notationsweise. Alle drei erzeugen gut lesbaren Notentext, LilyPond hat allerdings die Nase vorn:

Das ABC- und das LilyPond-Backend erzeugen jeweils ‘Notenbilder’, die als Graphik in den Text eingebettet werden. Sie mit LaTeX Mitteln zu erweitern oder zu kommentieren, ist mithin systematisch nicht möglich. Beide nutzen eine intuitiv erfassbare Sprache zur Eingabe von Partituren. Auch dabei liegt LilyPond vorn. Harmonieanalysen in die Notentexte einzubetten, war bei beiden Systemen allerdings nur sehr begrenzt möglich: man musste sich auf einfache Symbole beschränken und konnte keine komplexen Zusammenhänge repräsentieren.

Anders dagegen MusixTeX: Hier wird der Notentext auf LaTeX-Ebene formuliert. Das erlaubt eine textuelle Verknüpfung von LaTeX und MusixTeX. Diese Fähigkeit nutzt das LaTeX-Paket harmony. Mit ihm kann man auch sehr komplexe Harmonieanalysen in den Notentext einbetten. Allerdings zahlt man einen hohen Preis für diese Möglichkeit: die Syntax von MusixTeX ist so komplex und kompliziert, dass sie zu verwenden die Produktivität begrenzt.

Die Ausgangslage war also schon von den Backendsystemen her recht unangenehm: Die Musikwissenschaftlerin musstesich entweder auf einer langwierige ‘Fummelei’ einstellen, wenn sie wissenschaftlich adäquate Ergebnisse erzielen wollte. Oder sie nutzte eine elegante Sprache zur Notenrepräsentation und verzichtete auf komplexere Harmonieanalysen.

Ein Ausweg

Beides war für mich unakzeptabel. Deshalb unterbrach ich auch noch diese meinem eigentlichen Ansinnen vorausgeschickte Untersuchung und entwickelte zwischendrin eine Bibliothek, die zumindest das für LilyPond-Notate leisten sollte, was ‘harmony’ für MusixTeX offerierte. Konsequenterweise nannte ich dieses Tool harmonyli.ly. Danach habe ich — wie üblich — harmonyli.ly als Open-Source-Software veröffentlicht, eine dazu passende harmonyli.ly Internetseite angelegt und ein komplettes und ausgeklügeltes harmonyli.ly Tutorial geschrieben. Damit wurde der Weg LaTeX + LilyPond + harmonyli.ly zu einer echten Alternative zur LaTeX + MusixTeX + harmony:

Mittlerweile darf ich wohl sagen, dass sich harmonyli.ly – auch und gerade dank der Unterstützung durch die Community – zu einem musikwissenschaftlichen Tool entwickelt hat, das über die Fähigkeiten von harmony deutlich hinausgeht und mindestens ebenso gut dokumentiert ist. Mehr noch: im Verbund mit harmonyli.ly werden LilyPond und LaTeX auf hohem Niveau zu einem vom Forschungsgegenstand her adäquaten Tool für Musikwissenschaftler.

Frontends

Musikwissenschaftlerinnen sind allerdings immer auch Musiker: sie schreiben und lesen lieber Noten als spezielle Notationssprachen. Insofern wollte ich auch wissen, ob für die möglichen Backendsysteme passende Frontends bzw. Editoren zur Verfügung standen. Das Internet präsentierte viele. Ich habe die relevanten hinsichtlich Verfügbarkeit und Nutzbarkeit getestet. Letztlich blieben — prinzipiell gesehen — nur 7 Kandidaten: EasyABC, Denemo, Rosegarden, MuseScore, Canorus, Frescobaldi und Elysium. Allerdings stellte sich zuletzt heraus, dass

• nur die semi-graphischen Editoren Frescobaldi und Elysium direkt mit LilyPond und harmonyli.ly nutzbar waren
• es kein Frontend für MusixTeX gab, weder direkt, noch indirekt über die Einbindung von Konvertern
• für LilyPond nur das graphische Frontend MuseScore existiert, sofern die Wissenschaftlerin bereit ist, ihre Arbeit als MusicXml-Datei zu exportieren und mittels des Konverters musicxml2ly in eine LilyPond Datei umzuwandeln, in die dann — über Frescobaldi oder Elysium — die harmonyli.ly basierte Harmonieanalysesymbole nachträglich einbettet werden.

Fazit

Damit war das, was wirklich möglich war, zuletzt deutlich reduziert, selbst wenn man Konverter mit einbezog:

• Letztlich kann man aus den Tools in und um LATEX + ABC kein akzeptables Editiersystem für Musikwissenschaftler zusammenstellen.
• Der Vorteil der Methode LaTeX + MusixTeX + harmony liegt in der bruchlosen Integration in das gewohnte LaTeX-Handling und in der Tatsache, dass LaTeX-Syntagmen in MusixTeX-Bereichen verwendeten werden können.
• Der Nachteil der Methode LaTeX + MusixTeX + harmony besteht in der Komplexität und Unhandlichkeit von MusixTeX. Außerdem gibt es kein graphisches oder semi-graphisches Frontend zur Edition von MusixTeX-Dateien
• Der Nachteil der Methode LaTeX + LilyPond + harmonyli.ly besteht darin, dass die Notenbeispiele nicht nativ in den LaTeX-Text eingebettet werden, sondern ’nur’ als unabhängig generierte Graphiken. Damit muss man die Skalierung und Auflösung gesondert bedenken.
• Dem stehen mehrere Vorteile der Methode LaTeX + LilyPond + harmonyli.ly gegenüber:
  • Die LilyPond-Syntax ist deutlich einfacher als die von MusixTeX
  • Mit Frescobaldi gibt es einen ausgezeichneten semi-graphischen Editor, der gleich auch die Zusatzbibliothek harmonyli.ly korrekt auswertet.
  • Mit Elysium steht eine Eclipse-Alternative bereit.
  • In absehbarer Zeit dürfte Canorus zu einer nutzbaren dritten Möglichkeit werden.
  • Wer sich einen graphischen Editor wünscht, kann auf MuseScore zurückgreifen, seinen Text als MusicXml exportieren und nur die Analysen als LilyPond-Syntagmen einbetten — ein gut nutzbarer Weg, insbesondere wenn es um komplexere Notentexte geht.

Konsequenzen

Damit dürfte auch klar sein, wie ich mein initiales Ansinnen beantworte: Ich nutze LaTeX + LilyPond + harmonyli.ly.

Insgesamt bin ich froh, den Dschungel der Möglichkeiten, der sich nach der reinen Internetrecherche abgezeichnet hatte, systematisch ausgeleuchtet und die wirklich gangbaren Wege gefunden zu haben. Jetzt weiß ich, woran wir sind. Ich brauche mir keine Sorge mehr zu machen, mitten in der Arbeit das Pferd wechseln zu müssen und all die schon geleistete Untersuchungsarbeit zu verlieren.

Ich wünschte allerdings, ich selbst hätte meine Arbeit schon gleich zu Anfang von jemand anderem erhalten anstatt sie selbst geschrieben haben zu müssen. Das hätte mir sehr viel Zeit gespart. So hoffe ich, dass andere meine Vorarbeit verwenden und ihre Zeit für produktivere Dinge nutzen können.

Und in welchem Zusammenhang …

… steht das jetzt — im weitesten Sinne — mit Musizieren? Nun, dafür brauchen wir zunächst ein Instrument, das Zubehör und ein Etui. Helfen können uns dabei oft auch kleinere und größere Computerprogramme, mit denen wir komponieren und die wir verbessern, Musik wissenschaftlich analysieren und Workshops vorbereiten können. Dazu habe ich hier und im Geigenforum einiges zusammengetragen.

Im Übrigen: Männer sind mitgemeint.

The post Musik, Wissenschaft und LaTeX appeared first on Freigiebigkeit.

Dass Frescobaldi unter Ubuntu 22.04 mit einer Fehlermeldung startet, ist ärgerlich: Der Bereich der Notenanzeige sagt, Frescobaldi übergebe via qpageview/highlight.py und qpageview/shadow.py an eine Funktion unerwarteterweise ein Argument vom Typ float. Nun gilt es zu ‘googeln’ — oder hier weiterzulesen:

Die Google-Abfrage ‘Frescobaldi Python 3.10′ listet denn auch einige Fehlerberichte auf, darunter den mit dem Titel “Frescobaldi 3.13 crashes with python 3.10 #1398″. Frescobaldi selbst sagt in seinem About-Dialog, dass Ubuntu 22.04 die Version 3.1.3 enthalte. Und an der ’shell’ erfährt die Nutzerin via python3 --version, dass Python 3.10.4 installiert sei. Auch für diese Kombination gibt es Hinweise auf den Bug

Damit ist Frescobaldi unter Ubuntu 22.04 nicht wirklich nutzbar. Ohne die Wirkung dessen zu sehen, was sie ‘lilypondisch’ notiert hat, wird es für die Komponistin schwierig. Was kann sie tun?

• Zum einen könnte sie solange Paketupgrades einspielen, bis Ubuntu Frescobaldi gefixt hat — und bis dahin auf das Tool verzichten.
• Zum zweiten könnte sie — wie von Jorma Louhi beschrieben — den Code selbst anpassen.
• Oder sie könnte drittens per pip auf die neuere Version 3.2 umstellen

sudo apt-get remove frescobaldi
pip install qpageview
pip install frescobaldi

Voraussetzung dafür aber ist, das die anderen von frescobaldi benötigten Libs und Tools aus den Distributionspaketen installiert sind, also

sudo apt-get install python3-pip
sudo apt-get install python3
sudo apt-get install python3-qt5
sudo apt-get install python3-ly
sudo apt-get install python3-poppler-qt5
sudo apt-get install python3-pygame

Und in welchem Zusammenhang …

… steht das jetzt — im weitesten Sinne — mit Musizieren? Nun, dafür brauchen wir zunächst ein Instrument, das Zubehör und ein Etui. Helfen können uns dabei oft auch kleinere und größere Computerprogramme, mit denen wir komponieren und die wir verbessern, Musik wissenschaftlich analysieren und Workshops vorbereiten können. Dazu habe ich hier und im Geigenforum einiges zusammengetragen.

Im Übrigen: Männer sind mitgemeint.

The post Frescobaldi unter Ubuntu 22.04: mit pip oder apt? appeared first on Freigiebigkeit.

Ubuntu 22.04 bietet beide Versionen an, MuseScore‑2 und MuseScore‑3. Mit MuseScore‑3 hatte ich bereits gute Erfahrungen gemacht. Also entfernte ich sicherheitshalber zuerst das ältere Release komplett, bevor ich meine bevorzugte Variante installierte

sudo apt-get remove --purge musescore
sudo apt autoremove
sudo apt-get install musescore3

Nachdem ich dann meinen Standard-Testsong in und mit MuseScore‑3 abspielen ließ, begegnete mir besagtes Durcheinander von Musik und Hintergrundgeräuschen. Das Internet sagte mir, es gäbe einen Fehler, der durch die Kombination von Puls-Audio und MuseScore‑3 hervorgerufen werde: MuseScore‑3 sollte angeblich die Puls-Latenz auf einen unbrauchbar kleinen Wert heruntersetzen.

Wenn dies zuträfe, müsste ich es — wie ich annahm — beheben können, indem ich den aktuellen Pulslatenzwert mittels einer Umgebungsvariablen überschriebe. Also öffnete ich eine Bash, gab ‘export PULSE_LATENCY_MSEC=30′ ein und rief ‘musecore3′ von der Kommandozeile aus auf. Und tatsächlich: keine störenden Wiedergabegeräusche mehr. Doch als ich MuseScore‑3 erneut über das offizielle Menü startete (also, ohne dass dabei die in der Shell gesetzte Umgebungsvariable ausgewertet würde), waren die Geräusche wieder da. Damit hatte ich die vermutete Ursache verifiziert. Als Nächstes brauchte ich Ubuntu 22.04 nur noch davon zu überzeugen, diesen Impulslatenzwert innerhalb des Bootvorgangs festzulegen. Dazu musste ich eine bestimmte Shell-Datei in das Verzeichnis profile.d einfügen:

sudo echo "export PULSE_LATENCY_MSEC=30" > /etc/profile.d/pulselat.sh

Von da an spielte die MuseScore-3-Version aus Ubuntu 22.04 meine Partitur immer ohne störende Geräusche ab.

Die Sache mit den verschwundenen Soundfonts blieb davon jedoch unberührt: Wenn ich — entsprechend der Dokumention — eine neue Sounddatei im Verzeichnis ‘MuseScore3/SoundFonts’ ablegte, fand MuseScore sie trotzdem nicht. Doch diesmal ’saß’ die Ursache – wie so oft – vor der Tastatur. Kürzlich hatte ich mein Home-Verzeichnis umbenannt, obwohl ich darin den alten Inhalt weiter verwendete. Also zeigte der MuseScore-3-Konfigurationsdialog immer noch Pfade an, die mein altes Benutzerverzeichnis enthielten. Ich konnte so viele neue Sounddateien in meinem Soundverzeichnis ablegen, wie ich wollte. Keine davon wäre so je gefunden worden. Um das zu ändern, musste ich die älteren Namen in der MuseScore-3-Konfigurationsdatei ‘~/.config/MuseScore/MuseScore.ini’ aktualisieren. Danach klappte es dann auch mit dem fluid-R3-GM-Soundfont und dem arachno-soundfont.

Und in welchem Zusammenhang …

… steht das jetzt — im weitesten Sinne — mit Musizieren? Nun, dafür brauchen wir zunächst ein Instrument, das Zubehör und ein Etui. Helfen können uns dabei oft auch kleinere und größere Computerprogramme, mit denen wir komponieren und die wir verbessern, Musik wissenschaftlich analysieren und Workshops vorbereiten können. Dazu habe ich hier und im Geigenforum einiges zusammengetragen.

Im Übrigen: Männer sind mitgemeint.

The post MuseScore 3 und Ubuntu 22.04 — ohne Kratzgeräusche appeared first on Freigiebigkeit.

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:

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

• [1] http://LilyPond.org/gpl.html
• [2] http://LilyPond.org/introduction.html
• [3] http://LilyPond.org/text-input.html
• [4] https://github.com/LilyPond/LilyPond
• [5] http://lsr.di.unimi.it/LSR/html/whatsthis.html
• [6] https://github.com/openlilylib/
• [7] https://openlilylib.org/
• [8] https://github.com/openlilylib/oll-core
• [9] https://github.com/openlilylib/oll-core/blob/master/package.ily
• [A] https://opensource.org/licenses/GPL‑3.0
• [B] https://opensource.org/licenses/LGPL‑3.0
• [C] https://opensource.org/licenses/Apache‑2.0
• [D] https://creativecommons.org/share-your-work/licensing-types-examples/
• [E] https://opensource.org/licenses/MIT
• [F] https://creativecommons.org/publicdomain/zero/1.0/

The post GPL lizenzierte LilyPond-Snippets — und ihre Nebenwirkungen appeared first on Freigiebigkeit.