Re: Are lilypond output files subject to GPL?

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
<lilypond-devel@gnu.org> writes:

> Am Freitag, den 25.09.2020, 17:11 -0600 schrieb Carl Sorensen:
>> After our two-day break as requested by Jean, I thought I'd look for
>> something definitive about the question raised by Karsten.
>> 
>> I haven't found any cases where this question has been adjudicated, so we
>> don't have the court's opinion on this.
>> 
>> However, the FSF has been active in defending Free Software, and created
>> the GPL 3.0, the AGPL 3.0, and LGPL 3.0 in response to court cases and user
>> behavior.  And I think you would be hard-pressed to find anybody who is
>> stronger in terms of asserting "copyleft" than the FSF.
>> 
>> With that in mind, I find these the answers to these two questions in the
>> FSF GPL 3.0 FAQ to be clear, convincing, and certain that there is no
>> mechanism by which GPL 3.0 applied to LilyPond or OLL can result in GPL
>> requirements for LilyPond output.
>> 
>> [...]
>> 
>> Is there some way that I can GPL the output people get from use of my
>> program? For example, if my program is used to develop hardware designs,
>> can I require that these designs must be free? (#GPLOutput
>> <https://www.gnu.org/licenses/gpl-faq.en.html#GPLOutput>)
>> 
>> [...]
>> 
>> So the only way you have a say in the use of the output is if substantial
>> parts of the output are copied (more or less) from text in your program.
>
> AFAICT this is partially the case for the Postscript output, see the
> files in ps/ and in particular music-drawing-routines.ps, maybe also
> parts of scm/framework-ps.scm and scm/output-ps.scm. (The font is also
> embedded, but has an explicit "Font exception" for that case.)

It's becoming of little relevance these days since those code fragments
don't survive into PDF or bitmap files (PDF does not have a programming
language, so they are not _translated_ into PDF but _executed_ in order
to produce PDF) and nobody really cares about distributing PostScript
files.  But yes, considering a different license for files, similarly to
what GCC code stubs are covered with, would be a part of licensing
hygiene.

>> Having this strong statement from the FSF, I feel no need to worry
>> about losing my music to the GPL.  If anybody has case law where this
>> principle is violated, I would be happy to hear it.
>
> I think this addresses only part of the questions, namely the
> implications for the output. The other topic is sharing code that uses
> OLL, which is much less clear to me but IANAL. I would generally agree
> that LilyPond input files can be considered some form of
> "programming", but it's beyond my knowledge how GPL applies to
> functional languages like Scheme where there is no binary form. The
> main question (for me) is:
>
> Does "\include"ing OLL make the .ly file a "covered work" that is
> based on OLL?

While there is no way to reliably predict what any jury might find, I
don't think it makes sense to diverge too far from sanity for making
stipulations.

> As far as I understand, David K. expressed that merely calling the
> functionality has no implications. Getting a definite source for this
> would be great because I do see the potential concerns with this
> question; after all it would be different from linking to library
> compiled from, say, C code under the GPL.

It's worth pointing out that the legal theories surrounding the
connection between dynamic linking and being derived works have not
really been tested in court so far.  As long as nobody wants to test
that, the FSF uses this to achieve some leverage.  I doubt that they
would be terribly upset if they were challenged on that position and
lost in good faith in court as that would create a case of precedence
that would be helpful in other regards.  Basically, those with the means
to call their bluff stand to lose more than they do.

In the mean time, I don't think it makes sense to diverge too far from
sanity for making stipulations.

-- 
David Kastrup