Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

Larry McVoy writes:
>On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote:
>> 	If you want to argue that a court will use a different definition
>> of aggregation, then please explain why and quote that definition.  Also,
>> it's important not to forget the word "mere."  If the combination is anything
>> *more* than aggregration, then it's not _merely_ aggregation.  So,
>> if you wanted to argue from the definition on webster.com:

>Adam, the point is not what the GPL says or what the definition is.
>The point is "what is legal".  You can, for example, write a license
>which says

>	By running the software covered by this license, you agree to 
>	become my personal slave and you will be obligated to bring
>	me coffee each morning for the rest of my life, greating
>	me with a "Good morning, master, here is your coffee oh
>	most magnificent one".

>If anyone is stupid enough to obey such a license, they need help.
>The problem is that licenses can write whatever they want, but what they
>say only has meaning if it is enforceable.  The "license" above would
>be found to be unenforceable by the courts in about 30 seconds or so.

	Contracts for slavery are specifically not enforceable due to
the 13th Amendment, and there is also a stronger question of formation
of a binding contract in your example, because the proposed mode of
acceptance (related to the pointers I provided before) is doing
something that you might have the right to do regardless of copyright
(running the program as opposed to distributing copies).  I believe
that people write contracts all the time that prohibit distribution of
certain works with others, for marketing reasons.

>OK, so what does this have to do with aggregration?  The prevailing 
>legal opinions seem to be that viral licenses cannot extend their
>terms across boundaries.

	We're not talking about mythically changing the copyright
status of another work.  If your opinion is "prevailing" please
include a reference to a section of the US code, a court decision
or some reference that one could actually track down.

	By the way, I have asked a lawyer at an IP litigation firm
that we use about this and he indicated the copyright infringement case
was quite strong.

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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Larry McVoy]

On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:
> 	Contracts for slavery are specifically not enforceable due to
> the 13th Amendment, and there is also a stronger question of formation

Completely misses the point.  THe point isn't about slavery, come on, Adam,
it's about putting unenforceable things into contracts.

It's also about the concept of boundaries - if you think that that 
concept is not a legal one then why aren't all programs which are run
on top of a GPLed kernel then GPLed?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Jeff V. Merkey]

On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:


Copyright infringement would void the GPL, since it would involve
conversion (there's that fancy legal word for "steal" again) of someone 
else's property into another form if you take someone's code and copy it.  
Some things cannot be copyrighted, however, such as on-disk structures 
and wire protocol formats.  Conversion claims do not have to prove bad 
faith to succeed, unlike most other torts.   

Common formats for communications and networking typically can be carried 
from one code base into another without fear of infringement claims.   
Copying source or binary code line for line *IS* copyright infringement 
if the owner has filed and obtained a copyright.  Trade secrets are a bigger
concern.  I have never seen a copyright infringement case succeed with 
regard to someone writing new code, but in piracy cases, this is 
the central tort, along with trademark infringement.  

The Copyright office banned certain classes of computer technology, such
as on-disk and wire protocol formats from being copyrighted over 5 years
ago, so no worries here.

There is, however, a new legal doctrine called "intangible copyright 
infringement" which is being pushed by the same companies that 
brought us the "doctrine of inevitiable disclosure", the legal doctrine
that judges use to slap non-compete agreements on folks who have the 
misfortune of signing an NDA or trade secret agreement with an employer.

This doctrine states that copyrights can be infringed "intangibly" by 
copying common elements from another copyright and assembling them
in the same manner.  It has not been used in any case that does not 
also involve trade secret misapprpriation, and I doubt it will survive
it's first rounf od appeals, but several large software companies 
are engaging in experimental law with this doctrine in an attempt to 
halt open source erosion.

:-)

Jeff   




> Larry McVoy writes:
> >On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote:
> >> 	If you want to argue that a court will use a different definition
> >> of aggregation, then please explain why and quote that definition.  Also,
> >> it's important not to forget the word "mere."  If the combination is anything
> >> *more* than aggregration, then it's not _merely_ aggregation.  So,
> >> if you wanted to argue from the definition on webster.com:
> 
> >Adam, the point is not what the GPL says or what the definition is.
> >The point is "what is legal".  You can, for example, write a license
> >which says
> 
> >	By running the software covered by this license, you agree to 
> >	become my personal slave and you will be obligated to bring
> >	me coffee each morning for the rest of my life, greating
> >	me with a "Good morning, master, here is your coffee oh
> >	most magnificent one".
> 
> >If anyone is stupid enough to obey such a license, they need help.
> >The problem is that licenses can write whatever they want, but what they
> >say only has meaning if it is enforceable.  The "license" above would
> >be found to be unenforceable by the courts in about 30 seconds or so.
> 
> 	Contracts for slavery are specifically not enforceable due to
> the 13th Amendment, and there is also a stronger question of formation
> of a binding contract in your example, because the proposed mode of
> acceptance (related to the pointers I provided before) is doing
> something that you might have the right to do regardless of copyright
> (running the program as opposed to distributing copies).  I believe
> that people write contracts all the time that prohibit distribution of
> certain works with others, for marketing reasons.
> 
> >OK, so what does this have to do with aggregration?  The prevailing 
> >legal opinions seem to be that viral licenses cannot extend their
> >terms across boundaries.
> 
> 	We're not talking about mythically changing the copyright
> status of another work.  If your opinion is "prevailing" please
> include a reference to a section of the US code, a court decision
> or some reference that one could actually track down.
> 
> 	By the way, I have asked a lawyer at an IP litigation firm
> that we use about this and he indicated the copyright infringement case
> was quite strong.
> 
> 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."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

> = Alan Cox
>>  = lk@tantalophile.demon.co.uk?
>>> = ??

>>> AFAICS, the firmware is just a file served up to the device as needed
>>> - no more a derivative work from the kernel than my homepage is a
>>> derivative work of Apache.
>> 
>> Indeed.  But if you compiled your home page, linked it into Emacs to
>> display on startup, and distributed the binary, the _combination_
>> "Emacs+homepage" binary would be a derived work, and you'd be required
>> to offer source for both parts.

>In which case GNU Emacs violates the GPL by containing a copy of COPYING which
>is more restricted than the GPL. After all it displays copying on a hotkey
>combination

	"M-x describe-copying" just displays the file
/usr/share/emacs/<version>/etc/COPYING.   The emacs binaries do not
contain the text of GPL.

	By the way, if one wanted to #include the text of the GPL,
