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/
