Are lilypond output files subject to GPL?

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

[see https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL ]


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

In general this is legally impossible; copyright law does not give you any
say in the use of the output people make from their data using your
program. If the user uses your program to enter or convert her own data,
the copyright on the output belongs to her, not you. More generally, when a
program translates its input into some other form, the copyright status of
the output inherits that of the input it was generated from.

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.
For instance, part of the output of Bison (see above) would be covered by
the GNU GPL, if we had not made an exception in this specific case.

You could artificially make a program copy certain text into its output
even if there is no technical reason to do so. But if that copied text
serves no practical purpose, the user could simply delete that text from
the output and use only the rest. Then he would not have to obey the
conditions on redistribution of the copied text.
In what cases is the output of a GPL program covered by the GPL too? (
#WhatCaseIsOutputGPL
<https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL>)

The output of a program is not, in general, covered by the copyright on the
code of the program. So the license of the code of the program does not
apply to the output, whether you pipe it into a file, make a screenshot,
screencast, or video.

The exception would be when the program displays a full screen of text
and/or art that comes from the program. Then the copyright on that text
and/or art covers the output. Programs that output audio, such as video
games, would also fit into this exception.

If the art/music is under the GPL, then the GPL applies when you copy it no
matter how you copy it. However, fair use
<https://www.gnu.org/licenses/gpl-faq.en.html#GPLFairUse> may still apply.

Keep in mind that some programs, particularly video games, can have
artwork/audio that is licensed separately from the underlying GPLed game.
In such cases, the license on the artwork/audio would dictate the terms
under which video/streaming may occur. See also: Can I use the GPL for
something other than software?
<https://www.gnu.org/licenses/gpl-faq.en.html#GPLOtherThanSoftware>
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.

Thanks,

Carl

[Dev mailing list]

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


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

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.

Jonas

[Jean ABOU SAMRA]

Le 26/09/2020 à 01:11, Carl Sorensen a écrit :

> 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.
>
> [see https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL ]
>
>
> 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>)
>
> In general this is legally impossible; copyright law does not give you any
> say in the use of the output people make from their data using your
> program. If the user uses your program to enter or convert her own data,
> the copyright on the output belongs to her, not you. More generally, when a
> program translates its input into some other form, the copyright status of
> the output inherits that of the input it was generated from.
>
> 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.
> For instance, part of the output of Bison (see above) would be covered by
> the GNU GPL, if we had not made an exception in this specific case.
>
> You could artificially make a program copy certain text into its output
> even if there is no technical reason to do so. But if that copied text
> serves no practical purpose, the user could simply delete that text from
> the output and use only the rest. Then he would not have to obey the
> conditions on redistribution of the copied text.
> In what cases is the output of a GPL program covered by the GPL too? (
> #WhatCaseIsOutputGPL
> <https://www.gnu.org/licenses/gpl-faq.en.html#WhatCaseIsOutputGPL>)
>
> The output of a program is not, in general, covered by the copyright on the
> code of the program. So the license of the code of the program does not
> apply to the output, whether you pipe it into a file, make a screenshot,
> screencast, or video.
>
> The exception would be when the program displays a full screen of text
> and/or art that comes from the program. Then the copyright on that text
> and/or art covers the output. Programs that output audio, such as video
> games, would also fit into this exception.
>
> If the art/music is under the GPL, then the GPL applies when you copy it no
> matter how you copy it. However, fair use
> <https://www.gnu.org/licenses/gpl-faq.en.html#GPLFairUse> may still apply.
>
> Keep in mind that some programs, particularly video games, can have
> artwork/audio that is licensed separately from the underlying GPLed game.
> In such cases, the license on the artwork/audio would dictate the terms
> under which video/streaming may occur. See also: Can I use the GPL for
> something other than software?
> <https://www.gnu.org/licenses/gpl-faq.en.html#GPLOtherThanSoftware>
> 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.
>
> Thanks,
>
> Carl
> 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.

I suggest contacting the FSF's Compliance Lab linked on the FAQ you
mention (https://www.gnu.org/licenses/gpl-faq.html), at [hidden email].
Surely they can help us sort things out.

Regards,
Jean

[David Kastrup]

Jonas Hahnfeld via Discussions on LilyPond development
<[hidden email]> 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