Re: Please open sysfs symbols to proprietary modules
On Thu, 2005-02-17 at 17:13 -0600, [EMAIL PROTECTED] wrote: > On Thu, 03 Feb 2005 09:41:00 +0100, Arjan van de Ven <[EMAIL PROTECTED]> > wrote: > > 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). > > So what about companies like ImageStream who write proprietary Linux network > drivers for their hardware from scratch with no previous ports from another > OS? Note that "has a previous port" is not enough for me to consider a proprietary driver "ok". Anyway you asked... if your description is accurate then yes I consider those modules (if they are distributed of course) a violation of the license of the code I contributed to the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
[EMAIL PROTECTED] wrote: On Thu, 03 Feb 2005 09:41:00 +0100, Arjan van de Ven <[EMAIL PROTECTED]> wrote: 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). So what about companies like ImageStream who write proprietary Linux network drivers for their hardware from scratch with no previous ports from another OS? Obviously he doesn't consider that to be okay, and those companies are taking a risk that someone will take legal action against them. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Thu, 03 Feb 2005 09:41:00 +0100, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > 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). So what about companies like ImageStream who write proprietary Linux network drivers for their hardware from scratch with no previous ports from another OS? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
> 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. As one of the copyright holders I make no such exception. Its either a derived work in law or its not. In the former case obey the license or remove every line of code derived from anything I wrote. If it's not a derived work then fine. If you aren't sure ask your lawyer. [Sorry I'm sort of obliged to reply to this comment to prove I'm defending my copyrights and not accepting various positions Linus and others may claim exist. I believe others like the FSF whose code is used in the kernel have similar views] Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
"Randy.Dunlap" <[EMAIL PROTECTED]> said: > Chris Friesen wrote: [...] > > If you look at the big chip manufacturers (TI, Maxim, Analog Devices, > > etc.) they publish specs on everything. It would be nice if others did > > the same. > One of the arguments that I have heard is fairly old and debatable as > well. This was the subject of a panel discussion at LWE in 2000 or > 2001, chaired by journalist Nicholas Petreley. The panel was composed > of vendors from (mostly) audio devices IIRC, but I'm not sure. A friend of mine got to sign an NDA for access to the official specs to a device. Turned out to be some handwritten sheets, scribbled over... Shame might have something to do too ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Mon, 7 Feb 2005, jerome lacoste wrote: On Mon, 7 Feb 2005 11:55:31 -0500 (EST), linux-os <[EMAIL PROTECTED]> wrote: On Mon, 7 Feb 2005, Chris Friesen wrote: Lee Revell wrote: On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote: It's not like somebody will have some innate commercial advantage over you because they have your driver source code. For a hardware vendor that's not a very compelling argument. Especially compared to what their IP lawyers are telling them. Got anything to back it up? I have a friend who works for a company that does reverse-engineering of ICs. Companies hire them to figure out how their competitor's chips work. This is the real threat to hardware manufacturers, not publishing the chip specs. Having driver code gives you the interface to the device. That can be reverse-engineered from watching bus traces or disassembling binary drivers (which is how many linux drivers were originally written). Companies have these kinds of resources. If you look at the big chip manufacturers (TI, Maxim, Analog Devices, etc.) they publish specs on everything. It would be nice if others did the same. Chris I also have first-hand knowledge. Once there was a company called Data Precision. Just point your favorite search-engine to that name. They were a wholly owned subsidiary of Analogic. They no longer exist. Data Precision would take a year or more to develop a product. Six weeks after it was available on the market, it would have been cloned by Pacific-rim companies and dumped into the US at below US manufacturing cost. [..] Shouldn't you be able to use legal action against companies that provide such clones (at least in your country)? You could maybe even sue the local resellers for participating to the fraud. J Sure, but the window of opportunity necessary for sales has been lost. That's how these thieves live. They start a company with the secret backing of a mother-ship like (name any Pacific rim company). They clone the US product. Then they sell and ship. Once a distribution problem exists, of any kind BTW, the company disappears. The local resellers know only that a lower cost thingy, that worked just as good as the US advertised box, became available that allowed them to serve their customers at a lower cost, while improving the distributors profit. These are all altruistic. There is no avenue for a lawsuit here. FYI, in the 60s you could buy "transistor radios" made in USA. They were made in Usa, Japan, and they carried a "RCA Victrola" label. Everything was designed to deceive, including the name of a city that was incorporated solely to deceive Americans at a time when Americans were being taught to buy American products. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Mon, 7 Feb 2005 11:55:31 -0500 (EST), linux-os <[EMAIL PROTECTED]> wrote: > On Mon, 7 Feb 2005, Chris Friesen wrote: > > > Lee Revell wrote: > >> On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote: > >> > >>> It's not like somebody will have > >>> some innate commercial advantage over you because they have your > >>> driver source code. > >> > >> > >> For a hardware vendor that's not a very compelling argument. Especially > >> compared to what their IP lawyers are telling them. > >> > >> Got anything to back it up? > > > > I have a friend who works for a company that does reverse-engineering of > > ICs. > > Companies hire them to figure out how their competitor's chips work. This > > is > > the real threat to hardware manufacturers, not publishing the chip specs. > > > > Having driver code gives you the interface to the device. That can be > > reverse-engineered from watching bus traces or disassembling binary drivers > > (which is how many linux drivers were originally written). Companies have > > these kinds of resources. > > > > If you look at the big chip manufacturers (TI, Maxim, Analog Devices, etc.) > > they publish specs on everything. It would be nice if others did the same. > > > > Chris > > I also have first-hand knowledge. Once there was a company called > Data Precision. Just point your favorite search-engine to that > name. They were a wholly owned subsidiary of Analogic. They > no longer exist. Data Precision would take a year or more > to develop a product. Six weeks after it was available on > the market, it would have been cloned by Pacific-rim companies > and dumped into the US at below US manufacturing cost. > [..] Shouldn't you be able to use legal action against companies that provide such clones (at least in your country)? You could maybe even sue the local resellers for participating to the fraud. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
Chris Friesen wrote: Lee Revell wrote: On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote: It's not like somebody will have some innate commercial advantage over you because they have your driver source code. For a hardware vendor that's not a very compelling argument. Especially compared to what their IP lawyers are telling them. Got anything to back it up? I have a friend who works for a company that does reverse-engineering of ICs. Companies hire them to figure out how their competitor's chips work. This is the real threat to hardware manufacturers, not publishing the chip specs. Having driver code gives you the interface to the device. That can be reverse-engineered from watching bus traces or disassembling binary drivers (which is how many linux drivers were originally written). Companies have these kinds of resources. If you look at the big chip manufacturers (TI, Maxim, Analog Devices, etc.) they publish specs on everything. It would be nice if others did the same. One of the arguments that I have heard is fairly old and debatable as well. This was the subject of a panel discussion at LWE in 2000 or 2001, chaired by journalist Nicholas Petreley. The panel was composed of vendors from (mostly) audio devices IIRC, but I'm not sure. The bottom line summary was agreement that open-source drivers usually expose how generation A of a device works, while the company is off building generation B, and designing generation C. So if another company wants to clone generation A and be left in the dust when their product is ready, let them. They will usually lose. -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Mon, 7 Feb 2005, Chris Friesen wrote: Lee Revell wrote: On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote: It's not like somebody will have some innate commercial advantage over you because they have your driver source code. For a hardware vendor that's not a very compelling argument. Especially compared to what their IP lawyers are telling them. Got anything to back it up? I have a friend who works for a company that does reverse-engineering of ICs. Companies hire them to figure out how their competitor's chips work. This is the real threat to hardware manufacturers, not publishing the chip specs. Having driver code gives you the interface to the device. That can be reverse-engineered from watching bus traces or disassembling binary drivers (which is how many linux drivers were originally written). Companies have these kinds of resources. If you look at the big chip manufacturers (TI, Maxim, Analog Devices, etc.) they publish specs on everything. It would be nice if others did the same. Chris I also have first-hand knowledge. Once there was a company called Data Precision. Just point your favorite search-engine to that name. They were a wholly owned subsidiary of Analogic. They no longer exist. Data Precision would take a year or more to develop a product. Six weeks after it was available on the market, it would have been cloned by Pacific-rim companies and dumped into the US at below US manufacturing cost. Even Tektronix and Hewlett-Packard had these problems. What they did, to assure survival, was to create custom silicon and hide the inner-workings of everything. You can't even get a schematic anymore. Data Precision used to provide schematics so test equipment could be repaired. This resulted in the death of the division. The world is filthy with thieves. One of Data Precision's products had a 'glitch' in its spectrum analyzer display. This was because of a trade-secret method of performing a FFT that wasn't "exactly" a FFT, but good enough for a screen-display. This allowed fast screen updates (over 100 times per second) so that one could use the analyzer as a RF "sniffer" just like analog spectrum analyzers. Internally, the real FFT was performed so accurate readings could be made once somebody let the machine stabilize. Everything, including the glitch, was copied verbatum. The source-code wasn't made available, but the internal TMS320/C30 DSP was accessible using a IEEE serial port. They just sucked out the binary and used a disassembler to see where I/O was done, then just copied the binary directly. They didn't even need the source-code. The binary from one of the clones was identical to the binary from the original product, simply a copy. So companies that want to stay around for awhile don't devulge anything that will expedite the cloning of their hardware. It is particularly important where name recognition is meaningless. If you have a screen- card in your box that emulates your favorite vendor's screen card, do you care if it's a non-name clone as long as it works? Do you even know if your favorite vendor stole his design from somebody else in the first place? Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
Lee Revell wrote: On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote: It's not like somebody will have some innate commercial advantage over you because they have your driver source code. For a hardware vendor that's not a very compelling argument. Especially compared to what their IP lawyers are telling them. Got anything to back it up? I have a friend who works for a company that does reverse-engineering of ICs. Companies hire them to figure out how their competitor's chips work. This is the real threat to hardware manufacturers, not publishing the chip specs. Having driver code gives you the interface to the device. That can be reverse-engineered from watching bus traces or disassembling binary drivers (which is how many linux drivers were originally written). Companies have these kinds of resources. If you look at the big chip manufacturers (TI, Maxim, Analog Devices, etc.) they publish specs on everything. It would be nice if others did the same. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Wed, 2005-02-02 at 21:50 -0500, Kyle Moffett wrote: > It's not like somebody will have > some innate commercial advantage over you because they have your > driver source code. For a hardware vendor that's not a very compelling argument. Especially compared to what their IP lawyers are telling them. Got anything to back it up? Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Wed, 2005-02-02 at 19:07 -0500, Pavel Roskin wrote: > 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. Be very careful if distributing your driver in two parts -- a GPL'd part and a part which you claim is not affected by the GPL. If your non-GPL'd section is an independent and separate work in itself, then the GPL doesn't apply to it when it is distributed as a separate work. But if you distribute that same section as part of a whole which _is_ based on the kernel, then the distribution of the whole must be on the terms of the GPL. The GPL extends to the entire whole; to each and every part regardless of who wrote it. The intent of the GPL is to control the distribution of collective works based on the Program; not just derived works. You _really_ should consult a lawyer and make sure the final paragraphs of Â2 are taken into full consideration. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Thu, Feb 03, 2005 at 06:30:59AM -0600, Jonathan A. George wrote: >... > ** As noted previously it would be interested to see the opinion of a > U.S. IP lawyer who has conclusively tested the impact of copy right law > where the boundary of what constitutes a derivative work was explicitly > stated by a federal judge. >... Why is only the opinion of an US lawyer important? E.g. if you distribute something in Germany and a German kernel developer thinks the code you distribute violates the licence of a part of the kernel he has the copyright on German copyright law applies - and German copyright law is quite different from US copyright law. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Fri, 2005-02-04 at 01:20 -0800, Andrew Morton wrote: > Pavel Roskin <[EMAIL PROTECTED]> 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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
Pavel Roskin <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
Pavel Roskin wrote: 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. How about /proc/net/pavelStuff Still scriptable, and does not require GPL symbols Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Thu, Feb 03, 2005 at 03:12:59PM +, 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Wed, 2 Feb 2005, 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. 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. If the purpose is as you say, then it is illegal in the United States and probably elsewhere. It represents theft of intellectual property. I know something about modules. I created the first module-like interface so that I didn't have to reboot my system hundreds of times while I was working on one of the first SCSI drivers (the AH-1542 driver). Of course it was not as sophisticated as the existing system and it was designed to replace only one driver. It also couldn't replace it forever because it would run out of RAM (the existing driver was not removed). Nevertheless, this was the idea that started what Bas Laarhoven and Eric Youngdale developed. In principle, a software patent could probably have been obtained and I could have prevented Linux modules for 17 years. Instead, early motivation when Linus was still in college, was to help build an operating system that would destroy Microsoft. Everything we did was done for the sole purpose of replacing the predatory garbage that Microsoft was flooding into the market. Nothing I did was done under the auspices of Mr. Stallmen's so-called GNU Public License. In fact, I helped port lots of BSD utilities to Linux. The Linux API was designed to be exactly the same as BSD so it usually involved only a recompilation and fixing some syntax that was no longer considered correct by the newer compiler. While many of the Linux community were watching to see if Microsoft would steal its way into Linux, enter employees of IBM Corporation (read the current `insmod` man page for details). From time-to-time certain persons take what thousands have written in the past and attempt to regulate the use of those works. This was first done by the use of the "GPL" symbol which was required to exist within a module or else the entire kernel was marked "tainted" and considered to have been destroyed by a defective module, should anybody report a bug. This was touted as a "protection". Note how somebody set out to protect you from some problem you didn't know you had! Then, the entire module system was moved from user-mode code to inside the kernel. This was a quite obvious attempt to obfuscate the use of modules and create a logical wall where modules that did not propagate the GPL symbol conversion would not be allowed to work at all. However there are work-arounds. So the next-step has been to change all the exported symbols to symbols that can only be found in a artificial section created to further obfuscate interfacing with the kernel. This is the GPL only symbol theft that has now been planted within the kernel. I use the word theft in its true meaning. Further, the usurping of power from the Linux community as a whole to the individual(s) that have perpetrated this conversion could certainly be shown in a US court to be essentially the theft of intellectual property. This theft has occurred in little pieces, each so small that they tend to be ignored. The locking up of the Linux internals so that only those who ascribe to a particular political view may use these internals, could never be allowed, should these actions be brought before a United States Court. So, my advice to you is to do what you need to do. If anybody sues you or your company, you stand on solid moral ground, but on untouched legal ground since nobody has yet tested GPL and what it means within the courts. There are many work-arounds for the continuing theft of the Linux communities intellectual property. Linking with a "GPL" do-nothing object-file comes to mind. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EM
Re: Please open sysfs symbols to proprietary modules
> ...The EXPORT_SYMBOL_GPL is a license statement to binary module developers... As noted repeatedly a symbol prefix doesn't appear to carry any legal weight under U.S. law. In fact the GPL copyright notice is appear legally limited to the granting of *copy* *rights* per U.S. copyright law and specifically does _not_ appear to implicitly or explicitly create the kind of exceptions you seem to be looking for. > The one major stumbling block is that any code that imports symbols > that are exported via "EXPORT_SYMBOL_GPL" can only legally _export_ > symbols using the same, for the reason I stated above. The GPL as a *copy* *right* notice can apparently only apply obviously derivative works under U.S. law, and an independent driver created for a different OS is obviously _not_ a derivative work. Basically the attempt to create such a distinction does not appear to be supported by U.S. law as applied to the GPL. > If it's a non-GPL module it _cannot_ legally use EXPORT_SYMBOL_GPLed > symbols, either directly or indirectly, under any circumstances. Actually you can probably use any symbols you want since only the glue layer to the OS independent driver is would appear derivative of Linux, and since the glue layer appears to be derivative of two *independent* works (the OS and the Driver when done this way) you might need to license the glue layer in a way which is compatible with both works. The current BSD license could be a good choice in this instance. ** As noted previously it would be interested to see the opinion of a U.S. IP lawyer who has conclusively tested the impact of copy right law where the boundary of what constitutes a derivative work was explicitly stated by a federal judge. - P.S. Consider a kernel module which allows the use of a binary only MS-Windows driver in its unmodified stated. Could you actually consider the MS-Windows driver to be a derivative work of the Linux kernel by virtue of an intermediate glue module which was BSD licensed and made free use of all symbols? Would the Linux kernel be considered a derivative work of your motherboards firmware? These seem rather unlikely conclusions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
Zan Lynx wrote: 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? Well, it is ok because the proprietary FS in question does not access anything in the IDE layer. The VFS does not reexport ide symbols and interfaces. It is not a "workaround" for proprietary fs'es - someone who writes proper GPL code cannot simply take a shortcut, skip the VFS layer and have his GPL'ed fs drive the IDE layer directly. He'd end up with a stupid fs this way, one with artifical limitations such as being unable to work on SCSI too, and unable to cooperate properly with the VFS. If skipping some GPL glue layer is possible, technically convenient, better for performance but unfortunately illegal, then that is a strong hint that the glue layer itself may be an illegal circumvention device. In some countries, at least. The VFS however, is not a mere glue layer, it is an important subsystem of its own. Sitting between block devices and filesystems makes it a middle-man of course, but it is much more than that. 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. There is another alternative, which is to provide open drivers. The money is in pushing _hardware_, not drivers! And linux users are more likely to buy the hardware device with the open driver, rather than the device with the proprietary driver. So this is good for sales too. See the recent thread about a open hw graphichs card. Lots of people got interested, because of the "no secrets - *fully* documented" approach. Nobody really needs to be a "binary vendor". Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Feb 02, 2005, at 23:08, Jonathan A. George wrote: As an observation: The Linux kernel appears to contain the GPL copyright notice. This appears to explicitly releases the right to alter anything in a copy written work which shares that copyright notice. Therefore, all exported symbols would appear to carry equal weight; thus making the GPL_ prefix a notation of dubious value. The EXPORT_SYMBOL_GPL is a license statement to binary module developers that they are not allowed to use the code in question (by the author). Changing those is logically similar to changing the license header in a GPL licensed file from "Licensed under the GNU GPL v2 only" to "Licensed under the BSD license found here: http://somewhere/";. It just plain isn't legal to change those without the agreement of all contributors. Furthermore, it seems as if that the copyright might allow changing the GPL_ prefix notation to anything including BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL_ instead. You could legally change it as long as you document that the symbol "EXPORT_SYMBOL_BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL" really means that it's licensed under the GPL despite the confusing name, although even then you are at risk of the author calling foul. It also doesn't change the licensing restrictions on the symbols. It would seem just as surprising if the U.S. courts were to stop considering history of enforcement in copyright law as it would if they were to start considering in cases of patent law. One other thing, it technically _isn't_ legal to link any kind of binary module with the Linux kernel. The GPL actually indicates that "linking" *DOES* make a derivative work. However, Linus and basically all of the contributors have agreed that the current "EXPORT_SYMBOL" functions are ok for use by non-GPL modules, but they refuse to have hooks specifically there for closed-source modules, and usually require that most new innovative interfaces are "EXPORT_SYMBOL_GPL"ed instead. A paranoid approach it to develop your driver targeted at FreeBSD, and then develop a glue layer abstraction for porting to other OS's. Then you simply might GPL your glue layer code as a module using any symbols you want for your GPL copy written code per the observations earlier in this email. The one major stumbling block is that any code that imports symbols that are exported via "EXPORT_SYMBOL_GPL" can only legally _export_ symbols using the same, for the reason I stated above. In this way you will have created a work with no intrinsic dependencies on the Linux kernel which avoids presenting your work as an obvious target for those who prefer to spend their time looking for targets. :-) If it's a non-GPL module it _cannot_ legally use EXPORT_SYMBOL_GPLed symbols, either directly or indirectly, under any circumstances. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Wed, Feb 02, 2005 at 08:13:15PM -0500, Pavel Roskin wrote: > > I won't open all details, but suppose I want the bridge to handle certain > frames in a special way, just like BPDU frames are handled if STP is > enabled. There is a hook for that already - see br_handle_frame_hook. > The proprietary module would just have to change it. Why use Linux if you want to make a proprietary module? Why not use another operating system that is more suited toward such usage. The Linux kernel certainly is not such a system. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Please open sysfs symbols to proprietary modules
As an observation: The Linux kernel appears to contain the GPL copyright notice. This appears to explicitly releases the right to alter anything in a copy written work which shares that copyright notice. Therefore, all exported symbols would appear to carry equal weight; thus making the GPL_ prefix a notation of dubious value. Furthermore, it seems as if that the copyright might allow changing the GPL_ prefix notation to anything including BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL_ instead. It would seem just as surprising if the U.S. courts were to stop considering history of enforcement in copyright law as it would if they were to start considering in cases of patent law. (I would love to see the opinion of an IP lawyer who has conclusively tested these aspects of copyright law in court.) A paranoid approach it to develop your driver targeted at FreeBSD, and then develop a glue layer abstraction for porting to other OS's. Then you simply might GPL your glue layer code as a module using any symbols you want for your GPL copy written code per the observations earlier in this email. In this way you will have created a work with no intrinsic dependencies on the Linux kernel which avoids presenting your work as an obvious target for those who prefer to spend their time looking for targets. :-) P.S. Sorry about breaking mailer threading. :-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Wed, 2 Feb 2005 21:50:49 -0500, Kyle Moffett <[EMAIL PROTECTED]> wrote: > Please consider the benefits to GPL software ;-) Given his @gnu.org posts, I'd suggest he's between a rock and a hard place and can't just do that. Companies don't always understand these arguments :-) On the techical front, I think Pavel's stuck and will be forced to do something inelegant. Cheers, Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Feb 02, 2005, at 20:13, Pavel Roskin wrote: OK, then the "insufficiency" is inability to set and get additional named variables for network interfaces. I won't open all details, but suppose I want the bridge to handle certain frames in a special way, just like BPDU frames are handled if STP is enabled. There is a hook for that already - see br_handle_frame_hook. The proprietary module would just have to change it. What I want it to tell that module what to do with those special frames. I also want to get information like what was in the last special frame and how many of them have been received. In other words, I want the proprietary module to communicate with userspace. Ideally, the userspace application should be a simple shell script, so I'm reluctant to use ioctl. Why don't you just GPL your driver? It's not like somebody will have some innate commercial advantage over you because they have your driver source code. You might even have a commercial advantage by participating with GPL drivers because the community will help adjust them to in-kernel API changes too. Besides, you'll get cross-platform portability basically for free, as opposed to a binary-only driver for x86 where you can't use it on PPC, Alpha, etc. Please consider the benefits to GPL software ;-) Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
Hi, Joseph! On Wed, 2 Feb 2005, Joseph Pingenot wrote: From Pavel Roskin on Wednesday, 02 February, 2005: 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. Please pardon my ignorance, but if the existing network device management framework is insufficient, it seems that the optimal way to deal with this is to work with the community to address the insufficiencies, not hacking in a new interface to the device. OK, then the "insufficiency" is inability to set and get additional named variables for network interfaces. I won't open all details, but suppose I want the bridge to handle certain frames in a special way, just like BPDU frames are handled if STP is enabled. There is a hook for that already - see br_handle_frame_hook. The proprietary module would just have to change it. What I want it to tell that module what to do with those special frames. I also want to get information like what was in the last special frame and how many of them have been received. In other words, I want the proprietary module to communicate with userspace. Ideally, the userspace application should be a simple shell script, so I'm reluctant to use ioctl. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
>From Pavel Roskin on Wednesday, 02 February, 2005: >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. Please pardon my ignorance, but if the existing network device management framework is insufficient, it seems that the optimal way to deal with this is to work with the community to address the insufficiencies, not hacking in a new interface to the device. -Joseph -- [EMAIL PROTECTED] Graduate Student in Physics, Freelance Free Software Developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
On Wed, 2 Feb 2005, 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 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Please open sysfs symbols to proprietary modules
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/