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.rein...@fodina.de
60431 Frankfurt a.M. \/ http://www.fodina.de/kr/
