login
Search
A recent post to the lkml began, "I'm writing a module under a proprietary license." The debate as to whether or not a kernel module is a derivative work of the Linux kernel itself and thus must also be released under the GPL has come up many times. Linus Torvalds has previously noted that things like drivers that were originally written for other operating systems that have since been ported to Linux fall into a gray area as they are "clearly not a derived work of Linux in origin" [story]. In this most recent case, the author implied that he was working on an original work claiming, "but a module providing its internal state to the userspace doesn't need to be based on the kernel code in any way," going on to ask, "please replace every EXPORT_SYMBOL_GPL with EXPORT_SYMBOL in fs/sysfs/*.c".
The responses included numerous recommendations that he first consult with a lawyer. Greg KH replied, "no, the stated purpose of that marking is to prevent non-GPLd code from using those symbols. I don't see how you can state that using sysfs files in your driver does not make it a 'derived work' and force you to make all of your driver GPL." 2.6 maintainer Andrew Morton [interview] offered, "you shouldn't, although many people do. It's a derived work and hence the GPL is applicable. The only exception we make is for code which was written for other operating systems and was then ported to Linux. Because it is inappropriate to consider such code a derived work." Arjan van de Ven qualified Andrew's statement saying, "not all other kernel authors have to, or do, feel the same way, especially in the light of a huge gray area what 'ported' means, eg there is a gray area about how much new linux specific code is added."
From: Pavel Roskin [email blocked] To: linux-kernel Subject: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 17:56:57 -0500 (EST) Hello! I'm writing a module under a proprietary license. I decided to use sysfs to do the configuration. Unfortunately, all sysfs exports are available to GPL modules only because they are exported by EXPORT_SYMBOL_GPL. I have found the original e-mail where this change was proposed: http://www.ussg.iu.edu/hypermail/linux/kernel/0409.3/0345.html Patrick writes: "The users of these functions are all, in most cases, other subsystems, which provide a layer of abstraction for the downstream users (drivers, etc)." Maybe it was true in September 2004, but it's not true in February 2005. sysfs has become a standard way to make configurable parameters available to userspace, just like sysctl and ioctl. All I want to do is to have a module that would create subdirectories for some network interfaces under /sys/class/net/*/, which would contain additional parameters for those interfaces. I'm not creating a new subsystem or anything like that. sysctl is not good because the data is interface specific. ioctl on a socket would be OK, although it wouldn't be easily scriptable. The restriction on sysfs symbols would just force me to write a proprietary userspace utility to set those parameters instead of using a shell script. My understanding is that EXPORT_SYMBOL_GPL is only useful for symbols so specific to the kernel that the modules that use them would be effectively based on GPL code. But a module providing its internal state to the userspace doesn't need to be based on the kernel code in any way. Please replace every EXPORT_SYMBOL_GPL with EXPORT_SYMBOL in fs/sysfs/*.c -- Regards, Pavel Roskin
From: Greg KH [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 15:07:18 -0800 On Wed, Feb 02, 2005 at 05:56:57PM -0500, Pavel Roskin wrote: > I'm writing a module under a proprietary license. I decided to use sysfs > to do the configuration. Unfortunately, all sysfs exports are available > to GPL modules only because they are exported by EXPORT_SYMBOL_GPL. Heh, a gnu.org email address asking for us to change the GPL marking on symbols. Ah, the irony... > Please replace every EXPORT_SYMBOL_GPL with EXPORT_SYMBOL in fs/sysfs/*.c Sorry, but the answer is no. Good luck, greg k-h
From: Patrick Mochel [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 15:23:30 -0800 (PST) On Wed, 2 Feb 2005, Pavel Roskin wrote: > > Please replace every EXPORT_SYMBOL_GPL with EXPORT_SYMBOL in fs/sysfs/*.c No, thanks. Nothing has changed dramatically enough in 5 months to necessitate this change, and it's certainly not going to happen for a single binary driver. What is wrong with creating a (GPL'd) abstraction layer that exports symbols to the proprietary modules? Thanks, Pat
From: Greg KH [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 15:29:09 -0800 On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote: > > What is wrong with creating a (GPL'd) abstraction layer that exports > symbols to the proprietary modules? Ick, no! Please consult with a lawyer before trying this. I know a lot of them consider doing this just as forbidden as marking your module MODULE_LICENSE("GPL"); when it really isn't. thanks, greg k-h
From: Pavel Roskin [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 19:07:21 -0500 (EST) Hi, Greg and Patrick! On Wed, 2 Feb 2005, Greg KH wrote: > On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote: >> >> What is wrong with creating a (GPL'd) abstraction layer that exports >> symbols to the proprietary modules? > > Ick, no! > > Please consult with a lawyer before trying this. I know a lot of them > consider doing this just as forbidden as marking your module > MODULE_LICENSE("GPL"); when it really isn't. There will be a GPL'd layer, and it's likely that sysfs interaction will be on the GPL'd side anyway, for purely technical reasons. But it does feel like circumvention of the limitations set in the kernel. I thought it would be polite to ask the developers to lift those limitations, considering that they seem unfair and inconsistent with the stated purpose of EXPORT_SYMBOL_GPL. Sorry for using my gnu.org address. I'll use my rajant.com address for further questions about that project. -- Regards, Pavel Roskin
From: Greg KH [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 16:30:10 -0800 On Wed, Feb 02, 2005 at 07:07:21PM -0500, Pavel Roskin wrote: > On Wed, 2 Feb 2005, Greg KH wrote: > >On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote: > >> > >>What is wrong with creating a (GPL'd) abstraction layer that exports > >>symbols to the proprietary modules? > > > >Ick, no! > > > >Please consult with a lawyer before trying this. I know a lot of them > >consider doing this just as forbidden as marking your module > >MODULE_LICENSE("GPL"); when it really isn't. > > There will be a GPL'd layer, and it's likely that sysfs interaction will > be on the GPL'd side anyway, for purely technical reasons. But it does > feel like circumvention of the limitations set in the kernel. It is. And as such, it is not allowed. > I thought it would be polite to ask the developers to lift those > limitations, considering that they seem unfair and inconsistent with > the stated purpose of EXPORT_SYMBOL_GPL. No, the stated purpose of that marking is to prevent non-GPLd code from using those symbols. I don't see how you can state that using sysfs files in your driver does not make it a "derived work" and force you to make all of your driver GPL. I suggest that you consult your company's lawyers for what to do here. Good luck, greg k-h
From: Zan Lynx [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 02 Feb 2005 21:54:02 -0700 On Wed, 2005-02-02 at 16:30 -0800, Greg KH wrote: > On Wed, Feb 02, 2005 at 07:07:21PM -0500, Pavel Roskin wrote: > > On Wed, 2 Feb 2005, Greg KH wrote: > > >On Wed, Feb 02, 2005 at 03:23:30PM -0800, Patrick Mochel wrote: > > >> > > >>What is wrong with creating a (GPL'd) abstraction layer that exports > > >>symbols to the proprietary modules? > > > > > >Ick, no! > > > > > >Please consult with a lawyer before trying this. I know a lot of them > > >consider doing this just as forbidden as marking your module > > >MODULE_LICENSE("GPL"); when it really isn't. > > > > There will be a GPL'd layer, and it's likely that sysfs interaction will > > be on the GPL'd side anyway, for purely technical reasons. But it does > > feel like circumvention of the limitations set in the kernel. > > It is. And as such, it is not allowed. [snip] So, what's the magic amount of redirection and abstraction that cleanses the GPLness, hmm? Who gets to wave the magic wand to say what interfaces are GPL-to-non-GPL and which aren't? For example, the IDE drivers use GPL symbols but the VFS does not. So anyone can write a proprietary filesystem which eventually gets around to driving the IDE layer. That is okay, but this isn't? If the trend of making everything _GPL continues, I don't see any choice for binary module vendors but to join together to develop a stable driver API and build it as a GPL/BSD module. Do the same API for BSD systems to prove modules using it are not GPL derived. Watch Greg foam. It'd be fun. -- Zan Lynx [email blocked]
From: Greg KH [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Wed, 2 Feb 2005 21:07:42 -0800 On Wed, Feb 02, 2005 at 09:54:02PM -0700, Zan Lynx wrote: > So, what's the magic amount of redirection and abstraction that cleanses > the GPLness, hmm? Who gets to wave the magic wand to say what > interfaces are GPL-to-non-GPL and which aren't? Go read the historical posts from Linus that talk about how and why closed source modules were allowed for Linux. Then think about the fact that those issues are no longer pertintante these days for the majority of people who are trying to create such things. Then go consult an IP lawyer and listen to what they say. If your company feels that it can still ship a closed source driver, with legal approval, great, you've accepted the risk that this involves, and are willing to handle the issues that will occur (cease-and-deist letters, lawsuits, etc.) > If the trend of making everything _GPL continues, I don't see any choice > for binary module vendors but to join together to develop a stable > driver API and build it as a GPL/BSD module. Do the same API for BSD > systems to prove modules using it are not GPL derived. Watch Greg foam. > It'd be fun. Ah, UDI is over that-a-way. Been there, done that, watched everyone abandon it due to it being a stupid idea. If you want to revisit it and dig it up and get it working again, more power to you. I'll not foam, but laugh. good luck, greg k-h
From: Alan Cox [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Thu, 03 Feb 2005 15:12:59 +0000 On Iau, 2005-02-03 at 04:54, Zan Lynx wrote: > So, what's the magic amount of redirection and abstraction that cleanses > the GPLness, hmm? Who gets to wave the magic wand to say what > interfaces are GPL-to-non-GPL and which aren't? The "derivative work" distinction in law, which can be quite complex because it involves issues like intent. Other than the intentional clear statement that the syscall interface is considered a barrier by the authors there is no other statement. The GPL grants of patents are having a similar effect too, you'll need a patent license from IBM to write RCU using code for example unless its free software. You also appear to misunderstand dual licensing. If you have a GPL/BSD dual licensed module then when its using GPL'd code it ends up a combined GPL work you can't add binary blocks too (except as per being "not a derivative work") Alan
From: "Theodore Ts'o" [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Thu, 3 Feb 2005 12:26:47 -0500 On Thu, Feb 03, 2005 at 03:12:59PM +0000, Alan Cox wrote: > On Iau, 2005-02-03 at 04:54, Zan Lynx wrote: > > So, what's the magic amount of redirection and abstraction that cleanses > > the GPLness, hmm? Who gets to wave the magic wand to say what > > interfaces are GPL-to-non-GPL and which aren't? > > The "derivative work" distinction in law, which can be quite complex > because it involves issues like intent. Other than the intentional clear > statement that the syscall interface is considered a barrier by the > authors there is no other statement. When a copy actually takes place is another matter of law, and whether an MacOS init which links in and patches MacOS to provide various enhancements to MacOS, would therefore make Init a derived work of MacOS is also a matter of law, and may very well vary based on your the legal jourisdiction that you might happen to be in. So it's probably not worth discussing it (or the analogous situation involving proprietary code dlopen'ing GPL'ed code, or proprietary modules which use symbols that get linked into a GPL'ed kernel) on the Linux Kernel mailing list. To people who want to write proprietary modules and use GPL'ed symbol exports --- take it up with your lawyer, and maybe someday we'll have a few test cases and a decision one way or another so that armchair lawyers don't have to keep discussing it. It probably is worth saying that the non-legal concerns: * lack of cooperation from developers * the need to keep up with changing interfaces * the fact that the driver can't be included in the mainline kernel * refusal by distributions to carry the driver are probably the more important things for companies that want to use a proprietary driver model to consider. - Ted
From: Arjan van de Ven [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Thu, 03 Feb 2005 09:41:00 +0100 On Wed, 2005-02-02 at 17:56 -0500, Pavel Roskin wrote: > Hello! > > I'm writing a module under a proprietary license. I decided to use sysfs > to do the configuration. Unfortunately, all sysfs exports are available > to GPL modules only because they are exported by EXPORT_SYMBOL_GPL. I suggest you talk to a lawyer and review the general comments about binary modules with him (http://people.redhat.com/arjanv/COPYING.modules for example). You are writing an addition to linux from scratch, and it is generally not considered OK to do that in binary form (I certainly do not consider it OK).
From: Andrew Morton [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Fri, 4 Feb 2005 01:20:42 -0800 Pavel Roskin [email blocked] wrote: > > I'm writing a module under a proprietary license. You shouldn't, although many people do. It's a derived work and hence the GPL is applicable. The only exception we make is for code which was written for other operating systems and was then ported to Linux. Because it is inappropriate to consider such code a derived work.
From: Arjan van de Ven [email blocked] Subject: Re: Please open sysfs symbols to proprietary modules Date: Fri, 04 Feb 2005 10:40:11 +0100 On Fri, 2005-02-04 at 01:20 -0800, Andrew Morton wrote: > Pavel Roskin [email blocked] wrote: > > > > I'm writing a module under a proprietary license. > > You shouldn't, although many people do. It's a derived work and hence the > GPL is applicable. The only exception we make is for code which was > written for other operating systems and was then ported to Linux. Because > it is inappropriate to consider such code a derived work. Note that I would like to qualify the "we" word here for people who read this later. It is apparently your (and based on earlier mails, Linus' as well) opinion that you make an exception. Not all other kernel authors have to, or do, feel the same way, especially in the light of a huge gray area what "ported" means, eg there is a gray area about how much new linux specific code is added. Say you port a driver from windows to linux, and after the port 990 lines are linux specific and only 10 lines are left from the old code...
I dont understand why they ju
I dont understand why they just dont GPL the entire lot, everything and the kitchen sink and be done with the whole issue.
Easy
http://www.google.com/search?hl=en&q=shooting+yourself+in+the+foot&btnG=Google+Search
just GPL the module. how bad
just GPL the module. how bad can it be? is it so difficult to "give" something?
Yea.
Yea.
just GPL the module. how bad
It can be.
What if the author doesn't want to restrict people's use of their driver? What if he wants people to be able to do whatever they want with it without having to release their own changes under the GPL? The GPL is too restrictive for some people.
For example, what if someone wanted to port that driver over to a BSD (don't ask me why)? There isn't anything wrong with it, but if the person is working with BSD, they probably won't like the fact that they have to restrict THEIR users because the original author was forced to do the same thing.
The GPL gives you the freedom to do whatever you want with the software, as long as what you want to do with it is GPL it. In other words, "you can have it any colour you want, as long as you want it black."
Nonsense - you can mix BSD co
Nonsense - you can mix BSD code into a GPL kernel without problem, it is not a license violation. In fact, lot of BSD code was ported to Linux like this. It doesn't work the other way round - if you make something GPL, it cannot be BSD licensed.
So if he wanted to make a BSD licensed module, it is perfectly fine to dual-license it. With Linux, it will be licensed as GPL, with BSD as BSD. So this is not a valid concern.
Jan
That wasn't my point, maybe I
That wasn't my point, maybe I wasn't clear.. or I suppose I could just be way off-topic.. maybe if I put it in terms of myself.
If I were to write something, I wouldn't use the GPL because it means that anyone who uses that code must also use the GPL for their modifications to it, and thus force THEIR users to do the same, if applicable.
Yes, one could dual-license, but that seems a little annoying in the case of kernel modules because it would mean providing, and possibly maintaining, two different versions of the code in two different locations (one in-kernel, one standalone). Seems a little hard for some random anonymous person to get a BSD licensed version of something they see in the linux kernel and want to use.
I wasn't trying to imply a license conflict, but rather an ideology conflict.
Of course I could always be completely off my rocker, in which case it's safe to ignore me..
That is a possible ideologica
That is a possible ideological conflict, but it's not relevant to this case, which is clearly one of someone making something that is *closed*, not BSDed.
As it happens, I think the GPL ideology is better than the BSD one, but that old argument really has nothing to do with this issue. And I really don't think you're going to get far arguing the superiority of the BSD license at kerneltrap.org; just how many people hereabouts do you really think haven't thought through their position on licenses? Life's too short to reopen the license wars every five seconds.
look at what he is building
The company builds a battle field network for foot soldiers, trucks, etc. It uses ad hoc wireless to relay packets and adjust the network as things move around. They may not be free to "give" because of security classifications. Jon Smirl.
INAL, but it sounds like GPLi
INAL, but it sounds like GPLing the code might not be a problem. The GPL doesn't say you have to give your code away to everyone, just to the people you are distributing it to, if they ask for it. On imagines the contract might already specify that the govt. gets the code, and if it doesn't it still probably doesn't hurt if they can get the software some day.
Not just security
It's not just a matter of security, but patent rights, etc. Dynamically adaptive wireless networks are a very new field (there are at least a couple of big DARPA projects on it), and open-sourcing the code is just asking for your competitors to steal all your cool ideas. Not to mention that it eliminates the possibility of making money off patents on the implementation of the algorithms. This is one of the specific cases I think software patents make sense. It takes years of research to develop the algorithms for something like this, but the implementation itself isn't very interesting at all. Without the patent, there is no way to make money to recoup all those R&D dollars, because reimplementing the algorithm is very simple and straight-forward.
Open Source != GPL
"Open sourcing" code is not synonymous with licensing it under the GPL, which is what is required here. If the developer licenses it to the US Department of Defense, for example, then I don't think the DoD would be interested in sharing it with others, so there's no problem there. The GPL just says you have the right to share software with others, not that you're required to.
There is a problem
Think that one through. If the developer licenses it to the DoD under the GPL, then anybody at the DoD who has access to the software would be free to release it. Any contracts to keep them from leaking the software would be unlikely to work. So they just have to prey that a low-level techie at the DoD never decides to release their work publically.
I don't believe this is true.
I don't believe this is true. If my friend comes to my house and uses my Linux computer, I do not have to give him the source code if he requests it. I did not redistribute the software, but simply had it on my machine when someone else used it. The same would apply in this situation.
Employees of the US Gov't would not be receiving copies of the software, but simply using the software on the US Gov't's computers.
If this situation were possible, then Red Hat doing inhouse work on open source software without releasing regular CVS updates would not be possible.
That is just plain wrong. The
That is just plain wrong. The GPL allows you to use the GPL'ed software and your own changes under no restrictions as long as you don't release it, this includes being able to deny employers the right to distribute it, and they WOULD be able to sue the employees under the copyright law (or probably under employment contract law), for doing it.
You still have the GPL export
You still have the GPL export symbol restriction. While it is
not a licensing restriction it was written to discourage certain
rights of GPL.
Absolutely not
"If the developer licenses it to the DoD under the GPL, then anybody at the DoD who has access to the software would be free to release it."
The hypothetical software would be licensed to the DoD under the GPL, _not_ to the "low-level techie." The employee has no right whatsoever under the GPL to redistribute the code, because he/she is not the license holder. If it were leaked, the license to the DoD would be irrelevant, because it would be "stolen" code. It would not have any valid license to third parties, any more than if someone from Microsoft leaked MS source code and pasted the GPL onto the top of the files.
I doubt it's because of security classifications
I'm not saying that it's absolutely not; I just doubt it at this point quite seriously. The information to do that is already out there; it's simply a matter of writing some code to implement that idea.
I suspect that it's because of so-called "intellectual property" issues. Here's how he can handle that. He wants to run this on GNU/Linux systems, which is why he's asking this (in my opinion, ridiculous) question in the first place. He doesn't have to write it for GNU/Linux; he could choose another operating system, like any of the BSDs. The BSD license would let him do that without having to be concerned about the GPL. Heck, they could include their own bundled version of, say, OpenBSD with this proprietary driver, the same way that Apple does with OS X and FreeBSD. Thus, for whatever reason which is none of our business, either he or his company has made a conscious choice to write this driver for GNU/Linux, whose kernel, C library, and many other parts have long been licensed under the GPL.
If he or his company has chosen to do that, then he/his company must, of course, play by the license rules. He wants to protect his "invention" from competitors. What he could do is simply patent his "invention", GPL his driver, and grant a free (as in freedom, of course), perpetual, explicit patent license for any other GPL'd (and no other) implementation. Thus, if his competitors want to come out with competition, their stuff has to be GPL'd as well. Sure, the competitors can sell their implementation, but any financial benefit of taking the code, closing it up, and selling your "secret" version, as Apple has done with OS X and BSD, is now eliminated, so it's not likely to be done.
Protecting his assets...
If he just patents the process, he dosn't need to give a license to GPL users. The patent would give him the right to collect royalites from anyone using his driver. It would also give him the right to collect from anyone how took his driver and modified it (they would have to read his patent and rework the driver in such away that it no long did with the patent claimed be be safe).
He's best bet might be to just GPL the code and patent the concept. If he listed the patent number in the source code to make other developers aware that the code is protected; then the later users would need to take out a license to use the driver.
Actually
The problem is that the GPL doesn't allow you to distribute software covered under a patent license that isn't royalty-free. So you'd still have the patent, but you couldn't make any money off it. In my mind, the solution here is to just not write a driver for Linux. If it's an embedded military sort of thing, you could just put a BSD on the system.
Doesn't work
What he could do is simply patent his "invention", GPL his driver, and grant a free (as in freedom, of course), perpetual, explicit patent license for any other GPL'd (and no other) implementation. Thus, if his competitors want to come out with competition, their stuff has to be GPL'd as well.
That doesn't work. They GPL the implementation, and their competitors could just use that implementation in their own products. They still don't make any money off the IP. The thing is that there are quite a lot of companies (important ones, like BBN), that make their money "thinking stuff up". R&D is a big part of their business --- they solve hard problems, and more suitable people do stuff like manufacturing implementations. If they open-source their technology, without charging for patents, then they can't recoup that expensive R&D.
Of course, they are getting a competitive advantage using Linux, but that's sort of useless without making money on the technology. This might just be one of those situations where it doesn't make sense to use Linux.
Thus, for whatever reason whi
Nonsense; glibc is licensed under the LGPL.
How about trying to make it a servce
How about trying to go the Google way and turn the product into a service. Ie. the equipment is not sold rather it is provided to the customer as a service (or perhaps leased).
In practice it might be just impossible to do this in their field of business but just in theory wouldn't that solve all the original posters problems ? If you render a service using some linux based devices are you obliged by the GPL to release all your kernel modifications and additions ?
No, you are not, since you ar
No, you are not, since you are not redistributing the software.
Not quite
This is the web, chief. Much of the time, web services involve distribution of software. You're downloading codes in various forms and running it. How is that not distribution?
Redistribution
This is the web, chief. Much of the time, web services involve distribution of software. You're downloading codes in various forms and running it. How is that not distribution?
Becuase the interesting part of the vast majority of web services aren't "downloaded codes"?
Is there any license which fo
Is there any license which forbids ones code to be used by the military?
I certanily whould not like anything i code to be used for killing.
maybe there is, but it wouln'
maybe there is, but it wouln't be gpl compattible; the gpl forbids additional restrictions.
Ah I see. Well, "in the li
Ah I see.
Well, "in the light of these events"... I personaly wont code for anything that will be used in.. ahm. iraq. :/
BTW; On another discoussion above^, yes you cannot include GPLed code in your BSD code. FreeBSD for example cannot take linux' driver code and have it in their kernel, if they want to do that then they whould have to GPL their kernel. So that if i have coded something and using the bsd license, i wont be able to use your gpl code in it. I think it is so, but i might be wrong.
You can mix GPL+BSD (the one
You can mix GPL+BSD (the one without advertising clause) without any restrictions. The result is only GPL'ed.
Thats what i said.
Thats what i said.
It wouldn't be Free Software
by anyone's definition (FSF, Debian, etc) -- nor OSI-certified open-source -- because one of the prerequisites of Free Software is freedom of field of endeavour. This includes killing people.
This is alot more complicated than most people think!
It seems like the terminology is confusing people into thinking this issue is much simpler than it truely is. The phrase 'derived work' suggests to many people any work deriving from the original in some way. Yet the intent is to prevent others from copying the original work, or the ideas behind it and it is far from clear if using an interface falls under this protection.
For instance a joke about mickey mouse is in some sense 'derived' from disney's copyrighted works yet jokes about mikey mouse or other discussion of him do not run afoul of disney's copyright. On the other hand a joke *from* a mickey mouse cartoon may very well fall afoul of disney's copyright. I'm not entierly clear if the reason is that it does not bear sufficent similarity to qualify as a derived work or if this falls under the fair use exception. In either case, however, the same question applies to the kernel situation.
Is using an interface more like talking *about* mickey mouse or copying mickey mouse? While the legal question is no doubt much more technical I think this gives a sense of the complications inherint in this issue. The answer is hardly clear just because the program is using a GPL'd interface.
As a practical matter I think they should just put any module interface in the public domain. This is because a simple trick, as discussed in the article, will let a proprietary developer make use of the interface without (in most cases) running afoul of copyright. In particular one can always create your own GPL'd interface that sits on top of the kernel interface satisfying the GPL but since you also own the copyright to your own interface you can use it in your proprietary code without concern. So the whole buisness doesn't really make more things open source but just makes things more messy and complicated.
Since this GPL'd interface trick is somewhat confusing let me go through it slowly. The danger about using the normal kernel interface in a propriatary kernel module is (I assume) that one is copying copyrighted code without permission, say the names and properties of the interface, without permission. Now suppose I write a new piece of code which sticks a differnt interface on top of the GPL'd piece of code. If I write this interface carefully no part of the original GPL'd kernel code will 'show through' thus the code gives access to the functionality with none of the form (remember copyright protects form not function, you still can't copyright the idea of sorting a list but you could copyright particular code which accomplishes this end). Since this piece of code is itself GPL'd the fact that my interface copies parts of GPL'd code is of no concern. The GPL does not look at intent.
So now I have a new interface that I wrote myself to the functionality provided by the kernel. Since I wrote this code myself nothing prevents me from distributing it under more than one liscensce (I own the copyright and the GPL does not require me to assign it to the FSF). Thus nothing prevents me from incorporating things from my own interface in my proprietary module. So long as we take a reasonable view of when copying takes place (and even if we don't I'm still not sure if there is a problem) no violation of the GPL has been commited. The only proprietary code in question in the module and the module only contains code which is copyrighted by the writer, even if some has also been released under the GPL.
Of course in some situations one might run into patent problems. Supposing the interface to the kernel feature used a special type of data structure which had been patented you would either have to change that data structure into a more common type in your interface or risk patent infringement. Still, I don't think this will matter in most circumstances. Of course I'm not a lawyer but I am fairly confident in the above analysis. If someone knows differntly though i would be happy to hear it.
Not really that complicated.
Derivative (or "derived" works) are those that are the result of some intellectually-novel (ie non-automated) transformation of an original works. This is why without JKRowlings' authorization, you cannot write a Harry Potter novel nor film a Harry Potter movie (even if not based on any of the current novels). Copyright law does not permit the creation of derivative works. And yes, all fanfic is copyright infringement.
To determine if a work is a derivative of another, you have to apply the Holy Tritinty: Abstraction, Filtration, Comparison. But I have a rule-of-thumb: if work A would not exist (or would be radically different) if work B did not exist, then A is a derivative work of B.
In casu, that's exactly what we have: a device driver that would not exist or would be radically different if Linux did not exist.
EXPORT_SYMBOL_GPL is exactly a documental hint that says: "hey, if you use this symbol you will be messing with the bowels of Linux, and hence your code is a derivative work on the code that exports this." IOW, don't use this unless your code is GPL.
I have a rule-of-thumb: if wo
I have a rule-of-thumb: if work A would not exist (or would be radically different) if work B did not exist, then A is a derivative work of B. In casu, that's exactly what we have: a device driver that would not exist or would be radically different if Linux did not exist.
But applying that rule-of-thumb to Windows device drivers, you find that they are all derivative works of Windows - so how do they manage not to infringe Microsoft's copyright? What makes Linux different?
Read the Windows DDK licence
Try reading the licence on the Windows DDK; it explicitly permits you to write a driver using the kernel functions documented in the DDK. So, although your driver is a derived work of the Windows kernel, you have permission from Microsoft to distribute it.
You can also separate your driver from the Windows kernel API, and write to an abstraction layer; at this point, the abstraction layer is a derived work of the Windows kernel, as is the combination of the Windows implementation of the abstraction layer and the driver. The driver on its own is not then derived from the Windows kernel in any way, shape or form.
The Linux equivalent of this trick is used by nVidia; their binary drivers are written against an abstraction layer, which is distributed under GPL, with an exception to allow it to be distributed with nVidia's binary driver. The combination of the Linux implementation of that layer, the Linux kernel and the binary driver is not redistributable by anyone. This poses no problems for nVidia, as it does not distribute the kernel, just the two bits it owns, and can distribute any way it likes. No one may distribute a kernel with the nVidia driver without violating copyrights on Linux.
Thanks, that was a very helpf
Thanks, that was a very helpful reply...
There is life outside GPL-do you belief
For some of you GPL has become a religion. For me it is quite easy to understand that there are a lot of driver etc. that can't be released as GPL code is short run. There are licensing or patent issues.
You can say that no problem: just change the license or make patent publicly available. That is not possible if you don't own the rights to do so. In many case some ancient subcontractor owns some of vital copyrights. Then there is two alternatives: abandon Linux or make/release binary drivers.
You might think that its not your problem. However, that attitude might cause Linux to lose battle over for example home/game users. I think that the in graphics card side the lack of GPL drivers is one warning signal. There might be very remarkable reasons not to release everything. Then, if you get nothing back when you release some specs, why to release anything?
The attitude, if you are not with us you are against us, is somewhat strange for north European way of thinking. On my mind the beauty of GPL is that the code dealing with GPL slowly falls into GPL itself, if there are no remarkable reasons that prevents it. The additional work needed in the maintenance is the inertia that drives to that direction.
If and when the religion is part of the game that will not happen. If the interface between GPL and binary interface is made too complicated, there is no way to let the erosion drive the code base to GPL. Then it is easier to drop support or maintain the existing code base including the interface. Releasing some parts cause a lot of extra work without any real short term benefits.
On my mind the time is doing the work for GPL if you/we let it work for us. By making barriers we are only shooting our foot. The power of Linux has been that giving something the contributor or his/her employer has got more back. The most important issue is to keep this efficiency valid. On the other hand free riders has to be kept away to keep the game fair. Nevertheless, the process halts if all the free riders are tried to be kept away. There has to be some tolerance in real world. We don't live in utopia.
Not a programmer's view
You're clearly not looking at this from a programmers perspective; there are two reasons not to permit binary-only (non-GPL) modules, one technical, and one philosophical.
And there is tolerance in Linux land; we don't make it easy for you to violate the licence, but we don't actively seek licence violators and issue C&D notices for violating that licence. We work with you to bring you into compliance, or get you to port away from Linux to another OS instead.
For some reason I feel I am s
For some reason I feel I am some kind of programmer and I have felt that way for long time. For me it is obvious that the kernel tree has to be kept as clean as possible. So in the main line there are no room non GPL stuff. I didn't insist any tolerance for that. In fact my point is that changes on interface is one force that drives the alien code to GPL, if there are enough room for that. Why to maintain code if you don't get incomes. On the other hand you want to see your child to be alive.
For the second argument I have to say that there are cases when you don't even have the rights to release the the planing parameters but you want to sell your product. The product can be for example some extension card. It can also be some devise that can be connected to PC. ”Everybody” would benefit when as much as possible of the ”supporting” code is released as GPL.
You have to understand that in many cases the business is the products and drivers only support it. Then the driver issue should be handled with minimum effort and in many cases outside the house. If plenty of extra effort is needed to give something back to community why to bother at all.
I feel that GPL is winning concept and that is why I prefer it. In fact it is so strong that it horrify ”outsiders”. If the force is used against friendly but suspicious parties they will walk away. GPL gives huge amount of power for community. Unfortunately, force includes responsibility and you have to respect it. When you have responsibility you can't say: my way or highway. You have to have great respect also to people that don't think like you.
I don't think you're getting it
What the Linux devs are saying is very simple:
"We wrote this valuable code. Pay us for it, or don't use it."
If the benefits of writing a driver for Linux exceed the payment demanded, write one, and comply with the licence. If they don't, then use something else.
No other copyrighted software allows you to opt out of paying the requested price for it if you don't like the price. Just because you're not used to paying for software in code doesn't give you the right to demand that Linux changes its price. I'd prefer to pay for Microsoft Windows with code contributions rather than cash, but Microsoft doesn't give me that option; my employer would rather pay for VxWorks and ThreadX with code rather than cash, but their copyright owners don't give that option either.
Even if you're manufacturing PC add-ons rather than embedded devices, the rules are unchanged. Either the extra sales from a Linux driver are worth the price, or they're not. Don't expect to get away with ignoring the copyright on Linux just because it suits your commercial imperatives; I can't get away with ignoring the copyright on your software just because it's cheaper for me.
Maybe I don't get it right. H
Maybe I don't get it right. However, I was involved this type of business before IBM PC was born. Even then there was code exchange going on. There was closed source and free ware and so on. There was room for ”ancient GNU/Linux” but the media was the problem: no internet.
A bit later IBM PC/Microsoft released our from ”monopoly markets”. However, Microsoft didn't want to be a liberator, it turned out to be a conqueror. It want to become a caliph by forcing the caliph aside. There are plenty of us who remember the process. If too many of us believes that Linux is trying the same, too many important people don't want to be involved that process. As important people I don't mean finance department because they would sell even the rope that is used to hang hang them.
I see GPL as instrument for knowledge/effort exchange not for blackmailing. You see GPL as instrument of trade. There is an enormous gap between them. Maybe I am naive when I believe on honesty. Maybe it is because here in north we don't value greed. My point is that when somebody gives as much as he humanly speaking can give, it is enough. If he don't play with your rules you are free not to invite him to your club but you must have respect. There must be room for common sense too.
Respect is the key factor of the success of the model. I am on a different position because my work don't have wide interest and major part of my effort is open anyway. The rest I can't release due non-disclosure . However, my own choice has been just to give some code away (basically freeware). Another choice has been licence core with GPL and some interface with LGPL (= relatively near to LGPL). My attitude is try to keep the process alive. If someone is using my work unfairly that is their problem. I don't want back something that has only minor value to me or community. On the other hand I hope the majority of valuable changes (if exist) finds back to me.
They're not saying that at all
The devs are saying "I wrote this code. You think I'm cool, don't you? If you use my stuff then I must be cool." It's an enormous crock of crap.
If I use your API I have NOT derived from your work any more than people who use my drivers have derived from my work. There is no legal tie between the writer and the user of an API. The EXPORT_SYMBOL_GPL tag is nothing more than an attempt to force even commercial software vendors to release their source code for no other reason than "Because I said so. And I'm cool."
If you use my device driver, and thus its API, you are not overlapping my copyright in any way, shape or form. You are using my code, not deriving from it. There is a huge difference between using code and deriving from it. Simply releasing the source to my driver does not allow me to claim later than the user of my driver must have derived his work from mine because he had the source. I suggest you brush up a bit on copyright law and how it applies to intellectual property.
Depends on the API
You've obviously not talked to a lawyer about this, as you're completely wrong with respect to both New York law and UK law.
Where an API is more than a functional interface description (as in the case of the Linux VFS), you are creating a derived work. You must be able to show that your work functions independently of the work that I'm claiming you derived from (so that it's a mere aggregation), or that there is nothing in the API that you've used that qualifies as creative.
By marking a symbol as GPL only, the kernel devs are making it clear that in their opinion, there is no way to use that symbol that does not involve deriving from the kernel; you're free to ignore it if you reckon that you could prevail in a copyright infringement case.
In any case, if you intend to distribute your driver integrated with the kernel, the entire unit must be distributed under the GPL, regardless of derivation issues, in order to comply with section 2 of the GPL. Your permission to distribute your non-derived driver separately only applies to the driver on its own; you may not distribute the kernel with a non-GPL driver.
I think that the fundamental issue is not the law. It is much more the attitude. Are you trying to make some kind of memorandum with your work? Then it is clear why you want to control the outcome by any usable methods. If your intention is just to give your effort to welfare of the community then you think how well your choices serve the community and interest groups beyond that.
We all understand word respect slightly differently. So I have to choose slightly worse perspective. Let’s think that you don’t respect others work enough and for some reason they still want to stick to Linux. What they can do. Whey can’t respect your work either.
They can take your GPL code and modify it for their needs. I assume that not too much modification are needed in GPL side to make a hook for their code. Then they can claim that modifications are derived from closed source side. If there are respect for original author work one can practically just to remove additional restrictions (legal but immoral) and re-release more “practical” version.
At the end, if Linux will be major player also in future, there is no way to make arbitrary restrictions. If that is tried it is easy to predict what will happen. At some point commercial distributions and hardware suppliers finds themselves in situation where they must ensure the support. I think that the easies way is to make modifications to kernel (against original authors will). In addition big payers will have access to driver sources too. That will force to reduce their contribution to open source drivers.
Practically it means the there might be situation where big boys are stealing your toy and you can’t do much about it. You can leave your sandbox and let them destroy your work. The other possibility is to start to play within their rules. One thing you have to remember. If the line is crossed there is no way back.
Law matters.
I don't know where you get this "there is no way to make arbitrary restrictions" idea from; the Microsoft Windows licence is full of arbitrary restrictions, many of which were Microsoft innovations. Are you claiming that Windows will never be a major player, too? If so, I have a bridge to sell you.
The GPL was an active choice for Linux, and it's arguable that part of the modern success of Linux relative to the BSDs (which have this free licence that you're suggesting) is that big boys can contribute to Linux, safe in the knowledge that their competitors cannot just take the code closed, add a driver or some other software enhancement to increase the value, and make money off it. You really don't want IBM to allege that you're infringing their copyright in your use of Linux; they're in a position to destroy you completely.
Yes but Linux best friend is Microsoft with it monopoly attitude. I don’t think that IBM will ever allow Linux community become new Microsoft or harm the business by senseless restrictions. On the other hand MS even provide vendor support on driver side. They may out compete you unfairly but I don’t think they try to force to give up your IP. That is big difference on favour MS.
I don’t mean that there is anything wrong in GPL, quite opposite, even it can be misused. I don’t even think that there is much wrong in the attitude of the Linux community either. However, I don’t share the opinion that the end justifies the means. Behind every choice, there has to be intention of noble nature not egoism. In separate cases that may cause damages to your goals but at the end it is the only long lasting way. What I am asking is some kind of value discussion.
I don't get what you're driving at.
The intention behind Linux's use of the GPL is noble; we'll show you our code up front. You can take it and use it as much as you like, and you can even add your own features to it; all we ask is that if you distribute a version of Linux to someone else, you give them source to the version you distribute under the same terms as we gave you our source.
There was a conscious decision made not to use a BSD-type licence, which lacks the redistribution terms, or even an LGPL-type licence, which would allow you to keep your own changes private and still redistribute. The reason is that Linux was never intended as a commercial replacement for any mainstream OS, and it's only the fact that the GPL has allowed Linux to absorb all contributions in a maintainable form that has allowed Linux to grow to its current position.
Now that Linux is as good as other OSes for many uses, people are complaining that it doesn't let them do what they want to do (usually ignore copyright laws). As I've said before in this thread, there are other choices; if *BSD isn't good enough, but Linux is, I'd say that that's a strong argument in favour of the effects of the GPL.
In short I want see GPL software as backbone of all the main stream software. Main stream software is commercial due the need of formal support. That can’t be changed by licensing. For commercial purposes there has to be some (but not much) room for secrets wiht relatively high “costs”. At the end maintaining costs and information leaks/fragments works favour of opening as much as possible.
After all, I don’t see Linux as project of some hobbyists. I see it as serious project that is supported by business objectives. In short I see GPL as way to avoid frustrating standardization process. It is tool for cooperation and sharing. By using GPL you can’t change the world but you can make it a different/better place to live.
High costs
Nothing stops you charging for GPL software, or for support. If you need secrets, arrange an NDA, and don't distribute publically. If neither charging and hoping people pay, or arranging a unique contract with every customer suits your business model, don't use GPL software. Use LGPL stuff, or BSD stuff, or something where the copyright owners are happy for you to keep your stuff secret.
The whole point of using the GPL is that it's a "we'll give you ours if you'll give us yours" licence. Anything where you need to hide stuff is not suitable for integration with the Linux kernel. If the Linux kernel, or other GPL'd code, represents added value for you, either you show us your stuff, or you do without that added value. If you can find enough added value in a BSD, use that instead.