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: Joseph Rushton Wakeling
Subject: Re: Lilypond \include statements and the GPL
Date: Tue, 02 Apr 2013 23:01:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

On 04/02/2013 09:50 PM, Tim McNamara wrote:
> On Apr 2, 2013, at 12:47 PM, Joseph Rushton Wakeling wrote:
>> But now suppose that bobjones.ly defines a number of new functions, \bobFoo,
>> \bobBar, etc., and that you use them on a number of occasions throughout your
>> own .ly file.  Is the issue so clear any more?
> 
> I think again that these are references only and that this causes no problem 
> with copyright and the GPL; what will happen for anyone else who tries to 
> compile my .ly file is that it will fail.
> 
>> If that's not good enough, suppose that you don't just use Bob Jones' 
>> functions
>> in your .ly file, but you actually construct new functions of your own that 
>> use
>> Bob's functions.  Can you still say there's no issue?
> 
> Interesting question.  Insofar as I am not actually copying any of the "Bob 
> Jones.ly" code into my .ly file, I still think "no."  It is still only a 
> reference to copyrighted content, not the copyrighted content itself; if my 
> music functions actually contain code from "Bob Jones.ly" then yes, there is 
> a problem.
> 
> I can write a novel that tells the reader to go and read paragraph 3 on page 
> 241 of "Of Mice and Men" without violating Steinbeck's copyright.  I can even 
> write the sentence before and after the reference in such a way that they 
> make no sense of the reader doesn't read the paragraph in question, and still 
> not violate Steinbeck's copyright.  That's basically what \include does.  If 
> someone takes my .ly file and tries to compile it in the absence of having 
> "Bob Jones.ly," the compilation will just fail.  On the other hand, if I copy 
> Steinbeck's paragraph into my novel without permission, I have violated the 
> copyright.

OK, now let's consider a specific example.  Here's a bit of C code that
generates 100 random numbers and calculates their sum.

//////////////////////////////////////////////////////////////////////////////////////
#include <stdio.h>
#include <gsl/gsl_randist.h>

double random_number_sum(const gsl_rng *r, size_t n)
{
        size_t i;
        double x = 0.0;

        for(i=0; i<10; ++i)
                x += gsl_ran_flat(r, 0.0, 1.0);

        return x;
}

int main(void)
{
        size_t n = 100;
        gsl_rng *r = gsl_rng_alloc(gsl_rng_default);
        double x = random_number_sum(r, n);
        printf("The sum of %lu random numbers in [0, 1) is %g\n", n, x);
        gsl_rng_free(r);
        return 0;
}
//////////////////////////////////////////////////////////////////////////////////////

Let's go through it line by line.  The first line tells the compiler, when
compiling, to make use of the standard library header describing input and
output.  That doesn't matter -- it's a system library and therefore irrelevant
as far as licensing is concerned.  The second line tells the compiler to make
use of the header file describing the functions from the GNU Scientific Library
(GSL) that implement random number distributions.

Then you have a function which takes as part of its input a pointer to the
gsl-defined random number generator type, and which calls internally the GSL
function to generate a pseudo-random number from a uniform distribution.

Inside the main() function, there are calls to the GSL functions to allocate and
free memory in which to store a random number generator.

Now, just as in your case, I've not copied either stdio.h or gsl_randist.h.
I've not given them to you, either.  It's just an instruction to your compiler
to look for these files when trying to build the program, and if you try and
compile this program without those files present on your system, the compilation
will fail.

Nor does this program contain any copyrighted content from those files.
(Function names and APIs are generally considered to be uncopyrightable.)

However, I think the consensus of opinion about free software licensing would be
that, in distributing to you this little program, purely in source code form,
not compiled or linked in any way, I am still obliged to offer it to you under
licensing terms that are GPL-compatible, or else lose my right to use the GNU
Scientific Library.

The point is not that my program is derivative in the sense of copying content
from gsl_randist.h, but that it is a "covered work" in the language of the GPL
-- that is, a work based on the GPL-licensed program -- and I am only licensed
to distribute covered works under terms that are compatible with the GPL.

Now, I cannot personally see the distinction between what I have done with my
daft little bit of C source code, and what I have described to you in terms of
functions defined in a .ly file.

(Since I do in fact want to keep using the GNU Scientific Library, I should
probably say that of course I offer my daft little program to you under the
terms of the GPL, version 2 or, at your option, any later version.:-)

> Not write it off but let's not make it muckier than it already is.  For one 
> thing, there doesn't yet seem to be a real-life example of any of these 
> situations existing in the LilyPond world.

Waiting until someone falls foul of a problem we can anticipate, doesn't seem to
me to be a good idea.  The real-world example we have is that people are right
now working on a library of Lilypond functionality (conveyed as .ly files) which
implements various useful functions for others to use.  They would like to
distribute it under the terms of the GPL, for fairly obvious reasons.  But there
needs to be clarity over the impact of that licensing choice on users.

The fact that TeX users are having similar concerns (and that no one could
provide a concrete answer) ought to be a warning sign.

> Can one even write a LilyPond function that is not covered under the GPL, 
> given the terms of the LGPL, GPL3, etc?  I am not sure.

Lilypond, the program, is an interpreter.  So I don't see that per se calling
functions from Lilypond's public function interface (or writing code that
combines them) has a GPL requirement, any more than someone writing code in R
(the GPL-licensed statistical programming package) is obliged to license their
code under GPL.  (Similar situations apply for e.g. PHP or Python as we've
discussed.)

But, when you're talking about functions defined in a .ly file that has an
explicit GPL license, things are different (just as if I write an R program that
calls functions from a GPL-licensed module, things are different).

For what it's worth, though, I agree that this question ought to be part of any
formal request for advice to an organization like the SFLC.

> There are multiple "copyleft" licenses and most of them have inherent 
> problems- just as copyright has some inherent problems (Lessig describes them 
> quite well in his book; Stallman is more earthy his his descriptions).  The 
> GPL has managed to magnify some of those problems as it has attempted to 
> increase its reach over several revisions, which has paradoxically diminished 
> the presence of the GPL and has resulted in the proliferation of alternative 
> licenses.  One of those problems is that LilyPond .ly files are weird hybrids 
> of code and of art.  The GPL only applies to part of the file and a separate 
> set of copyright laws and licenses applies to the other part.

You may well be right about this last point.  The GPL explicitly notes:

> A compilation of a covered work with other separate and independent works,
> which are not by their nature extensions of the covered work, and which are 
> not
> combined with it such as to form a larger program, in or on a volume of a
> storage or distribution medium, is called an “aggregate” if the compilation 
> and
> its resulting copyright are not used to limit the access or legal rights of 
> the
> compilation's users beyond what the individual works permit. Inclusion of a
> covered work in an aggregate does not cause this License to apply to the other
> parts of the aggregate.

However, the two potentially independent parts in this case -- Lilypond
functions, and Lilypond musical input -- arrive combined in the same file and
are not readily separable.  In those circumstances, I am not confident that the
rules on "aggregate" works apply.

That's why I strongly suggest we look for clarification from people qualified to
offer it.



reply via email to

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