then, in the specific case of the GPL, one could argue that the
restrictions on modifying the GPL are part of the GPL and, therefore
not further restrictions.  (Even though those restrictions occur before
the "preamble", they're just as binding and removing them would be a
change to the GPL, so they are an existing restriction of the GPL rather
than a further restriction.)

	That said, I have long advocated that authors use
GPL-compatible copying conditions for everything, including plain text,
to facilitate free software effects on platforms that comingle code
and documentation, such as many web pages and some other interactive
media.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
A
+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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

James Sutherland wrote:
>On Fri, 25 May 2001, Adam J. Richter wrote:
>> Larry McVoy wrote:
>> >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:

>> >It's also about the concept of boundaries - if you think that that
>> >concept is not a legal one then why aren't all programs which are run
>> >on top of a GPLed kernel then GPLed?
>>
>> 	Apparently Linus felt that that was a sufficiently
>> plausible gray area that he addressed it explicitly in
>> /usr/src/linux/COPYING:
>>
>> |   NOTE! This copyright does *not* cover user programs that use kernel
>> | services by normal system calls - this is merely considered normal use
>> | of the kernel, and does *not* fall under the heading of "derived work".
>> | Also note that the GPL below is copyrighted by the Free Software
>> | Foundation, but the instance of code that it refers to (the Linux
>> | kernel) is copyrighted by me and others who actually wrote it.

>Note the "derived work"; there is no way on this earth (or any other) that
>you could regard the device's firmware as being a "derived work" of the
>driver! AFAICS, the firmware is just a file served up to the device as
>needed - no more a derivative work from the kernel than my homepage is a
>derivative work of Apache.

	Nobody is arguing that it is illegal to copy the keyspan
firmware by itself.  What I think is clearly illegal is copying the
whole keyspan .o file, not because it infringes the firmware copyrights,
but because it infringes the GPL'ed material's copyrights.

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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

Larry McVoy wrote:
>On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:
>> 	Contracts for slavery are specifically not enforceable due to
>> the 13th Amendment, and there is also a stronger question of formation

>Completely misses the point.  THe point isn't about slavery, come on, Adam,
>it's about putting unenforceable things into contracts.

	The point is you have to agree to the contract that is the
GPL to get the right to make a copy of a GPL'ed work.  You raised
the ridiculous example of slavery apparently as an analogy to the
requirements of permissions on copying conditions that go beyond
restrictions one is subject to anyway by copyright.  The point
is that you can make require someone to agree to conditions that
go beyond the restrictions already imposed by copyright in exchange
for permission to, for example, make a copy, so your argument about
the boundaries of copyright is inapplicable.  The GPL is enforceable.

>It's also about the concept of boundaries - if you think that that 
>concept is not a legal one then why aren't all programs which are run
>on top of a GPLed kernel then GPLed?

	Apparently Linus felt that that was a sufficiently
plausible gray area that he addressed it explicitly in
/usr/src/linux/COPYING:

|   NOTE! This copyright does *not* cover user programs that use kernel
| services by normal system calls - this is merely considered normal use
| of the kernel, and does *not* fall under the heading of "derived work".
| Also note that the GPL below is copyrighted by the Free Software
| Foundation, but the instance of code that it refers to (the Linux
| kernel) is copyrighted by me and others who actually wrote it.


	I believe you could enforce copying conditions on a kernel
where, in order to have the right to make a copy of the kernel, you
agree only to run certain types of programs.  I believe Windows CE
has historically been "licensed" this way.

	I did not say that you cannot define boundaries and I also
think you can even make inferences that a judge is likely to agree
with.  What I am saying is that in order to have the right to make
a copy of the of the GPL'ed code in the keyspan_usa drivers, you
must agree to everything the GPL requires, and those requirements
do not have to be limited to the boundaries of the author's existing
copyright.  The GPL is a contract.  If you don't agree to it, don't
do anything with GPL'ed material that the copyright monopoly restricts.

	I am not a lawyer, so please do not rely on this as legal advice.


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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[James Sutherland]

On Fri, 25 May 2001, Adam J. Richter wrote:
> Larry McVoy wrote:
> >On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:

> >It's also about the concept of boundaries - if you think that that
> >concept is not a legal one then why aren't all programs which are run
> >on top of a GPLed kernel then GPLed?
>
> 	Apparently Linus felt that that was a sufficiently
> plausible gray area that he addressed it explicitly in
> /usr/src/linux/COPYING:
>
> |   NOTE! This copyright does *not* cover user programs that use kernel
> | services by normal system calls - this is merely considered normal use
> | of the kernel, and does *not* fall under the heading of "derived work".
> | Also note that the GPL below is copyrighted by the Free Software
> | Foundation, but the instance of code that it refers to (the Linux
> | kernel) is copyrighted by me and others who actually wrote it.

Note the "derived work"; there is no way on this earth (or any other) that
you could regard the device's firmware as being a "derived work" of the
driver! AFAICS, the firmware is just a file served up to the device as
needed - no more a derivative work from the kernel than my homepage is a
derivative work of Apache.


James.

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Jamie Lokier]

James Sutherland wrote:
> Note the "derived work"; there is no way on this earth (or any other) that
> you could regard the device's firmware as being a "derived work" of the
> driver!

The same is true if you add another completely new and separately
written .c source file: the new file is not a derived work of the
driver.  The GPL even has an explicit provision to make it clear that
the GPL covers only the combined work, and the individual components
continue to be available under their original terms.

> AFAICS, the firmware is just a file served up to the device as needed
> - no more a derivative work from the kernel than my homepage is a
> derivative work of Apache.

Indeed.  But if you compiled your home page, linked it into Emacs to
display on startup, and distributed the binary, the _combination_
"Emacs+homepage" binary would be a derived work, and you'd be required
to offer source for both parts.

It is the combination which is considered a derived work, and the GPL
terms apply to a combination when any of the parts is GPLed.  (Otherwise
you aren't granted permission to distributed the combination).

Combination, as ever, is different from "mere aggregation" and that's
where so many arguments begin...

-- Jamie

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alan Cox]

> > AFAICS, the firmware is just a file served up to the device as needed
> > - no more a derivative work from the kernel than my homepage is a
> > derivative work of Apache.
> 
> Indeed.  But if you compiled your home page, linked it into Emacs to
> display on startup, and distributed the binary, the _combination_
> "Emacs+homepage" binary would be a derived work, and you'd be required
> to offer source for both parts.

In which case GNU Emacs violates the GPL by containing a copy of COPYING which
is more restricted than the GPL. After all it displays copying on a hotkey
combination

Is that really what you are trying to say ??

Alan

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Jamie Lokier]

Alan Cox wrote:
> > > AFAICS, the firmware is just a file served up to the device as needed
> > > - no more a derivative work from the kernel than my homepage is a
> > > derivative work of Apache.
> > 
> > Indeed.  But if you compiled your home page, linked it into Emacs to
> > display on startup, and distributed the binary, the _combination_
> > "Emacs+homepage" binary would be a derived work, and you'd be required
> > to offer source for both parts.
> 
> In which case GNU Emacs violates the GPL by containing a copy of
> COPYING which is more restricted than the GPL. After all it displays
> copying on a hotkey combination
> 
> Is that really what you are trying to say ??

Interesting idea.  But no, not at all -- that would be daft!

Whether COPYING, or any other file, is displayed on a hotkey combination
is irrelevant.  My copy of Mozilla can pop up google.com on a mouse
click; there is no implication that Mozilla and google.com are a single
copyrighted entity.  

However, if Mozilla had the Google search engine built in to it, then of
course that instance of the Google code would have to be distributed
under MPL-compatible terms.  If Mozilla simply had the Google front page
built into it as internal "moz_printf" statements, then that code would
have to be MPL-compatible in order to be distributed.

There might be absurd technicalities if COPYING were part of the "source
code" for Emacs ("the Program").  Fortunately COPYING is not part of the
source code of an Emacs binary, because you don't need COPYING to build
the binary.

-- Jamie

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

Doug Ledford wrote:
>"Adam J. Richter" wrote:

>>         On the question of whether this is nothing more than
>> aggregation,

>Yes, on that very question, I would argue it is a mere aggregation.

>> the firmware works intimately with the device driver to
>> produce a unitary result.

>Irrelevant.

        The 1991 Abridged 6th Edition of _Black's Law Dictionary_
defines "aggregation" thusly (unfortunately, talking in terms of
patent law, but it is the most authoratitive definition I have found
so far):

        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.


	If you want to argue that a court will use a different definition
of aggregation, then please explain why and quote that definition.  Also,
it's important not to forget the word "mere."  If the combination is anything
*more* than aggregration, then it's not _merely_ aggregation.  So,
if you wanted to argue from the definition on webster.com:

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

	You have to argue that absolutely nothing more than this
is being done.  For example, the code the parts are not working
together.

>All drivers work with some sort of firmware on their respective
>targets to produce a unitary result, even if that firmware is implemented with
>silicon (as a ROM BIOS that loads the proper firmware code, or as
>microcode/state hardware built into the chip(set) itself).  As a closely
>similar device, think about the 1542 SCSI controller.  [...]

	Yes.  It would also be illegal to distribute a GPL'ed driver
.o that #include'd that proprietary firmware.

>>  You actually have to do some
>> kernel development to remove the
>> [proprietary firmware from the keyspan_usa drivers].


>That's because you are assuming that uploading garbage to the device is not an
>option.

	No.  If I you change the driver to upload garbage, your
userland loader that just looks for the unitialized device ID will
not be able to get to the uninitialized device before the device
driver claims the interface and trashes it.  So, your supposed act of
disaggregation by zeroing out the effected bytes did not fully
restore the old functionality.

	By the way, I'm pretty sure that the situation is even
worse.  The modified driver would not just load garbage to the
ezusb device.  It would tell the ezusb device to jump to it, so
you would not be able to talk to it after that point, other than
by telling the kernel to reset the hub port that the ezusb device
is connected to, in which case, the keyspan_usa driver will again
grab the device and trash it.

	I would also argue that searching for a lengthy bit string
in file format and carefully zeroing it out is enough complexity
so that the connection between the two pieces of information (the
firmware integrated in the .o and the rest of the .o) are more
than just aggregation.

	I'm not denying that you could imagine a case that is a gray
area where the FSF's understood intention in writing the GPL as
interpreted by a judge from the GPL _and other evidence_ under the
four corner's rule may have been to allow it, but I don't think
we're anywhere near it.  But I agree that one could find some
point where it's a judgement call.  If you get sued and the judge
agrees with the plaintiff, you can lose your house, you life's savings,
etc.  in statutory damages at, I believe, $50k per act of copying.
If the judge agrees with you, well, then you have the satisfaction
of winning that argument.  I hope you appreciate the asymmetry of
the risk and have similarly calibrate your standards for caution,
at least when you advocate exposing others to these kinds of risks.

>> you could just skip distribution of an extra file and have the rest of
>> the functionality work. 

>That is exactly the case.  The only change that must be made to remove that .h
>file from the driver source is to tell the driver where the *new* location of
>the correct firmware is.

	What do you mean "remove the .h file" from the .o and
"tell the driver" (open your mouth and talk to the screen?).
We are talking about a .o file.  Copying the .o file is the
act of infringement.

	Also, if you're going to respond further, please also
answer the following question.  Are you claiming that the FSF intended
to allow a GPL'ed .o file that contains proprietary firmware for another
microprocessor or are you claiming that FSF made a drafting error in
the writing the GPL?

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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Jacob Luna Lundberg]

On Fri, 25 May 2001, Adam J. Richter wrote:
>       1 : a group, body, or mass composed of many distinct parts
>           or individuals
>         2 a : the collecting of units or parts into a mass or whole
>         b : the condition of being so collected
>
>       You have to argue that absolutely nothing more than this
> is being done.  For example, the code the parts are not working
> together.

Um.  So you mean that if I use a processor with proprietary microcode then
I can't run Linux on it?  ;-)

Seems the argument is about where an arbitrary boundry should be placed
and clearly it's not black and white.

-Jacob

--

At a global level, the most developed countries "stabilize" the wars
among the outcasts depending on how important each conflict is to the
global economy.

 - ``The Hacker Ethic'' by Pekka Himanen

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Larry McVoy]

On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote:
> 	If you want to argue that a court will use a different definition
> of aggregation, then please explain why and quote that definition.  Also,
> it's important not to forget the word "mere."  If the combination is anything
> *more* than aggregration, then it's not _merely_ aggregation.  So,
> if you wanted to argue from the definition on webster.com:

Adam, the point is not what the GPL says or what the definition is.
The point is "what is legal".  You can, for example, write a license
which says

	By running the software covered by this license, you agree to 
	become my personal slave and you will be obligated to bring
	me coffee each morning for the rest of my life, greating
	me with a "Good morning, master, here is your coffee oh
	most magnificent one".

If anyone is stupid enough to obey such a license, they need help.
The problem is that licenses can write whatever they want, but what they
say only has meaning if it is enforceable.  The "license" above would
be found to be unenforceable by the courts in about 30 seconds or so.

OK, so what does this have to do with aggregration?  The prevailing 
legal opinions seem to be that viral licenses cannot extend their
terms across boundaries.  The aggregration verbage is alluding to that
boundary.  If it is true that viral licenses cannot cross some sort of
boundary (and obviously it is true, otherwise the system call boundary
would not be recognized and all programs ever run on Linux would be GPLed),
then the GPL doesn't get to say what it means by that boundary, the law
gets to say that.  Just like the above "license" doesn't get to create
slaves, some issues are outside the license scope.

I've spoken with my lawyer in depth about this and the feeling is that
there are boundaries which licenses may not cross, and the definition
of such a boundary is one where you could remove the code on one side
of the boundary (aka interface), replace it with completely different 
code, and get substantially the same behaviour.  A device driver is a
good example.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Fri, May 25, 2001 at 11:30:38AM -0700, Larry McVoy wrote:
> 	By running the software covered by this license, you agree to 
> 	become my personal slave and you will be obligated to bring
> 	me coffee each morning for the rest of my life, greating
> 	me with a "Good morning, master, here is your coffee oh
> 	most magnificent one".

Wow, when I read that I thought immediatelyly of the LMbench
"licence"!

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Larry McVoy]

On Fri, May 25, 2001 at 03:30:20PM -0700, Aaron Lehmann wrote:
> On Fri, May 25, 2001 at 11:30:38AM -0700, Larry McVoy wrote:
> > 	By running the software covered by this license, you agree to 
> > 	become my personal slave and you will be obligated to bring
> > 	me coffee each morning for the rest of my life, greating
> > 	me with a "Good morning, master, here is your coffee oh
> > 	most magnificent one".
> 
> Wow, when I read that I thought immediatelyly of the LMbench
> "licence"!

If that's true, I have two questions for you:

    a) Where is my damn coffee?!?!
    b) What about the "Oh master" part?

I've been ripped off.  Where are the license police :-)
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Doug Ledford]

"Adam J. Richter" wrote:
> 
> Doug Ledford wrote:
> >"Adam J. Richter" wrote:
> 
> >>         On the question of whether this is nothing more than
> >> aggregation,
> 
> >Yes, on that very question, I would argue it is a mere aggregation.
> 
> >> the firmware works intimately with the device driver to
> >> produce a unitary result.
> 
> >Irrelevant.
> 
>         The 1991 Abridged 6th Edition of _Black's Law Dictionary_
> defines "aggregation" thusly (unfortunately, talking in terms of
> patent law, but it is the most authoratitive definition I have found
> so far):
> 
>         Aggregation: The combination of two or more elements in patent claims,

So the first thing the attorney would have to do is convince the judge that
the definition of a term from patent claims means what you are claiming it
means in software licensing 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.
> 
>         If you want to argue that a court will use a different definition
> of aggregation, then please explain why and quote that definition.

Why is because the definition you have been pushing here is anything that
results in a "unitary" result.  That's flawed (it's actually quite insane
IMNSHO, since the major point of my last email was that *damn near everything*
in the computer world results in a "unitary" result, including the glibc ->
kernel syscall interface Larry mentions in his email, the module loading
interface that the kernel exports, etc.  The point of my last email was
largely that what you are calling a "unitary" result, is in fact what most
people call an API).  To quote Larry, it would take roughly 30 seconds to get
that definition of "unitary" result thrown out as overly broad.

>  Also,
> it's important not to forget the word "mere."  If the combination is anything
> *more* than aggregration, then it's not _merely_ aggregation.  So,
> if you wanted to argue from the definition on webster.com:
> 
>         1 : a group, body, or mass composed of many distinct parts
>             or individuals
>         2 a : the collecting of units or parts into a mass or whole
>           b : the condition of being so collected
> 
>         You have to argue that absolutely nothing more than this
> is being done.  For example, the code the parts are not working
> together.

Yep, that's pretty much what it is.  The firmware is what actually implements
the API on the device we are discussing.  The driver interacts via said API. 
The firmware is actually an opaque object that could be replaced with any
other firmware that implements the same API and things would work the same. 
The downloading of the firmware is just one step in the initialization of the
device and is not dependant on any given firmware version or release.  The
placing of the driver that downloads any valid firmware to the device (or
invalid for that matter) and the firmware itself in the same .o is a matter of
convenience and is merely collecting two individual parts into a mass.

> >All drivers work with some sort of firmware on their respective
> >targets to produce a unitary result, even if that firmware is implemented with
> >silicon (as a ROM BIOS that loads the proper firmware code, or as
> >microcode/state hardware built into the chip(set) itself).  As a closely
> >similar device, think about the 1542 SCSI controller.  [...]
> 
>         Yes.  It would also be illegal to distribute a GPL'ed driver
> .o that #include'd that proprietary firmware.
> 
> >>  You actually have to do some
> >> kernel development to remove the
> >> [proprietary firmware from the keyspan_usa drivers].
> 
> >That's because you are assuming that uploading garbage to the device is not an
> >option.
> 
>         No.  If I you change the driver to upload garbage, your
> userland loader that just looks for the unitialized device ID will
> not be able to get to the uninitialized device before the device
> driver claims the interface and trashes it.  So, your supposed act of
> disaggregation by zeroing out the effected bytes did not fully
> restore the old functionality.

You missed the point.  The firmware is an opaque object to the driver, not an
integral part of the driver.  Read above.

> >That is exactly the case.  The only change that must be made to remove that .h
> >file from the driver source is to tell the driver where the *new* location of
> >the correct firmware is.
> 
>         What do you mean "remove the .h file" from the .o and
> "tell the driver" (open your mouth and talk to the screen?).

The current driver knows where the firmware is by #include'ing it in itself. 
That is, in and of itself, a means of locating the firmware.  You could
replace that with a code snippet that loaded the firmware from a file on disk
or on an initrd and read it into the same data format that the .h file
presents the firmware in.  That would, in effect, tell the driver the new
location of the file (you would again have the location hard coded in the
driver).

> We are talking about a .o file.  Copying the .o file is the
> act of infringement.

And while that's an interesting topic, my original statement, and the only one
I am arguing, is whether or not the .o is a mere aggregation or is it
something more.

>         Also, if you're going to respond further, please also
> answer the following question.  Are you claiming that the FSF intended
> to allow a GPL'ed .o file that contains proprietary firmware for another
> microprocessor or are you claiming that FSF made a drafting error in
> the writing the GPL?

