On Thu, Mar 03, 2005 at 06:59:44PM -0800, Michael K. Edwards wrote:
> 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.
I would agree it's a useful consideration; whether it's a benchmark, I'm
not so certain, but it certainly affects the question "Do we consider the
claim that this is the source format insanity?" (or, really, more likely,
"is anyone insane enough to want to deal with this source?").
> 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.
Agreed.
> 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.
Agreed.
> 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.
Still agreed.
> 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".
I think that this is where the judgement call starts to creep in. If the
statement is "solve this numerical integral", then the ways of doing that
are (fairly) widely known, documented, and there's a good chance that
there are tools which will make it practical for the mythical "reasonable
person" to accomplish this task sufficiently well to be able to modify
things without it being excessively onerous (especially since, presumably,
understanding that the starting point is a solution to one may be an
important part of grasping what the table is for in the first place and how
the code actually operates).
I would say it's still "is it how the author does it", with the caveat that
it may warrant a broader interpretation. Just as I can edit C source code
in Emacs, Vi, or any number of other editors - and that source may have
meta-info for some but not all of them that, say, improves the formatting
and readabilitiy - does not affect the fact that that code is the preferred
form of modification. The correct scope of "how the author does it" is "the
author edits the code in an editor of his or her choice", not "the author
edits the code in Vim with the perl modules loaded".
If "solve a numerical integral" is a sufficiently generic task that it can
be accomplished (reasonably) in a variety of ways, then I agree that it
sufficies to simply say "Here's the integral, and here's the solution table
so that everyone doesn't have to re-do this step unless they want to adjust
this particular part of the code."
Adding comments about what you did to experiment is not required, but
certainly goes a long way towards establishing an intent of allowing others
to modify the code meaningfully, too. :)
> 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.
See, this is where I disagree, at least in part. If you're putting out a
format that is inherently lossy, you have discarded important information
from one form to the next; this is the difference between "Here's the
integral, and here's a pre-solved table with some tweaks that produces
results I consider good" and "Here's a table of values that come from some
integral I don't feel like providing, that I solved and then tweaked more
to be what I consider good". You've discarded crucial information that
constitutes what you, as an author, would potentially use to make a change
in the future (not every change, but some important set of them, just like
you don't need the PNG to do *every* JPEG transformation that is possible,
but if you, say, want to build JPEGs with the loss cranked way down, it's
impossible to do if all you're given is JPEGs with a high loss).
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature