Re: LilyPond, LilyPond snippets and the GPL
> Am 2019-11-01 um 12:16 schrieb J Martin Rushton > : > > On 01/11/2019 10:45, Henning Hraban Ramm wrote: >> BTW there is _no_ copyright on the design of sheet music, even if some music >> publishers claim it. > > This depends upon the country. In the UK: "The typographical > arrangement of a published edition lasts for 25 years from first > publication". See Copyright Notice Number: 6/2016 at > https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/554033/Copyright_Notice_Printed_Music.pdf Ah, ok, then this is subject to the “sweat of the brow” concept. My statement is only valid for Germany. Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm https://www.fiee.net
Re: LilyPond, LilyPond snippets and the GPL
On 01/11/2019 10:45, Henning Hraban Ramm wrote: > > > BTW there is _no_ copyright on the design of sheet music, even if some music > publishers claim it. > This depends upon the country. In the UK: "The typographical arrangement of a published edition lasts for 25 years from first publication". See Copyright Notice Number: 6/2016 at https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/554033/Copyright_Notice_Printed_Music.pdf As the notice explains: "For example, the copyright in music by Ludwig van Beethoven is no longer protected by copyright, but editions of his work published in the last 25 years will have their typographical arrangement protected by the publisher, and modern editions, adaptations or arrangements of his work may still be protected by copyright for life of the adapter or arranger plus 70 years". Since most UK law is set by Brussels you need to carefully check the position in any EU country, it's likely to be the same. > > > Greetlings, Hraban > --- > fiëé visuëlle > Henning Hraban Ramm > https://www.fiee.net -- J Martin Rushton MBCS signature.asc Description: OpenPGP digital signature
Re: LilyPond, LilyPond snippets and the GPL
> Am 2019-10-31 um 03:15 schrieb Carl Sorensen : > > In the US, a typeface is not copyrightable. But a computer program that > makes a font or its glyphs is copyrightable. The "program code" of fonts is juristically not regarded a program, because it is usually auto-generated by a design tool. And the design of a font is not copyrightable in some legislations (e.g. Germany), because it’s regarded craftmanship and not art, because letters have to adhere to traditions to be readable. In other legislations (e.g. UK) the craftmanship of the design *is* copyrightable (see “sweat of the brow”). If the design of the letters would be regarded art, a license would be necessary for every single use of a letter! The copyright and licensing of fonts is a really complicated matter that I won’t cover here; you can look it up in Wikipedia. There is an international treaty about the copyright on fonts, but since it was not ratified by enough countries it’s not effective. BTW there is _no_ copyright on the design of sheet music, even if some music publishers claim it. LilyPond-generated PostScript code I see equivalent to the generation of fonts. But it might be juristically critical that code snippets get included in that PostScript code. While publishing of LilyPond source files –and apparently also LilyPond-generated PostScript– touches the copyright of the musical content as well as the copyright of the code (included in LilyPond’s distribution or from other sources), publishing of PDF and MIDI files regards only the copyright of the contents, since there is no LP code left in them. Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm https://www.fiee.net
Re: LilyPond, LilyPond snippets and the GPL
> On 31 Oct 2019, at 22:10, David Kastrup wrote: > > Hans Åberg writes: > >>> On 31 Oct 2019, at 21:31, David Kastrup wrote: >>> All those parts should be LGPL, and also included headers, I believe: Not GPL, because that would legal technically force copyright limitations on the output, and not public domain, because then one could exploit the inputs in ways you do not want. But check with the experts. >>> >>> I think this kind of stuff should just be exempt from licensing (namely >>> declared public domain) like stub code in GCC. It doesn't survive into >>> PDF anyway (since PDF is not programmable and so the PostScript-to-PDF >>> conversion executes the code in question rather than converting it) and >>> it is very unusual to distribute PostScript these days instead of >>> executing it right away in the form of some document processing >>> workflow. >>> >>> So that is indeed something that would warrant getting separate >>> appropriate licensing attention, but in most use cases it would end up >>> not being relevant since there are few workflows where a PostScript file >>> ends up as something to be distributed. >> >> It is only a problem if code survives in the output and is >> copyrightable. Like glyph designs, for example, there are in the works >> new microtonal accidentals, the design of which I figure would be >> copyrightable, and take a long time to develop. Would you want them to >> be in the public domain? It would mean that the design could be >> exploited freely without acknowledgement. With LGPL, any altered >> design must have the same license, but the glyphs can be used freely >> in publications. > > If I remember correctly, our fonts have already been relicensed under > some typical free font license several years ago. That is good. I merely wanted to illustrate the principle, that some stuff may survive into the output in copyrightable form. The most explicit example I have in my mind is the Bison skeleton file that originally was mostly verbatim, but now is processed using M4, and needs to be LGPL, not GPL, nor public domain.
Re: LilyPond, LilyPond snippets and the GPL
Hans Åberg writes: >> On 31 Oct 2019, at 21:31, David Kastrup wrote: >> >>> All those parts should be LGPL, and also included headers, I believe: >>> Not GPL, because that would legal technically force copyright >>> limitations on the output, and not public domain, because then one >>> could exploit the inputs in ways you do not want. But check with the >>> experts. >> >> I think this kind of stuff should just be exempt from licensing (namely >> declared public domain) like stub code in GCC. It doesn't survive into >> PDF anyway (since PDF is not programmable and so the PostScript-to-PDF >> conversion executes the code in question rather than converting it) and >> it is very unusual to distribute PostScript these days instead of >> executing it right away in the form of some document processing >> workflow. >> >> So that is indeed something that would warrant getting separate >> appropriate licensing attention, but in most use cases it would end up >> not being relevant since there are few workflows where a PostScript file >> ends up as something to be distributed. > > It is only a problem if code survives in the output and is > copyrightable. Like glyph designs, for example, there are in the works > new microtonal accidentals, the design of which I figure would be > copyrightable, and take a long time to develop. Would you want them to > be in the public domain? It would mean that the design could be > exploited freely without acknowledgement. With LGPL, any altered > design must have the same license, but the glyphs can be used freely > in publications. If I remember correctly, our fonts have already been relicensed under some typical free font license several years ago. -- David Kastrup
Re: LilyPond, LilyPond snippets and the GPL
> On 31 Oct 2019, at 21:31, David Kastrup wrote: > >> All those parts should be LGPL, and also included headers, I believe: >> Not GPL, because that would legal technically force copyright >> limitations on the output, and not public domain, because then one >> could exploit the inputs in ways you do not want. But check with the >> experts. > > I think this kind of stuff should just be exempt from licensing (namely > declared public domain) like stub code in GCC. It doesn't survive into > PDF anyway (since PDF is not programmable and so the PostScript-to-PDF > conversion executes the code in question rather than converting it) and > it is very unusual to distribute PostScript these days instead of > executing it right away in the form of some document processing > workflow. > > So that is indeed something that would warrant getting separate > appropriate licensing attention, but in most use cases it would end up > not being relevant since there are few workflows where a PostScript file > ends up as something to be distributed. It is only a problem if code survives in the output and is copyrightable. Like glyph designs, for example, there are in the works new microtonal accidentals, the design of which I figure would be copyrightable, and take a long time to develop. Would you want them to be in the public domain? It would mean that the design could be exploited freely without acknowledgement. With LGPL, any altered design must have the same license, but the glyphs can be used freely in publications.
Re: LilyPond, LilyPond snippets and the GPL
Hans Åberg writes: >> On 31 Oct 2019, at 03:15, Carl Sorensen wrote: >> >>> On 10/30/19, 5:13 PM, "Hans Åberg" wrote: >>> On 30 Oct 2019, at 22:14, Carl Sorensen wrote: The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries. What processed part remains in the output? >>> >>>If say somebody makes a snippet on how to make special type of >>> clef, then that is copyrightable, just as a font and its glyphs >>> are, it would seem, and that copyright will remain if >>> copy-and-pasted into user code. >> >> In the US, a typeface is not copyrightable. But a computer program >> that makes a font or its glyphs is copyrightable. I can see your >> argument here. But if this argument is true, then it seems that all >> music set with LilyPond is GPL3, because the code for drawing beams, >> stems, staff lines, and straight flags is in LilyPond and is >> licensed under GPL3. I find it very hard to believe that this is >> true. And certainly, as far as the FSF is concerned, this is not >> true. > > All those parts should be LGPL, and also included headers, I believe: > Not GPL, because that would legal technically force copyright > limitations on the output, and not public domain, because then one > could exploit the inputs in ways you do not want. But check with the > experts. I think this kind of stuff should just be exempt from licensing (namely declared public domain) like stub code in GCC. It doesn't survive into PDF anyway (since PDF is not programmable and so the PostScript-to-PDF conversion executes the code in question rather than converting it) and it is very unusual to distribute PostScript these days instead of executing it right away in the form of some document processing workflow. So that is indeed something that would warrant getting separate appropriate licensing attention, but in most use cases it would end up not being relevant since there are few workflows where a PostScript file ends up as something to be distributed. -- David Kastrup
Re: LilyPond, LilyPond snippets and the GPL
> On 31 Oct 2019, at 03:15, Carl Sorensen wrote: > >> On 10/30/19, 5:13 PM, "Hans Åberg" wrote: >> >>> On 30 Oct 2019, at 22:14, Carl Sorensen wrote: >>> >>> The snippets should be LGPL for being includable under other licenses, I >>> believe, because the processed part remains in the output, and thus >>> copyrightable. Thus, they play the same role as the Bison skeleton file and >>> GCC libraries. >>> >>> What processed part remains in the output? >> >>If say somebody makes a snippet on how to make special type of clef, then >> that is copyrightable, just as a font and its glyphs are, it would seem, and >> that copyright will remain if copy-and-pasted into user code. > > In the US, a typeface is not copyrightable. But a computer program that > makes a font or its glyphs is copyrightable. I can see your argument here. > But if this argument is true, then it seems that all music set with LilyPond > is GPL3, because the code for drawing beams, stems, staff lines, and > straight flags is in LilyPond and is licensed under GPL3. I find it very > hard to believe that this is true. And certainly, as far as the FSF is > concerned, this is not true. All those parts should be LGPL, and also included headers, I believe: Not GPL, because that would legal technically force copyright limitations on the output, and not public domain, because then one could exploit the inputs in ways you do not want. But check with the experts.
Re: LilyPond, LilyPond snippets and the GPL
On 10/30/19, 5:13 PM, "Hans Åberg" wrote: > On 30 Oct 2019, at 22:14, Carl Sorensen wrote: > >The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries. > > What processed part remains in the output? If say somebody makes a snippet on how to make special type of clef, then that is copyrightable, just as a font and its glyphs are, it would seem, and that copyright will remain if copy-and-pasted into user code. In the US, a typeface is not copyrightable. But a computer program that makes a font or its glyphs is copyrightable. I can see your argument here. But if this argument is true, then it seems that all music set with LilyPond is GPL3, because the code for drawing beams, stems, staff lines, and straight flags is in LilyPond and is licensed under GPL3. I find it very hard to believe that this is true. And certainly, as far as the FSF is concerned, this is not true. Carl
Re: LilyPond, LilyPond snippets and the GPL
Urs: ... > 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. ... Just to provide a data point... As I work with postscript files, the result is certaintly a program. Also files (at least one) from the lilypond distribution are included verbatim in the output (I.ps is just one file created using lilypond). // $ fgrep -a -A10 'procset (music-drawing-routines.ps)' I.ps %%BeginResource: procset (music-drawing-routines.ps) 1 0 %!PS-Adobe-2.0 % % Functions for direct and embedded PostScript % Careful with double % as comment prefix. % Any %%X comment is interpreted as DSC comments. % TODO: use dicts or prefixes to prevent namespace pollution. /pdfmark where // $ head -10 /Net/git/lilypond/ps/music-drawing-routines.ps %!PS-Adobe-2.0 % % Functions for direct and embedded PostScript % Careful with double % as comment prefix. % Any %%X comment is interpreted as DSC comments. % TODO: use dicts or prefixes to prevent namespace pollution. /pdfmark where // Regards, /Karl Hammar
Re: LilyPond, LilyPond snippets and the GPL
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
:
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
Re: LilyPond, LilyPond snippets and the GPL
> On 30 Oct 2019, at 22:14, Carl Sorensen wrote: > >The snippets should be LGPL for being includable under other licenses, I > believe, because the processed part remains in the output, and thus > copyrightable. Thus, they play the same role as the Bison skeleton file and > GCC libraries. > > What processed part remains in the output? If say somebody makes a snippet on how to make special type of clef, then that is copyrightable, just as a font and its glyphs are, it would seem, and that copyright will remain if copy-and-pasted into user code.
Re: LilyPond, LilyPond snippets and the GPL
> On 30 Oct 2019, at 23:36, David Kastrup wrote: > > Hans Åberg writes: > >>> On 30 Oct 2019, at 23:05, David Kastrup wrote: >>> >>> Hans Åberg writes: >>> The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries. >>> >>> LSR snippets are public domain already. >> >> So then this is not an issue, but public domain means that it can be >> exploited in ways you may not approve of, therefore LGPL would be >> better. But I am not an expert on such matters. > > For the snippets, that is a reasonable compromise avoiding the user > having reservations and headaches. They are more intended as starting > points for your own documents than as cut code. As examples, I have also done that. So if everyone is happy with that, it is a non-issue.
Re: LilyPond, LilyPond snippets and the GPL
Hans Åberg writes: >> On 30 Oct 2019, at 23:05, David Kastrup wrote: >> >> Hans Åberg writes: >> >>> The snippets should be LGPL for being includable under other licenses, >>> I believe, because the processed part remains in the output, and thus >>> copyrightable. Thus, they play the same role as the Bison skeleton >>> file and GCC libraries. >> >> LSR snippets are public domain already. > > So then this is not an issue, but public domain means that it can be > exploited in ways you may not approve of, therefore LGPL would be > better. But I am not an expert on such matters. For the snippets, that is a reasonable compromise avoiding the user having reservations and headaches. They are more intended as starting points for your own documents than as cut code. -- David Kastrup
Re: LilyPond, LilyPond snippets and the GPL
Hans Åberg writes: >> On 30 Oct 2019, at 18:48, Carl Sorensen wrote: >> >> This says to me that you can consider LSR snippets as part of the >> code used to create music (any music, not just your specific music). >> You can then put your specific music in a separate file, with >> separate copyright. And the modified LilyPond (including the LSR >> snippets) is a derivative work of LilyPond, and has GPL rights, and >> you would be required to share all of that code. But the created >> music engraving (pdf, svg, or midi) is not a derivative work of >> LilyPond, but an output of the program lilypond, and cannot be >> restricted by the GPL, according to the FSF. > > The snippets should be LGPL for being includable under other licenses, > I believe, because the processed part remains in the output, and thus > copyrightable. Thus, they play the same role as the Bison skeleton > file and GCC libraries. LSR snippets are public domain already. -- David Kastrup
Re: LilyPond, LilyPond snippets and the GPL
On 10/30/19, 3:17 PM, "Hans Åberg" wrote: > On 30 Oct 2019, at 22:14, Carl Sorensen wrote: > >>The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries. > > What processed part remains in the output? The part of them that one includes in ones own code, if large enough to be copyrightable. If you just look at them and write something else, it does not matter. How so? When I wrote fret-diagram code, and before it was accepted in the distribution, it could be contained in an included .ly file. When the fret-diagram code was executed, no part of that code ended up in the resulting PDF or PNG files. The fret-diagram code created ink at specified locations; but the specified locations were not part of the code I wrote. Instead they were generated by the interaction of the main lilypond distribution with the music input I wrote. And the result was printed music that matched my intent. If the music was original, the copyright was mine. If I was transcribing music from another composer, the copyright remained with the composer. The GPL had no influence on the copyright of the printed music. Carl
Re: LilyPond, LilyPond snippets and the GPL
On 10/30/19, 3:10 PM, "Hans Åberg" wrote: > On 30 Oct 2019, at 18:48, Carl Sorensen wrote: > >> 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. > > This says to me that you can consider LSR snippets as part of the code used to create music (any music, not just your specific music). You can then put your specific music in a separate file, with separate copyright. And the modified LilyPond (including the LSR snippets) is a derivative work of LilyPond, and has GPL rights, and you would be required to share all of that code. But the created music engraving (pdf, svg, or midi) is not a derivative work of LilyPond, but an output of the program lilypond, and cannot be restricted by the GPL, according to the FSF. The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries. What processed part remains in the output? Carl
Re: LilyPond, LilyPond snippets and the GPL
> On 30 Oct 2019, at 23:05, David Kastrup wrote: > > Hans Åberg writes: > >> The snippets should be LGPL for being includable under other licenses, >> I believe, because the processed part remains in the output, and thus >> copyrightable. Thus, they play the same role as the Bison skeleton >> file and GCC libraries. > > LSR snippets are public domain already. So then this is not an issue, but public domain means that it can be exploited in ways you may not approve of, therefore LGPL would be better. But I am not an expert on such matters.
Re: LilyPond, LilyPond snippets and the GPL
> On 30 Oct 2019, at 22:28, Carl Sorensen wrote: > >> On 10/30/19, 3:17 PM, "Hans Åberg" wrote: >> >>> On 30 Oct 2019, at 22:14, Carl Sorensen wrote: >>> The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries. >>> >>> What processed part remains in the output? >> >>The part of them that one includes in ones own code, if large enough to >> be copyrightable. If you just look at them and write something else, it does >> not matter. > > How so? When I wrote fret-diagram code, and before it was accepted in the > distribution, it could be contained in an included .ly file. > > When the fret-diagram code was executed, no part of that code ended up in the > resulting PDF or PNG files. The fret-diagram code created ink at specified > locations; but the specified locations were not part of the code I wrote. > Instead they were generated by the interaction of the main lilypond > distribution with the music input I wrote. And the result was printed music > that matched my intent. If the music was original, the copyright was mine. > If I was transcribing music from another composer, the copyright remained > with the composer. > > The GPL had no influence on the copyright of the printed music. It depends on the snippet then: If it just processes, GPL suffices; if it is stuff that remains in the output albeit it processed form, it ought to be LPGL if one wants it to freely usable. The Bison skeleton file has stuff that part is copied verbatim, part processed with M4, and compiled with languages like C/C++, and the copyrightability remains through it all, that is why it is LGPL. LGPL would be simplest not having to working through all individual cases. But that is just my take on it.
Re: LilyPond, LilyPond snippets and the GPL
> On 30 Oct 2019, at 22:14, Carl Sorensen wrote: > >>The snippets should be LGPL for being includable under other licenses, I >> believe, because the processed part remains in the output, and thus >> copyrightable. Thus, they play the same role as the Bison skeleton file and >> GCC libraries. > > What processed part remains in the output? The part of them that one includes in ones own code, if large enough to be copyrightable. If you just look at them and write something else, it does not matter.
Re: LilyPond, LilyPond snippets and the GPL
> On 30 Oct 2019, at 18:48, Carl Sorensen wrote: > >> 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. > > This says to me that you can consider LSR snippets as part of the code used > to create music (any music, not just your specific music). You can then put > your specific music in a separate file, with separate copyright. And the > modified LilyPond (including the LSR snippets) is a derivative work of > LilyPond, and has GPL rights, and you would be required to share all of that > code. But the created music engraving (pdf, svg, or midi) is not a > derivative work of LilyPond, but an output of the program lilypond, and > cannot be restricted by the GPL, according to the FSF. The snippets should be LGPL for being includable under other licenses, I believe, because the processed part remains in the output, and thus copyrightable. Thus, they play the same role as the Bison skeleton file and GCC libraries.
Re: LilyPond, LilyPond snippets and the GPL
On 10/30, Karsten Reincke wrote: > 1) I did not refer to the libstdc or anything else for which indeed > the gcc runtime exception can be used. I am talking about the a bit > abstract case of using a GPL licensed library or module or snippet as > base of ones work compiled by the GCC to complere the analogy used by > other participants of this discussion. Okay, then GCC didn't need to be brought up at all. Sorry for misunderstanding. That said, a pdf generated by Lilypond still does not need to contain or use any Lilypond code. Users do not need to fear that they will "lose their rights" if they use a GPL'd snippet. > it is complete misleading if you say that I > > a) want to enforce Urs to relicense his work I'm not sure how else to interpret a call to "perhaps convince the OpenLilyLib developers to relicense their work." Mason signature.asc Description: PGP signature
Re: LilyPond, LilyPond snippets and the GPL
From: Karsten Reincke Date: Wednesday, October 30, 2019 at 9:02 AM To: Henning Hraban Ramm , lilypond-user Cc: Subject: Re: LilyPond, LilyPond snippets and the GPL On Wed, 2019-10-30 at 15:08 +0100, Henning Hraban Ramm wrote: [...] It’s the same if you publish a book using TeX: No, it isn't. Actually, it is. While original TeX is PD and some other parts have their own licenses, those never apply to the contents of your book or the PDF or printed version of it, That's an unproven proposition In the TeX world, it may be unproven. In the GPL world, with the best legal advice the license creators could get, it is proven. See their FAQ. because the code of TeX (or LilyPond) isn’t in there, it was just used to generate the result. (Same if you use OS software to generate graphics, videos etc.) Not it isn't. Again - like others in this thread - you are mixing the cases Actually, I think you are mixing the cases. a) The GCC, the TeX-engine, and LilyPond are programs, which take a piece of source code and compile the output (Binary, PDF, PNG). b) The licenses of these engines do not influence the licensing of the input or output. c) But if the gcc compiles a source code, which uses the prework of a GPL licensed library, snippet, or anything else, then - in accordance to the GPL-v3 §6 - the compiled program (binary) has also to be distributed under the terms of the GPL (strong copyleft effect). If you deny this statement, then you argue against the idea of the Free Software itself. This is true, not because of the license of gcc, but because of the license of the program that is used by the gcc (the library). And it holds true because the output of gcc is a *program*, i.e., a piece of software executed by the computer to achieve desirable results. And it needs the four freedoms that the FSF cares about. d) If the TeX engine compiles a LaTeX source code, which uses the prework of a GPL licensed style or anything else, then indeed - in accordance to the GPL-v3 §6 (titled "Conveying Non-Source Forms"), the compiled result (the PDF etc.) has to be distributed under the terms of the GPL too. That's stated in and by the LaTex community (e.g. https://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages ). And that's the reason, why ctan mostly does not contain GPL licensed packages. That’s stated by one person in the LaTeX community, and only upvoted by 3 people in the LaTeX community. I suppose it creates a non-zero risk of having that argument upheld, and you are free to act according to that risk. Personally, I am sure that if somebody tried to sue a user demanding the application of GPL to the output of the TeX processing based on the usage of a GPL package, the FSF would get involved in the lawsuit. The FSF can’t afford to have this interpretation hold, because if this interpretation held up in court, nobody would ever license software by the GPL. And it’s clearly contrary to the stated intent of the GPL. Quoting from the GPL FAQ: 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.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. This says to me that you can consider LSR snippets as part of the code used to create music (any music, not just your specific music). You can then put your specific music in a separate file, with separate copyright. And the modified LilyPond (including the LSR snippets) is a derivative work of LilyPond, and has GPL rights, and you would be required to share all of that code. But the created music engraving (pdf, svg, or midi) is not a derivative work of LilyPond, but an output of the program lilypond, and cannot be restricted by the GPL, according to the FSF. e) If the LilyPond engine compiles a LilyP
Re: LilyPond, LilyPond snippets and the GPL
On 10/30/19, 11:48 AM, "Karsten Reincke" wrote: 2) Your polemic attack is wrong and unfair. If you had read my posts carefully, you would know [and probably you know it, but withhold this aspect], that I offered URS already the opportunity to integrate my coming lib - licensed under the MIT license - into his OpenLIlyLib. I only refused and refuse to use any GPL licensed Lilypond snippet as 'module' / 'lib' for my own work. I am curious as to why you feel you cannot use any GPL licensed LilyPond snippet but you can use the GPL licensed lilypond itself. What about a snippet makes it more invasive in terms of the GPL than the original program? I don't understand. Carl
Re: LilyPond, LilyPond snippets and the GPL
On Wed, 2019-10-30 at 09:41 -0700, ma...@masonhock.com wrote: > On 10/30, Karsten Reincke wrote: > > 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, 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 rational for the GCC exception is "These libraries are automatically > used by the object code that GCC produces. Because of that, if these > libraries were simply distributed only under the terms of the GPL, all > the object code that GCC produces would have to be distributed under the > same terms."[1] > > This does not apply here. A pdf generated by Lilypond does not > automatically use any snippets of Lilypond code. A pdf reader can't > even do anything with Lilypond code. You can distribute the pdf under > any license you want. The GPL only comes into play if you distribute > your Lilypond code. > > All of this is beside the point, though. The library that started this > discussion (analysis) is for "graphical highlighting of musical > analysis," which is probably not something you need in order to engrave > and publish your music. It seems more likely that the purpose behind > this FUD about the GPL is to put pressure on Urs to relicense of > analysis so that you can use it in harmonyli without having to comply > with the GPL. > > On 10/30, Karsten Reincke wrote: > > RMS has invented the LGPL to ensure that free code stays free. (weak > > copyleft effect). > > RMS intends the LGPL for libraries that do not provide any practical > advantages over existing non-GPL'd alternatives.[2] The fact that you > are complaining about the license instead of using a different library > indicates that the license was probably chosen correctly. > > On 10/30, Karsten Reincke wrote: > > 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. And perhaps convince the OpenLilyLib developers to > > relicense their work. > > There it is. > > Mason Dear Mason; before you shoot, you should perhaps carefully read the line of argumentation: 1) I did not refer to the libstdc or anything else for which indeed the gcc runtime exception can be used. I am talking about the a bit abstract case of using a GPL licensed library or module or snippet as base of ones work compiled by the GCC to complere the analogy used by other participants of this discussion. 2) Your polemic attack is wrong and unfair. If you had read my posts carefully, you would know [and probably you know it, but withhold this aspect], that I offered URS already the opportunity to integrate my coming lib - licensed under the MIT license - into his OpenLIlyLib. I only refused and refuse to use any GPL licensed Lilypond snippet as 'module' / 'lib' for my own work. 3) And if you follow the thread thoroughly, you could also have known, that I was asked by Urs to take a look at OpenLilyLib instead of inventing the wheel twice. To reason why I can't do that is matter of courtesy. Hence it is complete misleading if you say that I a) want to enforce Urs to relicense his work b) do not want to develop my own snippet (I am doing that already) EOM KARSTN -- Karsten Reincke/\/\ (+49|0) 170 / 927 78 57 Im Braungeröll 31 >oo< mailto:k.rein...@fodina.de 60431 Frankfurt a.M. \/http://www.fodina.de/kr/
Re: LilyPond, LilyPond snippets and the GPL
On 10/30, Karsten Reincke wrote: > 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, 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 rational for the GCC exception is "These libraries are automatically used by the object code that GCC produces. Because of that, if these libraries were simply distributed only under the terms of the GPL, all the object code that GCC produces would have to be distributed under the same terms."[1] This does not apply here. A pdf generated by Lilypond does not automatically use any snippets of Lilypond code. A pdf reader can't even do anything with Lilypond code. You can distribute the pdf under any license you want. The GPL only comes into play if you distribute your Lilypond code. All of this is beside the point, though. The library that started this discussion (analysis) is for "graphical highlighting of musical analysis," which is probably not something you need in order to engrave and publish your music. It seems more likely that the purpose behind this FUD about the GPL is to put pressure on Urs to relicense of analysis so that you can use it in harmonyli without having to comply with the GPL. On 10/30, Karsten Reincke wrote: > RMS has invented the LGPL to ensure that free code stays free. (weak > copyleft effect). RMS intends the LGPL for libraries that do not provide any practical advantages over existing non-GPL'd alternatives.[2] The fact that you are complaining about the license instead of using a different library indicates that the license was probably chosen correctly. On 10/30, Karsten Reincke wrote: > 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. And perhaps convince the OpenLilyLib developers to > relicense their work. There it is. Mason [1] https://www.gnu.org/licenses/gcc-exception-3.1-faq.html [2] https://www.gnu.org/licenses/why-not-lgpl.html signature.asc Description: PGP signature
Re: LilyPond, LilyPond snippets and the GPL
On Wed, 2019-10-30 at 15:08 +0100, Henning Hraban Ramm wrote: > [...] > It’s the same if you publish a book using TeX: No, it isn't. > While original TeX is PD and some other parts have their own licenses, those > never apply to the contents of your book or the PDF or printed version of it, That's an unproven proposition > because the code of TeX (or LilyPond) isn’t in there, it was just used to > generate the result. (Same if you use OS software to generate graphics, videos > etc.) Not it isn't. Again - like others in this thread - you are mixing the cases a) The GCC, the TeX-engine, and LilyPond are programs, which take a piece of source code and compile the output (Binary, PDF, PNG). b) The licenses of these engines do not influence the licensing of the input or output. c) But if the gcc compiles a source code, which uses the prework of a GPL licensed library, snippet, or anything else, then - in accordance to the GPL-v3 §6 - the compiled program (binary) has also to be distributed under the terms of the GPL (strong copyleft effect). If you deny this statement, then you argue against the idea of the Free Software itself. d) If the TeX engine compiles a LaTeX source code, which uses the prework of a GPL licensed style or anything else, then indeed - in accordance to the GPL-v3 §6 (titled "Conveying Non-Source Forms"), the compiled result (the PDF etc.) has to be distributed under the terms of the GPL too. That's stated in and by the LaTex community (e.g. https://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages ). And that's the reason, why ctan mostly does not contain GPL licensed packages. e) If the LilyPond engine compiles a LilyPond music source code, which uses the prework of a GPL licensed LilyPond snippet, then - in accordance to the GPL-v3 §6 (titled "Conveying Non-Source Forms"), the compiled result (the PDF, PNG) has to be distributed under the terms of the GPL too. Why should c) and d) be valid, but not e)? You can't have and eat the cake. If we want to protect the 'biotope' of free and open source software from being misused and if we want that others respect the licensing rules, then at least we have to take the license texts as seriously as possible. They are not a hawker's tray from which we can take what we love and ignore the rest. With best regards Karsten
Re: LilyPond, LilyPond snippets and the GPL
Am 2019-10-30 um 13:06 schrieb David Kastrup : > > You are correct that you cannot license the source under any license > other than the GPL if you are going to distribute it containing GPL > licensed snippets (the LSR snippets are PD, the Notation Reference > contents GFDL). But the PDF reflecting your source code is a derivative > of the actual content-reflecting parts of the source code. Of which you > are the copyright holder. It’s the same if you publish a book using TeX: While original TeX is PD and some other parts have their own licenses, those never apply to the contents of your book or the PDF or printed version of it, because the code of TeX (or LilyPond) isn’t in there, it was just used to generate the result. (Same if you use OS software to generate graphics, videos etc.) A *program* that’s using open source code *contains* this code (in compiled form). On the other hand if I write a book *about* TeX and show a lot of its code or copy examples from the FDL-licensed documentation, my book also falls under that license. While the publisher can sell copies, we can’t prohibit users to make their own copies, becaus the book is derived work of the publicly available documentation. Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm https://www.fiee.net
Re: LilyPond, LilyPond snippets and the GPL
Am 30. Oktober 2019 12:45:06 MEZ schrieb Karsten Reincke : >Dear Elaine > >On Tue, 2019-10-29 at 18:13 -0700, Flaming Hakama by Elaine wrote: >> [...] >> It seems you think that, if you use code from the LSR as part of your >input >> files, that you are obligated to distribute both the input files and >the >> resulting PDF/MIDI files under the GPL. >YES, if the LSR snippet was licensed under the GPL (In fact, the LSR >snippets are >not licensed under the GPL, they are Public Domain, I know!) >> > >> One thing you state is clearly incorrect: "snippets are either >linked into the >> main code using the command #include “ABC.ly”..." No, this is >actually part of >> the reason why the openlilylib is structured the way it is, since the >LSR is >> explicitly NOT a library or set of libraries, and many people find >that >> annoying. openlilylib was started (as I understand it) by people who >do want a >> libary-based approach, since the LSR approach encourages lots of >duplication. > >I cannot say anything about the methods of OpenLilyLib - because I did >not find >any 'Hello World' example which I could compile on my machine (Ubuntu >19.10). >(This is another topic, which I want to ignore in this context.) > openLilyLib may be awfully underdocumented, but there are usage examples all over the place, really. I think every package or module has an example next to it or a usage-wxamples directory... >But at least without beside using OpenLilyLib you have to methods to >use the LSR >snippets: either you save the snippet in your file tree and insert an >include >directive into your code which takes the path to that file as an >argument. Or you >copy the snippet literally and directly into your code. > > >> So, here we have the solution to your dilemma: don't copy them. > >Yeep, that's what I will do: as long as I am afraid to lose not only my >LilyPond >code (which I do not care), but the rights of my using scientific / >musical work, >I won't use any snippet which is license und er GPl. All other snippets >are ok. >And the LSR is a great help. > >> [...] Besides the debate about the letter of the law, then there is >the reality >> check part. >> >> Which is to say, you seem to think that someone who voluntarily >submitted >> content to the LSR as "public domain" is going to turn around and >state that, >> because that language is either inaccurate, or does not hold >relevance in their >> legal domain, they will take you to court to force you to comply with >the terms >> and distribute both your input files and resulting PDFs, or desist in >> distributing the work. >Yes and No. > >No, because I do not believe, that contributors to the LSR, later on, >change their >mind or want to attack us due to an infringement based on the weakness >of a local >legal system (But can we really be sure? Do you know that we have a lot >of patent >trolls and meanwhile also GPL trolls, who invented a business model on >suing users >because of a non-compliant use of a GPL licensed program?) > >And yes, because I believe in good systems. And if we minimize the >weakness of a >system, then we should do that. The weakness of the LSR is, that Europe >does not >know the idea of 'public domain' (based on the principle, that you >first have to >claim your copyrights before you grant any rights). In Europe, nearly >every work >has a copyright owner. Hence every snippet contributed by a European >citizen >legally is not correctly contributed. This could be healed by using the >CC0: It >also talks about the public domain, but it explicitly grants all rights >to the >users without requiring any service in return. > >Best regards Karsten -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: LilyPond, LilyPond snippets and the GPL
Karsten Reincke writes: > Many thanks for your comment. It contains an important hint. BUt it is a bit > apart > from my crucial point: > > I am not arguing that my LilyPond work (or a snippet) is covered by >the GPL because it is 'executed' by LilyPond. I argue that my code is >covered by the GPL if I use (include or copy) a GPL licensed >snippet. And if it is covered, then in accordance to the GPL §6 (title: >"Conveying Non-Source Forms") also the compiled version is covered by >the GPL. (BTW: even a picture is binary code which is interpreted) You are correct that you cannot license the source under any license other than the GPL if you are going to distribute it containing GPL licensed snippets (the LSR snippets are PD, the Notation Reference contents GFDL). But the PDF reflecting your source code is a derivative of the actual content-reflecting parts of the source code. Of which you are the copyright holder. So the solution is not to distribute your source code embedding GPLed elements. -- David Kastrup
Re: LilyPond, LilyPond snippets and the GPL
Karsten Reincke writes: > On Wed, 2019-10-30 at 01:36 +0100, David Kastrup wrote: >> Karsten Reincke 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
Re: LilyPond, LilyPond snippets and the GPL
Dear Elaine On Tue, 2019-10-29 at 18:13 -0700, Flaming Hakama by Elaine wrote: > [...] > It seems you think that, if you use code from the LSR as part of your input > files, that you are obligated to distribute both the input files and the > resulting PDF/MIDI files under the GPL. YES, if the LSR snippet was licensed under the GPL (In fact, the LSR snippets are not licensed under the GPL, they are Public Domain, I know!) > > One thing you state is clearly incorrect: "snippets are either linked into > the > main code using the command #include “ABC.ly”..." No, this is actually part > of > the reason why the openlilylib is structured the way it is, since the LSR is > explicitly NOT a library or set of libraries, and many people find that > annoying. openlilylib was started (as I understand it) by people who do want > a > libary-based approach, since the LSR approach encourages lots of duplication. I cannot say anything about the methods of OpenLilyLib - because I did not find any 'Hello World' example which I could compile on my machine (Ubuntu 19.10). (This is another topic, which I want to ignore in this context.) But at least without beside using OpenLilyLib you have to methods to use the LSR snippets: either you save the snippet in your file tree and insert an include directive into your code which takes the path to that file as an argument. Or you copy the snippet literally and directly into your code. > So, here we have the solution to your dilemma: don't copy them. Yeep, that's what I will do: as long as I am afraid to lose not only my LilyPond code (which I do not care), but the rights of my using scientific / musical work, I won't use any snippet which is license und er GPl. All other snippets are ok. And the LSR is a great help. > [...] Besides the debate about the letter of the law, then there is the > reality > check part. > > Which is to say, you seem to think that someone who voluntarily submitted > content to the LSR as "public domain" is going to turn around and state that, > because that language is either inaccurate, or does not hold relevance in > their > legal domain, they will take you to court to force you to comply with the > terms > and distribute both your input files and resulting PDFs, or desist in > distributing the work. Yes and No. No, because I do not believe, that contributors to the LSR, later on, change their mind or want to attack us due to an infringement based on the weakness of a local legal system (But can we really be sure? Do you know that we have a lot of patent trolls and meanwhile also GPL trolls, who invented a business model on suing users because of a non-compliant use of a GPL licensed program?) And yes, because I believe in good systems. And if we minimize the weakness of a system, then we should do that. The weakness of the LSR is, that Europe does not know the idea of 'public domain' (based on the principle, that you first have to claim your copyrights before you grant any rights). In Europe, nearly every work has a copyright owner. Hence every snippet contributed by a European citizen legally is not correctly contributed. This could be healed by using the CC0: It also talks about the public domain, but it explicitly grants all rights to the users without requiring any service in return. Best regards Karsten
Re: LilyPond, LilyPond snippets and the GPL
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 : >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. > >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, ...) > >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 > >best regards karsten -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: LilyPond, LilyPond snippets and the GPL
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. 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, ...) 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 best regards karsten
Re: LilyPond, LilyPond snippets and the GPL
On Wed, 2019-10-30 at 01:36 +0100, David Kastrup wrote: > Karsten Reincke 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. 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. And - under the title "Conveying Non-Source Forms" - §6 requires us also to distribute our non-source forms under the terms of the GPL. 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, 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. 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. And perhaps convince the OpenLilyLib developers to relicense their work. with best reagards Karsten -- Karsten Reincke/\/\ (+49|0) 170 / 927 78 57 Im Braungeröll 31 >oo< mailto:k.rein...@fodina.de 60431 Frankfurt a.M. \/http://www.fodina.de/kr/
Re: LilyPond, LilyPond snippets and the GPL
On Wed, 2019-10-30 at 00:55 +, Carl Sorensen wrote: > > On 10/29/19, 5:46 PM, "David Kastrup" wrote: > > Karsten Reincke wrotes: > >[...] > > > > [4] But if a GPL licensed LilyPond snippet is used by another LilyPond > > code (either by a functional call into the included snippet or by > > literally copying the snippet into the other code), then the copyleft > > effect of the GPL is triggered. > > > [...] > > I disagree with your assessment that calling any code/function makes the > work doing so a derivative of that code (that would concern using > OpenLilyLib code). I do agree that including/using/changing LSR > snippets as part of your work means deriving from them. That's why I > would agree that using the GPL for the LSR snippets would not be > desirable since it would introduce a licensing regime where it seems > exaggerated. > > I agree with this comment only to the extent that you are distributing the > source code for your music. If you only distribute the PDF and/or MIDI > output, > the GPL does not apply, according to the FSF: > > " In what cases is the output of a GPL program covered by the GPL too? > (#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. Many thanks for your comment. It contains an important hint. BUt it is a bit apart from my crucial point: I am not arguing that my LilyPond work (or a snippet) is covered by the GPL because it is 'executed' by LilyPond. I argue that my code is covered by the GPL if I use (include or copy) a GPL licensed snippet. And if it is covered, then in accordance to the GPL §6 (title: "Conveying Non-Source Forms") also the compiled version is covered by the GPL. (BTW: even a picture is binary code which is interpreted) Nevertheless, I would be happy if the statement you quoted would be judically approved! But as long as we do not have such a legal descision there is a great risk that my scientific and artistical music work can freely be used due to the fact that I used a GPL licensed snippet for ceating the music scores - a risk, which I don't want to take. But even if I agreed with your position, then we both still have to conlude, that we can only distribute / hand over our LilyPond code under the terms of the GPL, if our code used a GPL licensed snippet. And even this is a strong side effect. with best regards Karsten > Carl Sorensen > > 1. https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL > > > -- Karsten Reincke/\/\ (+49|0) 170 / 927 78 57 Im Braungeröll 31 >oo< mailto:k.rein...@fodina.de 60431 Frankfurt a.M. \/http://www.fodina.de/kr/
Re: LilyPond, LilyPond snippets and the GPL
> From: Karsten Reincke > To: lilypond-user > Cc: k.rein...@fodina.de > Bcc: > Date: Wed, 30 Oct 2019 00:06:32 +0100 > Subject: LilyPond, LilyPond snippets and the GPL > By my last post, I, unfortunately, evoked a discussion concerning > LilyPond, LilyPond snippets, and the GPL which actually did not belong > to the original topic. During this discussion Harm stated, that „maybe > LSR should better use GPL 3, not this deprecated one (Public Domain)“. > Urs asked whether anything has to be done with respect to the Lilypond > Snippet Repository. And Andrew asked whether I apprehend not to be able > to use lilypond due to the fact that it is licensed under the GPL. > > I owned these comments by my statement, that I will not be able to use > and to support the development of LilyPond snippets or libraries (as > OpenLilyLIb) as long as they are licensed under the GPL. Meanwhile, I > have written a thorough analysis of the situation. It is published > under the title „LilyPond, LilyPond Snippets and GPL: About some bad > side effects“. https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ > > For those, who do not want to read such an exhaustive document – I need > this depth of detail due to my work as the open-source compliance > officer of a Germany company – let me briefly summarize the line of > argumentation: > > [1] The LilyPond language (interpreted by the LilyPond program which > creates nice music sheets in the form of PDFs or PNGs) is a programming > language. > > [2] The LilyPond interpreter is licensed under the GPL. > > [3] None of the existing Lilypond snippets is licensed under the GPL > because the interpreter is licensed under the GPL (= no copyleft effect > from the engine to its input/output). If they are licensed under the > GPL, then it is a decision of the snippet authors, who also could have > chosen one of the other open-source licenses. > > [4] But if a GPL licensed LilyPond snippet is used by another LilyPond > code (either by a functional call into the included snippet or by > literally copying the snippet into the other code), then the copyleft > effect of the GPL is triggered. > > [5] The copyleft effect does not distinguish between distributing the > source (the LilyPond code) or the compilation (the PDFs, the PNGs): it > simply requires that the resulting work (the derivative work) has to be > distributed (published) under the terms of the GPL too. > > [6] If one has the right to use, to inspect, to modify and to > redistribute (share) the (modified) work to/with third persons, then – > in case of music – one has also the right to make music by using the > music scores. > > (If you doubt these statements, please read > https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ ) > > Hence, now I reached the bad result: Using a GPL licensed LilyPond > snippet for creating your own music – regardless, whether you use the > include- or the copy & paste method – evokes that everyone who gets > your work in any form also and inherently gets the right to use it – > for any purpose and without having to ask you again. In other words: by > using any GPL licensed snippet you give away all your rights, even your > artistic rights. > > I hope you understand why I cannot let automatically become my > scientific or my musical work common property only because I use one > GPL licensed LilyPond snippet for creating the sheet music of my > examples or my musical work. > > In my article, I also analyze the alternatives. The result is this: The > best method is to license your work under the MIT license. The worse, > but possible solution is, to use a creative commons license, especially > the CC0 license. > > With respect to the question of Urs, I can now say: The existing LSR > snippets can only be relicensed by the original copyright owners. But > for the next uploaded files, it could be helpful, to recommend (or > enforce?) their authors to license them under the CC0. > > And with respect to your OpenLilyLib, I, unfortunately, have to say > this: I hope that you can conclude why I am not able to develop my > snippet ‚harmonily‘ as part of your framework. But I will license it > under the terms of the MIT. That allows you, to integrate the code into > your work (But only, if you preserve the MIT license which is part of > the code. You will not be allowed to relicense my code – which should > not disturb your work and goals). > > In the hope having answered respectfully, appreciatively and clearly > Karsten > > > -- > Karsten Reincke/\/\ (+49|0) 170 / 927 78 57 > Im Braungeröll 31 >oo< mailto:k.rein...@fodina.de > 60431 Frankfurt a.M. \/http://www.fodina.de/kr/ I'm trying
Re: LilyPond, LilyPond snippets and the GPL
On 10/29/19, 5:46 PM, "David Kastrup" wrote:
Karsten Reincke writes:
> By my last post, I, unfortunately, evoked a discussion concerning
> LilyPond, LilyPond snippets, and the GPL which actually did not belong
> to the original topic. During this discussion Harm stated, that „maybe
> LSR should better use GPL 3, not this deprecated one (Public Domain)“.
> Urs asked whether anything has to be done with respect to the Lilypond
> Snippet Repository. And Andrew asked whether I apprehend not to be able
> to use lilypond due to the fact that it is licensed under the GPL.
>
> I owned these comments by my statement, that I will not be able to use
> and to support the development of LilyPond snippets or libraries (as
> OpenLilyLIb) as long as they are licensed under the GPL. Meanwhile, I
> have written a thorough analysis of the situation. It is published
> under the title „LilyPond, LilyPond Snippets and GPL: About some bad
> side effects“. https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/
>
> For those, who do not want to read such an exhaustive document – I need
> this depth of detail due to my work as the open-source compliance
> officer of a Germany company – let me briefly summarize the line of
> argumentation:
>
> [1] The LilyPond language (interpreted by the LilyPond program which
> creates nice music sheets in the form of PDFs or PNGs) is a programming
> language.
>
> [2] The LilyPond interpreter is licensed under the GPL.
>
> [3] None of the existing Lilypond snippets is licensed under the GPL
> because the interpreter is licensed under the GPL (= no copyleft effect
> from the engine to its input/output). If they are licensed under the
> GPL, then it is a decision of the snippet authors, who also could have
> chosen one of the other open-source licenses.
>
> [4] But if a GPL licensed LilyPond snippet is used by another LilyPond
> code (either by a functional call into the included snippet or by
> literally copying the snippet into the other code), then the copyleft
> effect of the GPL is triggered.
>
> [5] The copyleft effect does not distinguish between distributing the
> source (the LilyPond code) or the compilation (the PDFs, the PNGs): it
> simply requires that the resulting work (the derivative work) has to be
> distributed (published) under the terms of the GPL too.
I disagree with your assessment that calling any code/function makes the
work doing so a derivative of that code (that would concern using
OpenLilyLib code). I do agree that including/using/changing LSR
snippets as part of your work means deriving from them. That's why I
would agree that using the GPL for the LSR snippets would not be
desirable since it would introduce a licensing regime where it seems
exaggerated.
I agree with this comment only to the extent that you are distributing the
source code for your music. If you only distribute the PDF and/or MIDI output,
the GPL does not apply, according to the FSF:
" In what cases is the output of a GPL program covered by the GPL too?
(#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 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?" [1]
Carl Sorensen
1. https://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL
Re: LilyPond, LilyPond snippets and the GPL
Karsten Reincke writes: > On Wed, 2019-10-30 at 00:46 +0100, David Kastrup wrote: >> [...] >> >> I disagree with your assessment that calling any code/function makes >> the >> work doing so a derivative of that code (that would concern using >> OpenLilyLib code). [...] > > I agree with you, that the question, when and how a piece of code > definitely becomes a derivative work of another is not finally > clarified, especially not judically. Therefore, we all have to argue > and can finally only deliver more or less rational 'rule of thumbs'. I > argue the following way: > > RMS has invented the LGPL to ensure that free code stays free. (weak > copyleft effect). And he invented the GPL to ensure that no one can use > the advantages of free software without let his own the advantages > using software becoome free software too. (strong copyleft effect). > This is the successful spirit of the free software world. (If you doubt > this, please consider, why the AGPL has been invented) > > 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. It doesn't cover the output of running your LilyPond code, namely the PDF. -- David Kastrup
Re: LilyPond, LilyPond snippets and the GPL
On Wed, 2019-10-30 at 00:46 +0100, David Kastrup wrote: > [...] > > I disagree with your assessment that calling any code/function makes > the > work doing so a derivative of that code (that would concern using > OpenLilyLib code). [...] I agree with you, that the question, when and how a piece of code definitely becomes a derivative work of another is not finally clarified, especially not judically. Therefore, we all have to argue and can finally only deliver more or less rational 'rule of thumbs'. I argue the following way: RMS has invented the LGPL to ensure that free code stays free. (weak copyleft effect). And he invented the GPL to ensure that no one can use the advantages of free software without let his own the advantages using software becoome free software too. (strong copyleft effect). This is the successful spirit of the free software world. (If you doubt this, please consider, why the AGPL has been invented) 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. > > [...] > > MIT license definitely permits relicensing, but of course without > copyright to the actual code, you would not have standing for > enforcing > the license of a relicensed (or non-relicensed) version, so that does > not make a whole lot of sense for an unmodified version. > No. In case of script languages, the MIT does implicitely prevent this (and in case of compiled languages too, but there ir does not have any visible effect): The MIT license requires that "the above copyright notice and this permission notice [the MIT license text] shall be included in all copies or substantial portions of the Software". ( https://opensource.org/licenses/MIT) Hence, whenever you take over any substantial piece of my MIT licensed code, then you have to add the MIT license text and my copyright line too. Therefore, my code stays MIT licensed. But of course, you are allowed to combine my code with your work and to distribute your larger overarching work under any other license. As I mentioned above: in case of compiled languages, you cannot see my code anylonger. But in case of interpreted languages at least the substantial portion is there and stays MIT licensed. This aspect of distributing the larger work under different license is often taken as 'relicensing' of the embedded MIT code. But in fact, that's wrong - even if that does indeed not have any important effect. best regards and thanks for your quick answer Karsten -- Karsten Reincke/\/\ (+49|0) 170 / 927 78 57 Im Braungeröll 31 >oo< mailto:k.rein...@fodina.de 60431 Frankfurt a.M. \/http://www.fodina.de/kr/
Re: LilyPond, LilyPond snippets and the GPL
Hi Karsten, first of all let me comment on your final stance: yes, I think you have answered respectfully, appreciatively and clearly. And I have also read your longer post. But I think there is one single flawed thought you build your argumentation on. I'll leave most of your statements alone and basically comment only on that one: Am 30.10.19 um 00:06 schrieb Karsten Reincke: By my last post, I, unfortunately, evoked a discussion concerning LilyPond, LilyPond snippets, and the GPL which actually did not belong to the original topic. During this discussion Harm stated, that „maybe LSR should better use GPL 3, not this deprecated one (Public Domain)“. Urs asked whether anything has to be done with respect to the Lilypond Snippet Repository. And Andrew asked whether I apprehend not to be able to use lilypond due to the fact that it is licensed under the GPL. I owned these comments by my statement, that I will not be able to use and to support the development of LilyPond snippets or libraries (as OpenLilyLIb) as long as they are licensed under the GPL. Meanwhile, I have written a thorough analysis of the situation. It is published under the title „LilyPond, LilyPond Snippets and GPL: About some bad side effects“. https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ For those, who do not want to read such an exhaustive document – I need this depth of detail due to my work as the open-source compliance officer of a Germany company – let me briefly summarize the line of argumentation: [1] The LilyPond language (interpreted by the LilyPond program which creates nice music sheets in the form of PDFs or PNGs) is a programming language. [2] The LilyPond interpreter is licensed under the GPL. [3] None of the existing Lilypond snippets is licensed under the GPL because the interpreter is licensed under the GPL (= no copyleft effect from the engine to its input/output). If they are licensed under the GPL, then it is a decision of the snippet authors, who also could have chosen one of the other open-source licenses. Correct. [4] But if a GPL licensed LilyPond snippet is used by another LilyPond code (either by a functional call into the included snippet or by literally copying the snippet into the other code), then the copyleft effect of the GPL is triggered. Well, sort-of ... [5] The copyleft effect does not distinguish between distributing the source (the LilyPond code) or the compilation (the PDFs, the PNGs): it simply requires that the resulting work (the derivative work) has to be distributed (published) under the terms of the GPL too. ... of course it does. What you are referring to is the relation of software distributed in source code or binary/compiled form. But as you outlined before using LilyPond (like with all other comparable tools like e.g. LaTeX) does not have any implications on *what* you do with it. The intellectual property to the *documents* is not affected by the license the compiler is distributed with. If there is a snippet or an openLilyLib package that creates a certain sign, let's say a vertical line to indicate a line break in the original source (\diplomaticLineBreak in an openLilyLib package) and that package is licensed with the GPL then the function is essentially licensed identically as any function within the regular LilyPond distribution. Consider the function \IJ. This is defined in a file gregorian.ly within the LilyPond distribution. In order to use \IJ your document has to actively \include "gregorian.ly". gregorian.ly is licensed under the GPL, but that does *not* require you to license the *music* (or other kind of artistic/scientific "work") under the GPL as well. Basically *any* use of LilyPond uses function calls into GPLed code, and in that sense code within openLilyLib is part of the compiler domain like LilyPond, and not part of the document domain where it would affect the work you do with it. However, if you are building a library that uses \IJ and you want to distribute your libary *that* triggers the copyleft implications of the original file's GPL. The same is true (and that's probably a practically realistic example) if you write a custom openLilyLib package (by including oll-core/package.ily) and want to distribute that package you'd be bound by the relicensing provisions of the GPL. Still, that doesn't affect the artistic or scientific works created *using* the package in any way. Given the \diplomaticLineBreak above using the function does not put any burden on you. OTOH your *scholarly decision* to apply a diplomatic line break may be a copyrightable decision in its own right. Another example: If you use a GPLed document editor that provides the ability to use/apply macros, and there is an option to use custom macros which may stem from a GPLed macro repository. Such macros might (for example) be used to apply a certain styling to a certain type of content, e.g
Re: LilyPond, LilyPond snippets and the GPL
Karsten Reincke writes: > By my last post, I, unfortunately, evoked a discussion concerning > LilyPond, LilyPond snippets, and the GPL which actually did not belong > to the original topic. During this discussion Harm stated, that „maybe > LSR should better use GPL 3, not this deprecated one (Public Domain)“. > Urs asked whether anything has to be done with respect to the Lilypond > Snippet Repository. And Andrew asked whether I apprehend not to be able > to use lilypond due to the fact that it is licensed under the GPL. > > I owned these comments by my statement, that I will not be able to use > and to support the development of LilyPond snippets or libraries (as > OpenLilyLIb) as long as they are licensed under the GPL. Meanwhile, I > have written a thorough analysis of the situation. It is published > under the title „LilyPond, LilyPond Snippets and GPL: About some bad > side effects“. https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ > > For those, who do not want to read such an exhaustive document – I need > this depth of detail due to my work as the open-source compliance > officer of a Germany company – let me briefly summarize the line of > argumentation: > > [1] The LilyPond language (interpreted by the LilyPond program which > creates nice music sheets in the form of PDFs or PNGs) is a programming > language. > > [2] The LilyPond interpreter is licensed under the GPL. > > [3] None of the existing Lilypond snippets is licensed under the GPL > because the interpreter is licensed under the GPL (= no copyleft effect > from the engine to its input/output). If they are licensed under the > GPL, then it is a decision of the snippet authors, who also could have > chosen one of the other open-source licenses. > > [4] But if a GPL licensed LilyPond snippet is used by another LilyPond > code (either by a functional call into the included snippet or by > literally copying the snippet into the other code), then the copyleft > effect of the GPL is triggered. > > [5] The copyleft effect does not distinguish between distributing the > source (the LilyPond code) or the compilation (the PDFs, the PNGs): it > simply requires that the resulting work (the derivative work) has to be > distributed (published) under the terms of the GPL too. I disagree with your assessment that calling any code/function makes the work doing so a derivative of that code (that would concern using OpenLilyLib code). I do agree that including/using/changing LSR snippets as part of your work means deriving from them. That's why I would agree that using the GPL for the LSR snippets would not be desirable since it would introduce a licensing regime where it seems exaggerated. > In my article, I also analyze the alternatives. The result is this: > The best method is to license your work under the MIT license. The > worse, but possible solution is, to use a creative commons license, > especially the CC0 license. LSR code is most of the time edited/adapted to particular use cases. It's not really intended to be retained in a reasonably attributable form, so I think that even the MIT license makes little sense. CC0 seems fine to me, as basically an internationalised abstraction of "Public Domain". > That allows you, to integrate the code into your work (But only, if > you preserve the MIT license which is part of the code. You will not > be allowed to relicense my code – which should not disturb your work > and goals). MIT license definitely permits relicensing, but of course without copyright to the actual code, you would not have standing for enforcing the license of a relicensed (or non-relicensed) version, so that does not make a whole lot of sense for an unmodified version. -- David Kastrup
LilyPond, LilyPond snippets and the GPL
By my last post, I, unfortunately, evoked a discussion concerning LilyPond, LilyPond snippets, and the GPL which actually did not belong to the original topic. During this discussion Harm stated, that „maybe LSR should better use GPL 3, not this deprecated one (Public Domain)“. Urs asked whether anything has to be done with respect to the Lilypond Snippet Repository. And Andrew asked whether I apprehend not to be able to use lilypond due to the fact that it is licensed under the GPL. I owned these comments by my statement, that I will not be able to use and to support the development of LilyPond snippets or libraries (as OpenLilyLIb) as long as they are licensed under the GPL. Meanwhile, I have written a thorough analysis of the situation. It is published under the title „LilyPond, LilyPond Snippets and GPL: About some bad side effects“. https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ For those, who do not want to read such an exhaustive document – I need this depth of detail due to my work as the open-source compliance officer of a Germany company – let me briefly summarize the line of argumentation: [1] The LilyPond language (interpreted by the LilyPond program which creates nice music sheets in the form of PDFs or PNGs) is a programming language. [2] The LilyPond interpreter is licensed under the GPL. [3] None of the existing Lilypond snippets is licensed under the GPL because the interpreter is licensed under the GPL (= no copyleft effect from the engine to its input/output). If they are licensed under the GPL, then it is a decision of the snippet authors, who also could have chosen one of the other open-source licenses. [4] But if a GPL licensed LilyPond snippet is used by another LilyPond code (either by a functional call into the included snippet or by literally copying the snippet into the other code), then the copyleft effect of the GPL is triggered. [5] The copyleft effect does not distinguish between distributing the source (the LilyPond code) or the compilation (the PDFs, the PNGs): it simply requires that the resulting work (the derivative work) has to be distributed (published) under the terms of the GPL too. [6] If one has the right to use, to inspect, to modify and to redistribute (share) the (modified) work to/with third persons, then – in case of music – one has also the right to make music by using the music scores. (If you doubt these statements, please read https://fodina.de/en/2019/lilypond-snippets-and-the-gpl/ ) Hence, now I reached the bad result: Using a GPL licensed LilyPond snippet for creating your own music – regardless, whether you use the include- or the copy & paste method – evokes that everyone who gets your work in any form also and inherently gets the right to use it – for any purpose and without having to ask you again. In other words: by using any GPL licensed snippet you give away all your rights, even your artistic rights. I hope you understand why I cannot let automatically become my scientific or my musical work common property only because I use one GPL licensed LilyPond snippet for creating the sheet music of my examples or my musical work. In my article, I also analyze the alternatives. The result is this: The best method is to license your work under the MIT license. The worse, but possible solution is, to use a creative commons license, especially the CC0 license. With respect to the question of Urs, I can now say: The existing LSR snippets can only be relicensed by the original copyright owners. But for the next uploaded files, it could be helpful, to recommend (or enforce?) their authors to license them under the CC0. And with respect to your OpenLilyLib, I, unfortunately, have to say this: I hope that you can conclude why I am not able to develop my snippet ‚harmonily‘ as part of your framework. But I will license it under the terms of the MIT. That allows you, to integrate the code into your work (But only, if you preserve the MIT license which is part of the code. You will not be allowed to relicense my code – which should not disturb your work and goals). In the hope having answered respectfully, appreciatively and clearly Karsten -- Karsten Reincke/\/\ (+49|0) 170 / 927 78 57 Im Braungeröll 31 >oo< mailto:k.rein...@fodina.de 60431 Frankfurt a.M. \/http://www.fodina.de/kr/