While I may be moderately intelligent, I am not Ms. Cleo, and me and my Tarrot
cards are having a hard time discerning an intent on the part of the FSF.  Why
don't you ask them since they are the only ones that can explain their own
intent.  Or better yet, who cares about what their intent was, what matters is
what is actually written in the license and how a court will interpret that
license.

-- 

 Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
      Please check my web site for aic7xxx updates/answers before
                      e-mailing me about problems

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

	Here's a surprise.  I think the problems with the keyspan
copyrights may have sprung from an administrative error.  I notice that
the copyright notices in
linux-2.4.*/drivers/usb/serial/keyspan_usa{26,28,49}msg.h, which look
GPL compatible to me, look as if they were intended for
keyspan_usa{18x,19,28,28x,49w}_fw.h, since they refer to firmware
in their titles:

        Copyright (c) 1998-2000 InnoSys Incorporated.  All Rights Reserved
        This file is available under a BSD-style copyright

        Keyspan USB Async Firmware to run on Anchor EZ-USB
                          ^^^^^^^^


	Yet, the keyspan*msg.h files have no firmware.  The firmware
is in keyspan_usa*_fw.h.

	Hugh, perhaps you could pass this up the chain of command
at Keyspan and see if they will simply grant permission to
replace the *_fw.h copyright notice with the one from *msg.h, which
is probably a lot simpler than having them spend lawyer and management
time on writing new terms.

	I have cc'ed this to linux-kernel because there is a
current discussion going on there on this subject that I had just
responded to.

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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Adam J. Richter]

>> = Aaron Lehmann <aaronl@vitelus.com>.
>  = Albert D. Cahalan <acahalan@cs.uml.edu>

>> 	I believe this infringinges the copyrights of the authors
>> of the code used in these drivers who released their code under GPL.
>> Alan Cox, has gone on a campaign claiming that this is "mere aggregation"

