Re: Let's stop feeding the NVidia cuckoo
On Thu, 3 Mar 2005 17:15:41 -0700, Joel Aelwyn <fenton@debian.org> wrote:
[snip]
> Actually, we aim to throw out 100% of closed-source software. But I'm
> assuming you were just being careless with trying to make a point.
> Unfortunately, the point you're trying to make also misses.
Well, I was a little bit careless, in that I didn't spell out the bit
where 98% < 99.5% implies that closed-source software workflows are
typically even sloppier about retaining editable image formats than
open-source workflows are (unless, of course, regenerating those
images is such a frequent task that it overcomes someone's laziness
threshold). I think that's a useful benchmark for whether passing
JPEGs around is acting in good faith, whether or not you want to throw
out 100% of closed-source software. In other respects, you seem to be
in violent agreement with the scope of the argument in the message you
quoted, which was that the author's actual process is good enough even
if it isn't the way that imaging-industry professionals would do it.
That's not my entire opinion, though, as I discuss below.
When what we are being purist about is images, we want the trade-off
chosen by a sophisticated, experienced manipulator of images of that
kind -- which may well not be the earliest machine-parseable source,
and may omit the details of intermediate manipulations which are
obvious to a skilled practitioner and not worth automating.
Similarly, when what we are being purist about is software, we want
the thing that a manipulator of software would use, and sometimes
similar trade-offs are involved.
Consider a table of numbers in an approximation algorithm, originally
machine-generated using a Perl one-liner heuristic, massaged by hand
to truncate to integers (mostly alternating between floor and ceiling
but tuned by trial and error), and then embedded in a header file. If
I think there's little point in automating these steps because anyone
skilled enough to create a useful replacement table could do it
themselves easily enough, then it's reasonable for me to call the
header file "source code" when I distribute it. This is true even if
1) I still have the Perl one-liner in a logbook somewhere and would
look it up if I ever needed to recapitulate the work myself, 2) the
massaging loses information and makes it impractical to do more than a
point fix without redoing the heuristic, and 3) next time around I
would probably write a second Perl one-liner instead of inserting the
syntactic sugar by hand.
What would make it unreasonable to call the header file "source code"
is if the idea behind these manipulations is an important part of the
software design and is hidden from recipients in a way that it would
not be if I disclosed the process I followed. If I document the
intention behind the heuristic, and the rest is just aesthetic
judgment and trial and error, then I have acted in good faith, even if
parameterizing and automating all of the steps would show more
professionalism.
Now for a more controversial opinion. If the reason I'm disinclined
to release the heuristic in machine-executable form is that it happens
to be not a Perl one-liner but one of many functions of another piece
of software that I don't want to give away for free, I think the
resulting header file is still acceptable in free software. Just
because I say "solve this numerical integral as a starting point, then
experiment" doesn't mean I owe you a numerical integrator, even if
that's how I got there to begin with and how I personally would go
about subsequent changes. Sometimes the appropriate standard is not
"is it how the author does it" but "does it obstruct access to the
ideas embodied in the software".
Back to the image context: just because I provide some JPEGs as part
of a piece of free software shouldn't mean that I owe you my
full-resolution lossless inputs and the color calibration framework I
also use to produce fine art prints, as long as my image manipulation
workflow is not an important part of the way the software itself
works. It's not really much different from using my pet non-free
prettyprinter as part of the editing workflow for my program's code --
you may have a hard time modifying it and keeping it equally pretty
without reformatting it completely, but it isn't really an obstacle to
idea reuse.
Cheers,
- Michael
Reply to: