>> >And the firmware is mere aggregation. Which you've demonstrated by the fact
>> >it is possible to bundle it seperately.
>>
>> No. The fact that it is technically possible to develop
>> software to bundle something separately does not mean that you
>> have bundled it separately.
>Go talk to a lawyer. You'll find there is no difference between a #include
>"firmware.h" or a tar archive. Nor is linking a process carried out by
>gnu ld, its a generic question of dependancy.
>Alan
You know it's not worth $1k to anybody to "win" just an email
discussion, and, as you should know, I have plenty of experience
talking to lawyers about the GPL. If you admonish people to provide a
level of proof that you yourself are not providing, it calls into
question your ability to win the argument under a uniform standard of
proof.
To see how code compiled in files is not "mere aggregation", look at
the work involved in disaggregating it. You'd have to be a programmer
and have source code to produce a working keyspan driver that lacks
the contents of those .h files. If you wanted to have the rest of the
keyspan support with no unfree content on it (like say, Debian without
the "unfree" directory), you could not just omit the keyspan*fw.h
files. You would actually have to do some kernel development.
The 1991 Abridged 6th Edition of _Black's Law Dictionary_
defines "aggregation" thusly (unfortunately, only talking about patent
law):
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.
Perhaps it would help to clarify your position if you would
consider the following. As spelled out in the GPL, you agree to a number of
conditions to get permission to distribute GPL'ed software. So, are you
claiming:
1. that the FSF actually intended to allow people to #include
proprietary uploadable data in GPL'ed object files, or
2. that this is a legal drafting error on the part of FSF
that you have discovered,
3. that the FSF intended the GPL to prohbit such comingling
and the GPL does prohibit it, but _______________?
Admittedly, this does not shed a lot of light on distribution,
but I think it should be pretty clear that keyspan*fw.h fails these tests
too.
In any case, I you would hope that you would respect free software
copyrights enough to at take corrective action immediately when
notified of these problems long before anybody would get annoyed
enough to spend money on lawyers. Even were to accept for the sake of
argument the ridiculous notion that this is legal, it the result would
be creating a market situation where distributions that consist only
of free content would be perceived as not distributing the "complete"
Linux kernel.
If you want another way out of this, you might want to take
my suggestion on moving the firmware uploading to user land on the
grounds that it would clean up the kernel code, slightly reduce the
amount of unswappable kernel memory, and increase flexibility for
EZ-USB-based development. It really would be the right thing to
do technically in the absense of any legal or free software issue.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / 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."
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
