Re: Keyspan Firmware fun

["Adam J. Richter" <adam@yggdrasil.com>]

Sam Hartman <hartmans@mit.edu> writes:
>If the code is
>simply bits that will be spewed out to some device, that seems much
>more like a combination than linking.

	This is derived from a similar message that I posted to
linux-usb-devel, in case anyone notices the similarity.

	The 1991 Abridged 6th Edition of _Black's Law Dictionary_
defines "aggregation" thusly (unfortunately, only talking about patent
law, my emphasis):

	Aggregation: The combination of two or more elements in patent claims,
	each of which is unrelated and each of which performs separately and
	without cooperation, where combination does not define a composite
	integrate mechanism.  Term means that the elements of a claimed
	combination are incapabile of co-operation to produce a unitary
	result, and in its true sense does not need prior art patents to
	support it.

	Websters.com defines aggregation thusly:

	1  : a group, body, or mass composed of many distinct parts
	     or individuals
	2a : the collecting of units or parts into a mass or whole
	 b : the condition of being so collected

	
	One test that I would suggest for whether the combination of
two items is absolutely nothing more than (i.e., "mere") aggregation
is: is disaggregation of these supposedly still distinct parts
trivial?  Given one of these keyspan*.o files, how trivially can a
competent Linux user copy it without the firmware to save then
10kB or space?  Answer: It's a lot of work.  That person would practically
have to be a programmer to do it.  In fact, even if you zero out
the firmware with a binary editor (which still does not recover the
space), you will still get slighty different behavior: if you plug
in a keyspan device that exports the its initial ID, it will not just
ignore it, it will trash the keyspan's memory.

	I espcecially don't see how anyone can seriously claim that
inclusion of this feature is "mere aggregation" but removal of what
is supposedly merely aggregated is so complex that it needs to wait
for linux-2.5 to be done on the stock kernel releases.

	Here is another question to ponder.  As spelled out in the GPL,
you agree to a number of conditions to get permission to distribute
GPL'ed software.  Do you believe:
	1. that the FSF actually intended to allow people to #include
	   proprietary uploadable data in GPL'ed object files, or
	2. that you have discovered is a legal drafting error on the
	   part of FSF (which they should fix right away), or
	3. that the FSF intended the GPL to prohbit such comingling
	   and the GPL does prohibit it, but _______________?


	Although not a Debian user, I agree with most of the rest of what
you said.  The fact that somebody somewhere might be violating the GPL is
not of great urgency to me.  One can at least ignore it and never soil
one's machine with those bits.  The reason the keyspan firmware is a
more immediate problem is the inclusion of these bits in the stock kernel
.tar.gz files, which interferes with distributions tracking the Linux
kernel as a purely free software component, FTP mirroring, etc.  For
example, ftp://ftp.yggdrasil.com/pub/linux/kernel/v2.{3,4} is closed
to avoid infringing.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."