login
Search
FYI, this is a patch that will be sent out in the next round to Linus for inclusion in 2.6.25. If anyone has any objections about it, please let me know. thanks, greg k-h -------- From: Greg Kroah-Hartman <gregkh@suse.de> Subject: USB: mark USB drivers as being GPL only Over two years ago, the Linux USB developers stated that they believed there was no way to create a USB kernel driver that was not under the GPL. This patch moves the USB apis to enforce that decision. There are no known closed source USB drivers in the wild, so this patch should cause no problems. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- Documentation/feature-removal-schedule.txt | 16 ------- drivers/usb/core/driver.c | 10 ++-- drivers/usb/core/file.c | 4 - drivers/usb/core/hcd-pci.c | 10 ++-- drivers/usb/core/hcd.c | 18 ++++---- drivers/usb/core/hub.c | 5 +- drivers/usb/core/message.c | 32 +++++--------- drivers/usb/core/urb.c | 15 +++---- drivers/usb/core/usb.c | 62 ++++++++--------------------- 9 files changed, 61 insertions(+), 111 deletions(-) --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -156,22 +156,6 @@ Who: Arjan van de Ven <arjan@linux.intel --------------------------- -What: USB driver API moves to EXPORT_SYMBOL_GPL -When: February 2008 -Files: include/linux/usb.h, drivers/usb/core/driver.c -Why: The USB subsystem has changed a lot over time, and it has been - possible to create userspace USB drivers using usbfs/libusb/gadgetfs - that operate as fast as the USB bus allows. Because of this, the USB - subsystem will not be allowing closed source kernel drivers to - register with it, after this grace period is over. If anyone needs - any help in converting their closed source drivers over to use the - userspace filesystems, ...
On Fri, 25 Jan 2008 10:02:32 -0800 This is a bit disingenuous. Of course there are closed source USB drivers out there. I've written multiple of them during my life as a consultant. The nature of closed source drivers is that they quite often are written for custom hardware that isn't used by that many people, so you have probably not seen them, but they are definitely out there in the wild. For some of these drivers, being in kernel space is very important since they transfer large amounts of data with very tight latency requirements. It may, in theory, be possible to do the same thing in userspace with multiple cooperative threads and libusb, but it would be much more complex and much more error prone (it's hard to do control loops where you need about 40 us turnaround time). Yes, I'd much prefer if all companies would just publish their sources as GPL, but some companies, rightly or nor, believe that they expose too much information about their custom hardware if they do. And I do feel that such a rabid GPL-stance is going to alienate those companies. Most of those companies also select one kernel for their custom hardware and use that kernel for a long time, so for them this feature removal will come as a bit of a surprise. /Christer --
You sent one message on this topic to me, back in Feb of 2007, disagreeing that you could write a userspace USB driver running at full speed in a non-racey manner. Unfortunately, many other userspace USB drivers seem to disprove your statement, including a number of vision systems running in military applications (tanks running Linux!). Perhaps this is just a matter of using the api properly :) I do know that the current usbfs interface is a major pain, hence the work to create usbfs2. I know those developers could use the help in getting that cleaned up and into the kernel tree. Also see the rapid development these days in wrappers around usbfs. There is competing projects right now with OpenUSB and the revitalization of the old libusb project. I know those developers are looking for examples where their new frameworks do not meet the needs of developers for stuff exactly like you describe (lots of threads, async Again, I have asked for examples, and only received 2. One (sound driver) is totally not needed at all, as the kernel provides that It comes down to the simple fact, if you wish to use Linux, abide by the license it comes under. To do otherwise is both disenginous and See statement above about vision systems in tanks, it can, and is done all the time... If a company wants to keep a driver closed, then use another operating system, it's not like there isn't other options out there. I hear the BSDs and Microsoft are quite comfortable with things like that. :) thanks, greg k-h [1] This is the public position of my personal lawyers, my employer's lawyers, and a number of other companies whom hold copyright on the Linux kernel tree. So it's not like this is a minority decision these days... --
On Sat, 2 Feb 2008 11:19:30 -0800 Yes, I did spend quite a lot of time the last time looking for usable USB APIs, and I did not manage to find any. Unfortunately, my time is also limited, and I'd much prefer to work on getting support for Samsungs ARM CPUs into Linux. When I'm doing paid work for a customer and they want to a proprietary driver, I'm not going to spend a lot of my free time on working around that decision. I explain to them that binary drivers are definitely in a grey area and they might get in So in other words you want to crack down on GPL violations, and you're going to ignore anyone who does have a proprietary driver as "not relevant" or "it can be done with usbfs" (maybe). So why even ask on the mailing list? Just do it. Saying "use BSD" instead isn't a good answer for me since I don't know BSD well enough. And personally, I want to see Linux everywhere; I think it's a lot better to have Linux + a proprietary driver in an embedded system than BSD or Windows CE. It means that the customers get used to Linux, and if I can get them to at least contribute back a bit (any improvements to the core kernel for example), to me that is a lot better than giving a lot more money to BillG. Later, when I can show them how much easier everything gets if they use open drivers (I'd never have managed to get my latest Samsung platform up and running as quickly as I did without the patches I got from Sandeep Patil, and by posting my patches to his patches I got some feedback that helped me fix a bunch of bugs). But it usually takes some time to convince a company that the things they get back is more valuable than keeping things proprietary. So I think Linux as a whole gains a lot more by being a bit lenient about proprietary drivers. That is why I'm opposed this change of yours. /Christer --
Hi Christer,
Why are we discussing this again? The Linux kernel is distributed
under the GPLv2 and even though there are some legal gray areas
regarding derived work (think nvidia and ati binary blobs here), the
license is not friendly towards proprietary drivers at all.
Furthermore, many of the _kernel developers_ do not support
proprietary drivers, so why do you insist on using Linux for that
purpose?
Seriously, you really really want to look at the BSDs or proprietary
operating systems because they support your needs much better.
Pekka
--
Why? Because it is a gray area. I still have my reservations about the GPL being as viral as FSF says it is. Greg KH's lawyer says one thing, some legal departments I've talked to say something else (or they express it in laywerese, but it boils down to "you can probably get away with it") and apparently both nvidia's and ati's legal departmens think so too. And because I belive it's very important not to scare away Linux users unneccesarily. Yes, the kernel does not, and should not be friendly towards proprietary drivers, but there is a difference between not being So you'd rather have the Nokia 770 use BSD because Nokia couldn't find a low power WLAN chip with a GPLed driver? You'd rather see Nokia spend man-years on improving the support for the TI OMAP CPU's somewhere else than Linux? Yes, it sucks that the on WLAN Nokia 770 doesn't have an open driver, but I'm very happy that Nokia has spent all that effort on getting Linux to run well on the 770 and has given 99% of that work back to the Linux community. (Actually, I think there is a GPLed driver for the WLAN now, but that driver would most probably not have been written unless the Nokia 770 hardware had been out there so that frustrated Linux hackers decided to do something about it). And why is it ok for nvidia and ati to have proprietary drivers? Is it ok just because people are afraid to alienate them if they push too hard? Having no 3D graphics at all on Linux is a nightmare scenario for the distro makers, so I guess that's why people try not to rock the boat too much. So why don't you send in a patch that makes all EXPORTS into EXPORT_GPL? That would be the only honest course of action according to you, wouldn't it? /Christer --
No, it really is not a gray area at all, especially when you are writing a new driver for Linux. Go talk to a lawyer if you want the details. thanks, greg k-h --
If we're still talking about whether a kernel module is required to be released under GPL, then yes, this is not a gray area. This is something that authors of original works can decide for themselves. They have no obligation to release under GPL, however they must take special care to ensure that the module does not (statically) link with the kernel. Richard Stallman (apparently, according to Pavel Roskin, although he didn't forward Richard's message as requested) said it nicely: A kernel module is akin to a process. It uses services of the kernel without being part of the kernel. However in order to use the kernel it might very well statically link with kernel support functions, such as copy_from_user(). This, it may not do without garnering a requirement to be released under GPL. That being said, a module can be written such that it only dynamically links with the kernel. Ndiswrapper is an example of how this can be done: None of the drivers that work under ndiswrapper make any direct use of the kernel, not in any way, indeed a wrapper could be written for a different operating system. There is no obligation for ndis drivers to be released under GPL, and even though they are not, they break no licence condition by calling services, even those exported as GPL-only. Bringing this back to the point, the notion that some exported symbols may be accessed by proprietary modules and others can't is wrong. The licence under which Linux is released makes no mention of this possibility, and so no such condition exists. In order to prevent proprietary modules from using a symbol, that symbol must be provided in such a way that a second module can only statically link to it. I think that precludes exporting it via EXPORT_SYMBOL or EXPORT_SYMBOL_GPL. Summarising the point: To claim all USB drivers must be released under GPL is wrong. --
Also wrong. You really should investigate a beginners text on intellectual property law. Alan --
Perhaps you might read up on unfair trade practices and contract law. The contract (GPL) doesn't prevent me from using GPL work, in fact it encourages me. Neither can it impose conditions upon original work authored by a third party. You do realise, I suppose, that it's easily feasible to write a Linux kernel module on a non-Linux platform, and in fact without even using any GPL software in its production. How could such a work possibly be derivative? How could it be affected by GPL? And please, don't give wishy-washy "lawyers tell me it's so" non-answers. Give something real. --
> Perhaps you might read up on unfair trade practices and contract law. I'm familiar with them to some extent because I have run companies in the past and continue to do so as a sideline to my Red Hat work. I also spend First mistake: The GPL is not a contract it is a license. If the GPL was a contract it could most certainly impose conditions upon original works. Contract law permits to write things like "If you buy the source for this package you agree not to write a competing product for three years even if an origina work". Alan --
Mea culpa. It is indeed a licence, which I did and do know. I really did mean, "The licence (GPL)" --
No Linux does not work like this at all. Like Alan said, you really need to brush up on your basic IP law, as well as some basic technical issues regarding how the Linux kernel works before trying to make statements like this. Also see the various issues surrounding "loadable modules" and Samba, and how they have successfully enforced the "linking" and other type issues that are being discussed here (shims, "GPL condoms", etc.) with regards to the GPLv2 and derivative works. good luck, greg k-h --
If you know of something relevant, give pointers. --
The issue is all about "derivative works" in copyright law. Ndiswrapper is in a good position because the closed-source drivers were originally written for another OS so it's pretty well impossible to argue that they are derived from linux. However, if I were to write a new GPL shim and then a new closed-source module that uses the shim to access kernel symbols, it is entirely possible that a court could rule that my closed-source module is a derivative work of the linux kernel because it was written specifically to run on linux. On the other hand if I were to sit down and write an OS-agnostic proprietary chunk of code, and then write a new GPL shim to use it under linux (and maybe other shim layers for other OS's as well), I _might_ be okay. But I would have to be prepared to prove that the proprietary code was not derived from the Linux kernel. Chris --
IANAL, but when looking at the "But when you distribute the same
sections as part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License" of the
GPLv2 I would still consult a lawyer before e.g. selling a laptop with a
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
Don't ignore, "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." Static linking certainly makes something part of the whole; dynamic linking doesn't. --
Wrong again. You really are quite amusing. The test is "derivative works" not linking. Linking is a meaningless (in law) computing term with no place. Legal precedent for combining of works is drawn from things like shipping a book and a commentary on the book together, putting music to films, putting photos in a book. These are not "linking" And I know what the lawyers I've talked to have said about the case of shipping proprietary modules with the OS. Its a pretty definite "bad idea" Alan --
I'm glad to entertain. It's a pity you refuse to be educated. Closed That is one of the terms used. Another, which I pointed out to your apparent glee, is "aggregation." Both terms are relevant only because Whatever the precedent is, and I'll take your word on it even though it's more hearsay, it's explicitly covered by that part of the licence Now, that's more like it. It sounds somewhat believable, unlike your previous statements which seemed to say, "you've spoken to numerous lawyers and they've all said that proprietary modules violate GPL." I paraphrased you, and if that's not what you meant then please take the opportunity to refine your claims. "Bad idea" is legal speak for, "I'll fight it for you, but you can lose." That's a big step away from "dynamic modules must be governed by GPL." --
> previous statements which seemed to say, "you've spoken to numerous Please don't use "seemed to say" and then quote words I've never said. That's misleading, rude and also awful language style. I've not said anything is definite because as I said before there is no caselaw. We know the GPL is enforcable (Germany and US) We have good reason to believe works can be derivative across all sorts of boundaries (non computing caselaw, cases that never went to court - eg objective C) Nobody has yet sued anyone to my knowledge over the module case because quite frankly the list of blatant binary only shipping of GPL code without licence, sources or offers people will keep us busy for quite some time yet. I actually don't expect to see that case tested - it isn't in anyones interest to test it right now. ATI are being good boys at last, the other big vendors that did binary modules are moving away and in several cases I know have been told 'no more binary modules' and Nvidia are a company without a processor in a world where graphics is going to be on CPU soon. Lets say I don't own any Nvidia shares. Alan --
No, it's called, "paraphrasing," and it's quite normal in a conversation. You say something, I tell you what I think you said, you refine your language, and the process continues until we're happy that a semantic consensus has been reached. In that spirit, should I now understand that what you meant is that *you* *think* that kernel modules must be released under GPL. Should I accept that you didn't mean that numerous lawyers had told you that this was factually so? Of course, this begs the question of why there would be a MODULE_LICENSE("proprietary"). You may hold beliefs as understood above, but it seems guaranteed that the opinions of those who count are divided. --
Actually, static linking does not, since the whole is not a "work". Under copyright law, a "work" can only be made by creative effort. Static linking is not creative effort, so it cannot create a work. If it were, the linker would be entitled to copyright on the new work, which makes no sense at all. An exception might exist if there were a large number of equally good ways to perform the link and the person who lined it had to creatively chose a method. But normally, anything purely dominated by functional considerations (which statically linking almost always is) is not considered sufficiently creative. If you statically link work "X" to work "Y", the result is *not* work "Z", derivative from "X" and "Y". It is parts of work "X" and parts of work "Y" mechanically combined. A group of combined works follows the license for each of the individual works from which sufficient protectable expression has been taken. A "derivative work" is a new work, and can only be formed by creative effort not in the works it is claimed to be derivative of. Sure, and those things would apply to anyone who has accepted the contract. Why do you think the GPL couldn't say those things and enforce them against anyone who had agreed to the GPL? How is agreeing to release source code any different from agreeing not to write a competing product? (Except that a court may be more likely to enforce the latter than the former, of course.) When there is only one way to do it, you cannot copyright that one way. You need a patent for that. So, no, it's not a derivative work because what was taken is the one way to do it, and "one way to do it" is not protectable expression. A derivative work only applies when protectable expression is taken. DS --
If that were true, you couldn't legally install more than one program on a computer without permission from all the copyright holders without specific license permission. A "work based on the Program" is the same as a derivative work. A laptop with an assortment of different programs on it is not a work, it is a collection of works. DS --
A lot of software is written specifically to run on Linux, but that doesn't mean it's derived from Linux. In the case of user-space code it's widely understood that no licence restrictions are conferred. The argument relating to kernel modules is that a module is somehow different because it runs in kernel mode. I can't see it, and in view No. Holders of Linux copyrights would have to prove that the proprietary code is derived from the kernel. They have the burden of proof, and defence needs merely show that their arguments are wrong. (So if the proof is faulty, the case fails even if the code is derivative.) --
Actually that is also questionable. The only reason it is fairly certain in Linux is Linus went to the trouble of stating that interpretation was Wrong again. In civil law in the USA and most of europe the test is "balance of probability". Alan --
No, I'm right. The word "proof" is appropriate in context. (I write in plain English, not Legalese.) I certainly didn't intend "proof" to mean "mathematically certain." Anybody who pretends that proof in court means that must be ignorant or trying to deceive. --
I'm afraid you are wrong despite your desperate attempts to reinterpret your own comments. The civil law is "balance of probability". Those are the precise words used. As it is a dispute between two civil parties with no assumed right or wrong it is a matter of which interpretation is most likely "proof" doesn't come into it whatever version of proof you want to pick this email. "burden of proof" is a specific term with a specific meaning in law. --
I've had this argument before. The conclusion is that spiteful people insist on using the legal meaning for words which have explicitly been said using plain English. If you are spiteful, then by all means rant about legal terms, but do so knowing that everybody understand what I mean. Even in civil matters, it is necessary for the appellant to present a case and the respondent may simply pick holes in it. Further, don't forget that copyright violation is a criminal matter in some jurisdictions. I it is so in Australia, and attracts penalties that include imprisonment. In Australia, and I wonder if it isn't so in USA, the legal interpretation that you so keenly insist upon, must therefore apply. I shall not engage in further debate about what the legal meaning is of plain English terms. It's a stupid argument suitable only for stupid people. --
What is the "propability" that drivers using the interfaces now declared as "EXPORT_SYMBOL_GPL" are derived from the Linux kernel source code instead of some definitive documentation? As you all (should) know there is a book called "Linux Device Drivers, 3rd Edition" published by O'Reilly (ISBN 0-596-00590-3)". All the USB kernel interfaces are documented there. One of the authors is Greg Kroah-Hartman which makes this book "definite" source of information on Linux USB driver programming. I assume Greg is the author of the USB related sections. The "legal" question is what is that which one is license the one that applies? Is it the licecense of the kernel (GPL) or is it the license of the documentation (no restrictions on usage)? The "moral" question is that why did Greg author a book that declares these USB interfaces as "free to use" and soon after that made a decision that they are no longer "free to use"? Best regards, Hannu --
Yes, I wrote that, and if you look at that chapter, it states it is based on the GPL licensed documentation that comes from the kernel Where did I ever declare these interfaces as "free to use in violation of the GPL" anywhere? If you look at the examples that I wrote for that book, they are all licensed under the GPLv2 only. Same goes for the Windows Driver book. You can use the Windows driver development kit and API, as long as you follow their license. And that license explicitly forbids using it in code that is under an open source license. Is describing those interfaces in a book somehow also "immoral"? geesh, this thread is just insane, time to just ignore it... greg k-h --
I think you're being dishonest. This isn't really about Linux and it being licensed under GPL, is it? Not if you're being 100% honest. This is really about Beejay's* kernel module; and you are attempting to force her to release that under GPL. You should 'fess up, that the change is 0% technical, 0% unavoidable and 100% political. This does, of course, disadvantage Linux with respect to many classes of devices, for example GSM transceivers when used in those parts of the world^ where regulatory requirements prohibit modification of power or frequency settings, which effectively prohibits open-source driver. An unbending bias towards GPL is impractical in many markets. It also hands an additional point or two of market share to Microsoft; who no doubt will be immensely grateful. *The fictitious author of an imaginary driver. ^Probably all of the world. --
On Mon, 2008-02-04 at 01:37 +1030, David Newall wrote: Are you sure that that is not only (the results of) propaganda of (certain) proprietary companies? Usually the *user* (at home, wherever) sets "illegal" values. So it's the users responsibility and the manufacturer, importer or sellers don't care (if only that can't prevent other "illegal" actions like "beating some to death with $WLAN_ROUTER"). Or do you get a gun manufacturer before court just because someone committed a crime with a its gun? Feel free to use other comparisons like "knifes" or "cars" if you need more harmless examples .... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services --
Or, as is the case perhaps almost everywhere, governments prohibit devices Let's not confuse the issue. --
BTW the (trivial?) solution for the hardware manufacturer: People must use/download some signed binary blurb which actually configures the There are rumors/stories that even the FCC in .us doesn't go after producers/vendors/sellers of devices which may be operated beyond governmental requirements. With exactly my comparison BTW. At least in .at it is not forbidden to import and/or sell devices which *can* be operated outside some local law requirements. If *you* configure it wrong, *you* have violated the law/rules and it is thus in *your* responsibility. The first reason is that there are European Union laws which basically override the local Austrian laws - but we can ignore that as it is a European Union thing. One (non-technical) reason is that even those requirements change over time. Another reason is that e.g. setting the transmit power on some common WLAN devices to the minimal possible values (which the hardware allows) doesn't imply staying within legal bounds: I can have a (common of the shelf!) high-quality antenna and not-so-bad cabling and than I'm beyond the officially allowed maximum transmit power. A third (non-technical) reason is that I (as a pure private person/organization) may have some explicit governmental exception of the governmental limits (for whatever reason). I concur that there might be governments which forbid importing/selling/distributing devices where legal usage is absolutely not possible. But historically at least in .at, these devices were simply marked "for It's IMHO precisely the issue (at least with my understanding of law stuff): Which action is illegal and who is responsible for it. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services --
Why "of course" ? In the cited example it's illegal to go outside certain parameters SOMEWHERE (if it was illegal everywhere, the the hardware shouldn't allow it and the sw could do nothing... not considering hw mods). Another example is WiFi: USA, Europe and Japan allows a different number of channels. But every AP I have had simply asks which country the user is in, then allows only a limited choice for the channel to use. If I'm in Europe but tell my AP that I'm in Japan, it lets me choose channel 13 (Europe allows up to ch 11). If the "cops" find it out, they prosecute ME, not my AP! It's not a TECHNICAL limit, it's a LEGAL one. So there's no point in keeping a driver closed *just* because else someone could hack it to make it work outside the allowed parameters: even a closed driver is hackable (just reverse engineer it...). Think about this scenario: a closed source driver contains: if(power<100) setpower(power); else setpower(100); to limit tx power and make it legal. Then the user finds this 100 and replaces it with 255 (inside the binary-only module), actually allowing for more than twice (if power is in mW) the legally permitted power. Is it legal? I don't think so (and I doubt you can find any lawyer that does). But it's not THE DRIVER that's doing something illegal. It's THE USER. It would be equally illegal if the driver was open source. Simpler to do, but equally illegal. Another example: how do you detect, from a driver, if the user actually got a license/permission from the government (somewhere it's needed, or you need to pay an annual fee) to use the device? You can't. Does this missing check make the device illegal? Nope. Just its USE. I stop here cause it's already too OT. BYtE, Diego. --
It isn't that easy. The "Tamper-Proof Torx" screws on a vacuum cleaner or a toaster won't stop anybody from opening up the thing, I mean every little hardware store stocks those Torx bits. But by using a slightly odd screw, the company can say "look, we'we done all we can to stop them, but the user bypassed our security device, and it's not our fault". Apparently Intel and Atheros are trying to protect themselves in a similar way, they Open Source everything except for the regulatory daemon (Intel) or HAL object file (Atheros). Why? Because they belive that if they give away the sources to those parts they do the software equivalent of putting a normal Phillips screw in a home appliance. (Personally I think what they are doing is ridiculous, but apparently those companies' lawyers dont' agree). It's of course possible to argue that normal users don't compile their own drivers, they use a driver from their distribution maker, and compiling a hacked driver which allows them to override the limits is just as hard as it is for a Windows user to replace the driver binary with a hacked binary which overrides the limits, so hiding the source Welcome to the modern world, companies spend so much money on protecting themselves against potential lawsuit that it is silly. /Christer --
while the HAL case of Atheros might be still true despite the fact that an OpenHAL has been around for a long time now. The Intel argument is out of the picture since quite some time. The regulatory daemon was an interim solution and has been replaced by a proper firmware solution. So please get your examples up-to-date. You might wanna now point to hiding something in firmware, but the hardware, firmware, driver separation (with being hardware and firmware closed source) is an accepted solution. It is a clean separation. Interface wise and license wise. Remember that nobody inside the community ever asked for any kind of IP or trade secrets. We only want specifications so we can write the drivers under an appropriate open source license. If the specification describes an API exposed via firmware then that is perfectly fine. Regards Marcel --
On Mon, 04 Feb 2008 22:38:11 +0100 So how does that invalidate my point? Intel did jump through a lot of hoops to avoid giving away the code that controls their radio. When the regulatory daemon stuff got too much complaints, they finally redid their firmware to avoid the daemon. But they still have not Yes, that is a nice solution. Provided that you have any firmware at all. But price is everything, chips become dumber and dumber and more control functions are pushed to the host. If you want to sell a device in Korea, price is everything; if you can shave off 30 cents by putting the firmware in ROM, or by using 1.5 mbits of flash instead of 2 mbits, I definitely agree. I think it's stupid of companies to hide away their documentation out of fear of, well, something. I find it extremely frustrating when I bought a device touted as "the first open Linux mobile", just to find out that it used a binary-only kernel module for the M-Systems DiskOnChip. A quite nice phone, but due to that one module, it was completely impossible to use anything but the ancient 2.4 kernel it came with. I also think that my customers, that decided to keep their kernel modules binary only, made a big mistake and have told them so. But I still think it's better for the Linux community to be a bit soft on such companies for a while. It's better to let them get away with it for a while, and slowly try to convince them about the error of their ways, rather than see them go with Windows CE or a BSD. /Christer --
find an Intel engineer that worked on it. There is a bigger story behind it and I am not telling it. And btw. it is perfectly fine that Intel is not giving full access to I heard this all before and I don't buy it anymore. At some point the companies in Asia will understand that the whole picture looks different and that not always cheap, cheap, cheap is best for their margins. And btw. the fully supported Linux hardware is in a lot of cases not I disagree here. They either play by the roles or they really do pay Microsoft or go with BSD. I really couldn't care less. Regards Marcel --
The asian companies for the most part don't care about giving programming info away including for wireless. Why should they - even if the FCC pees on one of them they just set up another 8) Alan --
Again, I missed who wrote the above. I'm reminded of Apple computer, who explaining some engineering decisions in the Apple ][ pointed out that an additional 10c in components adds $10 to the retail price (or something rather like that.) Cheap, cheap, cheap helps market share far more than quality. --
That depends on the market. Also the software cost is dominant not the hardware cost so saving 10c on licensing by not using Windows kind of wipes out any questions. Alan --
Software cost is fixed, whereas hardware is per-unit, so saving 10c in production at an expense of $1,000,000 in development can be an easy win. --
On Wed, 06 Feb 2008 21:55:45 +0100 I think it is perfectly within their rights to do so. I think it's kind of silly to try to hide it, if someone wants to boost the maximum transmit power, they're going to hack the firmware anyway. But if it I've been hoping that they will understand that too. So far it has been a futile hope. It is soo fun to write a design spec saying "Whatever you do, do not use this chip, it sucks. Yes, I know it is 50 cents cheaper than the competition, but it is not worth it." just too Mmm. I've actually put consulting on the shelf for a while and have become employed by CSR instead. They have a really nice, and as far as I've understood, fairly good and price competitive WIFI chip for low power systems such as mobile phones or PDAs. I've gotten a preliminary go ahead from the bosses to provide documentation under an NDA to Linux developers that would like to write GPL drivers for it. I just haven't had time to do anything more about it yet. And since I'm fairly new to CSR and are located at a remote office, it takes time to How could you guess? :-) Actually, I got three of them, and all of them lie unused in a box at work. And the OpenMoko sucks. Or actually, it doesn't suck at all, I'm thinking of buying one just for fun, it's just that I like buttons on a phone, and really don't want a touch screen. So I like the OpenMoko project in every way, it's just not the right phone for me. /Christer --
And break the HW :-) Actually, they could be happier, since then you have to buy another... [...] Urgh... I don't think NDAs and Open Source mix well... Are you sure your bosses KNOW Linux and the OS in general? :-) BYtE, Diego. --
talk to Greg KH about this. Have NDAs and open source work together is really simple. Have the NDA say that you can use all provided documentation to write an open source driver and publish it under GPL. A lot of companies are okay with this these days. The Linux Foundation should have NDA template texts for this. Regards Marcel --
Developing GPL'ed Linux drivers with an NDA on the documentation has
been done in hundreds of cases.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
Then you should keep away from the kernel. The last thing that Linux needs is someone who doesn't care if Linux succeeds or fails. "I don't care" will lead to failure. --
I actually care about Linux certainly more than you do. I care about the copyright of my kernel contributions and the contributions of others. Not caring about these things is what is the worst. It means you disrespect all the work that a lot of people and companies have put into Linux. And don't quote we with "I don't care". Alan already complained about your quoting style. Don't put words in my mouth that I never said. The Linux kernel is licensed under GPL. If you don't like, go and play with someone else. You can quote me on that one. Regards Marcel --
Am Wed, 6 Feb 2008 21:34:49 +0100 If somebody prefers an other OS for license reasons only, let them. You cannot have open source software without open source license. If a company chooses Linux, they do it for technical reasons, and because they're able to modify the sources to suit their needs. Whatever advantages they see in Linux, they have to know that they have to accept its license. Just saying "I like your software but your license is stupid" is childish. Use CE instead. Thanks, Hans --
Nobody is saying "I don't like your licence." The issue is a technical restriction in Linux that attempts to restrict non-GPL software from running under it. It's a bullish approach, technically incompetent, legally meaningless and politically damaging. --
Am Thu, 07 Feb 2008 23:49:42 +1030 What are you trying to say? You like the license but you're against It is not legally meaningless if copyright holders publicly state how they interpret the license and what they consider a license violation. In the end, a court must decide, but lots of courts will at least look That's your opinion because it's damaging _your_ political goals. Hans --
Copyright-holders' opinions mean nothing. In the particular case of EXPORT_SYMBOL_GPL, copyright-holders' opinions are clearly flawed because they make a statement about code that they do not even know of. It's equivalent to someone saying, "you are wrong," before you've even How ludicrous. That's as much a nonsense as EXPORT_SYMBOL_GPL. You have no idea what my political goals are. Less there be further confusion: I am not an advocate for binary drivers. That role is reserved for others. However that does not stop me from criticising something that is obviously wrong. Stating that only a GPL code is permitted to use a symbol contravenes the GPL, because the GPL states no such requirement. Saying that it's impossible for code that uses the symbol to be non-GPL (as has been claimed) is a lie at worst, and a hope at best. Nobody claiming such a thing could know it to be true. (It is not true.) --
Am Fri, 08 Feb 2008 01:01:24 +1030 What are you talking about? That's what every GPL-licensed library does. By putting a library under the GPL, the copyright-holder clearly states that he considers all programs that link against that library a derived work. And that he therefor requires these programs to be GPL, too, no matter if these programs already exist or not. The LGPL exists to allow the linked program to be non-GPL, remember? But the kernel is GPL, and not LGPL. And all these arguments that a kernel module does not "link" against the kernel code, is therefor not a derived work, and not bound by the GPL's restrictions, is just No. The GPL is about derived work. Derived code can obviously only Nice to hear. So, if you're an advocate for open source drivers, why do Using a symbol from a library means linking to it, and that creates a derived work. Why should it be different when using kernel symbols? Thanks, Hans --
Your last sentence, above: That is what EXPORT_SYMBOL_GPL attempts to do. The place to state such a requirement is in the licence, not in the source code. That is what I am talking about. I can't provide you with software under a licence that says, "you are free to use this software in any way you want," and later say, "oh, but in the source code is I don't, but EXPORT_SYMBOL_GPL doesn't do that. It makes an ambit claim, that might coerce an author into making a driver GPL, but might also cause them to exit the Linux market. I have a problem with driving I don't agree with your claim, but I'm going to explain something else: The GPL doesn't require software that *uses* GPL code to itself be GPL. It requires software that is *distributed* as part of a GPL work to itself be GPL. At time of distribution, a kernel module is neither using nor linked to the kernel. --
Am Fri, 08 Feb 2008 03:20:26 +1030 The license says that derivative work has to be GPL. Naturally, every sensible and practically usable license has gray areas. We know that and we live with that. But if there's room for interpretation, it's perfectly OK and helpful, if the copyright holder states what his interpretation is. If you use an EXPORT_SYMBOL_GPL symbol in non-GPL code, you know that the owner of the work doesn't agree with you license-wise. You had to cheat, e.g. by setting your MODULE_LICENCE to "GPL", and deliberately acted against the wishes of the copyright holder. Here in Germany, the GPL is enforceable, and such evidence will at least weaken your position. You won't get away with just saying you didn't know the copyright holder's position. Even printouts of some mails in this thread could be used to prove that you knew. IANAL, there hasn't been such a case AFAIK, and you might well leave the court unharmed. But can you (or anyone else) be sure? That's what Yes it does. Chapter 2b requires any part that is derived from a GPL work to be GPL, too. As you well know. Just to help you a bit: The only argument you could use is that a kernel module, even if it uses GPL'ed kernel code, is not a derivative work. You _might_ succeed with that interpretation, even before a German court, and even if it can be proven that you knew that the original Oh, come on! You cannot turn a derived work into an original work just by distributing them seperately. Thanks, Hans --
On Thu, 7 Feb 2008 18:49:39 +0100 No, but the other way doesn't work either. Lets say that I write a piece of code, a B-tree algorithm. If I take that piece of code and put it in the Linux kernel and distribute it as a statically linked binary kernel, then quite obviously the whole is a derived work of the original Linux kernel and my b-tree code. If I refuse to give the source code to my b-tree code [1] I have obviously violated the GPL. That is very clear and I don't think anyone disputes that. What is more disputed is if my b-tree code is a derivative work of the kernel or not. In my opinion it is not, that b-tree code is my original work and I can ship it as a part of a proprietary product if I want to. If I distribute it as a .o file and somebody links it into the kernel, that is the end users decision, and the GPL explicitly says "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted [...]". But lets say that the b-tree code uses Linux-only primitives such as kmalloc or spinlocks, and that I wrote the code specifically for the Linux kernel, does that make it into a derivative work? kmalloc is only a function call, so I'd say that is too trivial to be copyrightable, APIs or just directories mapping names to numbers are not copyrightable. The spinlocks are a bit more troublesome since they are implemented as macros or inline functions so they do pull in some code from the header files. On the other hand, since they in a way form an API, and are the only way of interoperating with the kernel, they might not be copyrightable either. Then there's the question of fair use which might also make it possible to legally use those functions anyway, even if they are copyrightable. What if I do a trivial replace of the kmalloc calls with malloc and the spinlock calls with pthread locks instead, has my code been forever tainted by being written ...
As the copyright owner, you're free to distribute the original parts as you wish as long as it doesn't contain anything that is derived work. So, when you remove those kmalloc/spin_lock calls, you're _obviously not_ tainted. But that doesn't mean you're free to distribute it when it _does_ contain derived work. Besides, a device driver can't even be compared to something as trivial as b-tree implementation that uses kmalloc/spin_lock in terms of "is it derived work or not." Thanks for the straw man, though! --
On Sat, 9 Feb 2008 17:41:00 +0200 So it magically becomes a derived work if I do a: #define malloc(n) kmalloc(n, 0) #define pthread_mutex_lock(l) spin_lock(l) at the beginning of the file? My guess is that it is much to trivial to be considered a creative expression and thus would not be covered by A device driver isn't that hard either. I can write a device driver with a hand tied behind my back, to write a good balancing tree, I'd have to spend a lot more time reading up on algorithms. So "trivial" is a matter of background. And once again, I don't believe API copyrights are valid, because in *sigh* Now you're just being insulting. /Christer --
It doesn't matter how "hard" it was to write that code. What matters is whether your code requires enough copyrighted aspects of the original work to constitute as derived work. There's a huge difference between using kmalloc and spin_lock and writing a driver that is built on to of the full USB stack of Linux kernel, for example. --
There's an interesting parallel in the SCO vs Novell case. Dave ************************************************************************************************************************************************************************************************************************************************* NICE CTI Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP. Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately. Monitoring: NICE may monitor incoming and outgoing e-mails. Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. **************************************************************************************************************************************************************************************************************************************************** --
ROFL! Well, since a lot of screwdriver types are easily available, I Well, then why close the driver? Simply place the check in the firmware. Much harder to find, since it have to run on proprietary HW. The OS driver instead runs on standard (and usualli well-known) HW. Keeping the screws similitude, closing the driver is more like using a Torx, while placing checks in the FW is more like using a lock-only screw (already seen some)... Well, we all agree on this... Now we just have to make THEM agree, too... BYtE, Diego. --
"Of course", because in many parts of the world, a device who's manufacturer fails to take reasonable steps to prevent it from being used outside regulatory limits is illegal. Providing source code not only is a failure to take those reasonable steps, but is quite the opposite. It may even be viewed as encouraging users to use it inappropriately. --
To my knowledge there is no caselaw on this for software, nor is it clearly so simple - many vendors do provide source, many vendors provide windows drivers where any end user can click to specify their country and can lie trivially. Many users retrofit US firmware to non US devices and its trivial to do. Its a hard problem - if I get on the train I can change regulatory domain and wireless regulations mid trip. I'm not even sure at what point the wireless rules are deemed to change between the UK and France either - there isn't any caselaw for that ;) Some (particularly US) companies choose to take a conservative view based on their pessimistic reading of the intent of the US regulator plus the ability of the regulator to do a lot of damage to their business. The notion they are illegal is a real unknown and the market seems split on views of this. Alan --
In Australia, devices require approval from a regulatory body. Such Yes it is; but what is simple, is to understand that lack of such safeguards, even though they are imperfect, does result in refusal to Also, particularly Australia and New Zealand. I can't imagine France or That is what I was saying: To require that only GPL-licenced USB drivers may be used with Linux puts Linux at a disadvantage in the market. The embedded market is simply huge. Microsoft would _love_ Linux to fail there, because that's what's necessary for Wince to win. --
We were talking about the USA. I am not aware of any Australian answers to the specific question of software as an appropriate safeguard. The US requires appropriate safeguards but no court has actually established an Diddums, thats what the license says. Requiring ac cinema pays the movie company puts a cinema at a disadvantage in the market from those who don't pay. That is why we have laws to try and ensure that crime is not profitable. Alan --
We most certainly were not. We are talking about Linux, and everybody Probably the same in Australia, for the same reason as in USA. Probably That's what you claim it says, but has any court, anywhere, agreed with you? You claim the authority of others (i.e. numerous lawyers), but I don't believe you have that authority. You're just starting hearsay. You've never said what lawyers and you've never told us what they actually said. I see that you have a clear political agenda, and I respect it in principle, but you're claiming that things are so in pursuit of that agenda when you don't *know* that they are. You don't need to stretch I don't understand this, but I do understand that an essential question being considered is whether or not Linux can participate in a market that prohibits GPL drivers, whether explicitly, or more likely through pressure from regulatory bodies. Doing this would be a mistake. Probably a big one. Don't telling people to switch to BSD, as some have done; they might do it. Where would Linux be if embedded devices used BSD instead? Don't think they can't. Don't think Linux has a technical advantage. Lose the embedded market, and that's where it would be felt first, and Linux volumes fall by what? 50%? 90%? Would you care if servers followed? --
That would be improper as you'd well know if you knew the first thing Why don't you just say "you are a liar" as I assume that is what you want Linux is GPL licencesed code you either follow the licence or don't use I don't actually care. If you want to do binary products then pick a The market will ultimately decide which models of software development are the right ones for which situation. Alan --
It would not be improper to say that "such and such a lawyer said this and that." I'm not proposing that you breach their copyright in their opinions, but there is such a thing as fair use, and I expect you to use Various reasons. I don't know that you're a liar and I'm too much the gentleman to accuse you of that without being quite sure of my facts. As it happens I assume you're not lying, but I do suspect you of having misrepresented what was said to you. I don't say you've done this out of malice; it's possible you've read things into opinions given to you that weren't meant; or even inaccurately remembered what was said. Mostly, I think what I've already said: In other words, I think you've put a spin on the opinions in pursuit of your own agenda. You've Okay, that I understand. That is simple. But it's irrelevant to the topic under discussion, which is to seek to restrict access to modules based on their specific licence conditions. The GPL makes no such restriction, and it is improper and legally meaningless, from a licence point of view, to claim that EXPORT_SYMBOL_GPL forms a condition of licence. It doesn't. (There may be DMCA considerations, but I hope Please don't refer to me in this way. Say, rather, "if someone wants to do binary products." Putting that aside, Linux is such a product. There is nothing in the GPL that suggests it may not be used with Presumably you mean "product," and not "model of software development," since later in no way relates to the topic. The market will ultimately decide which product is right. It would be a great shame if Linux dwindled. There's no shortage of fully open source operating systems, but the one enjoying success which requires source to be distributed with (hardware) product is Linux. I don't want that to change. I make purchasing decisions for clients based on availability of source. BSD isn't useful. Annex used BSD (there was no GPL) and their product was poorer for it. I don't particularly like ...
It would be highly improper given these were business discussions involving companies using Linux. --
On Fri, 08 Feb 2008 13:25:33 +1030 I thought you would care that lawyers had discussed the matter. But no you simply want to waste the lists time until everyone else gives up on you and you can say you "won". I hope it makes you very happy, welcome to my killfile. Alan --
I care, but I have no way of knowing what was advised. I bet you a dollar they never said that all kernel modules are derivative. You haven't said that they did, but the entire argument supporting, let me Why would that bother me? You said it before, anyway. It was childish then, and is childish now. --
If the device is well engineered, there's nothing the sw can do to make it work outside regulatory limits. Sometimes there's simply NOTHING the SW can do to *avoid* it. Think about a CB radio. International standard is 5W (well, somewhere it's 3, IIRC, but that's another story: nobody produces a special model with a final amplifier for only 3W, everyone produces the 5W and turns down power in some other way). But linear amplifiers are commonly sold. And (at least in Italy) it's not illegal to buy one, even if it can boost antenna power to 1000W. It's illegal just to USE it. If a citizen of a country where only 3W are allowed opens his CB and removes the limiter, it makes the use of THAT CB illegal, not the use of that MODEL: untampered ones are still legal! And it's a logical problem, too: why should the *driver* enforce a *technical* limit? It's up to the device. If the driver tells my WiFi device to use 10W, should it fail? I think so! IMO there's no judge that can rule out that an open source driver is encouraging users to use a device over its regulatory limits: there are easier ways (like lying about the configured country, to get more channels or more power) than hacking a driver. Else it should be ruled "reasonable" having to sell different drivers in different countries (no user-selectable country to choose, no lying possible... as long as the user doesn't download an updated driver...). The key is "reasonable". IMVHO enforcing a limit with a driver is not a "reasonable step to prevent use outside regulatory limits". There are more effective ways to enforce those limits that costs about the same. BYtE, Diego. --
That's naive, since requirements differ in different jurisdictions, as In Australia it's illegal to own them (CB licensee; HAMs are allowed to That's part of it's purpose. It permits a manufacturer to make a global device that operates within local restrictions. --
Naive? Who thinks a limit can be enforced by sw is naive! It can't *enforce* it anyway, at least if the users are all around the world. At most it can *suggest*. Then it's up to the user to make sure Then Australian shops can ask for the licence. And what about online shops? Ebay? They'll send you an unmarked package (same as letting you download another country's driver). The result is that you can have your LA more easyly than going to a local shop or tampering with your CB (or Nope. The driver should simply make the device WORK. The USER must make sure to meet the local regulations. The driver can help, but as long as it asks the user a country setting, its enforcement is nearly nothing! The simpler way for the user to trick it into using illegal settings is simply to lie! It's like if your LA had a switch on it, allowing you to select the country. Another example. Think about what happens if you're right: the user gets caught with a WiFi card operating on an illegal channel, but the system appears correctly configured (location-wise). When analyzed, it turns out that, due to a bug in the driver, the card uses that channel (for example 13) because the user only changed the country setting when flying back from Japan (where he used channel 13) and channel limiter didn't kick in. Is the manufacturer responsible? If you're right, he is and must pay, remove that device from shops and replace sold ones. Or at least make sure all users update their drivers with others without that bug... A real can of worms... BYtE, Diego. --
Of course. Naturally it's near impossible to prevent people from tweaking the software. But reasonable restrictions are what regulatory Yes it can. You're confusing the software with different or modified software. Different things. And by the way, if you modify the software to defeat the restrictions you are committing a criminal act, or you would be if you did it in Australia. You'd probably get with What's your point? That it's easy to break the law? Nobody's arguing Definitely no. The manufacturer must ensure it meets local You're correct, but that's still how it is. In fact, some manufacturers provide country specific drivers simply to shore up this weakness. Are you asking if the manufacturer could lose their licence to sell the That's the most likely result. That would be what I expect would happen. This is why manufacturers view open source licences dimly in certain markets, of which radio communications is just one example. --
You said it! Gotcha! :-) There's no difference if what I'm going to modify is the binary or the source: it's a criminal act anyway. I was simply implying there are easier ways than others... And binary Well, the driver must trust the user, that's my point. If the user lies, the driver can't know (well, it could, but I don't And it's a reason to release open drivers, so that everybody can check there's no such bug. And, if found, it can be fixed with a lot less effort. BTW I've now asked a lawyer... Waiting his answer. BYtE, Diego. --
Then the hardware vendor needs to review there practices. If you want to limit the ability of your technology do not include it. I realize that this has become large revenue stream for many company's. What they do not realize is that they have created a Wack-a-Mole situation. Just look at the Digital Satellite TV industry. Companies used to Produce one logic board and selectively remove certain resistors or ic's to limit the end users ability. The end user could still solder the missing chips etc to by pass but much more difficult. Way I see it is let the companies does as they please as they will bury themselves in the long run. Now we have hardware ASIC that depend on the most part a (dll in windows) or .ko .o file under linux to provide the entire instruction set. Think Winmodems, Winprinters etc.... --
Well, winmodem case is the only I could *almost* understand closed-source drivers: the algorithms used *are* the modem. It's not a simple firmware upload. What I really don't understand are graphic cards producers... If what they say about the card is true, then there's no "advanced" algorithm in the driver, just (at most) a firmware uploader (that's better suited off-kernel anyway)... Bohf! BYtE, Diego. --
Winmodem is all about patents, the modem standards come from ISO so are created by all out corporate warfare with the winner getting the patent money. Its why we had X2 v 56K, its why they took so long to get anything done 8) Graphics interfaces can be very clever and critical to performance. 3Dfx for example had some very clever register layout tricks to get PCI bursting of commands. Personally I wish someone would just get around to putting the basic rasterising ops (including texture scaling/mapping to 2D plane) into the CPU. It would be more useful than half of MMX to have a "load texturepointer, load step and angle, rep textureop" sequence in the CPU Alan --
Please keep me out of this. I did not write any driver, imaginary or otherwise. Nor am I fictitious. Truely yours, bjd --
By the way, I'm almost certain that the COPYING file is the first, last and only document specifying licence conditions, and nothing in that prevents a proprietary driver from including a patch that, for example, globally replaces ALL GPL-only symbols by the less restrictive ones. In fact, you'd be in a bit of strife down under if you tried to say otherwise. We've got quite strong consumer protection laws down here. You're just not allowed to claim additional licence conditions based on source code commentary. It's just games and hot air, isn't it? --
Hi David, So I am going to assume you're not trolling here (although some of your snarky remarks make that bit hard). A vendor is, of course, allowed to distribute a patch (under the GPLv2 proper) that removes the license checks no doubt‚ but it doesn't change the fact whether the actual driver they're distributing (under a proprietary license) is derived work or not (one way or another). And, _if_ you're distributing a derived work that is not under the GPLv2, you're breaking the law. I think we can agree on this? As there is some controversy over the definition of derived work (think Linus' comments on porting a driver or a filesystem from another operating system here), we use the EXPORT_SYMBOL_GPL annotations as a big warning sign that what you're doing is likely to be considered as a derived work. If the USB developers want to annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want to argue about it? They know the code better than you and as copyright holders they can actually sue those parties distributing proprietary code they think is derived work. Bringing up Linux world domination or Microsoft market share in these kind of discussion is totally pointless. The license is what it is (GPLv2) and it seems unlikely to change at this point. If you want to develop for Linux, you're most certainly better off always distributing your code under the GPLv2; otherwise you really really want to consult an IP lawyer to be sure. But what I don't understand is why people insist using the Linux kernel for something it clearly can never really properly support (proprietary code)? --
Thanks. I'm not trolling. Perhaps I was a bit snarky; it's an issue I feel strongly about. (I'm sure others feel just as strongly, but Let's consider a totally original USB driver. There are an infinite Have I the wrong end of the stick? Isn't that mark restricting an interface to GPL _callers_? Isn't it a technical switch that means, "Don't use my software if yours isn't (also) GPL"? As such it's mere I agree; but let's not disadvantage applications where regulatory requirements prohibit GPL code, nor applications where the proprietor simply chooses to keep the work proprietary. A proprietary module is simply a piece of software. Many people couldn't use Linux if they That's defeatist. Of course the Linux kernel can properly support ("run") proprietary code. It would be a miserable excuse for an operating system if it couldn't. --
if a new drivers is originally written for Linux, then you are breaking the GPL. There is no other way to name this. Using EXPORT_SYMBOL or EXPORT_SYMBOL_GPL make no difference here. You driver was meant to be running as Linux kernel module and thus it is derivative work. While What are you arguing here. It makes no difference if it is technical or not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this symbol, you have to obey to the GPL. Even the EXPORT_SYMBOL is protected by the same GPL license. And thus both has the same binding power to be used from GPL modules only. At this point I would strongly advise to talk to lawyer since you are First of all we are talking about kernel modules here. Not the In userspace, yes, the kernel would "run" proprietary code fully legally without any problem. As a kernel module, the only safe answer is no. And in case of EXPORT_SYMBOL_GPL, it is pretty clear. You would obviously violate the license. Regards Marcel --
Completely wrong. However if the driver is distributed as built-in, then it would need to be licensed under GPL. This means that a driver can be written and distributed as a module under any licence, proprietary or It is precisely the fact that it is a loadable module, and does not form And that "hint" is a lie. --
how to do you wanna write a new original Linux driver (modular or built-in) without creating derivative work. This is not possible and due to the fact that it is derivative work the driver becomes automatically licensed under GPL. This is not a gray area. The gray area that exists if you have code that was written for some other operating system and licensed under some proprietary license in the first place. And now that code is used in conjunction with a glue That is such a nonsense. Stop distributing FUD and start talking to a lawyer. You are clearly under some weird impression what the GPL means If the developers say that this symbol can only be used in GPL code (and with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that license or don't use this symbol at all. If you use that symbol inside non-GPL (meaning you link at runtime) then you are in violation of the GPL license. We can't make it much clearer. Regards Marcel --
Not necessarily so. The developers feel that any code using that symbol is necessarily a derivative work, but at the end of the day it would be up to the legal system to decide whether it really is or not. If the courts decided that the symbol could be used and the driver wouldn't be a derivative work, it would be perfectly legal to use a GPL'd shim to "re-export" the symbol, essentially stripping off the GPL-only protection for that symbol. In our group all kernel modules that we write are GPL'd, as it lets us sleep at night, simplifies our lives, and makes the lawyers much happier. Other people may be willing to take more risks. Chris --
I agree with you that a court can decide that the usage of a EXPORT_SYMBOL_GPL symbol is not derivative work, but I see the likelihood of this happening as almost non existent. And even if so then you still have to deal with the fact that the license of this symbol is clearly GPL. No questions asked about that, because it says so and due technical means you can't load a non-GPL kernel module that uses EXPORT_SYMBOL_GPL symbol without tainting the kernel. The same fact is valid in userspace where you can't link (not even runtime) a GPL library into a non-GPL program. All big companies are going this way. And licenses beside, there are valid technical points in making your driver open source and get it merged upstream. Just a hint for all these binary-only people :) Regards Marcel --
Not sure who wrote the above, but it contains a glaring legal error: Developers choose an invalid forum to impose licence conditions when they choose to do so via EXPORT_SYMBOL_GPL. The licence that prevails is GPL, and nowhere does it say that protected works may only be used by Of course courts are the proper forum to decide "fact" from opinion, but a statement of claim, which is a necessary preliminary to such an action, must state from what the alleged offending work is derived. The fact that claim of violation is made before any violating work has been identified, or even created, does work against such an action. A half-decent lawyer should be able to have any such action dismissed on that basis alone. I wonder if it isn't fraud to offer a work under the GPL and then to try to impose new conditions. --
The problem with that is this: To be derivative, a work has to be derived from another work. That's what "derivative" means. Is it by prescience that those marking symbols as EXPORT_SYMBOL_GPL know that only things derived from something else are capable of using them? Derived from what? The use of a separate module does not make something derivative. It makes it a client. Any binding between the two modules occurs only at runtime, and is purely ephemeral. I make this charge: Some, perhaps much, of the GPL-exported symbols have been mislabelled. There is no prescience, and those who labelled them such are really trying (and failing) to claim an additional licence condition. I further make this claim: an attempt to add a licence condition in that fashion is illegal, at least it is under various Australian laws, but I expect it's a similar story elsewhere. For a start, it's an attempt to vary licence conditions after the contract is made, and also without due notice. It also attempts to unfairly restrict trade. It's probably fraud, in that it purports to be a work provided under GPL, while silently claiming a different (and largely unstated) licence. The EXPORT_SYMBOL_GPL should be removed, because it's based on a lie. You cannot know that only GPL works are capable of using the symbol; you cannot know that all works that do use it are derivative of something; you cannot even say, a priori, what they are derived from. --
In which case for each statement please give the case at appeal or higher Export symbol is a guide. There is no reason to think that EXPORT_SYMBOL symbols alone mean your work is somehow not derivative. --
I am giving my opinion. By contrast, you have claimed to be giving the opinion of numerous lawyers. I hate to be so blunt, but that is the No argument, other than with, "export symbol is a guide." My argument with that is that one could mistakenly infer that "export symbol" includes "EXPORT_SYMBOL_GPL." The latter is not a guide, is it? It restricts a symbol from use by proprietary modules. --
That would be your own personal strange opinion. Having actually spent time with lawyers on the subject the question that matters for the GPL is the line between a derivative work and a non-derivative work. The former the GPL covers - the latter it does not. That is totally independent of the technical implementation of the loading and combining of the code. There is even at least one case where the lawyers on both sides of a dispute have concurred that something is derivative because it was closely dependant on a backend that it communicated with by pipes and was useless without that backend and clearly built solely to use it. Mechanism is not important, whether you are doing RPC calls, dynamic linking or static linking isn't part of the creative process. The only exception to the derivative work question is usual system calls. I don't think anyone expects those to create a derivative work anyway but just in case the law gets a bit carried away the COPYING file for the kernel explicitly covers this to ensure there is certainty about running totally seperate proprietary applications on the Linux kernel. Alan --
Again, you are wrong, as per the recommendations of every lawyer I have ever talked to (and unfortunatly, that's a lot...) It's fine for you to feel differently, and you yourself can act however you want to, but as you do not hold any copyright on any portions of the Linux kernel code, please do not speak as if your statements hold any weight. In the end, it's up to the copyright holders to enforce the license. And as I have stated in the past, a number of them have made public statements as to what they think about this issue. And it corresponds exactly with what Marcel has stated above. So if you wish to violate the copyright of others, you take the risk that you might be caught and punished, something that you and your legal council needs to take into account. thanks, greg k-h --
On Tue, 5 Feb 2008 12:34:18 -0800 So when do you sue Nvidia, ATI, Atheros, Broadcom[1], M-Systems/Sandisk[2] or Nokia? All those companies distribute binary drivers for Linux without providing source code? /Christer [1] WIFI chips and drivers used by Cisco, Asus and a lot of other manufacturers. [2] DiskOnChip devices used in lots of embedded systems, among others the Troll Tech Greenphone. --
How do you know that such legal action isn't already happening? greg k-h --
On Wed, 6 Feb 2008 12:28:10 -0800 I don't. But AFAIK no such lawsuits have been made public so far. ATI/AMD are moving in the right direction already, looking at open sourcing their drivers. (How is that going by the way, I haven't had time to keep up lately). And that I guss might be thanks to the competition from Intel on the graphics side. Or is it due to legal pressure out of the public eye? Or has ATI just realised that the Linux market is big enough that going open source might gain them enough market share to be worth is? Anyway, I'm definitely going to vote with my wallet the next time I buy a laptop. My last laptop had an Intel graphics chip, because of the open source graphics drivers. I chose to buy a slower Intel chip instead of a faster Radeon model. And if something comes out of ATI before I buy a new one, I'll have to graphics chip manufacturers to choose from. But would ATI really have been interested in open sourcing their graphics drives now if they had been sued out of the water a couple of years ago when they did their first binary drivers for Linux? I don't know. /Christer --
Is it? Or are you falsely implying that it is? I hope it is; that will help add fact to an otherwise opinion-ridden topic. --
These words carry little weight as they are hearsay. You say that somebody told you something, but you don't who and you don't say precisely what, and on that basis you claim a conclusion. What you surely mean is that it's your opinion that I'm wrong, based on your interpretation of recommendations by lawyers. And since when did a lawyer ever give their opinion unequivocally? In my experience they always mince their words, providing no bankable guarantee. --
Hi David, What makes you qualified to make that statement (without giving any evidence)? Are you're an expert on international copyright law? --
On Tue, 5 Feb 2008 13:46:08 +0200 Are you? You've made some very definite statements about copyright law. Things that I've been told are definitely in a gray area and not at all as clear cut as you and the FSF likes to say. FSF has a very clear agenda, and taking what they say as the gospel is a big mistake. If I link a binary .o file into a static kernel image, does that make it a derivative work of the kernel? It most definitely violates the GPL in that the total is a derivative work, but does it really make the .o file a derivative work? What if I let the user do the linking at runtime? But as Alan Cox wrote, how the linking is done doesn't decide if it is a derivative work or not, copyright law does. So what does make it a derivative work then? If I use an in kernel API, but from a piece of code which is external to the kernel, is that really a derived work? If you say it is, do you realise that you are advocating something which is very close to an API copyright, something which I think most open source people are very adverse to. If API copyrights were valid, Wine, or editline, or lesstiff would be in a lot of trouble. Of course, the Linux headers don't only define an API, they also contain a lot of inline code. But if I don't care about an extra jump, I could write a glue layer between the Linux kernel and some proprietary code that wraps all inline functions. In that case, is a module written against that glue layer a derivative work of the kernel? If I write a glue layer that allows me to run the same driver in userspace via libusb and directly in the kernel, and give the user a choice to link my binary .o file either the userspace or kernel space glue, does that make my code a derivative work of the kernel? Most probably not, it is independent of the kernel in that case. So where is the line in the sand that makes it clearly a derivative work? It's up to the courts to decide, and until there is a clear and final court ruling it is a gray ...
And in fact, at least in the US, current case law states that when there's only one practical way to write something (which is the case in an API, you either code it the way the API says or you don't get a correctly functioning program), it's not copyrightable. See "scenes a faire" in http://www.copyright-laws.com/pgs/protect-rights.html
Hi Christer,
On Tue, 5 Feb 2008 13:46:08 +0200
I have simply stated that (1) the problem boils down to what is
derived work and what is no and (2) the developers use the
EXPORT_SYMBOL_GPL as a hint of what they think to be derived work (not
necessarily tested in court). The _logical conclusion_ of these two
simple facts is, of course, to _not use_ functions marked as
EXPORT_SYMBOL_GPL unless you're willing to test your belief in court.
Now I see you really want to argue about this but could you please do
it on some other list than the LKML? We use this list for real work
too, you know, and right now you're only contributing noise. Thanks!
Pekka
--
This *is* real work. You have blinded yourself to the fact that this discussion is preliminary to a proposed change. Or put another way, if you want to kill the discussion then the answer to "shall we" is "no." --
Hi David,
Ok. I am not interested in continuing this discussion so please remove
from the cc. Thanks.
Pekka
--
Hi David,
I think you're missing my point: as long as the license stays the way
it is now, you can never distribute proprietary code unless you've
consulted a lawyer and even then you run the risk of being sued for
infringement if the copyright holder thinks what you have is derived
work. The GPLv2 and thus Linux was never designed to allow proprietary
code and arguing that is pointless, isn't it? There are much better
alternatives available and people interested in proprietary code
should be looking there.
Pekka
--
Yes I can, if the proprietary code is not linked with GPL code (and the proprietary code is original). Loadable modules are not linked. This is a very clear-cut case. --
that is not clear-cut case. You link at run-time. Otherwise the module would do nothing. Regards Marcel --
That's why it's allowed. The module isn't linked when it's distributed, and the author doesn't do or cause the linking; the user does. And the user never distributes in the linked state. Distribution is key to GPL. --
so how do you build this module that is not linked without using the Linux kernel. Hence derivative work. Hence dynamic linking at runtime of binary only code is violating the GPL. Same goes for dynamic linking at runtime against GPL libraries. Nobody thinks that is possible and ships binary applications that link against GPL libaries. So why do you think you can distribute a binary only kernel module. Regards Marcel --
You could hand code in assembler, using Microsoft's assembler under Windows. You could compile from C, using GCC on FreeBSD. But that's immaterial. A module which is an original, non-derivative work, is, well, original and non-derivative. Do you say that it must be otherwise? Why would that be? --
since when does the language make any difference. Anyway you are still under the impression that a Linux kernel module can be original work in the end. We keep telling you that could be a wrong assumption which is based on the view of many of the kernel developers and of most of the lawyers that looked at this specific topic. Let me repeat this. Ask a legal counsel before you go ahead with your assumption. You might get away with it or you might not. What Greg, Alan and I try to tell you is that using EXPORT_SYMBOL or EXPORT_SYMBOL_GPL will create derivative work, but if you don't wanna believe us, that is your prerogative. So go ahead, but don't complain if you actually get sued for copyright infringement at some point and tell the court you didn't know. And while you are talking to a lawyer. Ask him/her if it is okay to create a binary only application that uses a GPL library. Tell him/her that it is original work. Good luck :) Regards Marcel --
Yes, I am of that view. I accept that I could be wrong, but that also means that I could be right. We agree, so far. The important point is that I could be right. What will be done when somebody brings forth such an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will the driver be unfairly restricted from using those other modules? You did agree I could be right, so positing such a driver, what happens? (I predict nothing; the driver is unfairly restricted.) Now, Alexander Terekhov has forwarded some links to me, relating to the question of whether or not a Linux kernel module can be original. Bear in mind that these links relate to U.S. Copyright Law. In http://digital-law-online.info/lpdi1.0/treatise27.html, Professor Lee A Hollaar discusses derivative work and linking with libraries. He says: Some have claimed that an application program that needs a library for its operation is a derivative work of that library. They take that position because the application program is "based on" the library because it was written to use the subroutines and other aspects of the library. Such a position is misplaced. Even though the definition of a derivative work contained in Section 101 seems to support such a reading when it talks about a derivative work’s being "based upon one or more preexisting works," the examples all illustrate derivative works where the original work is somehow incorporated or recast in the derivative work: A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ...
The point I wanted to make is that a few people have said that lawyers say that kernel modules are derivative, but I only remember Alan saying that he had actually spoken with the lawyers. Therefore I infer that this somewhat widely held opinion originates from him. My point was to those people who have been taking him at his word, and was to point out that there are more reliable and transparent sources. Don't take his word on it. Take the words of real experts in the law, because instead of a mere four word conclusion, they explain everything. --
My, I am full of post scripts today. This one is a peace token for Alan. I do realise that my later postings come across harshly for Alan, and that they might seem to be attacking him. Of course, he did set himself up for that with his own snide and personal attacks on me. However, I took no offense and likewise intended none. I have not intended anything personally. I'm sure he's a jolly reliable bloke, and I can see he's a hard worker for, and advocate of, Linux, and that he's enormously respected. Nobody is right all the time and this, I believe, is a case where he is wrong. I hope nobody is upset that I pointed it out. I also hope that the ideas behind EXPORT_SYMBOL_GPL might be reconsidered. --
The one technically inclined lawyer that I asked about this said that the Lexmark decision meant that code using an API did not mean the work was a derivative of the API. However, in the case of the Linux Kernel, the code is meant to function inside a much larger framework and the API available to modules includes large amounts of "boilerplate code" buried behind handy chunks of code like "list_for_each". The problem, he said, was that, in the US, such code is included in the module in a mechanical and wholly automated process. Which means that the module doesn't automatically inherit the GPL license. But, he cautioned me, this does not mean that a court couldn't (and/or wouldn't) rule that a module written specifically for Linux is a derivative of the kernel. He also cautioned that, although the Bern Convention broadly controlled international copyright laws, specific countries do seem to have laws that cover the "kernel module" situation much better than the US laws and that those laws do apparently make a module a derivative of the kernel. His overall statement on it was that, in his opinion, whether a given module is a derivative or not would depend on the amount of "original" work contained in it compared to the number of places where linux specific code is used. He also stated that, while disagreeing with the idea that parts of an API could be "so deeply embedded that using them creates a derivative work", it would be a good idea to always pay attention to the beliefs of the developers of the code, because it is their opinion that will start the legal problems. In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", but people ignoring this and doing things that circumvent this will, eventually, have problems with the people who hold the copyright on the code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" bit might also be in violation of the DMCA, but he isn't sure if a court would see it in the same ...
There was a good analysis of that argument on the list some time ago. I think the conclusion was fairly definitively no as the GPL explicitly gives the right to modify GPL code. You are therefore aready "authorised" to make such a change. It might have a significance in terms of intent but thats for lawyers to argue over. Alan --
I think that's why he said he "Wasn't Sure" - as was pointed out in another post, the Lexmark ruling appears to apply for more than the "interface" portion of the ruling. And Alan, while it might be legal to make the changes, making them for the sole purpose of using them in a proprietary module - when the people who actually hold the copyright have said "I think this is so core to the kernel that anything using it is a derivative work" - is what he thought *MIGHT* be legally actionable under the DMCA. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. --
A "driver" is not an "application" as you tried to reference in your prior quotes. It is a tiny portion of the whole kernel, and as such, does fall under the derivative works portion when it is run within the Linux kernel. So the comparison is quite different, sorry. Again, see the Samba decisions that have happened in the past when companies have tried to add modules to it that are not under the GPL. They have failed every single time, so there is a lot of precedent for this kind of thing. And again, this is not just my opinion. It is the legal opinion my lawyers and the lawyers of many large companies who deal with Linux every day. If you wish to disagree with this, fine. Consult with your own lawyer and make up your own mind. lkml and linux-usb is not for legal discussions, that's like asking lawyers for medical advice, you might get some good opinions, but then again, you can get a lot of crackpot ideas. This is going to be my last response on this thread, greg k-h --
I'd like to, but I've searched and searched and can't find them. Some Good idea. I've spent too much time on this already, so I think I'll join you. --
whatever you feel you get away with, but hey I am not a lawyer and my reading is that any kernel module is derivative work and thus has to be placed under GPL. Feel free to disagree with me. If you think you can convince me, than you are under the wrong impression. Since even if (and this is a big if) I am wrong, my action won't lead to a copyright Lets phrase this in better words as Valdis pointed out: You can't distribute an application (binary or source form) under anything else than GPL if it uses a GPL library. It makes no difference if you distribute the GPL library with it or not. But hey (again), feel free to disagree with me here. Regards Marcel --
This simply cannot be correct. The only way it could be true is if the work was a derivative work of a GPL'd work. There is no other way it could become subject to the GPL. So this argument reduces to -- any work that uses a library is a derivative work of that library. But this is clearly wrong. For work X to be a derivative work of work Y, it must contain substantial protected expression from work Y, but an application need not have any expression from the If you do not distribute the GPL library, the library is simply being used in the intended, ordinary way. You do not need to agree to, nor can you violate, the GPL simply by using a work in its ordinary intended way. If the application contains insufficient copyrightable expression from the library to be considered a derivative work (and purely functional things do not count), then it cannot be a derivative work. The library is not being This argument has no basis in law or common sense. It's completely off-the-wall. The legal standard is not whether it "requires" copyrighted aspects but whether it *contains* them. The driver does not contain the USB stack. The aspects of the USB stack that the driver must contain are purely functional -- its API. You simply can't have it both ways. If the driver must contain X in order to do its job, then X is functional and cannot make the driver a derivative work. You cannot protect, by copyright, every way to accomplish a particular function. Copyright only protects creative choices among millions of (at least arguably) equally good choices. DS --
go ahead and create an application that uses a GPL only library. Then ask a lawyer if it is okay to distribute your application in binary only form without making the source code available (according to the GPL). http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL Regards Marcel --
On Saturday 09 February 2008 23:50:17 Marcel Holtmann wrote: In the US, at least, the belief that "Linking", in *ANY* form, with a GPL library creates a derivative work, is fallacious. Were I to create an application that uses, say, GTK for the interface the protected expression is my "unique and creative" use of the GTK API for creating the specific interface and any other code I have written using the API. I hold sole license to the copyright on that code and am able to license said code under the specific license of my choice. Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and hence the output is not able to be separately copyrighted - if it could be, then the copyright would be held by the *COMPILER*, and I am *NOT* bound by the license on that code. The same applies if GPL'd code is included in my application during the linking process. QED: The "Linking" argument used by most people is wholly fallacious in at least one major country - and if I'm not mistaken, the output from an automated process is similarly not considered as carrying a separate copyright in all nations that are signatories of or follow the Bern Convention. (And yes, this also applies to some GPL'd tools that RMS extended "GPL Exemptions" to - such as "Bison". There is, generally, no need for such an exemption, because the process by which the GPL'd code is included in the final binary is wholly mechanical.) DRH PS: The above information is a very condensed form of the result of several past conversations on this list about copyright law and the GPL as well as my own, private discussions with lawyers. I'm being lazy here and not searching various archives of LKML to give pointers to the past discussions. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. --
that is how FSF states it and it seems that most legal departments of big companies (US and EU based) are not taking any risk on this. So it seems that someone actually has to prove in court that these assumptions Not even getting into this one since GTK+ is a LGPL based library. Get The GPL is a license. Nobody is talking about the copyright of your code here. You always have the copyright on your code. The point is that you have to license your code under GPL (when using a GPL library) and you are distributing your code. Regards Marcel --
The FSF is making a claim that can be traced back to the beliefs of one person - RMS - and that propagate their views. As I stated in the original, this is not just my opinion, but that of two different lawyers I've spoken to and also the stated belief of numerous people on LKML. The fact is that the GPL only affects a "derivative work" in a viral manner. Merely using a GPL'd libraries API is not enough to make a program And the LGPL was created because of the FSF propagated belief that using a GPL'd library means your application is automatically a "derivative work" and hence must be released under the GPL. So the LGPL was created with the "automatic" 'linking' exemption. It is not necessary and never has been. This is why, even if the FSF claims what I've said above (that linking code with the GPL doesn't propagate the GPL into the non-GPL code) most companies won't risk it... Because the FSF has taken actions that are the exact Yes, It is "my" code and "my" copyright. However, by the absolutely *common* belief that "linking to GPL libraries makes a program a derivative work" it would mean that I no longer have the freedom to license my code under the license of my choosing, because the *mechanical* process of linking has caused the GPL's "viral" clause to spread to cover my code. And you're absolutely wrong. It doesn't matter that the library is GPL'd at all. My code *cannot*, under any circumstances, be affected by the GPL license on the library. Because the libraries API *cannot* be copyrighted and any GPL'd code which winds up in the final binary got there via a "mechanical process" and doesn't affect my right to release the code under a license of my choosing. Any other belief is fallacious. Claiming otherwise would mean that any program that uses any library on a windows system makes an application a derivative work of that library. DRH PS: I'm going to shut up again, because I've been party in my fill of these copyright/derivative ...
And its not pirating Windows because Norton Ghost put Microsoft copyright material in your hard disk either - thats a mechanical process too. Right - no. Nor can the gcc compiler hold the copyright as you suggest as it is not a legal person. The compiler might perform a process which combines your creative work with another and thus creates a derivative work. It might do that with libgcc. In many cases the FSF is being careful when it makes sure specific things don't happen just as Linus did with the kernel. Sometimes it is best to make sure no judge got a bit carried away and instead to create certainty in advance. If you really think what you claim then I'll #include your entire work, flog it binary only and assure you it can't be derivative as you said so. That's entirely mechanical - in fact I can clain a defence of 'estoppel' given your previous statement, so you probably wouldn't be able to sue me for it even if it was otherwise a violation. There is btw lots of possibly useful caselaw in the area of books. People have spent time litigating and thus established some clearer answers to questions like whether you need copyright owners permission for - Two books in the same box - Two books in the same cover - A book that quotes another - A book that uses the characters of another - A book which is a sequel/prequel to another - One book inserted sectionally into another Similarly in music questions about - Compilations - Remixes - Sampling - Setting to film - Covers have all been somewhat heavily litigated as you might expect from that industry. It would not be reasonable to expect caselaw in these areas to drive caselaw in software. Alan --
It takes someone telling the program to do it. The act of instructing the Yes, of course, and I'll never argue otherwise. However, what I was saying is that it is the claim of the FSF that, in no uncertain terms, a C program that uses the standard C library interface and is linked to glibc instead of, say, the old Borland libc, is automatically GPL because it's been linked to GPL code. And in the case of the "Bison Exception", lets think of it this way... A company writes a configuration file parser and is selling the software to other companies for use on their Solaris and SysV machines. The board decides to sell the software for linux and the employee in charge of the linux build uses the standard GNU tools for the entire process, including Bison. Even without the exception it wouldn't make the program a derivative of Bison or Straw man. Again. But... You'd have fallen afoul of the "intent". Action follows intent, and so And I've actually read almost all the court cases that have a bearing on this. (I don't step into a discussion unprepared) If the process of linking could create a derivative work, the *EVERY* program that runs on *ANY* OS would be a derivative of that OS, because the program is linked to the OS at run-time. DRH PS: It is time for me to shut up now. I'm sick (bronchitis) and when sick, I tend to get very combative and come off like a troll. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. --
glibc is LGPL and will not force you to use GPL. --
What happens if I ship a binary-only program that uses *either* a GPL library or a custom library with the same API? "If you don't have the Frobozz-Foo library, you'll have to supply your own work-alike".... (Note that this is in fact the *usual* case - very few programs actually check that they are linking against a Genuine GPL(tm) library, they just want the *API*, so providing a work-alike is sufficient....)
It depends whether it is a derived work. It doesn't matter if you paint it green, hang from trees while writing it or recompile it backwards while chanting - the legal boundary is the one from copyright law and that is where you must look for precedent and answers whether from prior computing cases or from equivalents in other areas. Alan --
On Sat, 09 Feb 2008 05:10:04 +1030 Mercy, no, with friends like Alexander you don't need any enemies... He's been fighting windmills for ages. I wouldn't trust his legal opinion at all. He might have some some points, sometimes, but it gets totally lost in all the noise that he produces. /Christer --
It's perfectly legal to create such an application. It only gets interesting if you *distribute* it... (And yes, this is where you *have* to be pedantic about the wording used)...
true, true and true. However I was under the impression we passed that discussion point, that you can do whatever inside your own walls :) Regards Marcel --
There are the commercial OpenSound drivers. Regards, Clemens --
What are they? Do you have a link to them? And why have I not heard from any user of them for the past two years (we have had a kernel warning for over 2 years for this issue.) thanks, greg k-h --
They aren't used widely (with Linux), and AFAIK the USB driver doesn't have anything to favor it over the ALSA driver. As far as my (biased) opinion is of interest, I'm not objecting against your patch. Regards, Clemens --
Ok, then we don't have any issues :) thanks, greg k-h --
What about ndiswrapper and its windows binaries are they covered through ndiswrapper by GPL? (Unfortunately I use them, but less and less) Boaz --
Sorry, but no, they are not going to work, due to the way that ndiswrapper is marked by the kernel module loader. Again, you should be getting a kernel warning every time you try to use a USB function today. What USB drivers for wireless devices are not yet supported by Linux becides the Marvell-based ones (which some of us are actively working on...)? thanks, greg k-h --
I'm not even sure, its an old vaio pII 512MZ. Still works like a charm with Linux. I use a chokoloku usb dangle that I dismantled and assembled inside the laptop case. I use the original windows drivers that came with it. Last time I checked with 2.6.20 it did not work, but I should now try Thank you, I do support what you are doing here. Just the ndiswrapper is a special case. But I guess I, as a user, can always use it anyway, right? But not the commercial distros. Don't stop the transition on my account. Boaz --
Yes, as a user, you are free to do whatever you want with the source code :) thanks, greg k-h --
There a company that is providing a common API for writting Windows and Linux drivers. Last time I was using a Macraigor JTAG it was based on this proprietary dual platform driver. http://www.macraigor.com/cgi_bin/counters/unicounter.pl?name=counters/ocd_cmdr_linux&a... The dual platform driver was from Jungo. http://www.jungo.com/ WinDriver™ USB for Linux automates and simplifies the development of user-mode Linux device drivers and hardware control applications for USB peripheral devices. No Linux kernel knowledge or kernel level programming required. -- Jon Smirl jonsmirl@gmail.com --
Yes, I know all about Jungo, and have never heard anything good about them from either the Windows developers I know, or anyone who has tried to get their stuff working on Linux using their framework. I would not recommend their stuff at all, it's much easier to just write a native Linux and Windows driver instead. Especially with the new Windows Driver Framework, which helps those developers out a lot more these days. thanks, greg k-h --
The near paperweight of Avermedia A828 Hybrid FM Volar nevertheless works with their closed module[1] at least as a digital tuner and a pretty crap FM tuner, despite the warning in syslog that it will no longer work in short order. Yes, I was suckered in by their claim that "it works under Linux", wasn't I? I would have thought it would be fairly easy to write open drivers for it, given that it has pretty standard chips: Cypress FX2, WM8739, Conexant CX2584x, Xceive XC3028 and Zarlink MT352 [1] http://www.avermedia.com/EN/default.aspx?TYPE=test.htm&PT=downloadD1&tv_TCAT_P... http://www.avermedia.com/images/www.avermedia.com_EN/A828_LinuxDrv_v0.07_x86Beta.zip --
