Urs: ... > One of the main issues we have at play here (and that has been discussed > by others in this thread) is that tools like LilyPond and LaTeX blur the > lines between source, program, and document. > > The arguments that are expressed *for* a requirement to license the PDF > (etc.) files resulting from a LilyPond or LaTeX run are all based on the > assumption that the graphical documents created like this are > "comparable to the binary resulting from a compilation using a "typical" > C compiler." I think (which others have stated earlier today) that the > culprit here is that these arguments (e.g. when pointing to resources > like https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary) > assume that a "resulting PDF document" can be considered equivalent to a > "resulting program" or "resulting software". It has been said several > times: the PDF/PNG/SVG resulting from a LilyPond run is a document, not > a program. ...
Just to provide a data point... As I work with postscript files, the result is certaintly a program. Also files (at least one) from the lilypond distribution are included verbatim in the output (I.ps is just one file created using lilypond). ////////////////// $ fgrep -a -A10 'procset (music-drawing-routines.ps)' I.ps %%BeginResource: procset (music-drawing-routines.ps) 1 0 %!PS-Adobe-2.0 % % Functions for direct and embedded PostScript % Careful with double % as comment prefix. % Any %%X comment is interpreted as DSC comments. % TODO: use dicts or prefixes to prevent namespace pollution. /pdfmark where ////////////////// $ head -10 /Net/git/lilypond/ps/music-drawing-routines.ps %!PS-Adobe-2.0 % % Functions for direct and embedded PostScript % Careful with double % as comment prefix. % Any %%X comment is interpreted as DSC comments. % TODO: use dicts or prefixes to prevent namespace pollution. /pdfmark where ////////////////// Regards, /Karl Hammar