Re: Use GhostScript API instead of forking (issue 548030043 by address@hidden)

[jonas . hahnfeld]

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.

https://codereview.appspot.com/548030043/