Re: kernel firmwares: GR proposal
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
Reply to: