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
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
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
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 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
--
Joseph===============================================trelane@digitasaru.net
Graduate Student in Physics, Freelance Free Software Developer
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
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
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
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------
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.
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. :-(
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]>
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
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------
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
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).
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
<snip>
> ...The EXPORT_SYMBOL_GPL is a license statement to binary module
developers...
<snip>
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.
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.
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
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
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
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.
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...
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
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
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
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
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.
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
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
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.
"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, Chile Fax: +56 32 797513
> 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
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?
[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
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.