Re: LilyPond, LilyPond snippets and the GPL

[Urs Liska]

Since I was off for nearly a day there may well be aspects I missed when trying to read through the whole thread, but I have the feeling that some thoughts still haven't been expressed.

Am 30.10.19 um 12:27 schrieb Urs Liska:

Sorry for being short: what you say is very much hiw I meant it but not all. I'll clarify later but am currently on the road. Maybe tonight of tomorrow.

Am 30. Oktober 2019 12:09:37 MEZ schrieb Karsten Reincke <address@hidden>:

Dear Urs;

many thanks for your clever thoughts! You brought up a very seductive argument,
which I therefore will only summarize here for being sure that I've understood you
correctly. May I condense your line of argumentation in the following way?

You point out that there could be a function in a GPL licensed snippet which only
modifies the apperance of a score. Such a function does not concern the music
itself. And therefore, the copyleft effect is not applied of the music.

That is not fully to the point. What I mean is (and what others have expressed more succinctly) is that such a function (say my \diplomaticLineBreak) is a *tool* that you use to express some auctorial decision (whether artistic or scientific), and in that respect it is exactly equal to using \ottava or \accidentalStyle.

Then it seems that you try to generalize your argumentation: Every piece of
LilyPond code describing the music score does not not concern the music, but only
the appearance. Hence the, the copyleft effect can not be applied to any results
of the LilyPond compilation process (the pdfs, pngs, ...)

No, I don't think that properly reflects my argument.
One of the main issues we have at play here (and that has been discussed by others in this thread) is that tools like LilyPond and LaTeX blur the lines between source, program, and document.

The arguments that are expressed *for* a requirement to license the PDF (etc.) files resulting from a LilyPond or LaTeX run are all based on the assumption that the graphical documents created like this are "comparable to the binary resulting from a compilation using a "typical" C compiler." I think (which others have stated earlier today) that the culprit here is that these arguments (e.g. when pointing to resources like https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary) assume that a "resulting PDF document" can be considered equivalent to a "resulting program" or "resulting software". It has been said several times: the PDF/PNG/SVG resulting from a LilyPond run is a document, not a program.

The issue that makes this complicated is the fact that in LilyPond and LaTeX the "document" is expressed in the same domain (the .ly files and included files) as the software that produces it. This makes it somehow difficult to cleanly separate the domains I still argue that all the functionality that you can *use* to create your document is comceptually separate from the *content* of your document.

I would argue that (except that the example is of course too small to be copyrightable) in a situation with

% library.ily
myFunction = trill

% document.ly
\include "library.ily"
{
  c \myFunction
}

the content of library.ily is *code* while the content of document.ly is *content*, and you use library.ily to produce a document from your content.

To use yet another analogy: this is like if you are using GIMP and a plugin, where the license of that plugin has no bearing on the licensing of the produced image file.

Please tell me, whether I got your point or not. Again, it seems to seductive and
I want to consider it a bit longer, before I will answer

There's one more point, and I think that hasn't been brought up by anyone yet. At some point you say "You can't have and eat the cake." But that holds true for your approach as well. If you insist on the interpretation that the GPL used for a snippet or library forces you to also license your document with the GPL then this holds true for *any* document you compile with LilyPond. an LSR or openLilyLib snippet is technically and conceptually identical to LilyPond.

Maybe you are not fully aware of how LilyPond works:

• There is LilyPond as a binary that is executed within your operating system.
• You can extend LilyPond's capabilities using the Scheme scripting language, which is done in the snippets we're talking about
• BUT: LilyPond itself includes a ton of .scm and .ly files that are not part of LilyPond-as-a-compiler but actually "included" in the document, either implicitly by LilyPond's startup routine or explicitly from your input files (as I've exemplified in my previous post).

These files and the functions provided by them are exactly the same as the functions you can copy from the LSR or include through openLilyLib. The are not part of the compiler but of the compiled document. And if you are convinced that the GPL of openLilyLib packages forces you to license your music with the GPL then you have to do so with *any* PDFs created by LilyPond because they are "derivative works" of LilyPond. Would you go that far? Then I'm afraid you'll have to abandon LilyPond altogether.

As you can imagine I think that idea is pretty absurd and can't be the result of all this.

To summarize:

• The issue is not that a library function is only affecting appearance and not content.
• Rather it is that the library function is only a tool you use to create the graphical representation of your content
• You own the copyright to the content, the library creator owns the copyright to the function
• Therefore you can license the content however you like, even when the library author licenses its library with the GPL

Urs

best regards karsten

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.