Re: Social Contract GR's effect on sarge
Steve Langasek writes:
> A PNG generated from an SVG isn't a compiled form of the program, it's
> the *output* of running the program on an appropriate interpreter. This
> is not at all analogous to compiling a program; compiling a program is a
> process of preparing the program for execution, but rendering a PNG
> gives you only static output -- not something that's interesting to
> refer to as a program, and frequently not even something that's as
> useful to a computer (let alone a human) as the SVG. But it's also a
> lot faster to work with a prerendered PNG if that meets your needs.
>
> This is a gray area, and not one I think it's necessarily to formally
> disambiguate.
I disagree. This is an even weaker situation than most users face
with most firmware: it is fastest to use a provided binary blob and
that blob meets users' needs. On top of that, the tools used to
generate the firmware generally do not have any free equivalents. It
is not useful to provide the user with the source code for firmware[1]
but most people in this thread seem to think that firmware blobs are
unambiguously wrong.
The distinction "SVG interpreter output" versus "compiler output" is a
red herring: no matter what generates the output, it is still output
rather than input. The only reason I can see to consider PNG-from-SVG
preferable to firmware is that PNGs can be readily edited, whereas a
firmware blob requires additional knowledge to edit. On the other
hand, editing a lossily-compressed PNG implies either image
degradation or considerable size increase.
Actual border cases for this are currently (and hopefully will remain)
rare; but a consensus on how to apply the DFSG/SC to them must be
reached at some point.
Michael Poole
[1]- For most users, it is not useful to provide them with the source
code for any package. The DFSG does not establish a lower limit on
how useful having the source must be, just that it must be available
and redistributable.
Reply to: