Musicologists have a hard time — namely if they want to enrich their LaTeX texts by score examples and harmony analyses. Up to now, there did not exist any study of whether and how that could be realized with free software. This article summarizes a German-written self-referential tutorial teaching what’s possible and what is not with respect to LaTeX and Musicology:

How it started

In the beginning, there was my task to write a musicological work. I had already explored and documented how one can write humanistic texts with LaTeX. proScienta.ltx — a project ‘hosted on GitHub‘ — covered the results, a former version was labeled ‘myCsrf’. Their specific intentions have been described in a sophisticated German tutorial and in a shorter English version.

Nevertheless, I did not know how one could generate musical examples with free software and embed them into LaTeX texts. The first rough internet recherche presented a lot of tools and methods but did not provide any manual. It did not deliver any explication on how to successfully combine which tools and did not find any tutorial on how one could link notes and harmony analyses.

So, I postponed my original task and examined the topic LaTeX and Musicology: I preferred to know the best method before I started to not back the wrong horse. Finally, my investigation was documented in a larger text: It reviews smaller tools, describes usable backend systems, discusses frontends, tests converters and delivers a map of conceivable and really possible toolchains.

As usual, I have published the sources of the eBook LaTeX und Musikwissenschaft as open-source-software. Additionally, I have uploaded the compiled pdf-file ‘Musikwissenschaft mit LaTeX’. The point is, that this investigation backhandedly became a self-referential tutorial that explains, what it shows. This article summarizes the core results of that study

Backends

We know three free backend systems for embedding scores into LaTeX texts: the ABC notation method, MusixTeX, and LilyPond. All these techniques create well-readable scores. But LilyPond has the edge over the others.

The ABC backend — as well as the LilyPond backend — creates pictures of scores that are embedded into the LaTeX text as graphics. Hence, it is systematically not possible to comment or modify the examples on the LaTeX level. Both backends use a simple representation language. But again, the LilyPond language is a bit smarter. And both backend systems only allow integrating simple harmony analysis symbols into the scores. They do not offer a method to represent complex harmonic relationships on a level that fulfills the needs of musicology.

The alternative — MusixTeX — works differently: It represents the notes on the LaTeX level. That allows, to comment and improve the scores by LaTeX-based symbols. This capability is used by the LaTeX package harmony. It offers the possibility to integrate very sophisticated symbols into the music score. But one has to pay a heavy price for using the method with its elegant results: the syntax of MusixTeX is so complex and unwieldy, that it decreases the productivity of its users.

Hence, the situation was a bit inconvenient, even if one only considered the backend systems: A musicologist had either to keep in mind, that he would need a lot of time to create his examples. Or he could use a simpler representation language and had to refrain from using the symbols his profession required

A way out

I could not accept one of these positions. Therefore I interrupted my running investigation and developed a library, which should at least be able to do that for LilyPond, what harmony did for MusixTeX. Consistently, I named it harmonyli.ly. As usual, I published harmonyli.ly as open-source software, created a harmonyli.ly internet page, and wrote a complete harmonyli.ly tutorial. So, the method LaTeX + LilyPond + harmonyli.ly became a real alternative to LaTeX + MusixTeX + harmony. Here comes the first example that indicates the potential of harmonyli.ly:

Thanks to the help of the LilyPond community, harmonyli.ly has become a tool for musicologists, which functionally exceeds harmony and is documented on a level, which eases its use.

Frontends

Musicologists are also musicians; they prefer to read and write scores instead of having to deal with special representation languages. Therefore, I wanted to learn, which frontend systems resp. editors could create input for which backend system. An internet query provided a bunch of candidates. I tested the relevant items with respect to their availability and usability. In the end, 7 candidates remained: EasyABC, Denemo, Rosegarden, MuseScore, Canorus, Frescobaldi, and Elysium. But at last, I found that

• only the semi-graphical editors Frescobaldi and Elysium could directly and successfully deal with LilyPond and harmonyli.ly
• there did not exist a frontend for MusixTeX — neither directly, nor indirectly by using a converter
• one could use MuseScore as a graphical editor for LilyPond if one accepted to export the results as MusicXml, to convert that result by using musicxml2ly, and to subsequently insert the harmony analysis symbols via Frescobaldi or Elysium

Conclusion

So, finally, I met a very reduced result — even if I considered the existence of converters:

