On 2020/05/01 07:58:32, hahnjo wrote: > disclaimer: I'm not a lawyer, this is just my understanding of the licenses. > > On 2020/05/01 06:28:56, hanwenn wrote: > > Technologically speaking, this is a brilliant idea, and I am all in favor it. > > > > However, I think we can't enable this by default. > > > > Ghostscript is licensed under AGPL, and linking it in makes LilyPond a derived > > work, putting it under AGPL as well. That would be effectively a license > change > > of LilyPond, which would need consent of the current authors, and I think the > > Scorio folks would not be happy with. > > To put this on a solid basis, here's a quote from > https://www.gnu.org/licenses/gpl-3.0.html > > 13. Use with the GNU Affero General Public License. > > Notwithstanding any other provision of this License, you have permission to link > or combine any covered work with a work licensed under version 3 of the GNU > Affero General Public License into a single combined work, and to convey the > resulting work. The terms of this License will continue to apply to the part > which is the covered work, but the special requirements of the GNU Affero > General Public License, section 13, concerning interaction through a network > will apply to the combination as such. > > So I disagree that this is a license change as the "terms of this License will > continue to apply to the part which is the covered work". LilyPond stays > licensed under GPLv3. But yes "the special requirements of the GNU Affero > General Public License, section 13, concerning interaction through a network > will apply to the combination as such". > > And here's the point that many have long argued about and continue to disagree: > What is "combination"? Linking to a library clearly is (and it's even spelled > out explicitly), but what about other "control flows" like calling GhostScript. > Here's another quote: > > The “Corresponding Source” for a work in object code form means all the source > code needed to generate, install, and (for an executable work) run the object > code and to modify the work, including scripts to control those activities. > However, it does not include the work's System Libraries, or general-purpose > tools or generally available free programs which are used unmodified in > performing those activities but which are not part of the work. For example, > Corresponding Source includes interface definition files associated with source > files for the work, and the source code for shared libraries and dynamically > linked subprograms that the work is specifically designed to require, such as by > intimate data communication or control flow between those subprograms and other > parts of the work. > > So the first sentence and the example seem to include runtime dependencies > ("subprograms"), but others (like System Libraries) are excluded. I don't know > whether this applies to GhostScript, but I'd argue that it's not a "major > essential component" of the OS. So in my opinion, LilyPond + GS already is AGPL > if you're using a recent version of the software.
LilyPond can also output postscript with embedded fonts, which you should be able to send to a Postscript printer (I have a PS printer too, but it's a 2001 model, which probably is too old to deal with OTF/CFF fonts). In this scenario, you don't need Ghostscript, so LilyPond per se doesn't depend on GS. > > I suggest we make this an option that you have enable explicitly. If it is > > enabled, we'd have to change the --license output to say AGPL as well. > > I'm open to making this change if people prefer. The major benefit will be for > documentation builds anyway, so the "normal" usage of LilyPond is fine with > forking. Yeah, I think this is the better option. I might have a look at Cairo one of these days. https://codereview.appspot.com/548030043/
