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 ... _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user