Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
> = Alan Cox >> = [EMAIL PROTECTED]? >>> = ?? >>> 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//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 [EMAIL PROTECTED] \ / 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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
= Alan Cox = [EMAIL PROTECTED]? = ?? 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 [EMAIL PROTECTED] \ / 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 [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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 [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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] In my country we have almost anarchy and I don't care. Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 > [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." > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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 [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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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"! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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" 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
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 wrote: > Doug Ledford wrote: > >"Adam J. Richter" wrote: > > >> On the question of whether this is nothing more than > >> aggregation, ... [patent law definition of aggregation] ... Well, I'm just an interested bystander. But having read the recent lkml posts on this issue, it seems to me that the critical points are: >From the point of view of the kernel, the firmware code is just a big magic number that "turns on" the firmware. The kernel is not _linked_ _with_ the firmware code. The kernel doesn't even _exec_ the firmware. The firmware code can be used, unmodified, in other operating systems. The firmware code does not run in the same address space as the kernel. In principle, and maybe in practice, that firmware code might be running on a different processor, with different RAM, and a different instruction set. It's obviously not part of the kernel! Torrey Hoffman - [EMAIL PROTECTED] --- I find this corpse guilty of carrying a concealed weapon and I fine it $40. -- Judge Roy Bean, finding a pistol and $40 on a man he'd just shot. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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" 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. Du.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 > [EMAIL PROTECTED] \ / San Jose, California 95129-1034 > +1 408 261-6630 | g g d r a s
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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
[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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>. > = Albert D. Cahalan <[EMAIL PROTECTED]> >> 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 [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
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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 ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] private [EMAIL PROTECTED] http://www.suse.de/~aj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] private [EMAIL PROTECTED] http://www.suse.de/~aj - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 ;-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 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. Du.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 [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
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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.
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 wrote: Doug Ledford wrote: Adam J. Richter wrote: On the question of whether this is nothing more than aggregation, ... [patent law definition of aggregation] ... Well, I'm just an interested bystander. But having read the recent lkml posts on this issue, it seems to me that the critical points are: From the point of view of the kernel, the firmware code is just a big magic number that turns on the firmware. The kernel is not _linked_ _with_ the firmware code. The kernel doesn't even _exec_ the firmware. The firmware code can be used, unmodified, in other operating systems. The firmware code does not run in the same address space as the kernel. In principle, and maybe in practice, that firmware code might be running on a different processor, with different RAM, and a different instruction set. It's obviously not part of the kernel! Torrey Hoffman - [EMAIL PROTECTED] --- I find this corpse guilty of carrying a concealed weapon and I fine it $40. -- Judge Roy Bean, finding a pistol and $40 on a man he'd just shot. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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 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
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
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! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 [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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 [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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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
[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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
> From: "Adam J. Richter" <[EMAIL PROTECTED]> > Date: Sun, 22 Apr 2001 12:53:48 -0700 > To: [EMAIL PROTECTED] > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] 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
From: Adam J. Richter [EMAIL PROTECTED] Date: Sun, 22 Apr 2001 12:53:48 -0700 To: [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
