Re: LilyPond, LilyPond snippets and the GPL

[David Kastrup]

Karsten Reincke <address@hidden> writes:

> By my last post, I, unfortunately, evoked a discussion concerning
> LilyPond, LilyPond snippets, and the GPL which actually did not belong
> to the original topic. During this discussion Harm stated, that „maybe
> LSR should better use GPL 3, not this deprecated one (Public Domain)“.
> Urs asked whether anything has to be done with respect to the Lilypond
> Snippet Repository. And Andrew asked whether I apprehend not to be able
> to use lilypond due to the fact that it is licensed under the GPL.
>
> I owned these comments by my statement, that I will not be able to use
> and to support the development of LilyPond snippets or libraries (as
> OpenLilyLIb) as long as they are licensed under the GPL. Meanwhile, I
> have written a thorough analysis of the situation. It is published
> under the title „LilyPond, LilyPond Snippets and GPL: About some bad
> side effects“. https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/
>
> For those, who do not want to read such an exhaustive document – I need
> this depth of detail due to my work as the open-source compliance
> officer of a Germany company – let me briefly summarize the line of
> argumentation:
>
> [1] The LilyPond language (interpreted by the LilyPond program which
> creates nice music sheets in the form of PDFs or PNGs) is a programming
> language.
>
> [2] The LilyPond interpreter is licensed under the GPL.
>
> [3] None of the existing Lilypond snippets is licensed under the GPL
> because the interpreter is licensed under the GPL (= no copyleft effect
> from the engine to its input/output). If they are licensed under the
> GPL, then it is a decision of the snippet authors, who also could have
> chosen one of the other open-source licenses.
>
> [4] But if a GPL licensed LilyPond snippet is used by another LilyPond
> code (either by a functional call into the included snippet or by
> literally copying the snippet into the other code), then the copyleft
> effect of the GPL is triggered.
>
> [5] The copyleft effect does not distinguish between distributing the
> source (the LilyPond code) or the compilation (the PDFs, the PNGs): it
> simply requires that the resulting work (the derivative work) has to be
> distributed (published) under the terms of the GPL too.

I disagree with your assessment that calling any code/function makes the
work doing so a derivative of that code (that would concern using
OpenLilyLib code).  I do agree that including/using/changing LSR
snippets as part of your work means deriving from them.  That's why I
would agree that using the GPL for the LSR snippets would not be
desirable since it would introduce a licensing regime where it seems
exaggerated.

> In my article, I also analyze the alternatives. The result is this:
> The best method is to license your work under the MIT license. The
> worse, but possible solution is, to use a creative commons license,
> especially the CC0 license.

LSR code is most of the time edited/adapted to particular use cases.
It's not really intended to be retained in a reasonably attributable
form, so I think that even the MIT license makes little sense.  CC0
seems fine to me, as basically an internationalised abstraction of
"Public Domain".

> That allows you, to integrate the code into your work (But only, if
> you preserve the MIT license which is part of the code. You will not
> be allowed to relicense my code – which should not disturb your work
> and goals).

MIT license definitely permits relicensing, but of course without
copyright to the actual code, you would not have standing for enforcing
the license of a relicensed (or non-relicensed) version, so that does
not make a whole lot of sense for an unmodified version.

-- 
David Kastrup