Re: more evil firmwares found
Chris Cheney wrote:
> On Wed, Apr 14, 2004 at 01:49:03PM -0400, Nathanael Nerode wrote:
<snip>
>> That's a nice argument. It's also brand new. I haven't seen anyone
>> before you seriously claim that any of this stuff without source code, or
>> without
>> freedom to modify, satisfies the DFSG. Would you care to present such an
>> argument?
>
> The only part of DFSG that I saw that pertains to this matter is section
> 2.
>
> 2. Source Code
> The program must include source code, and must allow distribution in
> source code as well as compiled form.
>
> This statement is vague. All the drivers that have been discussed
> include the source code and can be compiled, the only question has been
> whether the hex data structure in the driver source violates section 2
> (AIUI).
Right. When the hex data structure is, in fact, a program, and is supplied
without source, it seems on the face of it to violate section 2.
I agree that the drivers *without* the embedded object files are supplied as
source code. I would love to know which nonfree-firmware-loading drivers
do not actually require firmware loading, so that the embedded object files
can just be removed; a quick examination indicates, for example, that the
tg3 driver only requires it for certain specific pieces of hardware, and
not for other supported hardware.
> The way that section 2 is worded I believe it does not.
So I can ship "source code" for whatever I like, in the form of great masses
of hex, and that satisfies the DFSG? That's one hell of a loophole; if
that's confirmed, I expect to see packages in "main" for i386 featuring .s
files made up of mostly of .byte directives (which are machine code
implementing the functions). Because that's "source code", right?
Except that it just isn't really source code; calling it source code is
sophistry. (Well, I it would be source code if someone actually wrote the
machine language by hand, but nobody has seriously contended that any of
this was written by hand.)
> These
> data structures differ from the nvidia object files in that they are in
> the code itself and not separate x86 compiled object files.
I can embed x86 compiled object files into "source code"; it's not
difficult. I can think of several really trivial ways off the top of my
head. These "data structures" are compiled object files embedded into
source code. How does this level of, well, let's call it obfustication,
really make any difference?
> They are
> also not meant to run on the host cpu directly
Which... is.... irrelevant.
> so probably could not
> even be compiled on a FOSS system in the first place even if they are
> not the original form of source for the firmware.
Well, Adaptec not only provided source code but also made available a free
software cross-assembler. That proves that it's possible; if the hardware
manufacturers choose not to, they *choose* not to.
> Others I have talked
> to have said that if 2 is considered in violation then even if we did
> have the source code if we had no way to compile it then it still could
> not go into Debian.
Um, that's correct. That means it would have to go in "contrib", at best.
This isn't rocket science; this is just the same old rules which have been
applied to everything in Debian.
> Also, if we have no way to compile the source how
> would we even know if it is really the source to begin with?
Same goes for lots of stuff which would qualify for 'contrib'.
So, in other words, yes to most of what you said, but it doesn't seem to
actually be much of an argument that this stuff is DFSG-free.
--
Make sure your vote will count.
http://www.verifiedvoting.org/
Reply to: