Compliance Musicology

GPL-Licensed LilyPond Snippets — And Some Sideaffects

This arti­cle talks about some side effects. It explains why it is a bit sub­op­ti­mal to dis­trib­ute Lily­Pond snip­pets under the terms of the GPL. Even, if one loves to cre­ate, share, and/or use free and open-source soft­ware. And believe me, I do so. The side effect is sim­ple. Includ­ing GPL-licensed Lily­Pond snip­pets enforce you to dis­trib­ute your own work under the terms of the GPL:

[ en | de ]

Let us start with some hope­ful­ly indis­putable points: The pro­gram ‘Lily­Pond’ is licensed under the GPLv3 [⇒ 1]. It wants “[…] (to cre­ate) beau­ti­ful sheet music”. [⇒ 2] For that pur­pose, the pro­gram Lily­Pond takes a file con­tain­ing a music sheet rep­re­sent­ed in and by the Lily­Pond lan­guage. And based on this input file, Lily­Pond com­piles the out­put:

Tristan Chord

Lily­Pond is a com­piled sys­tem: it is run on a text file describ­ing the music. The result­ing out­put is viewed on-screen or print­ed. In some ways, Lily­Pond is more sim­i­lar to a pro­gram­ming lan­guage than graph­i­cal score edit­ing soft­ware. [⇒ 3]

Hence, the lan­guage Lily­Pond pre­tends for writ­ing a music sheet is a pro­gram­ming lan­guage exe­cut­ed by the Lily­Pond inter­preter. Writ­ing music in and by Lily­Pond is soft­ware pro­gram­ming. In oth­er words: Lily­Pond is a pro­gram­ming sys­tem like PHP‑, PYTHON‑, or BASH. The inter­preter (the PHP‑, python‑, bash‑, or Lily­Pond engine) takes its input code and cre­ates the cor­re­spond­ing, but new out­put. Such (open source based) engines are often licensed under dif­fer­ent licens­es than the code they exe­cute. For exam­ple, PHP is licensed under the PHP license. But there exist many PHP pro­grams licensed under the MIT, the BSD, or even under the LGPL license.

This holds also true for Lily­Pond — as the Lily­Pond repos­i­to­ry proves. This repos­i­to­ry con­tains … [⇒ 4]

  • a file named COPYING which con­tains the text of the GPLv3 license.
  • a file named LICENSE, stat­ing that Lily­Pond falls under the terms of the GPLv3.
  • a file named LICENSE.Documentation stat­ing that all doc­u­ment input falls under the GNU Free Doc­u­men­ta­tion License except the files in the direc­to­ry snip­pets. They are pub­lic domain.

From these facts we can con­clude:

  1. Lily­Pond itself is licensed under the terms of the GPL: You may run, study, mod­i­fy and redis­trib­ute it. But in case of dis­trib­ut­ing a (mod­i­fied) instance, you have also to dis­trib­ute the License text, a list of the copy­right own­ers, the source code and some oth­er com­pli­ance arti­facts — name­ly togeth­er with your instance.
  2. But the GPLv3 does not say any­where, that the input files (e.g. the snip­pets, writ­ten in the Lily­Pond lan­guage) or the out­put files (pdf, png, …) have also to be dis­trib­uted under the terms of GPLv3.
  3. Addi­tion­al­ly, the Lily­Pond copy­right hold­ers DO NOT require any­where that the input and out­put files also have to be released under the GPL (what they could have done, as for the exam­ple some code gen­er­a­tors have done).
  4. More­over, the Lily­Pond copy­right own­ers know and accept that the Lily­Pond input (and out­put) files are not auto­mat­i­cal­ly be cov­ered by the ‘strong copy­left effect’ of the GPL. Oth­er­wise, they could not have embed­ded a set of snip­pets into their repos­i­to­ry while stat­ing that these are part of the pub­lic domain.

Hence, we may gen­er­al­ly con­clude that — from the view­point of Lily­Pond and its devel­op­ers — the Lily­Pond input and out­put files may be licensed under oth­er licens­es than the inter­pret­ing pro­gram itself.

Con­se­quent­ly, we now should ask, which license the Lily­Pond snip­pet authors should choose. We see two role mod­els:

  1. The first role mod­el is the Lily­Pond Snip­pets Repos­i­to­ry which hosts reusable snip­pets. In accor­dance to this LSR, all these snip­pets are pub­lic domain. [⇒ 5]
  2. The sec­ond mod­el is the Open Lily­Pond Library. [⇒ 6] Its home­page is most­ly a site skele­ton. It only says that “openLilyLib is an enhance­ment library for the GNU Lily­Pond music nota­tion soft­ware”. [⇒ 7 ] But if one takes a look at the GitHub repos­i­to­ries col­lect­ed under openlilylib [⇒ 6], one finds the main repos­i­to­ry “oll-core”, which intro­duces itself as “the heart of openLilyLib” and promis­es to pro­vide com­mon func­tion­al­i­ty that any ‘openLilyLib’ pack­age uses. [⇒ 8]

Although this repos­i­to­ry does not con­tain any file named COPYING (con­tain­ing the GPL) or a file LICENSE or LICENSING, the head­er of the cen­tral source code file ‘package.ily’ clear­ly states, that “[…] openLilyLib is free soft­ware: you can redis­trib­ute it and/or mod­i­fy it under the terms of the GNU Gen­er­al Pub­lic License”. [⇒ 9] This state­ment describes the will of devel­op­ers (copy­right own­ers) that each user of openlilylib has to respect.

But unfor­tu­nate­ly the role mod­el ‘GPLv3 licensed Lily­Pond snip­pets’ has some very unat­trac­tive con­se­quences:

We know already, that the Lily­Pond snip­pet code itself is soft­ware. The com­mand #include “” links a snip­pet into one’s own Lily­Pond music code. Or you copy the con­tent of a snip­pet into your music code lit­er­al­ly. Both modes of use trig­ger the strong copy­left effect of the GPL (v3 and v2): if my code func­tion­al­ly calls a method offered by a GPL-licensed snip­pet or if my code con­tains the GPL-licensed snip­pet lit­er­al­ly, then my work depends on this GPL-licensed pre­work and I have to dis­trib­ute my code also under the terms of the GPL, regard­less whether I dis­trib­ute it as source code or in form of com­piled results.

Now, you might smell the rat: If I write my music by using the Lily­Pond descrip­tion lan­guage and if I use any GPL-licensed snip­pet to do so, then I have to dis­trib­ute my music under the terms of the GPL, name­ly the cre­at­ed pic­tures / pdfs as well as the code itself. More­over, by dis­trib­ut­ing it under the GPL I grant any­one, who gets my results to use them, to study them, to mod­i­fy them, and to redis­trib­ute them. And what does it mean to use music scores: Beside oth­ers, of course, to play the music.

Hence, using a GPL-licensed Lily­Pond snip­pet for cre­at­ing your own music — regard­less, of whether you use the include- or the copy & paste method — evokes that every­one who gets your work also and inher­ent­ly gets the right to use it — for any pur­pose and with­out hav­ing 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 ful­fill the require­ments of the license he has cho­sen. No doubt. That’s the core of the Free Soft­ware World.

But what can those snip­pet devel­op­ers do, who do not want to load such heavy con­se­quences on their users?

  • First, you might think that they could dis­trib­ute their snippets/libs under the terms of the LGPL. [⇒ B] Then — due to the weak copy­left effect of the LGPL [⇒ B, §2/§4] — their users are free to dis­trib­ute their own code/music under dif­fer­ent con­di­tions.

But that has also a — per­haps unwished — side effect: If I wrote a piece of music based on an LGPL licensed snip­pet, then I have to dis­trib­ute togeth­er with my work the code of the snip­pet, the LGPL license text itself, a list of copy­right own­ers [⇒ B, §4], and some oth­er com­pli­ance arti­facts. Dis­trib­ut­ing my work with­out these com­pli­ant arti­facts would sim­ply not be com­pli­ant. And for this it does not mat­ter whether I dis­trib­ute my work as Lily­pond source code or bina­ry pic­tures or pdfs!

  • As a sub­sti­tute, the snip­pet devel­op­ers could explic­it­ly state that dis­trib­ut­ing the music in the form of pic­tures / pdfs does NOT trig­ger the require­ments of the LGPL.

