On Thu, 3 Mar 2005 17:15:41 -0700, Joel Aelwyn <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
