> From: Karsten Reincke <k.rein...@fodina.de>
> To: lilypond-user <lilypond-user@gnu.org>
> Cc: k.rein...@fodina.de
> Bcc:
> Date: Wed, 30 Oct 2019 00:06:32 +0100
> Subject: LilyPond, LilyPond snippets and the GPL
> 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.
>
> [6] If one has the right to use, to inspect, to modify and to
> redistribute (share) the (modified) work to/with third persons, then –
> in case of music – one has also the right to make music by using the
> music scores.
>
> (If you doubt these statements, please read
> https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ )
>
> Hence, now I reached the bad result: 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 in any form also and inherently gets the right to use it –
> for any purpose and without having to ask you again. In other words: by
> using any GPL licensed snippet you give away all your rights, even your
> artistic rights.
>
> I hope you understand why I cannot let automatically become my
> scientific or my musical work common property only because I use one
> GPL licensed LilyPond snippet for creating the sheet music of my
> examples or my musical work.
>
> 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.
>
> With respect to the question of Urs, I can now say: The existing LSR
> snippets can only be relicensed by the original copyright owners. But
> for the next uploaded files, it could be helpful, to recommend (or
> enforce?) their authors to license them under the CC0.
>
> And with respect to your OpenLilyLib, I, unfortunately, have to say
> this: I hope that you can conclude why I am not able to develop my
> snippet ‚harmonily‘ as part of your framework. But I will license it
> under the terms of the MIT. 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).
>
> In the hope having answered respectfully, appreciatively and clearly
> Karsten
>
>
> --
>   Karsten Reincke    /\/\   (+49|0) 170 / 927 78 57
>  Im Braungeröll 31   >oo<  mailto:k.rein...@fodina.de
> 60431 Frankfurt a.M.  \/    http://www.fodina.de/kr/



I'm trying to figure out what your issue really is.  I will say that I
generally agree that perhaps there is a better license choice for the LSR
than GPL.

However, I read your article, but it doesn't make sense.

It seems you think that, if you use code from the LSR as part of your input
files, that you are obligated to distribute both the input files and the
resulting PDF/MIDI files under the GPL.

This seems incorrect to me.  Of course, I'm not a lawyer, so I certainly
could be wrong.  But the reason it does not seem correct is based on the
paradigm you mention, which is that a program is not necessarily
distributed under the same license as either its input or output.


One thing you state is clearly incorrect:  "snippets are either linked into
the main code using the command #include “ABC.ly”..."   No, this is
actually part of the reason why the openlilylib is structured the way it
is, since the LSR is explicitly NOT a library or set of libraries, and many
people find that annoying.  openlilylib was started (as I understand it) by
people who do want a libary-based approach, since the LSR approach
encourages lots of duplication.

"Or they are literally copied into once [sic] own LilyPond music code."
 So, here we have the solution to your dilemma: don't copy them.  Rewrite
them to your satisfaction.  Use them as a reference for how to approach the
problem, and write your own solution.  I will very rarely use a snippet
as-is, and not for this legal reason, but because the snippet is usually in
the neighborhood of what I need, but not exactly.


Besides the debate about the letter of the law, then there is the reality
check part.

Which is to say, you seem to think that someone who voluntarily submitted
content to the LSR as "public domain" is going to turn around and state
that, because that language is either inaccurate, or does not hold
relevance in their legal domain, they will take you to court to force you
to comply with the terms and distribute both your input files and resulting
PDFs, or desist in distributing the work.

That seems far-fetched.  Who is this spectre haunting Europe that will go
after sheet music publishers for doing the exact thing that they intended
for you to do when they posted snippets for others to use freely?

Since you mention this is related to your company, perhaps you should tell
us what exactly your use case is?  Why does your employer care about this?


Thanks,

Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to