Link­ing an open-source license with such an excep­tion is a well-known prac­tice. But using a real­ly appro­pri­ate license is bet­ter than using an excep­tion. Such a sup­ple­ment states that the license text does not mean what it says.

  • Third, they could license their Lily­Pond snip­pet under any oth­er per­mis­sive open-source license.

But even these licens­es enforce them to dis­trib­ute com­pli­ance arti­facts togeth­er with their music — in case of the Apache‑2.0 license, for exam­ple, the license text itself and the NOTICE file of their pack­ages. [⇒ C §4]

  • Final­ly, they could license the snippets/libs under the terms of one of the cre­ative com­mons licens­es [⇒ D]

By using the respec­tive attrib­ut­es they deter­mine how the users shall show them respect (BY) and which addi­tion­al require­ments they have to ful­fill [SA] or whether they do not have to ful­fill any require­ments [CC0]

  • And very last they could shift their snip­pets into the pub­lic domain. In this case, they have to give up all copy­rights.

The LSR chose this way to dis­trib­ute the snip­pets. Unfor­tu­nate­ly, this indeed does not hold for the Euro­pean Legal Area: Here, we can­not give up our copy­rights, we can only grant some of them to oth­ers: In Europe, there does not exist any ‘pub­lic domain’

Hence, what shall we do, if we — the snip­pet devel­op­ers — want to sup­port oth­er musi­cians by sim­pli­fy­ing their devel­op­ment work instead of bur­den­ing it by enforc­ing them to cre­ate some sel­dom rec­og­nized com­pli­ance arti­facts?

  • First, we can dis­trib­ute our Lily­Pond snip­pets under the terms of the MIT license. This license is so small, that we can lit­er­al­ly inte­grate it into our source code. Then, our source code con­tains already all arti­facts the license requires: „The above copy­right notice and this per­mis­sion notice shall be includ­ed in all copies or sub­stan­tial por­tions of the Soft­ware.“ [⇒ E]
  • Sec­ond, we can dis­trib­ute our snip­pets under the terms of a cre­ative com­mons license. But only the CC0 does not impose our users any­thing. [⇒ F]
  • Third, we can use the method of dual licens­ing — just as I did in the case of my snip­pet ‘’.

Yes, if we do so, we can no longer enforce, that our users share their improve­ments with the com­mu­ni­ty. But let us be hon­est with our­selves: are our snip­pets so impor­tant, that we must pro­tect their worth? I think, some­times it is bet­ter to give with­out requir­ing a return. Our users often give us some­thing back vol­un­tar­i­ly.

And in what way is this …

… part of the over­ar­ch­ing top­ic FOSS Com­pli­ance? For ful­fill­ing the require­ments of FOSS licens­es, we have to con­sid­er spe­cif­ic indi­vid­ual cas­es as well as side effects — for soft­ware, pic­tures, or doc­u­ments. We should unhide trends and write guide­lines. Above all, how­ev­er, we must dri­ve for­ward the automa­tion of license ful­fill­ment, make our licens­ing knowl­edge freely avail­able, cast it into small­er tools, and bring it into larg­er sys­tems: Because FOSS thrives on free­dom through license ful­fill­ment, large and small. That’s what also this arti­cle is about.

