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

[hanwenn]

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/