>As far as the Linux kernel is concerned, firmware images are
>not software at all. They are large magic numbers that must
>be written to the hardware. (they don't execute on your CPU)

>If a driver writes 0x63f30e44 (4 bytes) to the card, no problem?
>Fine, how about 0x52e590a84fc8231e (8 bytes) then? You can see
>where this is leading I hope: 200 kB is perfectly fine.

>It's obviously not size that matters. What matters is that Linux
>doesn't transfer control into the firmware; that is, Linux does
>not do a jump into firmware like this:

>goto *((void*)firmware);

	I have never heard of this legal standard.  A reference
to some section of Title 17 in the United States Code (copyright), a
relevant court precedent, etc. would be appreciated.

	I am not a lawyer, so please do not use this as legal advice.

	A software "license" typically grants you permission to do
things that you would not otherwise be allowed to do with a
copyrighted work in the absense of any permission (such as make a copy
in most cases), provided that you meet certain conditions.  Those
conditions could be nearly anything.  They're not necessarily limited
to what is restricted by copyright.  I used to think it was so limited
due to copyright preemption of state law by title 17 of US Code section
301, http://www4.law.cornell.edu/uscode/17/301.html, but apparently
this does not appear to be so according, for example, to
http://www.richmond.edu/~jolt/v1i1/hardy.html#fn13, which references
"Hines v. Davidowitz, 312 U.S. 52, 67 (1941), reaffirmed in Sears,
Roebuck & Co. v. Stiffel Co., 376 U.S. 225, reh'g denied, 376 U.S.
973 (1964)", which I HAVE NOT READ, but I have read other things about
this question and this just happens to be what I could dig up in a few
seconds on google.

	If I recall correctly, doing something that is only legal if
you had accepted an agreement is acceptance according to some
provision of the uniform commercial code.  (No, it's not new.  I think
at http://www.law.cornell.edu/ucc/2/2-206.html, section 1a, and the
definition of goods to include "goods in action" in
http://www.law.cornell.edu/ucc/2/2-105.html#Goods_2-105).

	From this, I hope we can agree that is possible to write
copying conditions that prohibit make any copies of certain free
software contained in the keyspan_usa drivers if the keyspan_usa firmware is
also distributed in the same driver ".o" file, and that the question
is simply whether the GPL does so.

	So, Albert, are you claiming that the FSF intended to allow a
GPL'ed .o file that contains proprietary firmware for another
microprocessor or are you claiming that FSF made a drafting error in
the writing the GPL?

	If you believe you have found an error in the GPL, do you
think a court would let you out of it given the four corners rule
(basically using evidence of the understood meaning of an agreement to
interpret what was actually written down)?

	On the question of whether this is nothing more than
aggregation, the firmware works intimately with the device driver to
produce a unitary result.  The part of the driver that runs in the
device and the CPU side speak a mutually agreed upon protocol, and the
unitary result is that you do not have to preload the firmware as
earlier versions of the driver required.  You actually have to do some
kernel development to remove the code.  It's not simply the case that
you could just skip distribution of an extra file and have the rest of
the functionality work.  In fact, even if you zeroed out the
microcode, you would still not get the result of having the driver
work (e.g., if you had loaded the code originally).  Instead, the
driver would fill the device with all zeroes.  Greg Kroah-Hartman has
already said he thinks removal is complicated enough that he does not
want to voluntarily do it in 2.4.  For these reasons, this situation
is not just shipping two works next to each other (mere aggregation).

	I hope it should be clear now that the GPL can and does
prohibit #include'ing this and that it is not mere aggregation.

	I also hope that people understand that while I think the
stability argument for not including my fix in 2.4 (which everyone
seems to like technically) is BS, I would be satisfied if the
keyspan_usa drivers were now released under GPL-compatible copying
conditions.  However, it has now been weeks this has not been done.

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."

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Doug Ledford]

"Adam J. Richter" wrote:

>         On the question of whether this is nothing more than
> aggregation,

Yes, on that very question, I would argue it is a mere aggregation.

> the firmware works intimately with the device driver to
> produce a unitary result.

Irrelevant.  All drivers work with some sort of firmware on their respective
targets to produce a unitary result, even if that firmware is implemented with
silicon (as a ROM BIOS that loads the proper firmware code, or as
microcode/state hardware built into the chip(set) itself).  As a closely
similar device, think about the 1542 SCSI controller.  It has a BIOS that must
load firmware before the card will work.  The only difference between it and
the device you are arguing about is *how* the firmware gets loaded, and by
what program, not whether the firmware gets loaded or whether the firmware is
required for the device to be in the least bit usefull as a computer
component.

>  The part of the driver that runs in the
> device and the CPU side speak a mutually agreed upon protocol, and the
> unitary result is that you do not have to preload the firmware as
> earlier versions of the driver required.

Again, irrelevant.  This has always been done.  In the past, it was done by a
user land program.  Now it's done as part of the kernel.  So, the code now
knows how to speak "load the firmware" language to the chipset.  This is a
feature of the driver that is, in fact, not in the least bit related to the
firmware itself.  The driver could load garbage to the device and this code
would be working properly.  The choice of what data to upload to a device is
distinctly different from the ability to upload data.

>  You actually have to do some
> kernel development to remove the code.

That's because you are assuming that uploading garbage to the device is not an
option.  This is incorrect.  You can in fact remove the firmware and upload
garbage.  The result would be that the device would not work as expected. 
Would this be because of a bug in the firmware loading code?  No.  It would be
because you uploaded garbage.  You could likewise make a much smaller
modification to the driver so that it would allow you to specify whether or
not to upload the code, then tell it not to upload the code, and preload the
firmware as before and things would work without removing the ability to
upload code from the driver.  You could also modify the driver to pass the
firmware to the driver via an initrd or some such and have this code work
without having the .h file included in the .o archive.

>  It's not simply the case that
> you could just skip distribution of an extra file and have the rest of
> the functionality work. 

That is exactly the case.  The only change that must be made to remove that .h
file from the driver source is to tell the driver where the *new* location of
the correct firmware is.  This does not constitute a dependancy on having the
firmware included in the driver, it merely constitutes a hard coded, expected
location of the firmware that must be updated whenever the firmware is moved.

> In fact, even if you zeroed out the
> microcode, you would still not get the result of having the driver
> work (e.g., if you had loaded the code originally).  Instead, the
> driver would fill the device with all zeroes.

And thank you for making my point.  The upload code would in fact work, it
would just upload a bogus firmware.  Bad data is bad data.  However, stating
that providing a driver with bad data makes it fail is a non-issue and proves
nothing.  I could write all 0's to the PCI bridge in my system and it wouldn't
work properly.  Duhhhh.....who would expect it to?

>  Greg Kroah-Hartman has
> already said he thinks removal is complicated enough that he does not
> want to voluntarily do it in 2.4.

Aka, he doesn't want to correct/work around the fact that the driver has the
location of the firmware data hard coded right now.  He doesn't have to remove
all the upload code to remove the firmware file, he merely has to teach the
driver to find the firmware code elsewhere or to not upload garbage when it
doesn't know where the firmware is.

>  For these reasons, this situation
> is not just shipping two works next to each other (mere aggregation).

Your reasons are bogus, it's a mere aggregation.

>         I hope it should be clear now that the GPL can and does
> prohibit #include'ing this and that it is not mere aggregation.
> 
>         I also hope that people understand that while I think the
> stability argument for not including my fix in 2.4 (which everyone
> seems to like technically) is BS, I would be satisfied if the
> keyspan_usa drivers were now released under GPL-compatible copying
> conditions.  However, it has now been weeks this has not been done.
> 
> 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."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

 Doug Ledford <dledford@redhat.com>  http://people.redhat.com/dledford
      Please check my web site for aic7xxx updates/answers before
                      e-mailing me about problems

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Fri, May 25, 2001 at 01:59:08AM -0400, Albert D. Cahalan wrote:
> If a driver writes 0x63f30e44 (4 bytes) to the card, no problem?
> Fine, how about 0x52e590a84fc8231e (8 bytes) then? You can see
> where this is leading I hope: 200 kB is perfectly fine.

Yes, I thought this way at first. However, the GPL is actually quite
explicit about defining source code:
	The source code for a work means the preferred form of the work for
	making modifications to it.

That means that if you modify your string of bytes in a hex editor,
it's not a problem. But if (as in the case of firmware) you create the
strings from secret, undistributed source files, then according to the
GPL the strings are not source code. Since the source code is
unavailable, that makes them non-free. You can see where this leads...

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On Thu, 24 May 2001, Aaron Lehmann wrote:

> explicit about defining source code:
> 	The source code for a work means the preferred form of the work for
> 	making modifications to it.

Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
of constants of unknown origin. If you want to modify the implementation
you most certainly want more than numeric values.

Same goes for any tables that contain anything besides well-known constants.

Should we file bug reports against glibc?

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> Should we file bug reports against glibc?

invsqrtpi=  5.64189583547756279280e-01
Inverted square root of pi. Want to file a bug on Pi?

tpi      =  6.36619772367581382433e-01,
R0/S0 on [0, 2.00]

I'm not sure what R and S are, but the glibc developers probably are.
IMHO poorly documented code is different from binary-only code.
However, it appears to be a sketchy line.

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On Thu, 24 May 2001, Aaron Lehmann wrote:

> On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> > Should we file bug reports against glibc?
> 
> invsqrtpi=  5.64189583547756279280e-01
> Inverted square root of pi. Want to file a bug on Pi?

Nope. Well-known constant.

> tpi      =  6.36619772367581382433e-01,
> R0/S0 on [0, 2.00]
> 
> I'm not sure what R and S are, but the glibc developers probably are.
> IMHO poorly documented code is different from binary-only code.
> However, it appears to be a sketchy line.

It _is_ a sketchy line. In that case you can be damn sure that constants
had been derived from other form. And you need that other form to do any
modifications that wouldn't turn the thing into random junk.

Normally you don't need it, unless you feel that one you have in glibc is
not good enough for your needs or want to experiment with modifying it.
Or analise the thing.

It's pretty similar to the case in question. The only difference is that
information needed to implement Bessel functions from scratch is easier
to find. However, it will be reimplementing from scratch. It won't help
you to answer any questions about the accuracy of implementation in glibc,
etc.

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Andreas Jaeger]

Aaron Lehmann <aaronl@vitelus.com> writes:

> On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> > Should we file bug reports against glibc?
> 
> invsqrtpi=  5.64189583547756279280e-01
> Inverted square root of pi. Want to file a bug on Pi?
> 
> tpi      =  6.36619772367581382433e-01,
> R0/S0 on [0, 2.00]
> 
> I'm not sure what R and S are, but the glibc developers probably are.

We have comments in the code that state how j0 is build, and R0/S0
come from some expansion:
 * Bessel function of the first and second kinds of order zero.
 * Method -- j0(x):
 *	1. For tiny x, we use j0(x) = 1 - x^2/4 + x^4/64 - ...
 *	2. Reduce x to |x| since j0(x)=j0(-x),  and
 *	   for x in (0,2)
 *		j0(x) = 1-z/4+ z^2*R0/S0,  where z = x*x;
 *	   (precision:  |j0-1+z/4-z^2R0/S0 |<2**-63.67 )

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On 25 May 2001, Andreas Jaeger wrote:

