On Mon, Sep 21, 2020 at 4:00 PM Karsten Reincke <k.rein...@fodina.de> wrote <snip>
> > We had this discussion a year ago and I won't repeat the details. The > last time it ended in a kind of unfruitful shitstorm which did not help > anyone. But if you now look for supporters, you have to see that your > license model reduces the list of candidates: They must be familiar with > music, they must love beautifully designed musical text, they must be > able to program scheme (LISP) code (in fact not the most widely used > programming language) and they must be willing to require the others to > distribute their music under the terms of the GPL. > What is special about OpenLilyLib that requires LilyPond music to be released under the GPL, when music not using OpenLilyLib does not need to be released under the GPL? How does OpenLilyLib change the type of license required for the PDF file generated by LilyPond? > Nearly all other GPL licensed programming libs/programs had the same > problem and found solutions. Linus invented the "explicit syscall > exception" for his kernel, openjdk was released under the "GPL with > classpath exception". That is why I would like to propose again to > re-license the OpenLilyLib under the terms of the LGPL. Or, if that is > not possible, to link the lib with a kind of an "include exception" with > the purpose, to explicitly prevent the including musical scores from > also having to be released under the terms of the GPL. > LilyPond is GPL. If base LilyPond doesn't require music to be released under the terms of the GPL, why does including OpenLilyLib suddenly enforce those terms on the music? I'm not trying to cause problems. I just don't understand how including OpenLilyLib in your LilyPond music file suddenly changes the license terms. Can you explain that to me? Thanks, Carl > >
