Re: Lilypond \include statements and the GPL

[Joseph Rushton Wakeling]

On 03/28/2013 06:35 PM, David Kastrup wrote:
> I don't see that.  \include is an instruction, not an actual inclusion.
> As opposed to dynamic linking, there is no combined entity being formed
> for the sake of execution where one could possibly claim "contributory
> infringement".  The inner workings of english.ly and its interoperation
> with LilyPond proper are not being accessed or questioned, either.

I take the point about instruction vs. real inclusion, i.e. that what the
\include command is saying is "read this set of instructions when processing
this file through Lilypond" rather than "include this material in the final
product".  But I feel it's still an unnecessary ambiguity.

english.ly isn't the best example of this, but suppose instead you have a .ly or
.ily file that defines a new command, and you use that new command throughout
your own .ly file?

The point here is that there is certainly not a combined entity coming out of
the running of your .ly file through the lilypond interpreter, but there _may_
be a combined entry in the form of your .ly source file containing calls to
functions defined in GPL-licensed files.

>> I can't imagine it's intentional that Lilypond copyleft should extend
>> so far as the .ly files of scores created by users, but as things
>> stand I'm concerned that this may be the strict letter of the
>> licensing.
> 
> I don't see that, short of _actual_ inclusion of english.ly etc.

Personally I feel it would be nice to resolve any potential ambiguity.

Obviously the best way to do this is just to show that I'm definitively wrong in
my interpretation (this would be nice:-), but aside from that I think there are
probably several other ways in which it could be done, including ensuring that
all files intended to be \include'd are licensed under something more permissive
(LGPL, BSD, Boost, Apache, ...), or adding a simple exception or clarification
to Lilypond's license akin to the GPL font exception.

I should add that the underlying motivation here is licensing clarity for some
of Urs and Janek's work on useful toolboxes for Lilypond.  It's clearly
desirable that these kits be copylefted as far as any code derivative is
concerned, but it's obviously not intended that the copyleft extend to users'
.ly files.

I was convinced that this issue must already have been systematically discussed
with respect to Lilypond's own files, hence my questions ...