> We have comments in the code that state how j0 is build, and R0/S0
> come from some expansion:
>  * Bessel function of the first and second kinds of order zero.
>  * Method -- j0(x):
>  *	1. For tiny x, we use j0(x) = 1 - x^2/4 + x^4/64 - ...
>  *	2. Reduce x to |x| since j0(x)=j0(-x),  and
>  *	   for x in (0,2)
>  *		j0(x) = 1-z/4+ z^2*R0/S0,  where z = x*x;
>  *	   (precision:  |j0-1+z/4-z^2R0/S0 |<2**-63.67 )
> 
> Andreas

Sure. However, the question about choosing the polynomials stands.
(And no, I'm not proposing to go and bugger glibc folks over that ;-)

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Erik Mouw]

On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
> of constants of unknown origin. If you want to modify the implementation
> you most certainly want more than numeric values.

Nothing special IMHO. Look up 'Bessel functions' in a math book and you
should be able to derive the constants.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alexander Viro]

On Fri, 25 May 2001, Erik Mouw wrote:

> On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
> > Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
> > of constants of unknown origin. If you want to modify the implementation
> > you most certainly want more than numeric values.
> 
> Nothing special IMHO. Look up 'Bessel functions' in a math book and you
> should be able to derive the constants.

Look up "sarcasm" in a dictionary. Seriously.

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Pavel Machek]

Hi!

> > explicit about defining source code:
> > 	The source code for a work means the preferred form of the work for
> > 	making modifications to it.
> 
> Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
> of constants of unknown origin. If you want to modify the implementation
> you most certainly want more than numeric values.
> 
> Same goes for any tables that contain anything besides well-known constants.

Imagine the hell opening when you generate table of random numbers
with hardware generator :-). How do you write source of hardware
random generator?
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Pete Zaitcev]

> From: "Adam J. Richter" <adam@yggdrasil.com>
> Date: Sun, 22 Apr 2001 12:53:48 -0700
> To: debian-legal@lists.debian.org
> Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

>[...]
> 	I believe this infringinges the copyrights of the authors
> of the code used in these drivers who released their code under GPL.
> Alan Cox, has gone on a campaign claiming that this is "mere aggregation"
> and insists that I bring in the lawyers to prove him otherwise.  I
> really do not want to take this step, but he is forcing my hand.  Note
> that Yggdrasil is a copyright owner in this case.

Translation: Adam was soundly beaten on linux-usb-devel and is sore.

> 	To simplify removal of the offending code, I have provided
> a separate user level facility that can use the USB "hot plugging"
> system to automatically load that "firmware" or any other. [...]

A good thing for many reasons, if it works. Personally, I do not
care why Adam writes right code as long as he does. :)

-- Pete

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Thu, May 24, 2001 at 10:00:15PM -0700, Matthew Jacob wrote:
> 
> It is my opinion, such as it is, that a BSD copyright inside of a GPL package
> does not, per se, weaken the GPL. The BSD copyright is, in fact, the more
> permissive license. My reading of both licenses would have me believe that a
> BSD licensed piece of software cannot then permit the linux kernel to be
> binary only. The BSD licencse does not, per se, prohibit any form of binary
> redistribution- nor does it require it. The GPL covers the whole kernel, and
> if a BSD piece of code is directly linked in (not modloaded), it would have to
> also be under GPL.
> 
> So pieces of linux-kernel which have BSD copyright are probably just fine.

