On 03/28/2013 08:28 PM, Tim McNamara wrote:
> My understanding is always been that the GPL applies to the software used to
> produce a file, not to the file itself.
I think (at least in this case) you mean "process", not "produce".
You can draw an analogy to e.g. shell scripts, where the fact that the bash
shell is GPL-licensed doesn't mean that shell scripts must also be GPL'd.
However, I'm not 100% convinced here because I think the situation of putting in
an \include to a GPL'd .ly file, and calling functions defined in that file,
might well make your own .ly file specifically a derivative work.
> Therefore, the GPL would not apply to the users' .ly files; the user has the
> option of specifying under what license any such files might be published.
That rests on the assumption that there is a separation between GPL'd
interpreter and the source file that's being interpreted. PHP is a nice example
-- the license of my PHP files can be independent of the license of PHP itself
(which as it happens is a dual-license between GPL and a custom license).
But when I start making calls in PHP to a written-in-PHP library that is GPL'd,
I think things become rather different.
I think the \import "somefile.ly" situation could be more analogous to this
second situation _where the .ly file defines functions that are used in your own
.ly file_. Hence it's an area of licensing concern.
And as I've stressed before, this licensing issue would kick in only if you
distributed your .ly file -- not if you distributed the graphical score produced
by processing it.
I will be away over the Easter weekend so not able to answer emails, but I'd
like to continue this discussion afterwards.
Thanks & best wishes,
-- Joe
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