• In the end, one cannot set up an ABC based toolchain for integrating music examples into LaTeX texts.
• The advantage of the method LaTeX + MusixTeX + harmony is its seamless integration into the LaTeX environment and the possibility to enrich the symbols by LaTeX syntagms.
• The disadvantage of the method LaTeX + MusixTeX + harmony is the complexity and the unhandiness of MusixTeX. That there does not exist any specific (graphical) MusixTeX editor does not simplify the world.
• The disadvantage of the method LaTeX + LilyPond + harmonyli.ly is that the scores are only embedded as prepared images. Therefore, one has separately to consider the intended resolution and scaling.
• But there are several advantages of the method LaTeX + LilyPond + harmonyli.ly:
  • The syntax of LilyPond is obviously more simple than that of MusixTeX.
  • Frescobaldi is an excellent semi-graphical LilyPond editor.
  • Elysium is an excellent Eclipse-based LilyPond editor.
  • In the future, Canorus could become the third editor.
  • Those, who need a graphical editor, could use MuseScore, if they agree to export and convert their work and integrate the harmony analysis symbols in a second step.

Consequences

Hence, it should be clear, what I will use when I will start my task, which stood at the beginning of this adventure: I will use LaTeX + LilyPond + harmonyli.ly.

Overall, I am happy that I could floodlight the jungle of opportunities provided by the internet and that I found really usable ways. Now I know, what’s going on. And I need not fear that I could have to change the horse during my ride and lose results that I’ve created as part of the process.

But I wished, I had got this study by another guy instead of having to write it by myself. That would have saved a lot of time. Thus, I hope, that others can use my prework and spend the time they gain on more productive aspects of their life.

And in what way is this …

… article related to the topic ‘Sciences’? To write humanities papers (on Linux), you need an appropriate scientific LaTeX framework. For papers on musicology in particular, scientific texts must be expanded by music examples — mostly written with LilyPond and its libraries. That is the topic also this post wants to support.

The post Musicology with LaTeX appeared first on FODINA 4 FOSS.

This article talks about some side effects. It explains why it is a bit suboptimal to distribute LilyPond snippets under the terms of the GPL. Even, if one loves to create, share, and/or use free and open-source software. And believe me, I do so. The side effect is simple. Including GPL-licensed LilyPond snippets enforce you to distribute your own work under the terms of the GPL:

Let us start with some hopefully indisputable points: The program ‘LilyPond’ is licensed under the GPLv3 [⇒ 1]. It wants “[…] (to create) beautiful sheet music”. [⇒ 2] For that purpose, the program LilyPond takes a file containing a music sheet represented in and by the LilyPond language. And based on this input file, LilyPond compiles the output:

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]

Hence, the language LilyPond pretends for writing a music sheet is a programming language executed by the LilyPond interpreter. Writing music in and by LilyPond is software programming. In other words: LilyPond is a programming system like PHP‑, PYTHON‑, or BASH. The interpreter (the PHP‑, python‑, bash‑, or LilyPond engine) takes its input code and creates the corresponding, but new output. Such (open source based) engines are often licensed under different licenses than the code they execute. For example, PHP is licensed under the PHP license. But there exist many PHP programs licensed under the MIT, the BSD, or even under the LGPL license.

This holds also true for LilyPond — as the LilyPond repository proves. This repository contains … [⇒ 4]

• a file named COPYING which contains the text of the GPLv3 license.
• a file named LICENSE, stating that LilyPond falls under the terms of the GPLv3.
• a file named LICENSE.Documentation stating that all document input falls under the GNU Free Documentation License except the files in the directory snippets. They are public domain.

From these facts we can conclude:

1. LilyPond itself is licensed under the terms of the GPL: You may run, study, modify and redistribute it. But in case of distributing a (modified) instance, you have also to distribute the License text, a list of the copyright owners, the source code and some other compliance artifacts — namely together with your instance.
2. But the GPLv3 does not say anywhere, that the input files (e.g. the snippets, written in the LilyPond language) or the output files (pdf, png, …) have also to be distributed under the terms of GPLv3.
3. Additionally, the LilyPond copyright holders DO NOT require anywhere that the input and output files also have to be released under the GPL (what they could have done, as for the example some code generators have done).
4. Moreover, the LilyPond copyright owners know and accept that the LilyPond input (and output) files are not automatically be covered by the ‘strong copyleft effect’ of the GPL. Otherwise, they could not have embedded a set of snippets into their repository while stating that these are part of the public domain.

Hence, we may generally conclude that — from the viewpoint of LilyPond and its developers — the LilyPond input and output files may be licensed under other licenses than the interpreting program itself.

Consequently, we now should ask, which license the LilyPond snippet authors should choose. We see two role models:

1. The first role model is the LilyPond Snippets Repository which hosts reusable snippets. In accordance to this LSR, all these snippets are public domain. [⇒ 5]
2. The second model is the Open LilyPond Library. [⇒ 6] Its homepage is mostly a site skeleton. It only says that “openLilyLib is an enhancement library for the GNU LilyPond music notation software”. [⇒ 7 ] But if one takes a look at the GitHub repositories collected under openlilylib [⇒ 6], one finds the main repository “oll-core”, which introduces itself as “the heart of openLilyLib” and promises to provide common functionality that any ‘openLilyLib’ package uses. [⇒ 8]

