Re: LilyPond, LilyPond snippets and the GPL

[David Kastrup]

Karsten Reincke <address@hidden> writes:

> On Wed, 2019-10-30 at 01:36 +0100, David Kastrup wrote:
>> Karsten Reincke <address@hidden> writes:
>> 
>> > [...]
>> > 
>> > Hence, if I use a piece of software as library, snippet, or module,
>> > then I am using the advantage that I do not have to program that code
>> > by myself. I am saving costs and time. A very good indicator, that I am
>> > saving resources by using the prework of another programer, is the call
>> > of a function (or method or similar). Therefore, calling a function /
>> > method delivered by a GPL licensed software indicates that I create a
>> > derivative work and that the strong copyleft effect is triggered.
>> 
>> Which would imply that distributing your LilyPond input combined with
>> OpenLilylib code would require licensing your LilyPond input under the
>> GPL.
> Yes, exactly. That's my point.
>> 
>> It doesn't cover the output of running your LilyPond code, namely the
>> PDF.
>
> I am afraid that this statement does judicially not hold:
>
> LilyPond itself says that it works "[...] as a compiled system: [...] In some
> ways, LilyPond is more similar to a programming language [...]". Hence the
> viewpoint of Carl Sorensen seems to be valid: LilyPond is like the gcc. And 
> even
> in case of the gcc, the copyleft effect does not cover the outpout (the 
> compiled
> program).
>
> But in case of a GPL licensed LilyPond snippet (sic!), the copyleft effetc is
> triggered by the use of that snippet.

Why do you assume that?

> And the GPLv3 is very clear: §4 and §5 require us also to distribute
> the code of the embedding / using work under the terms of th GPL.

Embedding is not the same as using.

> And - under the title "Conveying Non-Source Forms" - §6 requires us
> also to distribute our non-source forms under the terms of the GPL.

It isn't a non-source form of the library but a non-source form of the
input representation of the music.

> Here, the analogy of gcc and Lilypond matches perfectly: As we are
> must distribute binaries which are compiled by the gcc on the base a
> GPL licensed source code,

The copyright/licensing of GCC has nothing to do with the
copyright/licensing of source code compiled with it.  There is a special
license clarification for stubs to be included in the binaries.
However, LSR code as a rule is not included in the resulting PDF or Midi
files.

> we must also distribute the binaries (png) which are compiled by
> LilyPond on the base of a GPL licensed LilyPond score description. It
> is exactly the same case.

The score description in question reflecting the content of the score is
copyrighted by its author.  Even when LilyPond was used for its
preparation, its copyright does not affect independently created
content.

> I regret to be the messenger of bad news. But there is a simple
> solution: Don't use GPL licensed LilyPond snippets, if wou want to
> keep you rights.

There is a difference between using _content_ of snippets and using
_mechanisms_ of snippets.

Apart from that, the list of snippets declares right at its start:

    LilyPond — Snippets
    *******************

    This document shows a selected set of LilyPond snippets from the
    LilyPond Snippet Repository (http://lsr.di.unimi.it) (LSR). It is in the
    public domain.

while the LilyPond Notation Reference is licensed under the GFDL.

> And perhaps convince the OpenLilyLib developers to relicense their
> work.

I don't see the necessity as long as no _content_ of OpenLilyLib is
redistributed as matters of its output.

-- 
David Kastrup