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. > > > > 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.
>From Artifex' web site regaring licensing:: If you meet certain criteria, then we will not consider your distribution of your application in an executable form to be in violation of AGPL, even though you ship an executable product that includes your application and Ghostscript. Here are the criteria: It is conspicuous and clear to the end user that he/she is getting access to two separate pieces of software (i.e., AGPL Ghostscript in addition to the application using this product). The end user has the ability to opt out of installing the AGPL version of our products during the install process. Each AGPL module is separable and replaceable within the build. The available source code for the AGPL modules must be for the build that corresponds with your binaries. Any other redistribution is not licensed under AGPL. If you cannot meet the requirements of AGPL, please fill out the form below to inquire about a commercial license. It is pretty likely that if software like Scorio.com wanted to avail themselves of the advantages of the Ghostscript API performance, they would need to adhere to the AGPL terms or take out a commercial license of Ghostscript. We definitely should not be distributing LilyPond in a form where it would only work using the GhostScript API, but with a separate option that is off by default, I don't see much of a problem. https://codereview.appspot.com/548030043/