|

LilyPond, LilyPond Snippets and the GPL: About some bad side effects.

This article explains why it is a bit suboptimal to distribute LilyPond snippets under the terms of the GPL, even if one – as I do – loves to create, to share and/or to use free and open-source software.

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 which states that LilyPond is licensed under the GPLv3.
  • a file named LICENSE.Documentation stating that all document input is released 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 describes the will of developers (copyright owner) which has to be respected by all users of the openlilylib.

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. Such snippets are either linked into the main code using the command #include “ABC.ly” . Or they are literally copied into once own LilyPond music code. Both modes of use trigger the strong copyleft effect of the GPL (v3 as well as 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, 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?

  • 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 – regardless of I distribute my work in the form of LilyPond code or as a picture or a pdf file!

  • As a substitute, they could explicitly state that distributing the music in 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 it is always better to use an appropriate license than stating that the license text does not mean what it says.

  • They also 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 want to support other musicians by simplifying their development work instead of burdening it by enforcing them to create some seldom recognized compliance artifacts?

I think, the best way to distribute additional LilyPond snippets is to distribute our snippets and modules under the terms of the MIT license. This license is so small, that it can literally integrated in to the 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]

The second method is to distribute the snippets under the terms of a creative commons license. But only the CC0 does not impose our users anything. [⇒ F]

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 its worth? I think, sometimes it is better to give without requiring a return. Often such a giving back is given voluntarily.


2 annotations for “LilyPond, LilyPond Snippets and the GPL: About some bad side effects.”

  1. Carl Sorensen says:

    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 says:

    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

Leave a Reply

Your email address will not be published. Required fields are marked *

91 − 81 =

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