On 2020/05/03 10:46:49, hahnjo wrote: > On 2020/05/03 10:40:25, dak wrote: > > On 2020/05/03 09:46:56, hahnjo wrote: > > > rebase + allow -dgs-api=#f to still fork > > > > I decided to look up the terms of the Affero GPL version 3. The relevant > > differences are: > > [...] > > I think you're not looking at the right direction, ie we're not integrating GPL > (LilyPond) into AGPL (Ghostscript), but the other way around. In that case > Section 13 of the GPL 3.0 is relevant: > > > 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. > > Note there is no mention of modifying the work, AGPL applies "to the combination > as such".
Well, if it states "the special requirements of the AGPL apply to the combination" and the AGPL explicitly says that the combination remains licensed individually, it definitely sounds to me that the the requirement to distribute the source of _both_ components triggers when the AGPL component gets modified. Artifex states on its web site <https://artifex.com/licensing/agpl/>: Network Use > If you modify our software and make the functionality of the software available to users interacting with it remotely through a computer network (such as a SaaS or web-based application) you must share your application source code. > Any modified versions must also be made available to those interacting with the software remotely. To me that sounds like modification of the GPLed part does not count as modification of the AGPLed part. If we distribute a combined binary package, of course we have to state that the package is not, as a whole, governed by the rules of the GPL since any modification of the AGPLed part would trigger the requirement to make the combined source available to network users of the software. The FSF's GPL FAQ (which of course is not legally binding) states <https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingRemotely>: In AGPLv3, what counts as “interacting with [the software] remotely through a computer network?” (#AGPLv3InteractingRemotely) If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online. If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session. Again, that sounds to me like the AGPL requirements of using Ghostscript as an integrated component of web-based PDF generation would not be different when using Ghostscript unmodified from the command line as opposed to linked unmodified into a command-line version (modified or not) of LilyPond. There would be a conceivable difference if the server itself were linked with the GS API. At any rate: my take on this involved evaluating legalese and making a judgment on it and on the associated risks and possible interpretations. But that's not my job, and it shouldn't be ours. The main thing we can do here is be transparent. That basically leaves the responsibility of making decisions with or without contact to Artifex to the respective users wanting to provide a web service. And to be honest: I don't really see that using the GS API is making a significant difference in that regard. I think that would have been a requirement anyway. https://codereview.appspot.com/548030043/
