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: Tim McNamara
Subject: Re: Lilypond \include statements and the GPL
Date: Fri, 29 Mar 2013 09:43:59 -0500

On Mar 29, 2013, at 4:42 AM, Joseph Rushton Wakeling wrote:
> 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".

I didn't express myself very well, I realized after I re-read what I wrote.  
The GPL applies to source code that can be compiled into an application, not to 
the products of an application.  Thus LilyPond can be licensed under the GPL 
and that has implications for licensing an application that uses the LilyPond 
source code; however, the GPL does not apply to a PDF, PS, MIDI or other image 
file produced using LilyPond.  If I use Emacs to write a book and LaTeX to 
typeset it, I am not required to GPL the book.  This sort of thing was my 
intent.

> 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.

I don't see that a .ly or .ily file that may be \included creates a situation 
of derivation.  Lilypond is an application with a language that is somewhat 
similar to TeX in appearance and function.  As far as I can tell, if one uses a 
language that is GPL'd, this does not require that files written in that 
language also be GPL'd.  Most \include files modify the operation and output of 
LilyPond in some way and are functionally part of the application rather than 
the musical content of the file.  Using them does not have an affect on the 
licensing of the output (e.g., the PDF or MIDI file).  

I think that the user's copyrightable material consists of the music 
expressions between the curly braces.  It is separate from the LilyPond 
engraving language, which would not be copyrightable because it is released 
under the GPL.  So the formatting parts of a .ly file are derivative but the 
unique music expression- e.g., the music content, to use a term I have never 
been really happy with- cannot be considered derivative of LilyPond and is not 
subject to the GPL.  It may be derivative of something else and have other 
copyright issues, but those are independent of LilyPond.  The {} are the 
dividing line.

>> 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 am not sure that it would make a difference, because the copyrightable 
content (the music expressions) is separated from the LilyPond language by the 
curly braces.  It seems like a lot of weight to put on some {} symbols, but 
they are the demarcation line between the two aspects of a LilyPond file (one 
being what is rendered, the other being how it is rendered).  You'd end up with 
a hybrid copyleft/copyright file:  LilyPond functions which which are copyleft 
with an embedded music expression that is or can be copyrighted.  The music 
expression sort of lives in a walled neighborhood within a city, the 
neighborhood and the city having different property rights.

In short, \melody {} belongs to LilyPond and the GPL.  The c4 d e f g contained 
within the {  } is mine to license as I choose.

I think.  ;-)

Tim




reply via email to

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