First of all, I think we have quite a consensus on what we intend - which is a
good start.
On Fri, 29 Mar 2013 09:43:59 -0500
Tim McNamara <tim...@bitstream.net> wrote:
> 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.
OK, that's clear. But the question is whether the GPL applies to the LilyPond
source files.
>
> > 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).
No, surely not. What we are discussing it, whether that has an impact on the
licensing of the input.
>
> 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. ;-)
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.
As you say the GPL applies to the source code that can be compiled into
software/applications.
The standard situation is:
Group A writes an application (let's say an image processing tool) and releases
its source under the GPL.
User B installs that program and uses it (as an end-user). The GPL doesn't
affect at all what he does with the images he processes with the program.
User C is a programmer and makes some modifications to the source code. As long
as he does this only for himself and doesn't redistribute anything the GPL
doesn't affect him either.
User D makes some modifications to the source code and wants to share them. Now
he's forced to share the modified program with all the implications of the GPL.
Now take a programming language as another example (PHP and Python are
explicitely _not_ distributed under the GPL BTW).
The interpreter is GPLed by group A, as well as some libraries.
User B writes a program in that language. This program is considered a 'user
document', and the GPL doesn't affect it - User B can publish the program in
any way he likes, with or without source code.
User C writes a program, but uses functions from the GPLed libraries. That
forces him to release his program under the GPL too.
And that's where we have our ambiguity.
I think we all agree that the author of .ly files should be free to license
them in any way he wants to:
- He can only give away the pdf results.
- He can give away the pdf together with the sources.
- If he choses to do so he may do so with any license he wants to.
The inclusion and use of functions from GPLed files is analogous to the use of
GPLed libraries in the programming language example. This _seems_ to imply that
the compiled results could only be distributed under the GPL, i.e. together
with the sources which have to be GPLed too etc.
But the result of the compilation isn't an application but a document.
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. Maybe not with a regular exception in the license
but with a clarification explicitely stating that .ly input files are
considered as documents and not as source code in the sense of the GPL?
Another consideration (which _could_ imply that there is nothing to do) could
be to consider the .ly or .scm files that are part of LilyPond's distribution
not as libraries but as _part of the distribution_. So they wouldn't have to be
treated as 'libraries' but as plain 'usage' of the LilyPond program.
And in the context of an independent LilyPond library (which was the cause for
this thread) I'd say a clarification as suggested above would be appropriate
(and enough).
Urs
>
> Tim
>
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
