What strikes me as ironic, with these proposals, is that we ran into something like this problem back in the 90s, back during the initial adoption of the DFSG, and we had to solve that problem then: we created the non-free and contrib sections.
For some reason, these sections are no longer seen as adequate. As I understand it, one aspect of the problem is that CD/DVD distributors do not distribute these sections -- mostly because we have not made it easy for them to do so legally. Perhaps we should start addressing the CD distributor problem (perhaps tagging CD distributable software, and providing a simple mechanism to pull only CD distributable software for contrib/non-free). As for "hex as source". I've written machine code in hex, so I have no problem believing that other people would do such a thing. That said, for such source to be useful, the target (whether some general purpose machine language, microcode, some specific set of registers driving hardware, or whatever) needs to be documented well enough that someone else has a chance to read and comprehend the code. Also, except for really small bits of code (a couple K or less), a list of (or system of finding) entry points, internal branch points, and the like is also important The current proposals I've seen here don't seem to address these "readability" issues. That said, are plenty of grey areas here, and I understand that many programmers have little tolerance for ambiguity. Myself included, sometimes. So... if we want to get these issues sorted out in a timely fashion, perhaps the place to start would be enumerating the packages and issues, in some fashion that makes it easy for other informed people to append useful comments. (For example, if there were BTS pages for each package in question, a top level page listing the urls of each of those BTS pages might be nice.) Has someone already made such a page? Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
