lilypond-user
[Top][All Lists]
Advanced

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

Re: Lilypond \include statements and the GPL


From: David Kastrup
Subject: Re: Lilypond \include statements and the GPL
Date: Tue, 02 Apr 2013 15:52:16 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Joseph Rushton Wakeling <address@hidden> writes:

> On 03/29/2013 10:39 PM, Urs Liska wrote:
>> First of all, I think we have quite a consensus on what we intend -
>> which is a good start.
>
> Yup. :-)
>
>> I slightly disagree, although your considerations are valuable and
>> give some good insights in the situation.
>> I think the 'ambiguity' Joe is talking about is the ambiguity of
>> LilyPond's input files being 'user documents' and at the same time
>> compilable source code.
>
> Interestingly, it seems that TeX people are developing similar licensing
> concerns -- see e.g.:
> http://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages
>
>> I would say that the whole LilyPond input file should be considered
>> as a 'user document', and that the author should be completely free
>> to decide upon its licensing, whether or not he uses included
>> functions from LilyPond's distribution.
>> But as this discussion shows it's not really clear how GPL's
>> licensing model applies for that somewhat ambiguous situation. So it
>> might actually be necessary to clarify that.
>
> The problem is that while I think we can all agree on _intent_, the
> strict letter of the license may mandate something different.

The main difference is "work as a whole" vs "mere aggregation".  If you
include some file as a form of invoking its documented interface, you
form no new combined work.  If, however, you include a file, then patch
and access its internals, you are creating a new derived version of its
contents, and that would be covered by the GPL.

The GPL does not really define the work/aggregation difference, and
since there are gazillion ways to employ creative coding in order to
evade the letter of any definition, this is left for the courts to
decide, mostly according to local law.

With regard to linking executables, the FSF is of the position that
linking generally constitutes creating a derived work (whether linking
statically or dynamically), potentially via contributory infringement,
thus forming a fundamental difference between LGPL and GPL.  I find that
somewhat audacious, but short of actually decisive court precedents,
most people (and corporations) prefer not putting this theory to the
test.

-- 
David Kastrup




reply via email to

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