Karsten Reincke <k.rein...@fodina.de> 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