Although this repository does not contain any file named COPYING (containing the GPL) or a file LICENSE or LICENSING, the header of the central source code file ‘package.ily’ clearly states, that “[…] openLilyLib is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License”. [⇒ 9] This statement describes the will of developers (copyright owners) that each user of openlilylib has to respect.

But unfortunately the role model ‘GPLv3 licensed LilyPond snippets’ has some very unattractive consequences:

We know already, that the LilyPond snippet code itself is software. The command #include “ABC.ly” links a snippet into one’s own LilyPond music code. Or you copy the content of a snippet into your music code literally. Both modes of use trigger the strong copyleft effect of the GPL (v3 and v2): if my code functionally calls a method offered by a GPL-licensed snippet or if my code contains the GPL-licensed snippet literally, then my work depends on this GPL-licensed prework and I have to distribute my code also under the terms of the GPL, regardless whether I distribute it as source code or in form of compiled results.

Now, you might smell the rat: If I write my music by using the LilyPond description language and if I use any GPL-licensed snippet to do so, then I have to distribute my music under the terms of the GPL, namely the created pictures / pdfs as well as the code itself. Moreover, by distributing it under the GPL I grant anyone, who gets my results to use them, to study them, to modify them, and to redistribute them. And what does it mean to use music scores: Beside others, of course, to play the music.

Hence, using a GPL-licensed LilyPond snippet for creating your own music — regardless, of whether you use the include- or the copy & paste method — evokes that everyone who gets your work also and inherently gets the right to use it — for any purpose and without having to ask you again.

For being clear: Any author has the right to license his work under any license he likes. And the users of his work have to fulfill the requirements of the license he has chosen. No doubt. That’s the core of the Free Software World.

But what can those snippet developers do, who do not want to load such heavy consequences on their users?

• First, you might think that they could distribute their snippets/libs under the terms of the LGPL. [⇒ B] Then — due to the weak copyleft effect of the LGPL [⇒ B, §2/§4] — their users are free to distribute their own code/music under different conditions.

But that has also a — perhaps unwished — side effect: If I wrote a piece of music based on an LGPL licensed snippet, then I have to distribute together with my work the code of the snippet, the LGPL license text itself, a list of copyright owners [⇒ B, §4], and some other compliance artifacts. Distributing my work without these compliant artifacts would simply not be compliant. And for this it does not matter whether I distribute my work as Lilypond source code or binary pictures or pdfs!

• As a substitute, the snippet developers could explicitly state that distributing the music in the form of pictures / pdfs does NOT trigger the requirements of the LGPL.

Linking an open-source license with such an exception is a well-known practice. But using a really appropriate license is better than using an exception. Such a supplement states that the license text does not mean what it says.

• Third, they could license their LilyPond snippet under any other permissive open-source license.

But even these licenses enforce them to distribute compliance artifacts together with their music — in case of the Apache‑2.0 license, for example, the license text itself and the NOTICE file of their packages. [⇒ C §4]

• Finally, they could license the snippets/libs under the terms of one of the creative commons licenses [⇒ D]

By using the respective attributes they determine how the users shall show them respect (BY) and which additional requirements they have to fulfill [SA] or whether they do not have to fulfill any requirements [CC0]

• And very last they could shift their snippets into the public domain. In this case, they have to give up all copyrights.

The LSR chose this way to distribute the snippets. Unfortunately, this indeed does not hold for the European Legal Area: Here, we cannot give up our copyrights, we can only grant some of them to others: In Europe, there does not exist any ‘public domain’

Hence, what shall we do, if we — the snippet developers — want to support other musicians by simplifying their development work instead of burdening it by enforcing them to create some seldom recognized compliance artifacts?

• First, we can distribute our LilyPond snippets under the terms of the MIT license. This license is so small, that we can literally integrate it into our source code. Then, our source code contains already all artifacts the license requires: „The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.“ [⇒ E]
• Second, we can distribute our snippets under the terms of a creative commons license. But only the CC0 does not impose our users anything. [⇒ F]
• Third, we can use the method of dual licensing — just as I did in the case of my snippet ‘harmonyli.ly’.

Yes, if we do so, we can no longer enforce, that our users share their improvements with the community. But let us be honest with ourselves: are our snippets so important, that we must protect their worth? I think, sometimes it is better to give without requiring a return. Our users often give us something back voluntarily.

And in what way is this …

… part of the overarching topic FOSS Compliance? For fulfilling the requirements of FOSS licenses, we have to consider specific individual cases as well as side effects — for software, pictures, or documents. We should unhide trends and write guidelines. Above all, however, we must drive forward the automation of license fulfillment, make our licensing knowledge freely available, cast it into smaller tools, and bring it into larger systems: Because FOSS thrives on freedom through license fulfillment, large and small. That’s what also this article is about.

• [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-Licensed LilyPond Snippets — And Some Sideaffects appeared first on FODINA 4 FOSS.