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/
