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

[dak]

On 2020/05/01 11:44:05, hahnjo wrote:
> On 2020/05/01 11:41:13, dak wrote:
> > On 2020/05/01 11:18:11, hahnjo wrote:
> > >
>
https://codereview.appspot.com/548030043/diff/583830043/lily/general-scheme.cc
> > > File lily/general-scheme.cc (right):
> > > 
> > >
> >
>
https://codereview.appspot.com/548030043/diff/583830043/lily/general-scheme.cc#newcode783
> > > lily/general-scheme.cc:783: command += "(" + ly_scm2string (input)
+ ")
> run";
> > > On 2020/05/01 06:42:43, hanwenn wrote:
> > > > This doesn't hook very deeply into GS internals or how we
arrange the
> page.
> > > > Could we get the same speedup by putting the batching into an
encompassing
> > .ps
> > > > file, and calling GS on that file once?
> > > 
> > > I think this would require substantial refactoring of how LilyPond
works. As
> > far
> > > as I understand, currently each input file is handled separately
and
> temporary
> > > files are deleted after processing. To get similar speedup, we
have to reuse
> > the
> > > interpreter for the complete run of LilyPond.
> > > 
> > > > Also: is there a GPL'd version of Ghostscript for which this
works?
> > > 
> > > GPL Ghostscript 9.06 from 2012 is apparently the last GPL version.
You
> > probably
> > > don't want to stick with dependencies of that age ;-)
> > 
> > It would need to be GPLv3+ anyway.  Haven't checked, though.
> > 
> > preview-latex
<https://www.gnu.org/software/auctex/preview-latex.html> works
> by
> > feeding scraps of PostScript control through stdin.  The main thing
is that
> > startup and font loading are not once per graphics but per document.
 I have
> > little enough clue how this would work for us, but obviously any way
of using
> a
> > single Ghostscript session for multiple snippet conversions,
including just a
> > large batch of input files generating lots of small output files
with a
> > predictable naming scheme (this is what LaTeX/Ghostscript under
control of
> > preview.sty can do) will get us significant benefits.  The
Ghostscript API is
> > just one way of organising this.
> 
> Sure, we could also open an "interactive" gs command and keep it
around for the
> process. I didn't consider this different from using the API, but if
the license
> is happy as long as it's a separate process...

I haven't looked too closely at the details of Ghostscript but the
cursory license information from Artifex I have seen was not
specifically talking about the API.  I have not looked closer though. 
This is more of a question of "what are we prepared to get sued over". 
The legal situation with APIs and/or linking is at best murky.  Many
proprietary offerings work around that by casting themselves in contract
form, basically stating "you may not even use the software unless you
agree to those terms", and those define what is considered a
combined/derived work in the sense of the contract rather than the sense
of the law.  For us the line likely is not as much the law but when
Artifex is likely to spring in action.

That being said, the situation regarding Scorio, a proprietary entity
using Free Software as a component of delivering a web-based service
with non-disclosed components, is _exactly_ the reason Artifex chose the
AGPL as a basis for their business model selling commercial Ghostscript
licenses.

So they quite likely are prepared to threaten legal action over it.  We
just have to make sure that they aren't going to target us, and
preferably that it's actually easy to get a commercially licensed
Ghostscript version working in that context so that parties like
Scorio.com have the option to do so and know the conditions where it
makes sense for them to take out that option.

I don't see the API as the trigger point judging from the Ghostscript
licensing page, but I may well be overlooking something here.



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