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
<k.rein...@fodina.de>:
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.