2 Comments on “GPL-Licensed LilyPond Snippets — And Some Sideaffects”

  • Carl Sorensen


    I believe you are mis­in­ter­pret­ing the GPL license as it applies to Lily­Pond out­put.

    PDF files are not soft­ware, but out­put from soft­ware.

    Sim­i­lar­ly, MIDI files are not soft­ware, but out­put from soft­ware.

    gcc is licensed under GPL3. Using gcc to com­pile your pro­gram does not require you to dis­trib­ute your pro­gram under GPL terms, because your work is *NOT* a deriv­a­tive work. Instead, your work is sep­a­rate work that is cre­at­ed using the tools pro­vid­ed in gcc.

    Can you find a sin­gle ref­er­ence in any of the FSF dis­cus­sion of the GPL that indi­cates the out­put of a GPL pro­gram is cov­ered by the GPL?

    Here are two ques­tions and answers from the FSF GPL FAQ[1] that indi­cate the out­put is only cov­ered by the GPL if the out­put has a ver­ba­tim copy of the pro­gram. This is not the case for any LSR snip­pet of which I am aware.

    Is there some way that I can GPL the out­put peo­ple get from use of my pro­gram? For exam­ple, if my pro­gram is used to devel­op hard­ware designs, can I require that these designs must be free? (#GPLOut­put)
    In gen­er­al this is legal­ly impos­si­ble; copy­right law does not give you any say in the use of the out­put peo­ple make from their data using your pro­gram. If the user uses your pro­gram to enter or con­vert her own data, the copy­right on the out­put belongs to her, not you. More gen­er­al­ly, when a pro­gram trans­lates its input into some oth­er form, the copy­right sta­tus of the out­put inher­its that of the input it was gen­er­at­ed from.

    So the only way you have a say in the use of the out­put is if sub­stan­tial parts of the out­put are copied (more or less) from text in your pro­gram. For instance, part of the out­put of Bison (see above) would be cov­ered by the GNU GPL, if we had not made an excep­tion in this spe­cif­ic case.

    You could arti­fi­cial­ly make a pro­gram copy cer­tain text into its out­put even if there is no tech­ni­cal rea­son to do so. But if that copied text serves no prac­ti­cal pur­pose, the user could sim­ply delete that text from the out­put and use only the rest. Then he would not have to obey the con­di­tions on redis­tri­b­u­tion of the copied text.

    In what cas­es is the out­put of a GPL pro­gram cov­ered by the GPL too? (#What­Ca­seIsOut­put­G­PL)
    The out­put of a pro­gram is not, in gen­er­al, cov­ered by the copy­right on the code of the pro­gram. So the license of the code of the pro­gram does not apply to the out­put, whether you pipe it into a file, make a screen­shot, screen­cast, or video.

    The excep­tion would be when the pro­gram dis­plays a full screen of text and/or art that comes from the pro­gram. Then the copy­right on that text and/or art cov­ers the out­put. Pro­grams that out­put audio, such as video games, would also fit into this excep­tion.

    If the art/music is under the GPL, then the GPL applies when you copy it no mat­ter how you copy it. How­ev­er, fair use may still apply.

    Keep in mind that some pro­grams, par­tic­u­lar­ly video games, can have artwork/audio that is licensed sep­a­rate­ly from the under­ly­ing GPLed game. In such cas­es, the license on the artwork/audio would dic­tate the terms under which video/streaming may occur. See also: Can I use the GPL for some­thing oth­er than soft­ware?

    I do not think the issue you are con­cerned about is a prob­lem.

    Carl Sorensen



  • Karsten Reincke


    Many thanks for your exhaus­tive answer!

    Although your com­ment con­tains an impor­tant hint, it also pass­es the core of my argu­men­ta­tion:

    You com­pare GCC and Lily­Pond. And you con­clude, that — like in case of the GPL licensed GCC where the copy­left effect does not cov­er its out­put (the com­piled pro­gram), — also in case of the GPL licensed Lily­Pond the copy­left effect does not cov­er its out­put (the picture/pdf). Unfor­tu­nate­ly, that’s not my point:

    I am not argu­ing that my Lily­Pond work (or a snip­pet) is cov­ered by the GPL because it is ‘exe­cut­ed’ by Lily­Pond. I argue that my code is cov­ered by the GPL if I use (include or copy) a GPL licensed Lily­Pond snip­pet. And if it is cov­ered, then in accor­dance with the GPL §6 (title: “Con­vey­ing Non-Source Forms”) also the com­piled ver­sion is cov­ered by the GPL. (BTW: even a pic­ture is bina­ry code which still must be inter­pret­ed).

    Nev­er­the­less, your com­ment con­tains the impor­tant hint, that the FSF does not want that the out­put is cov­ered by the strong copy­left effect of its pro­grams.

    I would be hap­py if the state­ment you quot­ed would be judi­cial­ly approved! But as long as we do not have such a legal desci­sion there is a great risk that my sci­en­tif­ic and artis­ti­cal music work can freely be used due to the fact that I used a GPL licensed snip­pet for cre­at­ing the music scores — a risk, which I don’t want to take.

    But even if I agreed with your posi­tion, then we both still have to con­clude, that we can only dis­trib­ute/­hand-over our Lily­Pond code under the terms of the GPL, if our code used a GPL licensed snip­pet. And even this is a strong side effect.

    with best regards Karsten


Leave a Comment

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

To top