Re: Future of openLilyLib (to Gilles and David

[Karsten Reincke]

On 22.09.20 13:05, Gilles Sadowski wrote:
> Hi.
>
> Moving back to the ML; it was not my intention to discuss this
> "off-list"; I hope I won't be sued for public disclosure of a private
> communication. ;-)
No problem! Moreover, I appreciate your respectful way to clarify 
understandings before jumping into the argumentation!
> [...]
> Then, I don't understand the rest of the reasoning.[1]
>
> Why do you require a different license for using an *external*
> extension (like OpenLilyLib), than for using any of 900+ (".ly"
> and ".scm" files bundled with LilyPond) internal ones.
>
> [...]

Dear Gilles,

That indeed touches the heart of the matter. Let me quickly sort the 
situation:

1) Lilypond describes itself as a compiler system: it takes text and 
compiles PDFs. (https://lilypond.org/text-input.html) In general, a 
compiler is an independent program. Its license (normally) does not 
affect the license of its input or output. The GCC (= GPLv3) can be used 
to compile MIT licensed code as well as closed source code. So far, so 
clear I hope.

2) On the first glance - and I had thought, it would be completely true 
- Lilypond seems to be a compiler like the GCC. Now, I've learned by 
you, Gilles, that this is indeed not 100% true: Also my system contains 
60 ly files under /usr/share/lilypond/2.20.0/ly and 93 scm files under 
/usr/share/lilypond/2.20.0/scm. At least many of these files seems to be 
explicitly licensed under the GPLv3 etc.

So, the simple question is this: Is on of these snippets / code 
particles under /usr/share/lilypond/2.20.0/ included=merged with "my" 
following lilypond code

\version "2.20.0"

\score {
    c'4
}

if I insert this code into Frescobaldi (which I did) and let it generate 
the PDF by using the app /usr/bin/lilypond (what it successfully did)

Please read "included/merged" in the meaning of the C Preprocessor: 'my' 
shortened code is expanded to another version which - after this 
expansion - is translated / compiled by the compiler.

2.A) If none of these additional files under /usr/share/lilypond/2.20.0/ 
is included/merged into my code, it does not depend on any GPL licensed 
code and hence I may license it under any license I prefer.

2.B) But if yes, 'my' HelloWorld 'song' depends on the program ly- 
and/or scm files under /usr/share/lilypond/2.20.0/. They are licensed 
under the GPLv3. Thus, we have to deal with copyleft effect in any sense 
because a GPL v3 licensed code is integrated into my code and my code 
does not work without that code.

Whether this inclusion / merging of the system ly/scm code by the 
'preprocessor' into my HelloWorld 'song' which uses this 'system-code' 
shall evoke the relationship of a derivative work, can only be clarified 
by the copyright holder of Lilypond! If they do not want the copyleft 
effect be understood in such a way, that it affects the code that uses 
it, then they must invent an exception clause because the act of merging 
code into another normally creates a derivative work.

So the answer to your question is this: The only difference between OLL 
and the internal Lilypond files is that OLL is external. Hence, them OLL 
copyright owners (and not the copyright owners of LilyPond) must state, 
how they want the copyleft be understood. If the copyleft effect shall 
not affect the calling code, they must create their own exception, 
otherwise one had to assume that the code using the OLL is a derivative 
work of the OLL.

3)  David Castrup stated in another post, that - in opposite to the OLL 
copyright owner - the developers of the LSR perhaps could enforce their 
rights in a trial, because their snippets are adapted / copied into the 
using code (and therefore - as he said - "for LSR code, a GPL license 
would be quite problematic"). But that - as he added - is not how OLL is 
used. Instead of this - he said -if one uses OLL by its advertised 
interfaces, that does not make it part of the using code.

And indeed: for using OLL one only has to download the OLL and has to 
make the OLL availbale by the -I (=include) option of lilypond -I 
~/oll-lib path/to/file.ly. (https://openlilylib.org/getstarted/install.html)

But now we've reached the same point agvain: from this viewpoint it is 
totally clear, that the OLL code is handed over to the compiler lilypond 
in a combination with the using program whose functionality depends on 
the OLL. The OLL is licensed under the GPL-v3, hence the using code is a 
derivative work of the OLL as long as the OLL does not offer an 
exception or statement or whatever, which clearly says, that the 
copyleft effect does not affect the code using the OLL.

So, again, we have the same conclusion: As long as the copyright owner 
of the OLL do not deliver an 'inclusion  exception' which states that 
the copyleft effect shall not affect the code which uses functions of 
the OLL, the users of the OLL have to take the risk to be enforced to 
release their music under the terms of the GPL.

4) Again: The solution is very simple! Add such a statement to the OLL, 
and we can use it without any legal risk. But if the copyright owner 
don't want to add such a clause (name mit however you want), we, the 
users have to consider, that the do not want to clarify the situation.

5) And now, after hopefully having understood the arguments of Gilles, I 
want also to ask the copyright owners of Lilypond to add such a 
clarifying clause.

I know, that I at best I bore you. Programmers love good free code, but 
they do not love to read licenses. But to all those of you who want to 
simplify the situation let me say: Complexity is like water. You can't 
compress it.

With best regards

Karsten


--
  Karsten Reincke    /\/\   (+49|0) 170 / 927 78 57
 Im Braungeröll 31   >oo<  mailto:k.reincke@fodina.de
60431 Frankfurt a.M.  \/    http://www.fodina.de/kr/