/* keyspan_usa18x_fw.h
  
   Generated from Keyspan firmware image Wed Jul  5 09:18:29 2000 EST
   This firmware is for the Keyspan USA-18X Serial Adaptor

   "The firmware contained herein as keyspan_usa18x_fw.h is
   Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated
   ("Keyspan"), as an unpublished work.  This notice does not imply
   unrestricted or public access to this firmware which is a trade secret of
   Keyspan, and which may not be reproduced, used, sold or transferred to any
   third party without Keyspan's prior written consent.  All Rights Reserved.

   This firmware may not be modified and may only be used with the Keyspan 
                 ^^^^^^^^^^^^^^^^^^^
   USA-18X Serial Adapter.  Distribution and/or Modification of the
   keyspan.c driver which includes this firmware, in whole or in part,
   requires the inclusion of this statement."

That doesn't look like the BSD license to me.

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Matthew Jacob]

Sure- that's not BSD. You were speaking about all kinds of firmware, at least
I thought you were. Must be too short on sleep.


On Thu, 24 May 2001, Aaron Lehmann wrote:

> On Thu, May 24, 2001 at 10:00:15PM -0700, Matthew Jacob wrote:
> > 
> > It is my opinion, such as it is, that a BSD copyright inside of a GPL package
> > does not, per se, weaken the GPL. The BSD copyright is, in fact, the more
> > permissive license. My reading of both licenses would have me believe that a
> > BSD licensed piece of software cannot then permit the linux kernel to be
> > binary only. The BSD licencse does not, per se, prohibit any form of binary
> > redistribution- nor does it require it. The GPL covers the whole kernel, and
> > if a BSD piece of code is directly linked in (not modloaded), it would have to
> > also be under GPL.
> > 
> > So pieces of linux-kernel which have BSD copyright are probably just fine.
> 
> /* keyspan_usa18x_fw.h
>   
>    Generated from Keyspan firmware image Wed Jul  5 09:18:29 2000 EST
>    This firmware is for the Keyspan USA-18X Serial Adaptor
> 
>    "The firmware contained herein as keyspan_usa18x_fw.h is
>    Copyright (C) 1999-2000 Keyspan, A division of InnoSys Incorporated
>    ("Keyspan"), as an unpublished work.  This notice does not imply
>    unrestricted or public access to this firmware which is a trade secret of
>    Keyspan, and which may not be reproduced, used, sold or transferred to any
>    third party without Keyspan's prior written consent.  All Rights Reserved.
> 
>    This firmware may not be modified and may only be used with the Keyspan 
>                  ^^^^^^^^^^^^^^^^^^^
>    USA-18X Serial Adapter.  Distribution and/or Modification of the
>    keyspan.c driver which includes this firmware, in whole or in part,
>    requires the inclusion of this statement."
> 
> That doesn't look like the BSD license to me.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

On Thu, May 24, 2001 at 11:26:20PM -0700, Matthew Jacob wrote:
> Sure- that's not BSD. You were speaking about all kinds of firmware, at least
> I thought you were. Must be too short on sleep.

Yes, I am. New-style BSD licenses are compatible with the GPL. As long
as a piece of firmware contains source (which I discussed in a
previous post; see the GPL for the relevent defenition of source code)
and is under a GPL-compatible license it should be fine (excepting
further issues like patents.

In the case of the keyspan drivers, the source code is not distributed
and the license is not free, nor GPL-compatible. I hear steps are
going towards resolving this, which is excellent. My other concern is
what the general policy towards these non-free firmware images
is/should be. I know that a lot of firmware exists in advansys.c, and
there are probably many more occurances of binary-only firmware
throughout the kernel.

Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Aaron Lehmann]

This message sparked a long thread on the debian-legal mailing list,
which is long since dead. I am personally very curious about whether
this has been resolved upstream. I consider it a very important issue,
which is why I asked for RMS' opinion. He said that what is being done
is clearly not "mere aggregation", and that such firmware should be
moved out of the kernel (and even the tarball) to stop violating the
GPL and make Linux be free software.

As a user of hardware which requires firmware like this, I have mixed
feelings, but feel strongly that requirements of the GPL clearly
override any measure of convenience. Are there any plans to remove the
binary-only firmware from the kernel, and/or eventually from the Linux
source distribution? I am not refering to this USB driver
specifically, but rather the general occurance of firmware embedded in
Linux device trivers.

----- Forwarded message from "Adam J. Richter" <adam@yggdrasil.com> -----

From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 22 Apr 2001 12:53:48 -0700
To: debian-legal@lists.debian.org
Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h


	Linus's Linux kernel releases from 2.3.50 through the latest
test release (2.4.4-pre6) contain GPL-incompatible "firmware" images
for "EZUSB" devices in linux/drivers/usb/serial/keyspan*fw.h, which
are #included into drivers which contain GPL'ed code, even when compiled
as modules.

	I believe this infringinges the copyrights of the authors
of the code used in these drivers who released their code under GPL.
Alan Cox, has gone on a campaign claiming that this is "mere aggregation"
and insists that I bring in the lawyers to prove him otherwise.  I
really do not want to take this step, but he is forcing my hand.  Note
that Yggdrasil is a copyright owner in this case.

	To simplify removal of the offending code, I have provided
a separate user level facility that can use the USB "hot plugging"
system to automatically load that "firmware" or any other.  The USB serial
maintainer already plans to switch to it in 2.5, and has tested it and
verified that it works.  The software and a kernel patch to remove
the offending code is FTPable from
ftp://ftp.yggdrasil.com/pub/dist/device_control/ezusb/.  The kernel patch
also moves the "whiteheat" code loading into the same user space utility,
just for technical reasons, even though that code can apparently be legally
included in the kernel.  Note that even without this software, the EZUSB
firmware can apparently be loaded by other facilities or from other
operating systems.

	Here is what people involved in Debian should do:

		1. Make sure that no Debian release or snapshot that
		   includes a kernel from 2.3.50 through the current
		   one (don't know if there are any yet) includes
		   linux/drivers/usb/serial/keyspan*fw.h.  By the way,
		   even if there were no legal liability, these files
		   could not be in the "free" part of Debian, if I
		   read the Debian Free Software "Guidelines" correctly.

		2. Possibly include the user level software FTPable from
		   Yggdrasil, although be warned that that code will probably
		   be replaced in the near future to use an input file
		   format more compatible with other development tools used
		   for EZUSB 8051 microcontroller software development.

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."


-- 
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



----- End forwarded message -----

-- 
#define m(i)(x[i]^s[i+84])<< /* I do not condone improper use of this code */
unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=2048);write(1,s
,n))if(s[y=s[13]%8+20]/16%4==1){int i=m(1)17^256+m(0)8,k=m(2)0,j=m(4)17^m(3)9^k
*2-k%8^8,a=0,c=26;for(s[y]-=16;--c;j*=2)a=a*2^i&1,i=i/2^j&1<<24;for(j=127;++j<n
;c=c>y)c+=y=i^i/8^i>>4^i>>12,i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<6,a=a>>8^y<<9,k=s
[j],k="7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=k^(k&k*2&34)
*6^c+~y;}}//Please join us in civil disobedience and distribute DeCSS(or efdtt!)

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Greg KH]

On Thu, May 24, 2001 at 09:34:04PM -0700, Aaron Lehmann wrote:
> This message sparked a long thread on the debian-legal mailing list,
> which is long since dead. I am personally very curious about whether
> this has been resolved upstream. I consider it a very important issue,
> which is why I asked for RMS' opinion. He said that what is being done
> is clearly not "mere aggregation", and that such firmware should be
> moved out of the kernel (and even the tarball) to stop violating the
> GPL and make Linux be free software.

Last I heard, Hugh was talking with the Keyspan people to get this
resolved.  But that was a few weeks ago.

Any news Hugh?

thanks,

greg k-h

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[John Cavan]

Not to sound dense, but what part of the GPL prohibits a piece of GPL'd
software from including non-GPL'd code? The GPL does explicitly state
that you can't include it's software in proprietary code, but I don't
recall seeing a provision that prohibits the other way around.

It may not be in the "spirit" of the GPL, but as a legal document, the
letter means more than the spirit in the final determination.

Sorry to intrude on this, but the thought just struck me. I could be
wrong in my remembrance.

John

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alan Cox]

> Not to sound dense, but what part of the GPL prohibits a piece of GPL'd
> software from including non-GPL'd code? The GPL does explicitly state
> that you can't include it's software in proprietary code, but I don't
> recall seeing a provision that prohibits the other way around.

The same thinbg holds true both ways. A work containing GPL code must be GPL
or freer. Adding either to the other is the same thing.

The firmware is a seperate work, and its mere aggregation even if a .o file
is a more unusual archive formt

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

[Alan Cox]

> which is why I asked for RMS' opinion. He said that what is being done
> is clearly not "mere aggregation", and that such firmware should be
> moved out of the kernel (and even the tarball) to stop violating the
> GPL and make Linux be free software.

Given that the firmware is a seperate work (try loading it under windows
and you'll find its quite useful without Linux and does not depend on Linux)
and that the folks I have raised this with - who should know their law - 
disagree with Adam I'm not currently persuaded.

The relationship between a USB driver and the kernel is no different to that
between say a web browser and server chatting over a network. In this case
the network is USB not IP based that is all. Clearly mozilla does not cease
to be free software or a seperate work because you looked at microsoft.com
with it.

Now if you want a plausible example of the kind of thing Adam is talking about
you should take a hard look at the ACPI code, where ACPI bytecode is linked
into the kernel by interpreting it

Alan