lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future of openLilyLib


From: David Kastrup
Subject: Re: Future of openLilyLib
Date: Tue, 22 Sep 2020 14:11:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Karsten Reincke <k.reincke@fodina.de> writes:

> Dear Carl;
>
> here is my explanation using the method of showing an analogy:
>
>
> (1.A) MIT/GNU Scheme:
> (a) is an interpreter of the Scheme programming language
> (b) is licensed under the GPL
> (c) takes Scheme Code & delivers output
>
> (https://www.gnu.org/software/mit-scheme/)
>
> => Any Scheme code being taken as input for the MIT/GNU Scheme
> interpreter may be licensed under any other license. The GPL copy left 
> effect only affects the development of the MIT/GNU Scheme interpreter
> itself.
>
>
> (1.B) guile-aspell
> (a) is a Guile Scheme library for comparing a string against a dictionary
> (b) is licensed under GPL 3+
> (c) is included into an overarching program functionally using this library
> (d) is interpreted by MIT/GNU Scheme in combination with the
> overarching program
>
> https://www.gnu.org/software/guile/libraries/
>
> => Due to §5.c of GPL-v3
> (https://www.gnu.de/documents/gpl-3.0.en.html) the overarching program
> using the library guile-aspell must be released under the terms of
> GPL-v3 too because it depends of the functionally of the guile-aspell
> library
>
> (2.A) Lilypond:
> (a) is an interpreter of the Lilypond notation language
> (b) is licensed under the GPL
> (c) takes Lilypond code & delivers output
>
> (https://lilypond.org/index.html)
>
> =>  Any Lilypond code being taken as input for the Lilypond program
> may be licensed under any other license. The GPL copy left effect only 
> affects the development of the Lilypond program itself
>
>
> (2.B) OpenLilyLib
> (a) is a Lilypond library for the GNU LilyPond music notation software
> (b) is licensed under GPL 3+
> (c) is included into an overarching lilypond music code functionally
> using this library
> (d) is interpreted by the LilyPond interpeter in combination with the
> overarching lilypond music code
>
> https://openlilylib.org/
>
> => Due to §5.c of GPL-v3
> (https://www.gnu.de/documents/gpl-3.0.en.html) the overarching
> lilypond code using the library OpenLilyLib must be released under the
> terms of GPL-v3 too because it depends of the functionally of the
> OpenLilyLib library

Sure, you cannot magically remove the GPL from LilyPond just because you
are using it in connection with OLL.  But that's a red herring.

> Summary:
>
> If I wrote a piece of music using LilyPond Code (for being interpreted
> by the Lilypond interpreter) and if I included OpenLilyLib into my
> code,

If you include OLL code by copy into your source code.  If you use its
advertised interfaces, however, that does not make it part of your code.

> you as the Copyright owners of OpenLilyLib could me enforce to
> distribute my work (music'score) under the terms of the GPL simply by
> using this analogy. By using my explanation, you would win every trial
> in every legal area which accepted the GPL as an effective
> license. That's the risk I would have to take, if I used OpenLilyLib
> to ease my work.

That's just garbage, sorry.  It would apply for LSR snippets which are
not used via an interface but are code pieces to be copied and adapted
into your source.  For LSR code, a GPL license would be quite
problematic (by the way, what is the licensensing of LSR pieces?).  But
that is not how OLL is used.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]