lilypond-user
[Top][All Lists]
Advanced

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

Re: LilyPond, LilyPond snippets and the GPL


From: Karsten Reincke
Subject: Re: LilyPond, LilyPond snippets and the GPL
Date: Wed, 30 Oct 2019 01:23:57 +0100
User-agent: Evolution 3.34.1-2

On Wed, 2019-10-30 at 00:46 +0100, David Kastrup wrote:
> [...]
> 
> 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 agree with you, that the question, when and how a piece of code
definitely becomes a derivative work of another is not finally
clarified, especially not judically. Therefore, we all have to argue
and can finally only deliver more or less rational 'rule of thumbs'. I
argue the following way:

RMS has invented the LGPL to ensure that free code stays free. (weak
copyleft effect). And he invented the GPL to ensure that no one can use
the advantages of free software without let his own the advantages
using software becoome free software too. (strong copyleft effect).
This is the successful spirit of the free software world. (If you doubt
this, please consider, why the AGPL has been invented)

Hence, if I use a piece of software as library, snippet, or module,
then I am using the advantage that I do not have to program that code
by myself. I am saving costs and time. A very good indicator, that I am
saving resources by using the prework of another programer, is the call
of a function (or method or similar). Therefore, calling a function /
method delivered by a GPL licensed software indicates that I create a
derivative work and that the strong copyleft effect is triggered.

> 
> [...]
> 
> 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.
> 
No. In case of script languages, the MIT does implicitely prevent this
(and in case of compiled languages too, but there ir does not have any
visible effect):

The MIT license requires that "the above copyright notice and this
permission notice [the MIT license text] shall be included in all
copies or substantial portions of the Software". (
https://opensource.org/licenses/MIT) 

Hence, whenever you take over any substantial piece of my MIT licensed
code, then you have to add the MIT license text and my copyright line
too. Therefore, my code stays MIT licensed.

But of course, you are allowed to combine my code with your work and to
distribute your larger overarching work under any other license. As I
mentioned above: in case of compiled languages, you cannot see my code
anylonger. But in case of interpreted languages at least the
substantial portion is there and stays MIT licensed.

This aspect of distributing the larger work under different license is
often taken as 'relicensing' of the embedded MIT code. But in fact,
that's wrong - even if that does indeed not have any important effect.

best regards and thanks for your quick answer
Karsten

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





reply via email to

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