Hi,
I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
I have found that I can't use SYSFS on Linux-2.6.10.
Why ?.
I am not modifing the Kernel/SYSFS code so I should be able, to use all
the SYSFS/internal kernel function calls without hinderence.
In order to be able to use SYSFS to debug the driver during development
the way I would like to be able to do, I will have to temporally change
the module licence line to "GPL". When the development is finnished I will
then need to remove all the code that accesses the SYSFS stuf in the
Kernel and change the module back to a "Proprietry" licence in order to
comply with other requirements. This will then hinder any debugging if
future issues arise.
I believe that this sort of idiocy is what helps Microsoft hold on to its
manopoly and as shuch hinders hardware/software development in all areas
and should be chanaged in a way that promotes diversified software
development.
Regards
Mark Fortescue.
On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
>
> I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> I have found that I can't use SYSFS on Linux-2.6.10.
>
> Why ?.
What ever gave you the impression that it was legal to create a
"Proprietry" kernel driver for Linux in the first place. I seriously
encourage you to consult your company's legal department if you insist
on attempting to do this, as they will be contacted by others after your
driver is released.
> I am not modifing the Kernel/SYSFS code so I should be able, to use all
> the SYSFS/internal kernel function calls without hinderence.
I'm sorry, but as you have found out, that is not possible.
> I believe that this sort of idiocy is what helps Microsoft hold on to its
> manopoly and as shuch hinders hardware/software development in all areas
> and should be chanaged in a way that promotes diversified software
> development.
If your company does not agree with the current license of the Linux
kernel, which prevents you from creating "Proprietry" drivers, then do
not write or create such drivers in the first place. We (the kernel
community) are not forcing you to write a Linux driver.
However, if you do wish to create a Linux driver, you _must_ abide by
the legal requirements of the kernel, which I feel, along with every IP
lawyer I have ever consulted, that it is not allowed to create a non-GPL
compatible kernel module.
Good luck,
greg k-h
On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote:
> On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
> >
> > I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> > I have found that I can't use SYSFS on Linux-2.6.10.
> >
> > Why ?.
>
> What ever gave you the impression that it was legal to create a
> "Proprietry" kernel driver for Linux in the first place.
The fact that Nvidia and ATI get away with it?
Lee
>> > I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
>> > I have found that I can't use SYSFS on Linux-2.6.10.
>> >
>> > Why ?.
>>
>> What ever gave you the impression that it was legal to create a
>> "Proprietry" kernel driver for Linux in the first place.
>
>The fact that Nvidia and ATI get away with it?
Sssh... don't give hints.
Jan Engelhardt
--
No TOFU for me, please.
On Sat, Mar 26, 2005 at 03:34:34PM -0500, Lee Revell wrote:
> On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote:
> > On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
> > >
> > > I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> > > I have found that I can't use SYSFS on Linux-2.6.10.
> > >
> > > Why ?.
> >
> > What ever gave you the impression that it was legal to create a
> > "Proprietry" kernel driver for Linux in the first place.
>
> The fact that Nvidia and ATI get away with it?
So, the fact that someone else is doing something illegal, makes it
acceptable for you to do the same thing? Please, talk to a lawyer about
this issue if you have _any_ questions.
And, to paraphrase Larry McVoy, if you can't afford to consult a proper
IP lawyer, then your IP isn't worth risking. Release it under the GPL
and you will have no problems.
thanks,
greg k-h
> So, the fact that someone else is doing something illegal, makes it
> acceptable for you to do the same thing? Please, talk to a lawyer
> about
> this issue if you have _any_ questions.
How is what they are doing illegal? How it is even "bad"? They obviously
can't give up their IP. Them providing binary modules wrapped in GPL
glue (so anyone can fix most kernel incompatabilities) is a good thing
for Linux. Many people and businesses would not be using Linux if they
did not do that.
Aaron
On Sat, 2005-03-26 at 17:15 -0800, Aaron Gyes wrote:
> > So, the fact that someone else is doing something illegal, makes it
> > acceptable for you to do the same thing? Please, talk to a lawyer
> > about
> > this issue if you have _any_ questions.
>
> How is what they are doing illegal? How it is even "bad"? They obviously
> can't give up their IP.
Many kernel developers feel that when people use their GPL'ed Linux code
with the binary drivers they are giving up their IP to Nvidia. That
argument is no less valid than Nvidia's.
Only a lawyer can answer the first question, and AFAIK there is not much
precedent in the area so it's especially important to get legal advice.
One would think Nvidia and ATI got the green light from their lawyers
before releasing the binary drivers, so who knows.
Lee
On Mar 26, 2005, at 20:15, Aaron Gyes wrote:
> How is what they are doing illegal? How it is even "bad"? They
> obviously
> can't give up their IP. Them providing binary modules wrapped in GPL
> glue (so anyone can fix most kernel incompatabilities) is a good thing
> for Linux. Many people and businesses would not be using Linux if they
> did not do that.
I think that at the moment the general consensus is that it is ok to use
the Linux kernel APIs (but not the EXPORT_SYMBOL_GPL ones) from binary
modules _if_ _and_ _only_ _if_ the driver was originally written
elsewhere
and ported to the Linux kernel. Otherwise it's a derivative work, and
must therefore be GPLed. Yes it's kinda draconian, but it's generally
been for the betterment of the Open Source community.
BTW, to all you "But my drivers must be proprietary!" nerds out there,
take a look at 3ware, Adaptec, etc. They have _great_ hardware and yet
they release all of their drivers under the GPL. They get free updates
to new kernel APIs too!
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 Sat, Mar 26, 2005 at 08:04:40PM -0500, Lee Revell wrote:
> On Sat, 2005-03-26 at 16:48 -0800, Greg KH wrote:
> > On Sat, Mar 26, 2005 at 03:34:34PM -0500, Lee Revell wrote:
> > > On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote:
> > > > On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
> > > > >
> > > > > I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> > > > > I have found that I can't use SYSFS on Linux-2.6.10.
> > > > >
> > > > > Why ?.
> > > >
> > > > What ever gave you the impression that it was legal to create a
> > > > "Proprietry" kernel driver for Linux in the first place.
> > >
> > > The fact that Nvidia and ATI get away with it?
> >
> > So, the fact that someone else is doing something illegal, makes it
> > acceptable for you to do the same thing? Please, talk to a lawyer about
> > this issue if you have _any_ questions.
> >
>
> Well, I never said I agreed with it. But the fact that major vendors do
> it flagrantly might lead someone to think it's not illegal. Why doesn't
> anyone do anything? Afraid they'll drop Linux support rather than find
> a way to open their drivers?
Probably just because no one has gotten around to sueing them just yet.
It's only a matter of time...
And no, I don't think anyone is "afraid" at all, that's just silly.
> Anyway, this is news to me. How about putting it in the FAQ? Too
> politically charged?
Why does it need to be in the FAQ, when the file COPYING in the main
kernel directory explicitly spells this out?
thanks,
greg k-h
On Sat, 2005-03-26 at 19:20 -0800, Greg KH wrote:
> > Anyway, this is news to me. How about putting it in the FAQ? Too
> > politically charged?
>
> Why does it need to be in the FAQ, when the file COPYING in the main
> kernel directory explicitly spells this out?
That's the problem, it's not spelled out explicitly anywhere. That file
does not address the issue of whether a driver is a "derived work".
This is the part he should talk to a lawyer about, right?
Lee
On Sat, 26 Mar 2005 at 10:28:28 -0800 Greg KH wrote:
> However, if you do wish to create a Linux driver, you _must_ abide by
> the legal requirements of the kernel, which I feel, along with every IP
> lawyer I have ever consulted, that it is not allowed to create a non-GPL
> compatible kernel module.
Creating a non-GPL kernel module is perfectly legal.
Distributing that module to a third party may not be legal, though.
--
Chuck
Lee wrote:
>> What ever gave you the impression that it was legal to create a
>> "Proprietry" kernel driver for Linux in the first place.
>
>The fact that Nvidia and ATI get away with it?
>
>
>
The didn't write a Linux driver. They have multi-platform drivers that
work among other OS on Linux, too.
E.g. the Nvidia binary ethernet driver can be used on both Linux and
FreeBSD, and I've heard that the .o file contains Windows specific
functions, thus it appears that Nvidia compiles the driver for all three
OS from one common code base.
At least for me, such a driver cannot be considered to be derived from
Linux, thus a non-GPL license is ok.
OTHO a driver that was written for Linux is in my opinion derived from
Linux and thus the GPL is mandatory.
Just speaking for myself,
--
Manfred
> BTW, to all you "But my drivers must be proprietary!" nerds out there,
> take a look at 3ware, Adaptec, etc. They have _great_ hardware and yet
> they release all of their drivers under the GPL. They get free updates
> to new kernel APIs too!
Well, it boils down to the full sourcecode. NVidia does only half.
Other good examples besides 3ware are: VMware kernel modules and
SUNWut/SRSS3 Linux Kernel modules.
Looks like there's only the GPU industry left that thinks somebody could
"mis"use the kmod to make them (:one company) inferior on the market.
Jan Engelhardt
--
No TOFU for me, please.
On Sat, March 26, 2005 12:52 pm, Mark Fortescue said:
> Hi,
>
> I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> I have found that I can't use SYSFS on Linux-2.6.10.
>
> Why ?.
Because the people that contributed the code you want to use said so.
> I am not modifing the Kernel/SYSFS code so I should be able, to use all
> the SYSFS/internal kernel function calls without hinderence.
You're creating a derived work that could not exist without all the GPL
code that came before.
> In order to be able to use SYSFS to debug the driver during development
> the way I would like to be able to do, I will have to temporally change
> the module licence line to "GPL". When the development is finnished I
> then need to remove all the code that accesses the SYSFS stuf in the
> Kernel and change the module back to a "Proprietry" licence in order to
> comply with other requirements. This will then hinder any debugging if
> future issues arise.
Likely this won't be enough to keep you or your company from being sued.
> I believe that this sort of idiocy is what helps Microsoft hold on to its
> manopoly and as shuch hinders hardware/software development in all areas
> and should be chanaged in a way that promotes diversified software
> development.
So what? The people that created the kernel GPL code weren't necessarily
trying to topple microsoft. In essense, all they said was they were
willing to share their code with people who were also willing to share.
You're probably better off writing your proprietary driver on a
proprietary operating system.
Sean
Previously Sean wrote:
> On Sat, March 26, 2005 12:52 pm, Mark Fortescue said:
> > In order to be able to use SYSFS to debug the driver during development
> > the way I would like to be able to do, I will have to temporally change
> > the module licence line to "GPL". When the development is finnished I
> > then need to remove all the code that accesses the SYSFS stuf in the
> > Kernel and change the module back to a "Proprietry" licence in order to
> > comply with other requirements. This will then hinder any debugging if
> > future issues arise.
>
> Likely this won't be enough to keep you or your company from being sued.
Are you sure? It is perfectly legal to relicense things if you own the
copyright. As long as he never distributes his GPL version I don't see
why he should have a problem.
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
On Sad, 2005-03-26 at 20:34, Lee Revell wrote:
> > What ever gave you the impression that it was legal to create a
> > "Proprietry" kernel driver for Linux in the first place.
>
> The fact that Nvidia and ATI get away with it?
The choose to take a risk based upon a specific interpretation of the
boundary of a derivative work. Since the boundary is untested in law its
not certain who is right.
Alan
On Sul, 2005-03-27 at 14:53, Wichert Akkerman wrote:
> Are you sure? It is perfectly legal to relicense things if you own the
> copyright. As long as he never distributes his GPL version I don't see
> why he should have a problem.
The GPL is a distribution license, it doesn't really matter what you do
*internally* with GPL code. It might be a DMCA violation in the USSA but
thats because the law is broken.
Alan
On Sun, Mar 27, 2005 at 10:57:13AM +0200, Jan Engelhardt wrote:
> > BTW, to all you "But my drivers must be proprietary!" nerds out there,
> > take a look at 3ware, Adaptec, etc. They have _great_ hardware and yet
> > they release all of their drivers under the GPL. They get free updates
> > to new kernel APIs too!
>
> Well, it boils down to the full sourcecode. NVidia does only half.
> Other good examples besides 3ware are: VMware kernel modules and
> SUNWut/SRSS3 Linux Kernel modules.
>
> Looks like there's only the GPU industry left that thinks somebody could
> "mis"use the kmod to make them (:one company) inferior on the market.
Probably because it's true. What if everyone could notice that they are
cheating such as rendering one inferior frame every other frame or things
like this to increase performance ? Afterall, opensource also prevents you
from cheating, or at least lets others fix your "bugs".
Willy
On Mar 27, 2005, at 03:49, Arjan van de Ven wrote:
>> I think that at the moment the general consensus is that it is ok to
>> use
>> the Linux kernel APIs (but not the EXPORT_SYMBOL_GPL ones) from binary
>> modules _if_ _and_ _only_ _if_ the driver was originally written
>> elsewhere
>> and ported to the Linux kernel.
>
> I disagree there. Only a few copyright holders of the kernel suggested
> that "previously written elsewhere" would be an exception. I haven't,
> Alan Cox has been very vocal about that he hasn't. I've not seen my
> employer say that it would make that exception either.
>
> And it's a gray area.
> Is it ok if you have 5000 lines from another OS and 0 specific/modified
> for linux (the technical impossibility of this aside)
> Is 4990/10 still good?
> is 4900/100 still good ?
> is 4500/500 still good ?
> is 4000/1000 still good ?
> is 2500/2500 still good ?
> is 2000/3000 still good ?
> is 500/4500 still good ?
>
> if anyone thinks this is a loophole their lawyers better have an answer
> for this...
>
> (and note that I'm not claiming that those 4500 lines are a derived
> work
> when used elsewhere. But I do consider it a derived work if it's in a
> binary form where it does include linux specific code, and even code
> from the linux kernel via say inlines).
<flame type="Binary Driver Hatred">
NOTE: I *strongly* discourage binary drivers. They're crap and
frustrate
poor PowerPC users like me. Since this is purely a theoretical
discussion,
and I want to discourage binary crud, this email is Copyrighted:
This email is Copyright (C) 2005 Kyle Moffett.
The remainder of this email is available under the GNU General Public
License, version 2. See http://www.gnu.org/licenses/gpl.txt for
details.
THE BELOW MAY NOT BE USED IN A BINARY DRIVER, SO DON'T EVEN THINK ABOUT
IT!
</flame>
Ok, so what if the _driver_ provides an API like this:
int start_driver(void);
int stop_driver(void);
void register_alloc(void *(*alloc)(unsigned long));
void register_free(void (*free)(void *));
[... more register functions here, generic functionality ...]
And a BSD licensed bit of glue based on that interface that connects the
driver to a dozen different OSen by wrapping or using their interfaces
directly.
Do you think _that's_ legal? As far as I can see, even that level is
iffy, but it's a murky issue, and I doubt it will be decided one way or
another until people test it in various courts.
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------
>
> This email is Copyright (C) 2005 Kyle Moffett.
>
> The remainder of this email is available under the GNU General Public
> License, version 2. See http://www.gnu.org/licenses/gpl.txt for
> details.
> THE BELOW MAY NOT BE USED IN A BINARY DRIVER, SO DON'T EVEN THINK ABOUT
> IT!
> </flame>
>
> Ok, so what if the _driver_ provides an API like this:
>
> int start_driver(void);
> int stop_driver(void);
> void register_alloc(void *(*alloc)(unsigned long));
> void register_free(void (*free)(void *));
> [... more register functions here, generic functionality ...]
>
#GPL this e-mail my first C program,..
int main(int argc, char **argv)
{
}
damn every C program is a derived work.. it just means you need to get
a better lawyer... more than likely American courts will be involved..
I suggest the Chewbacca defence[1] will work if you can pay enough
money....
Dave.
[1] http://en.wikipedia.org/wiki/Chewbacca_defence
On Mar 27, 2005, at 12:52, Dave Airlie wrote:
> #GPL this e-mail my first C program,..
> int main(int argc, char **argv)
> {
> }
>
> damn every C program is a derived work.. it just means you need to get
> a better lawyer... more than likely American courts will be involved..
> I suggest the Chewbacca defence[1] will work if you can pay enough
> money....
Well, independently developed code is just that, independent. I don't
care if somebody does something similar (aside from the fact that it
pisses me off WRT binary drivers), I just don't want anybody to think
my email is a clear way to dodge around the GPL, because it isn't :-D.
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------
* Kyle Moffett ([email protected]) wrote:
> <flame type="Binary Driver Hatred">
> NOTE: I *strongly* discourage binary drivers. They're crap and
> frustrate poor PowerPC users like me.
I mostly agree - there is one case where I think they *might*
be acceptable; (and I think the original poster *may* fall
into this category).
If you are making a very specialist piece of equipment; not
the type of thing you can go and plug into any old PC; but
say an entire box with some obscure piece of hardware in
that no one would want to buy as a seperate add on. I just
don't see the need to force someone to make drivers for
this type of thing public.
Of course the poster could just go and use one of the BSDs
which is probably his safest bet.
Dave
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Sat, Mar 26, 2005 at 09:55:33PM -0500, Kyle Moffett wrote:
> On Mar 26, 2005, at 20:15, Aaron Gyes wrote:
> >How is what they are doing illegal? How it is even "bad"? They
> >obviously
> >can't give up their IP. Them providing binary modules wrapped in GPL
> >glue (so anyone can fix most kernel incompatabilities) is a good thing
> >for Linux. Many people and businesses would not be using Linux if they
> >did not do that.
>
> I think that at the moment the general consensus is that it is ok to use
> the Linux kernel APIs (but not the EXPORT_SYMBOL_GPL ones) from binary
> modules _if_ _and_ _only_ _if_ the driver was originally written
> elsewhere and ported to the Linux kernel. Otherwise it's a derivative
> work, and must therefore be GPLed. Yes it's kinda draconian, but it's
> generally been for the betterment of the Open Source community.
No, that is not the general consensus at all. Please search the
archives and the web for summaries of this discussion topic the last
time it came up.
greg k-h
On Sat, Mar 26, 2005 at 10:30:20PM -0500, Lee Revell wrote:
> On Sat, 2005-03-26 at 19:20 -0800, Greg KH wrote:
> > > Anyway, this is news to me. How about putting it in the FAQ? Too
> > > politically charged?
> >
> > Why does it need to be in the FAQ, when the file COPYING in the main
> > kernel directory explicitly spells this out?
>
> That's the problem, it's not spelled out explicitly anywhere. That file
> does not address the issue of whether a driver is a "derived work".
> This is the part he should talk to a lawyer about, right?
How about the fact that when you load a kernel module, it is linked into
the main kernel image? The GPL explicitly states what needs to be done
for code linked in.
Also, realize that you have to use GPL licensed header files to build
your kernel module...
greg k-h
On Sun, Mar 27, 2005 at 07:04:17PM +0100, Dr. David Alan Gilbert wrote:
> * Kyle Moffett ([email protected]) wrote:
>
> > <flame type="Binary Driver Hatred">
> > NOTE: I *strongly* discourage binary drivers. They're crap and
> > frustrate poor PowerPC users like me.
>
> I mostly agree - there is one case where I think they *might*
> be acceptable; (and I think the original poster *may* fall
> into this category).
>
> If you are making a very specialist piece of equipment; not
> the type of thing you can go and plug into any old PC; but
> say an entire box with some obscure piece of hardware in
> that no one would want to buy as a seperate add on. I just
> don't see the need to force someone to make drivers for
> this type of thing public.
>...
And then the user want to upgrade the 2.0 kernel that shipped with this
box although the company that made the hardware went bankrupt some years
ago.
If the user has the source of the driver, he can port the driver or hire
someone to port the driver (this "obscure piece of hardware" might also
be an expensive piece of hardware).
Or if the driver is in the kernel sources, it might have even been
ported.
> Dave
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
>> If you are making a very specialist piece of equipment; not
>>...
>
>
>If the user has the source of the driver, he can port the driver or hire
>someone to port the driver (this "obscure piece of hardware" might also
>be an expensive piece of hardware).
I am happy that nvidia (to name one) provides at least the source to its
glue... here's a real world example:
http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/52002e4f6d454e44/216311fff8f7c91b?rnum=1
could have been worse, but also could have been better, though.
> And then the user want to upgrade the 2.0 kernel that shipped with this
> box although the company that made the hardware went bankrupt some years
> ago.
>
> If the user has the source of the driver, he can port the driver or hire
> someone to port the driver (this "obscure piece of hardware" might also
> be an expensive piece of hardware).
So what? Sure, GPL'd drivers are easier for an end-user in that case.
What does that have to do with law? What about what's better for the
company that made the device? Should NVIDIA be forced to give up their
secrets to all their competitors because some over zealous developers
say so? Should the end-users of the current drivers be forced to lose
out on features such as sysfs and udev compatability?
I love Linux, and a I love that free software has become mildly
successful, but the zealots are hurting both.
On Mar 27, 2005, at 14:16, Aaron Gyes wrote:
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law?
Well, under most interpretations of the GPL, you are *NOT* allowed to
even _link_ non-GPL code with GPL code. (Basically, by distributing such
a linked binary, you are certifying that you have permission to GPL the
entire source-code and are doing so.
> What about what's better for the company that made the device?
Who says that free maintenance and bugfixes *isn't* better for said
company?
> Should NVIDIA be forced to give up their secrets to all their
> competitors because some over zealous developers say so?
We don't care about their secrets, we just want to be able to interface
with their hardware. Really, we don't care how the hardware does what
it does internally, we just care how to tell it to do that. It's the
difference between telling an artist to paint a big picture and
watching every thought he makes while he does the painting with a brain
scanner.
> Should the end-users of the current drivers be forced to lose out
> on features such as sysfs and udev compatability?
Should the end-users even *have* features such as sysfs and udev? If
the *open-source* developers hadn't *opened* their *source*, then that
code wouldn't exist. One condition they made when they gave that code
for free was that *only* people who also gave their code for free
could use it.
> I love Linux, and a I love that free software has become mildly
> successful, but the zealots are hurting both.
On the contrary, the zealots are what protect us from the even worse
proprietary software zealots. You may not agree with them, but if
there were only one kind of zealot then the world would be much
worse off.
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 Sun, Mar 27, 2005 at 11:16:54AM -0800, Aaron Gyes wrote:
> > And then the user want to upgrade the 2.0 kernel that shipped with this
> > box although the company that made the hardware went bankrupt some years
> > ago.
> >
> > If the user has the source of the driver, he can port the driver or hire
> > someone to port the driver (this "obscure piece of hardware" might also
> > be an expensive piece of hardware).
>
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law? What about what's better for the
I wasn't talking about legal issues.
I was answering Dave's "very specialist piece of equipment" opinion.
And my point was that even in this case it's better for the user to have
the source.
> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose
> out on features such as sysfs and udev compatability?
>
> I love Linux, and a I love that free software has become mildly
> successful, but the zealots are hurting both.
There are many bug reports to linux-kernel that are undebuggable because
they involve the nvidia binary-only module.
I do personally know several people who use the nvidia binary-only
modules and have as a result experienced stability problems on their
computer. Linux has an IMHO justified reputation for being stable.
Users experiencing system stability problems due to binary-only modules
might wrongfully attribute them to Linux harming the reputation of
Linux.
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
Mark Fortescue wrote:
> Hi,
>
> I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> I have found that I can't use SYSFS on Linux-2.6.10.
>
> Why ?.
>
> I am not modifing the Kernel/SYSFS code so I should be able, to use all
> the SYSFS/internal kernel function calls without hinderence.
>
> In order to be able to use SYSFS to debug the driver during development
> the way I would like to be able to do, I will have to temporally change
> the module licence line to "GPL". When the development is finnished I will
> then need to remove all the code that accesses the SYSFS stuf in the
> Kernel and change the module back to a "Proprietry" licence in order to
> comply with other requirements. This will then hinder any debugging if
> future issues arise.
>
> I believe that this sort of idiocy is what helps Microsoft hold on to its
> manopoly and as shuch hinders hardware/software development in all areas
> and should be chanaged in a way that promotes diversified software
> development.
>
> Regards
> Mark Fortescue.
>
>
If you wish to keep stuff secret, just don't bother with Linux drivers
for it. Use your PCI card in windows or some other system. Linux is
supposed to be open source...live with it.
El Sun, 27 Mar 2005 11:16:54 -0800,
Aaron Gyes <[email protected]> escribi?:
> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose
Is not just about zealotism, propietary drivers have to deal with locking, multiple
architectures and so on, and often they're not very good at that.
Note that this is not a problem only with linux, Windows is suffering the same
every day. Here: http://blogs.msdn.com/oldnewthing/archive/2004/03/05/84469.aspx
is a good example of how *scary* can be. This is what happens in a OS where a
certification process is needed. I don't want to know what are they doing in linux,
where such certification doesn't exist.....
On Sun, 2005-03-27 at 10:10 -0800, Greg KH wrote:
> How about the fact that when you load a kernel module, it is linked into
> the main kernel image? The GPL explicitly states what needs to be done
> for code linked in.
>
I've always wondered about dynamically loaded modules (and libraries for
that matter). The standard IANAL, but I've talked to many to try to
understand what is really legal, and I usually come up with the
conclusion, it's just an interpretation of the law by the judge.
If the user is loading the module (or library) and the distributer
doesn't, then is the the user breaking the license and not the
distributer?
> Also, realize that you have to use GPL licensed header files to build
> your kernel module...
>
Wasn't this long ago proven in court that the license of headers can't
control the code that calls them. IIRC, it was with X Motif and making
free libraries for that. So, actually it was for a free solution for a
non free one (the other way around). I believe the case sided on the
free use. But then again the free code may have had to write their own
headers and only the API was free. So if you want to compile against the
kernel, you may need to work on rewriting the headers from scratch. Ah,
but what do I know?
My code usually falls under something like LGPL. Link with what you
want, but keep any changes to my code open. I know that this is not the
stance of the kernel and I respect that. But I'm still waiting for the
day in court that talks about dynamic modules and libraries.
-- Steve
On Sun, Mar 27, 2005 at 01:37:11PM -0500, Steven Rostedt wrote:
>...
> Wasn't this long ago proven in court that the license of headers can't
> control the code that calls them. IIRC, it was with X Motif and making
> free libraries for that. So, actually it was for a free solution for a
> non free one (the other way around). I believe the case sided on the
> free use. But then again the free code may have had to write their own
> headers and only the API was free. So if you want to compile against the
> kernel, you may need to work on rewriting the headers from scratch. Ah,
> but what do I know?
>...
How do you define "proven in court"?
Decided by an US judge based on US laws?
Decided by a German judge based on German laws?
Decided by a Chinese judge based on Chinese laws?
...
If you distribute software you can be sued in every country you
distribute it.
E.g. Harald Welte is currently quite successful with legal actions in
Germany against companies that distribute Linux-based routers in Germany
without offering the source of the GPL'ed software they use.
> -- Steve
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
> > How about the fact that when you load a kernel module, it is linked into
> > the main kernel image? The GPL explicitly states what needs to be done
> > for code linked in.
> >
> I've always wondered about dynamically loaded modules (and libraries for
> that matter). The standard IANAL, but I've talked to many to try to
> understand what is really legal, and I usually come up with the
> conclusion, it's just an interpretation of the law by the judge.
>
> If the user is loading the module (or library) and the distributer
> doesn't, then is the the user breaking the license and not the
> distributer?
I think this is probably what the lawyers are telling the graphics
card companies at the moment, the GPL is broken by the act of linking
and at what stage is the link considered to have happened, so if I
distribute a GPL or BSD licensed stub layer in source form, a big
binary blob that doesn't use any kernel interfaces except my stub
layer ones, and never distribute any of it with a kernel or linked
into anything, am I breaking the GPL on the kernel? all I'm doing is
releasing some source code and some binary image files, the user is
doing the linking by loading my code into their running kernel and
I'm not distributing my code with the kernel...
It'll be an interesting day in court... and maybe then derived work
will become nicely defined at least for one country....
Dave.
On Sun, Mar 27, 2005 at 11:16:54AM -0800, Aaron Gyes wrote:
> > And then the user want to upgrade the 2.0 kernel that shipped with this
> > box although the company that made the hardware went bankrupt some years
> > ago.
> >
> > If the user has the source of the driver, he can port the driver or hire
> > someone to port the driver (this "obscure piece of hardware" might also
> > be an expensive piece of hardware).
>
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law? What about what's better for the
> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose
> out on features such as sysfs and udev compatability?
It's not zealotry, it's called being compliant with the license of the
kernel. It's as simple as that.
If you ignore the license, you will suffer the consequences of it, just
like if you ignore the license of any closed source chunk of software.
Would you expect the owner of that software to turn a blind eye toward
violators?
greg k-h
On Mon, 2005-03-28 at 00:01 +0200, Adrian Bunk wrote:
> On Sun, Mar 27, 2005 at 01:37:11PM -0500, Steven Rostedt wrote:
> >...
> > Wasn't this long ago proven in court that the license of headers can't
> > control the code that calls them. IIRC, it was with X Motif and making
> > free libraries for that. So, actually it was for a free solution for a
> > non free one (the other way around). I believe the case sided on the
> > free use. But then again the free code may have had to write their own
> > headers and only the API was free. So if you want to compile against the
> > kernel, you may need to work on rewriting the headers from scratch. Ah,
> > but what do I know?
> >...
>
> How do you define "proven in court"?
>
> Decided by an US judge based on US laws?
> Decided by a German judge based on German laws?
> Decided by a Chinese judge based on Chinese laws?
> ...
>
OK, I was talking about US courts since that case was done in the US.
But this is all what I remember about reading some 10 years ago. So I
could be all wrong about what happened. I don't have any references and
I'm too busy now to look them up. So I may be just speaking out of my
ass. :-)
> If you distribute software you can be sued in every country you
> distribute it.
>
> E.g. Harald Welte is currently quite successful with legal actions in
> Germany against companies that distribute Linux-based routers in Germany
> without offering the source of the GPL'ed software they use.
Your talking about something completely different. Yes, it is quite
explicit if you modify the source, and distribute it in binary only
form. I'm talking about writing a separate module that links with the
GPL code dynamically. So that the code is compiled different from the
GPL code. So the only common part is the API. Now is this a derived
work?
As someone mentioned already, if you write your own GPL interface that
supplies the interface for your binary module, is it legal? The GPL
interface remains GPL and delivered with the source, but the binary is
only delivered binary, and may even be on a separate CD or whatever
medium you distribute with. Just like NVidia. They have their GPL layer
that compiles with the kernel and it supplies an interface for their
binary only version. I haven't seen anyone take them to court. Just a
lot of complaints about incompatibilities and tainted kernels on the
mailing list, but nothing more.
-- Steve
On Sun, Mar 27, 2005 at 10:10:56AM -0800, Greg KH wrote:
> How about the fact that when you load a kernel module, it is linked
> into the main kernel image? The GPL explicitly states what needs to
> be done for code linked in.
oddly, the close nv driver has like 2.4MB if text in the kernel. i
suspect a good chunk of this really should be in userspace but
probably lives in the kernel because 'the windows driver does that'
if the in-kernel part was trimmed down it would be nice for nv to move
the resource manager and whatever else lives in their gigantic module
(larger than most kernels!) to userspace and side-step the entire
issue completely
> Also, realize that you have to use GPL licensed header files to
> build your kernel module...
people could make their own. i'm not sure if anyone has though.
greg k-h writes:
> On Sat, Mar 26, 2005 at 10:30:20PM -0500, Lee Revell wrote:
>> That's the problem, it's not spelled out explicitly anywhere.
>> That file does not address the issue of whether a driver is
>> a "derived work". This is the part he should talk to a lawyer
>> about, right?
>
> How about the fact that when you load a kernel module, it is
> linked into the main kernel image? The GPL explicitly states
> what needs to be done for code linked in.
This probably fails. Obviously, it's not over until the courts
say so, but...
First of all, the GPL might not be as infectious as you and RMS
wish it to be. There is a limit to what can be a derived work
in copyright law.
Second of all, module loading is not the same as "linking" in
the traditional sense. The GPL was written before Linux had
kernel modules. Don't be so sure a court would rule as you
would like it to rule.
> Also, realize that you have to use GPL licensed header files
> to build your kernel module...
Um, like the printer cartridges and game cartridges with code
in them? Courts have held that it was OK to copy because it was
needed to implement an interface.
Whatever your lawyer may have said was undoubtably influenced
by your biased attempt to describe the technical issues.
Not that I care for proprietary stuff, being a PowerPC user
myself, but spreading unjustified FUD isn't proper behavior.
Neither is it proper to be marking key driver interfaces as
GPL-only. It's far better to just ignore the proprietary stuff.
On Sun, Mar 27, 2005 at 06:54:52PM -0500, Steven Rostedt wrote:
> On Mon, 2005-03-28 at 00:01 +0200, Adrian Bunk wrote:
> >
> > How do you define "proven in court"?
> >
> > Decided by an US judge based on US laws?
> > Decided by a German judge based on German laws?
> > Decided by a Chinese judge based on Chinese laws?
> > ...
> >
>
> OK, I was talking about US courts since that case was done in the US.
> But this is all what I remember about reading some 10 years ago. So I
> could be all wrong about what happened. I don't have any references and
> I'm too busy now to look them up. So I may be just speaking out of my
> ass. :-)
>
> > If you distribute software you can be sued in every country you
> > distribute it.
> >
> > E.g. Harald Welte is currently quite successful with legal actions in
> > Germany against companies that distribute Linux-based routers in Germany
> > without offering the source of the GPL'ed software they use.
>
> Your talking about something completely different. Yes, it is quite
> explicit if you modify the source, and distribute it in binary only
> form. I'm talking about writing a separate module that links with the
> GPL code dynamically. So that the code is compiled different from the
> GPL code. So the only common part is the API. Now is this a derived
> work?
>...
My point was a bit different:
Harald's action was meant as an example, that such things can be brought
to court in virtually every country in the world.
And a court decision in e.g. the USA might not have any influence on a
court decision in e.g. Germany.
Some people seem to think that it was enough if something was OK
according to US law - but that's simply wrong.
> -- Steve
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 Mon, 2005-03-28 at 03:39 +0200, Adrian Bunk wrote:
> > Your talking about something completely different. Yes, it is quite
> > explicit if you modify the source, and distribute it in binary only
> > form. I'm talking about writing a separate module that links with the
> > GPL code dynamically. So that the code is compiled different from the
> > GPL code. So the only common part is the API. Now is this a derived
> > work?
> >...
>
> My point was a bit different:
>
> Harald's action was meant as an example, that such things can be brought
> to court in virtually every country in the world.
>
> And a court decision in e.g. the USA might not have any influence on a
> court decision in e.g. Germany.
>
> Some people seem to think that it was enough if something was OK
> according to US law - but that's simply wrong.
>
I understand this quite well since I do business in both the US and
Germany. But I do find the courts quite similar too, from reading the
newspapers in both countries. But even in the US, things differ from
one court to the next. Anyway, the problem the GPL may have with
dynamic loading is that the loading is done by the user and not the
distributer, which is who the GPL states is under the obligation of the
license.
Tsch?ss,
-- Steve
>> The fact that Nvidia and ATI get away with it?
>
> The choose to take a risk based upon a specific interpretation of the
> boundary of a derivative work. Since the boundary is untested in law its
> not certain who is right.
Plus the fact, that if somebody sues them, they just remove the drivers
from their list. Linux is so small for them, that probably don't care (plus
there is an open source nv & ati driver).
[ Clemens Schwaighofer -----=====:::::~ ]
[ TBWA\ && TEQUILA\ Japan IT Group ]
[ 6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp http://www.tbwajapan.co.jp ]
Kyle Moffett <[email protected]> said:
> On Mar 27, 2005, at 14:16, Aaron Gyes wrote:
> > So what? Sure, GPL'd drivers are easier for an end-user in that case.
> > What does that have to do with law?
> Well, under most interpretations of the GPL, you are *NOT* allowed to
> even _link_ non-GPL code with GPL code. (Basically, by distributing such
> a linked binary, you are certifying that you have permission to GPL the
> entire source-code and are doing so.
Wrong. You are free to do whatever you like in the privacy of your home,
but not distribute the result. So you could very well distribute both
pieces, one under GPL, the other not, and leave the linking to the end
user.
Sure, /creating/ the piece to be linked with the GPLed code might make it
GPL also, but that is another story.
> > What about what's better for the company that made the device?
> Who says that free maintenance and bugfixes *isn't* better for said
> company?
Not me. But it is not the only consideration involved.
> > Should NVIDIA be forced to give up their secrets to all their
> > competitors because some over zealous developers say so?
nVidia doesn't want to tell, that is their decision to make. If they don't
tell, Linux users don't get to use nVidia cards with OSS drivers. Both
sides loose something, nVidia thinks (right or wrong) that what they loose
this way is less than what they'd loose by opening up.
> We don't care about their secrets, we just want to be able to interface
> with their hardware. Really, we don't care how the hardware does what
> it does internally, we just care how to tell it to do that. It's the
> difference between telling an artist to paint a big picture and
> watching every thought he makes while he does the painting with a brain
> scanner.
That the "Linux kernel community" (whoever that might be) doesn't care
doesn't mean others wouldn't consider mining the Linux drivers for any data
on their competition.
> > Should the end-users of the current drivers be forced to lose out
> > on features such as sysfs and udev compatability?
> Should the end-users even *have* features such as sysfs and udev? If
> the *open-source* developers hadn't *opened* their *source*, then that
> code wouldn't exist. One condition they made when they gave that code
> for free was that *only* people who also gave their code for free
> could use it.
Grey area... it could be argued that this is /public/ interfase to the
kernel, and as such shouldn't be closed off.
> > I love Linux, and a I love that free software has become mildly
> > successful, but the zealots are hurting both.
> On the contrary, the zealots are what protect us from the even worse
> proprietary software zealots. You may not agree with them, but if
> there were only one kind of zealot then the world would be much
> worse off.
As long as the opposing zealots keep each other in check... ;-)
--
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
>> > Should NVIDIA be forced to give up their secrets to all their
>> > competitors because some over zealous developers say so?
>
>nVidia doesn't want to tell, that is their decision to make.
Well, they /could/, as to prove they are not cheating...(if they really don't)
>> > How do you define "proven in court"?
>> >
>> > Decided by an US judge based on US laws?
>> > Decided by a German judge based on German laws?
>> > Decided by a Chinese judge based on Chinese laws?
>> > ...
>>
>> OK, I was talking about US courts since that case was done in the US.
>And a court decision in e.g. the USA might not have any influence on a
>court decision in e.g. Germany.
I got a different impression. The US has "the biggest houses, the biggest
cars, ..." (Supersize me), so if something happens in the US, other countries
watch it more closely as if it was the other way round.
Jan Engelhardt
--
No TOFU for me, please.
On Sun, 2005-03-27 at 21:54 -0400, Horst von Brand wrote:
> Wrong. You are free to do whatever you like in the privacy of your home,
> but not distribute the result. So you could very well distribute both
> pieces, one under GPL, the other not, and leave the linking to the end
> user.
>
> Sure, /creating/ the piece to be linked with the GPLed code might make it
> GPL also, but that is another story.
Actually this is an easy one. If you are the creator of the code, you
can license it anyway you want. So you can make it both GPL and allow it
to link with your code. Heck, put it under LGPL since GPL is allowed to
link to that.
Anyway, I don't think that the GPL is that powerful to affect things not
linked directly with it. Just like the MS license can't make you do
certain things that were stated in the license, the GPL can't take too
much control over what you do. If something in the license is
reasonable, than it is easy to enforce (like taking the code from GPL
source and using it in a binary) but if it starts to stretch (like
controlling the code you write and how you can use it) then that will
have to be fought in court, and will probably lose.
-- Stev
On Sun, 27 Mar 2005, Alan Cox wrote:
> On Sul, 2005-03-27 at 14:53, Wichert Akkerman wrote:
> > Are you sure? It is perfectly legal to relicense things if you own the
> > copyright. As long as he never distributes his GPL version I don't see
> > why he should have a problem.
>
> The GPL is a distribution license, it doesn't really matter what you do
> *internally* with GPL code. It might be a DMCA violation in the USSA but
^^^^
Is this a plain stupid typo, or am I missing a new joke? ;-(
> thats because the law is broken.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 28 Mar 2005, Steven Rostedt wrote:
> On Sun, 2005-03-27 at 21:54 -0400, Horst von Brand wrote:
>
>> Wrong. You are free to do whatever you like in the privacy of your home,
>> but not distribute the result. So you could very well distribute both
>> pieces, one under GPL, the other not, and leave the linking to the end
>> user.
>>
>> Sure, /creating/ the piece to be linked with the GPLed code might make it
>> GPL also, but that is another story.
>
> Actually this is an easy one. If you are the creator of the code, you
> can license it anyway you want. So you can make it both GPL and allow it
> to link with your code. Heck, put it under LGPL since GPL is allowed to
> link to that.
>
> Anyway, I don't think that the GPL is that powerful to affect things not
> linked directly with it. Just like the MS license can't make you do
> certain things that were stated in the license, the GPL can't take too
> much control over what you do. If something in the license is
> reasonable, than it is easy to enforce (like taking the code from GPL
> source and using it in a binary) but if it starts to stretch (like
> controlling the code you write and how you can use it) then that will
> have to be fought in court, and will probably lose.
>
> -- Stev
Shims are used everywhere to interface with strange, incompatible,
or otherwise difficult to interface operating systems. If Linux
is too difficult or incompatible, use a shim.
In its simplest form, a shim might be a separate object containing
only the GPL license, linked with the difficult-to-interface code.
Don't jump on me yet. Read on.
In its most complicated form, the shim-file might contain some
pointers, statically initialized to GPL-only symbols, and additional
public symbols with which that your code interfaces.
In any event, you can do anything you want in the privacy of your
own bedroom, in most all countries except, perhaps, Cuba. The problems
come about when you try to sell a product, a portion of which was
designed by somebody who wanted his works to be forever "free". The
solution to this is to simply add the code that the "hold-out"
prevented you from using, to your code. Certainly, given the
complete source-code, you could come up with a perfect emulation
that doesn't copy a single line. In fact, given the time, you
could emulate all of Linux because you have the source-code
available.
To me, the fact that you want to interface with symbols that
the writer wanted to restrict, means that you want the writer
to do your work and not get paid. Perhaps you are just too
lazy to do your own thing and expect that something that
already exists should surely be freely available so you can
make money from it. Not so. I certainly am not allowed to
pick my neighbor's flowers (GPL symbols) simply because
they are where I can see them.
Of course there is the other side of the coin. I've seen
persons who had nothing at all to do with the writing of
some code, decide on their own, that its symbols are now
GPL-only symbols. Funny how they seem to know the intention
of some writer who wrote some code, left his mark, then
traveled on.
This "GPL" junk will continue forever. There is no way to
fight it. It's become a religion. If you want to write
drivers for Linux, they really must contain the GPL License
and you really need to make the source-code available. If
your "trade secrets" are really that "secret", they won't
be in a month or two, notwithstanding what the lawyers say.
Following the flock in this GPL issue insulates you from
many future changes in the kernel. Major portions of the
module code has already been rewritten to erect a solid
barrier, marking what's in the kernel and what's without.
What used to be done outside the kernel, the only reasonable
place to do it, has now been moved inside the kernel for no
other reason but isolation.
So tell your senior staff that you need to include the
GPL license with your code. If you write good code, the
chances of anybody outside your company actually reading
it is near zero. If your "trade secrets" are so obvious
that a look at the code will reveal them, you really need
to get another job, your company will disappear in a
month or two.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 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 Sun, 27 Mar 2005, Aaron Gyes wrote:
> > And then the user want to upgrade the 2.0 kernel that shipped with this
> > box although the company that made the hardware went bankrupt some years
> > ago.
> >
> > If the user has the source of the driver, he can port the driver or hire
> > someone to port the driver (this "obscure piece of hardware" might also
> > be an expensive piece of hardware).
>
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law? What about what's better for the
> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> say so? Should the end-users of the current drivers be forced to lose
^^^^^^^
> out on features such as sysfs and udev compatability?
Because otherwise they are violating someone else's copyright?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 2005-03-28 at 08:12 -0500, linux-os wrote:
> On Mon, 28 Mar 2005, Steven Rostedt wrote:
> Following the flock in this GPL issue insulates you from
> many future changes in the kernel. Major portions of the
> module code has already been rewritten to erect a solid
> barrier, marking what's in the kernel and what's without.
> What used to be done outside the kernel, the only reasonable
> place to do it, has now been moved inside the kernel for no
> other reason but isolation.
>
> So tell your senior staff that you need to include the
> GPL license with your code. If you write good code, the
> chances of anybody outside your company actually reading
> it is near zero. If your "trade secrets" are so obvious
> that a look at the code will reveal them, you really need
> to get another job, your company will disappear in a
> month or two.
I first started on this thread because of NVidia. Since I have many
machines that use nvidia drivers and I suffer the consequences of this,
but I'm a kernel programmer and can get around this too.
But now you hit on something that I'm fighting with. I may be part of
the GPL religion, but I'm not a true believer. I like the concept. All
code that I write on my own time is usually LGPL (otherwise it is just
public use). I like to share and share alike. But the problem I have is
that I don't have senior management. I'm a free lance programmer. I have
companies (my customers) pay me to code. I can refuse to code if I don't
agree with them, but then they get someone else and I go hungry. I
strongly recommend to them that it is in their interest to release the
code I write under GPL, but the managers don't see it. I may not be that
strong of a spokesman, but they don't like to listen to me, the just
tell me, do what we pay you to do. Like I said, I'm not a strong
believer, so I won't risk not being able to feed my family for the FSF
cause. So I just go on and code, and let their lawyers figure out what
to do.
The customers I work for are actually more interested in selling their
hardware than the software. But when they spend a lot of money to code
for their hardware, they find it hard to understand that it is best to
give it up as GPL code, especially when the workings of the hardware are
explicit in the code. I usually have to also make changes to the kernel
to handle the situation (which all goes under the GPL of course), so the
modules I write are never expected to be used by the vanilla kernel, or
by anyone elses kernel for that matter. The kernel is made to run on
special hardware, and then have some special extensions put on that are
in the form of modules. I'm still in the process of fighting to get
these under GPL, but I'm not an employee, I'm a vendor. And the
management sees me as such. It's very easy for them to pull the plug on
me and find another approach to go.
These companies are rather large, and sell things for a niche market,
that usually don't care about fighting for the GPL. This is not NVidia
selling video cards to consumers. This is large companies selling larger
systems to other large companies, and my part is just a small one. So, I
don't think they'll disappear simply because they don't put everything
under the GPL. They are smart enough to keep the extensions under GPL
and allow me to send fixes if I find a bug with the code back to the
maintainer. So the maintainer still benefits from this in the form of
testing and updates.
The one way I do try to fight for the GPL is always make the imbedded
code more efficient than the modules. So, to keep the code proprietary
always has a impact on performance. This isn't hard to do, since
obviously the code that is imbedded would be more efficient than code
that needs to be called indirectly through hooks. Nothing has been
decided yet, but if the benchmarks hold out, it all may be under GPL in
the end anyway.
-- Steve
On Mon, 2005-03-28 at 15:34 +0200, Arjan van de Ven wrote:
> >
> > Anyway, I don't think that the GPL is that powerful to affect things not
> > linked directly with it
>
> the problem with kernel modules is.. that you actually create quite a
> few lines of code directly from the kernel (via the headers). Also..
> derived work is both broader and smaller than "directly linked".
>
> Like if you write an extra chapter to a harry potter novel... even if
> it's not in the same bundle, it's still a derived work.
>
If you don't use any of the names of the characters, is it still a
derived work?
Having a GPL wrapper may be legal to do. You won't find out until you
are actually taken to court. I don't see why people are very upset with
doing this, since those that do must work very hard in keeping things
compliant. And those that write the GPL code, can keep things hard for
them, which could just be by ignoring them. Anyone who complains about a
crash that has the nvidia module loaded will not get any help, except
from those that also have the nvidia module.
Writing code that needs wrappers is not derived work, if that code can
also have wrappers for BSD, QNX and perhaps Windows. It may be an added
functionality, that needs some operating system, but if it is a separate
functionality, than it should really work for any operating system, and
thus it is not a derived work. I don't find nvidia modules a derived
work from linux. Since they are used for other operating systems. And I
believe you'll have a hard time convincing any court that nvidia is a
derived work.
God! I must be in the middle. With management, I'm always fighting to go
GPL, and here on LKML, I'm arguing for proprietary modules. I must be
going psycho!
-- Steve
On Mon, Mar 28, 2005 at 11:31:53AM +0200, Jan Engelhardt wrote:
>
> >> > How do you define "proven in court"?
> >> >
> >> > Decided by an US judge based on US laws?
> >> > Decided by a German judge based on German laws?
> >> > Decided by a Chinese judge based on Chinese laws?
> >> > ...
> >>
> >> OK, I was talking about US courts since that case was done in the US.
>
> >And a court decision in e.g. the USA might not have any influence on a
> >court decision in e.g. Germany.
>
> I got a different impression. The US has "the biggest houses, the biggest
> cars, ..." (Supersize me), so if something happens in the US, other countries
> watch it more closely as if it was the other way round.
German judges still decide based on German laws.
E.g. it might be legal in the USA to preppare a war of aggression, but
in Germany the preparation alone will bring you into prison for at least
ten years.
The USA might have influence on changes in the laws of other countries,
but there will never be an 1:1 mapping between the laws.
> Jan Engelhardt
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
> What used to be done outside the kernel, the only reasonable
> place to do it, has now been moved inside the kernel for no
> other reason but isolation.
I would not complain as much if nvidia was "more userspace" so
that bug reports could be more valid than they are currently,
when they are tainted.
Jan Engelhardt
--
No TOFU for me, please.
Hi Greg,
If you read the Linux Kernel header file "linux/module.h", there is a
section about Licenses. If "Proprietary" licences are not leagal, then why
are they supported ?
The implication of providing support for them in the header file is that
it is leagal to create and supply them.
I am porting a driver to Linux for a third party. I do not know if they
whish to release the Linux driver under GPL so I have assumed (because of
the nature of the hardware) that they do not whish to. I will discus this
matter with them when I have finnished the driver.
The use of header files to build a propriatory object files/binaries or
the use of GCC to compile such a file does not breach GPL as if it did,
GCC and GLIBC would not be available for non GPL platforms and it would
not be posible to provide propriatory code for use in a Linux/GNU
environment.
The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it
can be argued quite reasonably that the APIs are not coverd by the GPL.
With regard to derived work - mensioned in a number of responses, a new
driver ported from MS Windows is derived from the Windows Driver not the
Linux Kernel. If it can be shown that there are sections of code in the
new driver that have been coppied from other Linux drivers, then there is
a good argument with regard to derived code but it would still be very
difficult to prove that this code had not been written totally
independantly from the Linux drivers containing the same or similar code.
In addition the driver is being built as a module, out side of the kernel
source tree and as a result can be considered to be separate enterty to
the kernel. If it was required to be built into the kernel as apposed to
being a Kernel Module then it would be totally different and the driver
would need to be GPL.
The hardware that this driver is being written for is low volume, very
specialised (with regard to its application). The driver will only be of
interest to thoes who have or can aford to purchase this hardware and are
in an appropriate buisiness sector. Given this, I see little point in
making the driver GPL as the code will be of little interest to anyone who
will not already have access to it through the supplier of the hardware it
is written for. For thoes writing Linux drivers, there are a number of
Books that can be read on this subject.
The Linux Kernel used with the driver will be probably purchesed
independently as part of a standard Linux distribution. As I am not
changing any of that code, I am not in breach of the GPL associated with
that code. A device driver may or may not be derived from other drivers in
the Linux Kernel. In this case it is not so it is not covered by the
Kernel GPL. If the customer requires a linux kernel then I will be quite
happy to provide one configured to meet their requirements with all the
source code (as available from the various ftp mirrors) and any private
patches I may have applied, as per the terms and conditions in the
"COPYING" file in the kernel source tree.
I wait with interest for your comments.
Regards
Mark Fortescue.
On Sat, 26 Mar 2005, Greg KH wrote:
> On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
> >
> > I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> > I have found that I can't use SYSFS on Linux-2.6.10.
> >
> > Why ?.
>
> What ever gave you the impression that it was legal to create a
> "Proprietry" kernel driver for Linux in the first place. I seriously
> encourage you to consult your company's legal department if you insist
> on attempting to do this, as they will be contacted by others after your
> driver is released.
>
> > I am not modifing the Kernel/SYSFS code so I should be able, to use all
> > the SYSFS/internal kernel function calls without hinderence.
>
> I'm sorry, but as you have found out, that is not possible.
>
> > I believe that this sort of idiocy is what helps Microsoft hold on to its
> > manopoly and as shuch hinders hardware/software development in all areas
> > and should be chanaged in a way that promotes diversified software
> > development.
>
> If your company does not agree with the current license of the Linux
> kernel, which prevents you from creating "Proprietry" drivers, then do
> not write or create such drivers in the first place. We (the kernel
> community) are not forcing you to write a Linux driver.
>
> However, if you do wish to create a Linux driver, you _must_ abide by
> the legal requirements of the kernel, which I feel, along with every IP
> lawyer I have ever consulted, that it is not allowed to create a non-GPL
> compatible kernel module.
>
> Good luck,
>
> greg k-h
>
On Mon, 28 Mar 2005, Mark Fortescue wrote:
> If you read the Linux Kernel header file "linux/module.h", there is a
> section about Licenses. If "Proprietary" licences are not leagal, then why
> are they supported ?
>
> The implication of providing support for them in the header file is that
> it is leagal to create and supply them.
That is your interpretation. Your lawyer might well have a
different opinion, and judges might have yet other opinions.
If you want to know the answer to your question with a higher
degree of certainty, ask your lawyer.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Steven Rostedt <[email protected]> said:
> On Sun, 2005-03-27 at 21:54 -0400, Horst von Brand wrote:
[...]
> > Wrong. You are free to do whatever you like in the privacy of your home,
> > but not distribute the result. So you could very well distribute both
> > pieces, one under GPL, the other not, and leave the linking to the end
> > user.
> >
> > Sure, /creating/ the piece to be linked with the GPLed code might make it
> > GPL also, but that is another story.
> Actually this is an easy one. If you are the creator of the code, you
> can license it anyway you want. So you can make it both GPL and allow it
> to link with your code. Heck, put it under LGPL since GPL is allowed to
> link to that.
Right, but that is not the point. If you need to look closely at the GPL
part, or swipe stuff from other GPLed code that uses the same interface,
the result might have to be GPL.
> Anyway, I don't think that the GPL is that powerful to affect things not
> linked directly with it. Just like the MS license can't make you do
> certain things that were stated in the license, the GPL can't take too
> much control over what you do. If something in the license is
> reasonable, than it is easy to enforce (like taking the code from GPL
> source and using it in a binary) but if it starts to stretch (like
> controlling the code you write and how you can use it) then that will
> have to be fought in court, and will probably lose.
The problem is that noone is sure what exactly qualifies as "derived work",
and what can be used/copied without concern for infringement (Can you use
declarations of stuff in a public .h? What if the .h is "local use" in the
code? Can you write your own declarations matching what you find in random
code, and use them? What about inlined functions? Lists of e.g. IOCTL
codes or system calls?). Does it matter that you are writing your stuff for
compatibility with what is out there, or to add functionality? Does it
matter if you are just using "standard" interfases to the GPLed stuff
(whatever that means in each case)? How much copying makes it derived? 1
line, 5%, what?
--
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
> Writing code that needs wrappers is not derived work, if that code can
> also have wrappers for BSD, QNX and perhaps Windows.
Just because it works with another O.S. doesn't mean it is not derived
from Linux code. Good grief. Try your lawyer, or at least a Google
search for something like "copyright derived work", for a better idea
of what "derived" means.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373, 1.925.600.0401
On Mon, 2005-03-28 at 15:43 -0800, Paul Jackson wrote:
> > Writing code that needs wrappers is not derived work, if that code can
> > also have wrappers for BSD, QNX and perhaps Windows.
>
> Just because it works with another O.S. doesn't mean it is not derived
> from Linux code. Good grief. Try your lawyer, or at least a Google
> search for something like "copyright derived work", for a better idea
> of what "derived" means.
>
So you are saying that a stand alone section of code, that needs
wrappers to work with Linux is a derived work of Linux? If there's some
functionality, that you make, and it just happens to need some kind of
operating system to work. Does that make it a derived work of any
operating system?
OK, I took your advise and found this from googling:
http://www.pbwt.com/Attorney/files/ravicher_1.pdf
It's a good read (I recommend you to read it), and it goes back to one
of my first points, and that is the interpretation of a derived work is
basically up to the judge that is handling the case. There's nothing set
in stone here. It covers mainly US copyright law, and that's what I'm
mainly concerned with.
Unless you misunderstood me, and thought that I was talking about taking
some part of Linux and making it work under another OS, I still stand by
my statement.
-- Steve
On Mar 28, 2005, at 19:21, Steven Rostedt wrote:
> So you are saying that a stand alone section of code, that needs
> wrappers to work with Linux is a derived work of Linux? If there's
> some functionality, that you make, and it just happens to need
> some kind of operating system to work. Does that make it a derived
> work of any operating system?
It depends on how special and different the wrappers for Linux are
from the wrappers for other operating systems. Like, for example,
the sysfs stuff is so radically different from the APIs that other
operating systems provide that anything using it is most likely
copied from other in-kernel sysfs code, and is therefore derived
from the Linux kernel.
> OK, I took your advise and found this from googling:
>
> http://www.pbwt.com/Attorney/files/ravicher_1.pdf
Mmm, good reference, thanks!
> Unless you misunderstood me, and thought that I was talking
> about taking some part of Linux and making it work under another
> OS, I still stand by my statement.
I think it really depends on the APIs implemented. Anything based
on the sysfs code, even if only using the APIs, will probably be
found to be a derivative work (NOTE: IANAL) because the sysfs API
is so very different from everything else. Other interfaces like
PCI management, memory management, etc, may not be so protectable,
because they are standard across many systems. If Linux got a
new and unique memory hotplug API, however, that might be a very
different story. Similar things could be said about integration
between drivers and the new Unified Driver Model, which appears to
be quite original.
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 Sun, 2005-03-27 at 10:12 -0800, Greg KH wrote:
> No, that is not the general consensus at all. Please search the
> archives and the web for summaries of this discussion topic the last
> time it came up.
>
> greg k-h
Hi. I've searched the archives about this stuff. It looks like you
attempted to change the EXPORT_SYMBOL's to EXPORT_SYMBOL_GPL for sysfs
stuff back in February, and the issue in general has come up many times.
A few people have made the point that Linus has said that changing
EXPORT_SYMBOL to EXPORT_SYMBOL_GPL is not okay, that they are supposed
to start off as EXPORT_SYMBOL_GPL or somesuch. And it seems last time
you tried it, something made you change it back.
Can you explain this, please?
> So you are saying that a stand alone section of code, that needs
> wrappers to work with Linux is a derived work of Linux?
Not what I said.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373, 1.925.600.0401
On Mon, 2005-03-28 at 19:56 -0500, Kyle Moffett wrote:
> On Mar 28, 2005, at 19:21, Steven Rostedt wrote:
> > So you are saying that a stand alone section of code, that needs
> > wrappers to work with Linux is a derived work of Linux? If there's
> > some functionality, that you make, and it just happens to need
> > some kind of operating system to work. Does that make it a derived
> > work of any operating system?
>
> It depends on how special and different the wrappers for Linux are
> from the wrappers for other operating systems. Like, for example,
> the sysfs stuff is so radically different from the APIs that other
> operating systems provide that anything using it is most likely
> copied from other in-kernel sysfs code, and is therefore derived
> from the Linux kernel.
>
If your stand alone code has it's own API and your GPL wrapper handles
the sysfs interface, then this might get around it.
> > OK, I took your advise and found this from googling:
> >
> > http://www.pbwt.com/Attorney/files/ravicher_1.pdf
>
> Mmm, good reference, thanks!
>
You're welcome!
> > Unless you misunderstood me, and thought that I was talking
> > about taking some part of Linux and making it work under another
> > OS, I still stand by my statement.
>
> I think it really depends on the APIs implemented. Anything based
> on the sysfs code, even if only using the APIs, will probably be
> found to be a derivative work (NOTE: IANAL) because the sysfs API
> is so very different from everything else. Other interfaces like
> PCI management, memory management, etc, may not be so protectable,
> because they are standard across many systems. If Linux got a
> new and unique memory hotplug API, however, that might be a very
> different story. Similar things could be said about integration
> between drivers and the new Unified Driver Model, which appears to
> be quite original.
>
Yes, but as the article states, ideas are not protected under copyright
law. So an unique idea to handle hotplug then it may still not be
covered. This is all very ambiguous, and is too confusing. I'll leave
it up to the lawers!
-- Steve
On Mon, 2005-03-28 at 17:22 -0800, Paul Jackson wrote:
> > So you are saying that a stand alone section of code, that needs
> > wrappers to work with Linux is a derived work of Linux?
>
> Not what I said.
>
Good, so you most likely misunderstood me.
OK, I've had enough of being devil's advocate. I'm usually fighting to
get things under the GPL, or at least the LGPL, and I'm getting worn out
fighting for the other side.
Have a good one, I have work to do ;-)
-- Steve
> The GPL is a distribution license, it doesn't really matter what you do
> *internally* with GPL code. It might be a DMCA violation in the USSA but
> thats because the law is broken.
You can't violate the DMCA on a GPL'd work. At least, if there's a way to
do, I couldn't find it. See some of the previous posts on this list about
whether the DMCA meant you couldn't remove the GPL tag on exported symbols.
The GPL explicitly permits you to modify the code as you wish, and this
includes removing any restriction or enforcement type code.
DS
On Mar 28, 2005, at 20:53, David Schwartz wrote:
> The GPL explicitly permits you to modify the code as you wish, and this
> includes removing any restriction or enforcement type code.
Yeah, sure, one could remove the technological enforcement, but IIRC the
thread also brought up that you _still_ couldn't distribute anything
that
_used_ the broken type enforcement, because changing the source code to
include the comment "This is Public Domain!" likewise doesn't make it
so.
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------
Lee Revell wrote:
> On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote:
>
>>On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
>>
>>>I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
>>>I have found that I can't use SYSFS on Linux-2.6.10.
>>>
>>>Why ?.
>>
>>What ever gave you the impression that it was legal to create a
>>"Proprietry" kernel driver for Linux in the first place.
>
>
> The fact that Nvidia and ATI get away with it?
I have the nvidia GeForce4 driver: NVIDIA-Linux-x86-1.0-6629-pkg1.
$ ls NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/
Makefile@ makedevices.sh* nv-vm.c nv_compiler.h os-agp.c os-registry.c
Makefile.kbuild makefile nv-vm.h nvidia.ko os-agp.h os-registry.o
Makefile.nvidia nv-kernel.o nv-vm.o nvidia.mod.c os-agp.o pat.h
README nv-linux.h nv.c nvidia.mod.o os-interface.c precompiled/
conftest.sh nv-memdbg.h nv.h nvidia.o os-interface.h rmretval.h
gcc-version-check.c nv-misc.h nv.o nvtypes.h os-interface.o
So it seems nvidia has their kernel module `open'. Is it?
Coywolf
On Mon, Mar 28, 2005 at 05:04:37PM -0800, Aaron Gyes wrote:
> On Sun, 2005-03-27 at 10:12 -0800, Greg KH wrote:
> > No, that is not the general consensus at all. Please search the
> > archives and the web for summaries of this discussion topic the last
> > time it came up.
> >
> > greg k-h
>
> Hi. I've searched the archives about this stuff. It looks like you
> attempted to change the EXPORT_SYMBOL's to EXPORT_SYMBOL_GPL for sysfs
> stuff back in February, and the issue in general has come up many times.
I only tried to change the class_simple code at that time. This was
because the entire other driver core code was converted by the author of
that code at the same time. The reason people complained about the
class_simple code was because of vmware and nvidia.
Since then, vmware has stated that they don't even like sysfs and udev,
and dropped support for it entirely. Also, nvidia has told me that they
do not like udev either, so they don't care about the sysfs code too.
> A few people have made the point that Linus has said that changing
> EXPORT_SYMBOL to EXPORT_SYMBOL_GPL is not okay, that they are supposed
> to start off as EXPORT_SYMBOL_GPL or somesuch. And it seems last time
> you tried it, something made you change it back.
Yes, I was asked nicely to do so by some people I respect. Since then,
I sought out the only closed source users of this code that I could
find, and consulted them for what to do. As mentioned above, neither
company has a problem with me doing this.
Also, the code has undergone a rewrite, fixing many issues, and changing
the way things work to tie more closely into the main driver core code.
As such, the class_simple code is now just gone, there is no such need
for it. And as such, the new code contains the _GPL markings, as I do
not think that _anyone_ can try to claim that their code would not be a
derived work of Linux who wants to use it (as no other OS has such a
driver model interface.)
> Can you explain this, please?
I hope the above explanation is acceptable. If you have further
questions, please do not hesitate to ask. And I would personally like
to thank you for your civil tone. My current inbox reflects the rants
of people without such civility at this time.
thanks,
greg k-h
On Mon, Mar 28, 2005 at 05:52:37PM +0100, Mark Fortescue wrote:
> Hi Greg,
>
> If you read the Linux Kernel header file "linux/module.h", there is a
> section about Licenses. If "Proprietary" licences are not leagal, then why
> are they supported ?
They are not "supported" in any sense of the word.
> The implication of providing support for them in the header file is that
> it is leagal to create and supply them.
I'm sorry, but you need to consult with a lawyer about this issue, as I
am not one, and you are asking me legal questions and asking for my
advice, which is not the wisest thing to do :)
Also, the current symbol markings for the sysfs and driver code
interfaces are going to remain as is.
thanks,
greg k-h
On Mon, 2005-03-28 at 15:12 +0200, Geert Uytterhoeven wrote:
> On Sun, 27 Mar 2005, Alan Cox wrote:
> > On Sul, 2005-03-27 at 14:53, Wichert Akkerman wrote:
> > > Are you sure? It is perfectly legal to relicense things if you own the
> > > copyright. As long as he never distributes his GPL version I don't see
> > > why he should have a problem.
> >
> > The GPL is a distribution license, it doesn't really matter what you do
> > *internally* with GPL code. It might be a DMCA violation in the USSA but
> ^^^^
> Is this a plain stupid typo, or am I missing a new joke? ;-(
>
That's quite an old joke actually.
Lee
On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote:
> Also, the code has undergone a rewrite, fixing many issues, and changing
> the way things work to tie more closely into the main driver core code.
> As such, the class_simple code is now just gone, there is no such need
> for it. And as such, the new code contains the _GPL markings, as I do
> not think that _anyone_ can try to claim that their code would not be a
> derived work of Linux who wants to use it (as no other OS has such a
> driver model interface.)
That does not really make sense, as the driver model code could be used
for ndiswrapper, for example. That would not make the Windows net
drivers derived code of the Linux kernel. ndiswrapper, yes it would be.
Binary driver blobs, no.
ndiswrapper is a perfect example, in fact. It is GPL, and implements an
_interface_ to binary code that is not GPL.
It seems to me that any author has the right to create a public
interface into the kernel.
If that interface is well-defined and public, implementing it from the
other side in binary code does not create a derived work. It is
especially obvious if there are multiple interface implementations.
Hard to argue that the same binary that links unchanged into Windows,
BSD and Linux is Linux-derived.
--
Zan Lynx <[email protected]>
On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote:
> I hope the above explanation is acceptable. If you have further
> questions, please do not hesitate to ask. And I would personally like
> to thank you for your civil tone. My current inbox reflects the rants
> of people without such civility at this time.
Beyond acceptable, thank you. I'll admit I started off (other posts in
this thread) somewhat upset ("That jerk broke the udev support in the
drivers I use!") But I've been somewhat swayed by what I've read. And I
guess if a license say something, it doesn't really matter how
inconvienient it is for me. (Though "derived work" is still pretty vague
and I eagerly await a lawsuite that will disambiguate it.
In other news: How do I get udev to create a static node?
Aaron Gyes
On Mon, Mar 28, 2005 at 08:28:31PM -0800, Aaron Gyes wrote:
>
> In other news: How do I get udev to create a static node?
What do you mean by "static"? Something that persists over a reboot?
Or after the device is removed?
If reboot, mount your /dev on a disk-backed filesystem, not a ramfs or
tmpfs.
If after removed, that's not what udev is set up to do, sorry.
thanks,
greg k-h
On Mon, Mar 28, 2005 at 09:03:29PM -0700, Zan Lynx wrote:
> On Mon, 2005-03-28 at 19:33 -0800, Greg KH wrote:
> > Also, the code has undergone a rewrite, fixing many issues, and changing
> > the way things work to tie more closely into the main driver core code.
> > As such, the class_simple code is now just gone, there is no such need
> > for it. And as such, the new code contains the _GPL markings, as I do
> > not think that _anyone_ can try to claim that their code would not be a
> > derived work of Linux who wants to use it (as no other OS has such a
> > driver model interface.)
>
> That does not really make sense, as the driver model code could be used
> for ndiswrapper, for example. That would not make the Windows net
> drivers derived code of the Linux kernel. ndiswrapper, yes it would be.
> Binary driver blobs, no.
>
> ndiswrapper is a perfect example, in fact. It is GPL, and implements an
> _interface_ to binary code that is not GPL.
And do your lawyers deem ndiswrapper as something that is legal under
the GPL? The ones I have talked to definitely do not feel that way.
Again, why are we, non-lawyers arguing about this. If you work for a
company that deals with Linux kernel issues, and you have any questions
about the legality of _anything_, get a legal opinion. Don't rely on
lkml for this.
greg k-h
On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote:
> If after removed, that's not what udev is set up to do, sorry.
There's no way to either a) Hack udev.conf to always create a node with
a certain major and minor or b) A way to make sysfs trick udev?
I'll kind of need to do this for nvidia and any other modules affected
by this change, or else switch back to the inferior devfs.
Aaron Gyes
On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote:
> What do you mean by "static"? Something that persists over a reboot?
> Or after the device is removed?
Forgot to clarify. Create a node for something that's not in sysfs, with
udev.
Aaron Gyes wrote:
> On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote:
>
>
>>What do you mean by "static"? Something that persists over a reboot?
>>Or after the device is removed?
>
>
> Forgot to clarify. Create a node for something that's not in sysfs, with
> udev.
At least in Fedora, /etc/udev/makedevices.d or /etc/udev/devices.
--
Brian Gerst
On Mon, Mar 28, 2005 at 09:01:27PM -0800, Aaron Gyes wrote:
> On Mon, 2005-03-28 at 20:45 -0800, Greg KH wrote:
> > If after removed, that's not what udev is set up to do, sorry.
>
> There's no way to either a) Hack udev.conf to always create a node with
> a certain major and minor
No.
> or b) A way to make sysfs trick udev?
From userspace? No.
> I'll kind of need to do this for nvidia and any other modules affected
> by this change, or else switch back to the inferior devfs.
I know debian provides a way for the udev startup script to create any
static device node that you want to have be created. I suggest you look
at that as an example to do what you wish.
Also, vmware already supports using udev, yet it does not use sysfs. It
does so by creating the device nodes in its startup script. There is no
reason why you can't do the same thing in the nvidia driver.
thanks,
greg k-h
On 03/29/05 10:37:52AM +0800, Coywolf Qi Hunt wrote:
> Lee Revell wrote:
> >On Sat, 2005-03-26 at 10:28 -0800, Greg KH wrote:
> >
> >>On Sat, Mar 26, 2005 at 05:52:20PM +0000, Mark Fortescue wrote:
> >>
> >>>I am writing a "Proprietry" driver module for a "Proprietry" PCI card and
> >>>I have found that I can't use SYSFS on Linux-2.6.10.
> >>>
> >>>Why ?.
> >>
> >>What ever gave you the impression that it was legal to create a
> >>"Proprietry" kernel driver for Linux in the first place.
> >
> >
> >The fact that Nvidia and ATI get away with it?
>
> I have the nvidia GeForce4 driver: NVIDIA-Linux-x86-1.0-6629-pkg1.
>
> $ ls NVIDIA-Linux-x86-1.0-6629-pkg1/usr/src/nv/
> Makefile@ makedevices.sh* nv-vm.c nv_compiler.h os-agp.c
> os-registry.c
> Makefile.kbuild makefile nv-vm.h nvidia.ko os-agp.h
> os-registry.o
> Makefile.nvidia nv-kernel.o nv-vm.o nvidia.mod.c os-agp.o
> pat.h
> README nv-linux.h nv.c nvidia.mod.o
> os-interface.c precompiled/
> conftest.sh nv-memdbg.h nv.h nvidia.o
> os-interface.h rmretval.h
> gcc-version-check.c nv-misc.h nv.o nvtypes.h os-interface.o
>
>
> So it seems nvidia has their kernel module `open'. Is it?
See that 4.2M binary file called nv-kernel.o? That's the real driver, the open
part is the glue, a sort of middle-ware so that the driver can be
recompiled and loaded into any kernel.
>
>
> Coywolf
> -
> 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/
Mark Fortescue wrote:
> Hi Greg,
>
> If you read the Linux Kernel header file "linux/module.h", there is a
> section about Licenses. If "Proprietary" licences are not leagal, then why
> are they supported ?
Because it does want to let module authors tell the truth, however bleak.
The GPL is quite unambiguous on the subject - the answer is "not allowed".
But the GPL is a copyright license, not an EULA-style contract. If you feel
confident that you can defend a case claiming that your driver was a
derived work, it may not be necessary to agree to the terms at all. Only if
the additional rights granted by GPL (such as the right to distribute
derived works) are required, are you forced to accept it's terms in
exchange for such rights.
There are at least some who grudgingly accept that it may be possible to
write drivers which are not derived works, at least if they stick to a
interfaces which are widespread and in not specific to Linux. This is
arguably a weakness of the GPL-as-copyright-license, but given the ideals
it represents, arguing to strengthen the laws would be most
counterproductive :-)
> The implication of providing support for them in the header file is that
> it is leagal to create and supply them.
This is certainly something that could be argued from, but I don't know how
successful you it would be. Only a court case could tell.
> I am porting a driver to Linux for a third party. I do not know if they
> whish to release the Linux driver under GPL so I have assumed (because of
> the nature of the hardware) that they do not whish to. I will discus this
> matter with them when I have finnished the driver.
I would suggest you discuss it now; they take a while to get legal advice
and make their decision.
> The use of header files to build a propriatory object files/binaries or
> the use of GCC to compile such a file does not breach GPL as if it did,
> GCC and GLIBC would not be available for non GPL platforms and it would
> not be posible to provide propriatory code for use in a Linux/GNU
> environment.
glibc and libgcc are not under a vanilla GPL. gcc itself is GPL, but it's
fairly well accepted that the output of a tool is not a derived work and
does not fall under that tool's copyright. Otherwise microsoft would be
pocketing a slice of the royalties on everything written using Word. Even
they haven't been that bold yet :-) In any case, these licenses carry
specific exemptions allowing proprietary use. This is a deliberate choice
on the part of their maintainers.
> The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it
> can be argued quite reasonably that the APIs are not coverd by the GPL.
I fail to see how this is even relevent. The kernel COPYING file
specifically states the widely held (I won't claim universal - there's
bound to be someone who would otherwise disagree) belief that the syscall
interface is sufficiently generic; namely, that proprietary use at that
level does not carry any implication that the proprietary component is a
derived work. But this is only a clarification; it does this as the GPL's
interpretation is quite broad. Nothing specific is said about internal
kernel API, so it's covered by the GPL.
> With regard to derived work - mensioned in a number of responses, a new
> driver ported from MS Windows is derived from the Windows Driver not the
> Linux Kernel. If it can be shown that there are sections of code in the
This is the sort of claim that nVidia and ATI make - that the proprietary
portions are not derived works. The fact that they are portable across
multiple OSes, make use of only basic OS services, and predate the linux
port, are reasonably good arguments to that effect. Assuming they aren't
just crazy (which seems a good assumption) they apparently think they can
win if anyone ever challenges them. Seemingly, so do most of the people
complaining, since no court case has yet appeared about it.
> new driver that have been coppied from other Linux drivers, then there is
> a good argument with regard to derived code but it would still be very
> difficult to prove that this code had not been written totally
> independantly from the Linux drivers containing the same or similar code.
> In addition the driver is being built as a module, out side of the kernel
> source tree and as a result can be considered to be separate enterty to
Built inside or outside is not a particularly compelling argument, though it
certainly would be worth a mention if trying to put a case together.
> the kernel. If it was required to be built into the kernel as apposed to
> being a Kernel Module then it would be totally different and the driver
> would need to be GPL.
It wouldn't be all that different. Just another point of evidence in the
decision of whether or not the addition was a derived work.
> The hardware that this driver is being written for is low volume, very
> specialised (with regard to its application). The driver will only be of
And this has no bearing whatsoever on the legality, though if nobody cares
the odds of being sued are much reduced. The only case where it might
matter is if the volume is 1; if the driver will thus never be distributed
at all (just used by its creator), copyright doesn't come into play at all,
and one can do whatever one wants.
> interest to thoes who have or can aford to purchase this hardware and are
> in an appropriate buisiness sector. Given this, I see little point in
> making the driver GPL as the code will be of little interest to anyone who
Other than access to handy, but linux-only things like sysfs, removal of the
need to maintain huge numbers of different binaries (SMP, 32/64, Preempt,
kernel versions, etc), and receipt of a lot less whining :-)
> will not already have access to it through the supplier of the hardware it
> is written for. For thoes writing Linux drivers, there are a number of
> Books that can be read on this subject.
>
> The Linux Kernel used with the driver will be probably purchesed
> independently as part of a standard Linux distribution. As I am not
> changing any of that code, I am not in breach of the GPL associated with
Distributing a derived work without permission of the copyright holder is
every bit as illegal as distributing a modified work, or a simple knockoff
copy. Such permission is granted, but *only* to GPLed modules, and anything
else is a claim that the work is independent and didn't need any specific
permission.
> that code. A device driver may or may not be derived from other drivers in
> the Linux Kernel. In this case it is not so it is not covered by the
> Kernel GPL. If the customer requires a linux kernel then I will be quite
> happy to provide one configured to meet their requirements with all the
> source code (as available from the various ftp mirrors) and any private
> patches I may have applied, as per the terms and conditions in the
> "COPYING" file in the kernel source tree.
>
> I wait with interest for your comments.
>
> Regards
> Mark Fortescue.
On Mon, 28 Mar 2005, Steven Rostedt wrote:
> On Mon, 2005-03-28 at 19:56 -0500, Kyle Moffett wrote:
>> On Mar 28, 2005, at 19:21, Steven Rostedt wrote:
>>> So you are saying that a stand alone section of code, that needs
>>> wrappers to work with Linux is a derived work of Linux? If there's
>>> some functionality, that you make, and it just happens to need
>>> some kind of operating system to work. Does that make it a derived
>>> work of any operating system?
>>
>> It depends on how special and different the wrappers for Linux are
>> from the wrappers for other operating systems. Like, for example,
>> the sysfs stuff is so radically different from the APIs that other
>> operating systems provide that anything using it is most likely
>> copied from other in-kernel sysfs code, and is therefore derived
>> from the Linux kernel.
>>
>
> If your stand alone code has it's own API and your GPL wrapper handles
> the sysfs interface, then this might get around it.
>
>>> OK, I took your advise and found this from googling:
>>>
>>> http://www.pbwt.com/Attorney/files/ravicher_1.pdf
>>
>> Mmm, good reference, thanks!
>>
>
> You're welcome!
>
>>> Unless you misunderstood me, and thought that I was talking
>>> about taking some part of Linux and making it work under another
>>> OS, I still stand by my statement.
>>
>> I think it really depends on the APIs implemented. Anything based
>> on the sysfs code, even if only using the APIs, will probably be
>> found to be a derivative work (NOTE: IANAL) because the sysfs API
>> is so very different from everything else. Other interfaces like
>> PCI management, memory management, etc, may not be so protectable,
>> because they are standard across many systems. If Linux got a
>> new and unique memory hotplug API, however, that might be a very
>> different story. Similar things could be said about integration
>> between drivers and the new Unified Driver Model, which appears to
>> be quite original.
>>
>
> Yes, but as the article states, ideas are not protected under copyright
> law. So an unique idea to handle hotplug then it may still not be
> covered. This is all very ambiguous, and is too confusing. I'll leave
> it up to the lawers!
>
> -- Steve
In the United States there is something called "restraint of trade".
Suppose there was a long-time facility or API that got replaced
with one that was highly restrictive. To use the new facility, one
would have to buy a license or kiss somebody or something that
was not previously required. If an action was brought against the
person(s) who replaced the old facility with the new one, it
is likely that the plaintiff would prevail.
If there is documented proof that those symbols were previously
available and then they were changed to something more restrictive,
I think one would prevail if a complaint were brought in court.
If course, you need to convince the person(s) who changed them
that the action was unconscionable and therefore force them to
change them back without making money for the lawyers by suing
them. And, yes, somebody who modifies software in that manner
can be sued. They could also be charged with criminal behavior
(malicious mischief) in the State of Massachusetts or charged
under federal law with restraint of trade. Modifying an existing
policy to further an individual's ambitions can be fraught
with consequences.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 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 Tue, March 29, 2005 7:15 am, linux-os said:
> In the United States there is something called "restraint of trade".
> Suppose there was a long-time facility or API that got replaced
> with one that was highly restrictive. To use the new facility, one
> would have to buy a license or kiss somebody or something that
> was not previously required. If an action was brought against the
> person(s) who replaced the old facility with the new one, it
> is likely that the plaintiff would prevail.
>
> If there is documented proof that those symbols were previously
> available and then they were changed to something more restrictive,
> I think one would prevail if a complaint were brought in court.
>
> If course, you need to convince the person(s) who changed them
> that the action was unconscionable and therefore force them to
> change them back without making money for the lawyers by suing
> them. And, yes, somebody who modifies software in that manner
> can be sued. They could also be charged with criminal behavior
> (malicious mischief) in the State of Massachusetts or charged
> under federal law with restraint of trade. Modifying an existing
> policy to further an individual's ambitions can be fraught
> with consequences.
>
What the hell is this world coming to? Can we please just respect the
intent of the GPL and dispense with all this legalese crap; at least here
on LKML? People who want a free ride and don't care about returning
anything to the community that created Linux have many other forums in
which to vent.
Regards,
Sean
Kyle Moffett <[email protected]> said:
[...]
> I think it really depends on the APIs implemented. Anything based
> on the sysfs code, even if only using the APIs, will probably be
> found to be a derivative work (NOTE: IANAL) because the sysfs API
> is so very different from everything else. Other interfaces like
> PCI management, memory management, etc, may not be so protectable,
> because they are standard across many systems. If Linux got a
> new and unique memory hotplug API, however, that might be a very
> different story. Similar things could be said about integration
> between drivers and the new Unified Driver Model, which appears to
> be quite original.
Sorry, but an /interfase/ is there to do exactly that. It can be placed
under copyright protection as code, but /using/ it just can't be considered
a derived work. It makes no sense that if I get a description (docu,
example code, whatever) and learn from that how it is used, and then go and
write my own, that my code it should be a derived work of what is at the
other side of the interfase.
If this was true, Linux would be a ripoff from Unix (same system calls),
and any program ever written for Unix would belong to Novell (or SCOXE, or
UCB, depending on whom you believe in the current mess). Note that this is
quite similar to the gargabe SCOXE tried claiming against Linux/IBM, and
had to take back.
--
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
> On Mar 28, 2005, at 20:53, David Schwartz wrote:
> > The GPL explicitly permits you to modify the code as you wish, and this
> > includes removing any restriction or enforcement type code.
> Yeah, sure, one could remove the technological enforcement, but IIRC the
> thread also brought up that you _still_ couldn't distribute anything
> that
> _used_ the broken type enforcement, because changing the source code to
> include the comment "This is Public Domain!" likewise doesn't make it
> so.
The GPL specifically permits unrestricted functional modification and
distribution. So you cannot violate the GPL by modifying and distributing
the resulting modifications (except perhaps by altering or removing the text
of the GPL itself).
The GPL contains no technical restrictions or software enforcement
mechanisms. While you could add some to GPL'd software, you could not
prohibit their removal. That would be an "additional restriction", which the
GPL forbids.
Since the GPL permits their removal, removing them cannot be circumventing
the GPL. Since the GPL is the only license and the license permits you to
remove them, they cannot be a license enforcement mechanism. How can you
enforce a license that permits unrestricted functional modification?
Perhaps you could make an argument if the code only restricted things
specifically prohibited by the GPL. But the GPL also permits unrestricted
usage, so it's not clear how this could happen.
DS
On Tue, Mar 29, 2005 at 11:00:30AM -0800, David Schwartz wrote:
> Since the GPL permits their removal, removing them cannot be circumventing
> the GPL. Since the GPL is the only license and the license permits you to
> remove them, they cannot be a license enforcement mechanism. How can you
> enforce a license that permits unrestricted functional modification?
You misunderstand totally the EXPORT_GPL system. It does not mean
"this is a technological system to prevent you to use it with non-gpl
compatible code". It means "The author of that code consider that
using this function makes your code so linux-specific that it must be
a derivative work of the code implementing the function, so if you use
it from non gpl-compatible code you'll be sued. And since he's nice,
he uses a technical method to prevent you from doing such a copyright
violation by mistake.".
See the subtle difference? EXPORT_GPL is here to _help_ proprietary
driver authors. Your lawyers should _love_ it and skin you alive if
you try to get around it.
OG.
On Tue, Mar 29, 2005 at 12:31:42PM -0400, Horst von Brand wrote:
> Sorry, but an /interfase/ is there to do exactly that. It can be placed
> under copyright protection as code, but /using/ it just can't be considered
> a derived work. It makes no sense that if I get a description (docu,
> example code, whatever) and learn from that how it is used, and then go and
> write my own, that my code it should be a derived work of what is at the
> other side of the interfase.
IANAL, but I've seen two extremes in the interpretation of "derived
work" w.r.t the GPL:
1- If there isn't GPL code in your sources, it's not a derived
work. That interpretation would make the GPL and the LGPL
pretty much equivalent.
2- If you depend on GPL code in any way to make your code useful,
then it's a derived work.
The truth is, as always, somewhere in the middle, and intentions,
local law and jurisprudence matter a lot when a judge states on a case
like that, whichever your country is. That's why the "check with a
lawyer in your jurisdiction" is the only appropriate answer.
The FSF stance btw is a little less harsh than 2. It's pretty much,
from what I understand it, "if you depend on gpl code, and there is no
non-gpl alternative which means you really, really depend on gpl code
no matter what, then it's a derived work.". Makes a lot of sense too.
Whether it holds water is a matter of the court. It _is_ the intent
behind the GPL though, they wrote the GPL and said so numerous times,
so it will have its importance if someone puts that part of the GPL to
the test.
You'll notice that I never talk of interfaces in all that. Interfaces
is a technical matter, and maybe an intent matter[1]. Derived work
status is a _legal_ matter which puts in play dependency and intent.
Not a technical matter at all.
OG.
[1] Compare for intent differences:
- "Linux has a sysfs interface, check the sources for how it works"
- "Here is the sysfs interface documentation for use in the GPL-ed
Linux kernel"
- "Here is the sysfs interface documentation, an implementation-neutral
interface for <whatever>, which happens to be implemented in, among
others, the Linux kernel".
On Tue, 29 Mar 2005, linux-os wrote:
> If there is documented proof that those symbols were previously
> available and then they were changed to something more restrictive,
> I think one would prevail if a complaint were brought in court.
They're still available. Just download an older version of Linux.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Wed, 30 Mar 2005, Olivier Galibert wrote:
> It _is_ the intent behind the GPL though, they wrote the GPL and said so
> numerous times, so it will have its importance if someone puts that part
> of the GPL to the test.
Note that for judges in many countries, intent matters.
Intent might not overrule the language in the license, but
it is often used to clarify things and to guide the way in
which the license is interpreted.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On Wed, 30 Mar 2005, Rik van Riel wrote:
> On Tue, 29 Mar 2005, linux-os wrote:
>
>> If there is documented proof that those symbols were previously
>> available and then they were changed to something more restrictive,
>> I think one would prevail if a complaint were brought in court.
>
> They're still available. Just download an older version of Linux.
>
Yes. And this would show that whomever did that already violated
the intent of the GPL by adding restrictions to use. NotGood(tm).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 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 Tue, Mar 29, 2005 at 07:15:01AM -0500, linux-os wrote
[snip]
>
> In the United States there is something called "restraint of trade".
> Suppose there was a long-time facility or API that got replaced
> with one that was highly restrictive. To use the new facility, one
> would have to buy a license or kiss somebody or something that
> was not previously required. If an action was brought against the
> person(s) who replaced the old facility with the new one, it
> is likely that the plaintiff would prevail.
>
[snip]
The key phrase here is 'restraint of /trade/'.
Noone has been selling these drivers, and nonone's been dealing in
the right to use or write them. Without being a lawyer (US or otherwise),
I'd suggest that it's highly unlikely any such legislation would apply.
E.g.: suppose there are 2 snack bars within 100 yards of a school; one
is out of sight, across an intersection and down a side street, and one
is clearly visible across an empty lot. For years the lot has been
unfenced and, human nature being what it is, kids just walk across the
open lot. The owner of the lot then decides to put up a high fence
around it with a combination lock on the gate (now he's raising chinchillas,
or peaches; he won't say) so all the kids start going to the other snackbar,
except for a few that he trusts with the combination. It seems to me
you're suggesting that the snackbar owner who's lost out would have
an action for restraint of trade; I can't see it myself.
John.
[snip]
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.11 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/
>
>
>
> ------------------------------
--
Voice: +61 8 8202 9040
Email: [email protected]
Oasis Systems Pty Ltd
288 Glen Osmond Road
Fullarton, South Australia 5063
Ph: + 61 8 82029000
Fax: +61 8 82029001
CAUTION: This email and any attachments may contain information that is
confidential and subject to copyright. If you are not the
intended recipient, you must not read, use, disseminate, distribute or
copy this email or any attachments. If you have received this
email in error, please notify the sender immediately by reply email and
erase this email and any attachments.
DISCLAIMER: OASIS Systems uses virus-scanning technology but accepts
no responsibility for loss or damage arising from the use of the
information transmitted by this email including damage from virus.
On Wed, March 30, 2005 2:57 pm, linux-os said:
> Yes. And this would show that whomever did that already violated the
> intent of the GPL by adding restrictions to use. NotGood(tm).
Dick,
You are so full of shit. There are no additonal restrictions, just the
restrictions of the GPL; period. Adding _GPL to the symbol does not
place any additional restriction on the people who are already bound by
the GPL. You were much easier to endure when you were just pretending to
have invented RLE.
Sean
On Thu, 31 Mar 2005, Sean wrote:
> On Wed, March 30, 2005 2:57 pm, linux-os said:
>
>> Yes. And this would show that whomever did that already violated the
>> intent of the GPL by adding restrictions to use. NotGood(tm).
>
> Dick,
>
> You are so full of shit. There are no additonal restrictions, just the
> restrictions of the GPL; period. Adding _GPL to the symbol does not
> place any additional restriction on the people who are already bound by
> the GPL.
Sure it does. Before the GPL-only stuff the only problem one would
have with a proprietary module, i.e., one that didn't contain
the GPL "license" notice, was that the kernel would be marked
"tainted". Everything would still work.
With the ADDITIONAL RESTRICTION added, the module won't even work
because an ARTIFICIAL CONSTRAINT was added to prevent its use
unless a GPL "license" notice existed.
> You were much easier to endure when you were just pretending to
> have invented RLE.
>
No pretense, and the original implementation, used under CP/M for
*.LBQ files, given to the world through my PROGRAM EXCHANGE
BBS in 1980, long before there was any GPL, was a much better
implementation than what became known as "RLL" when the disc-
drive people got ahold of it. For those, not in their '60s,
*.LBQ was the early precursor to Phil Katz's *.ZIP files.
He wasn't able to take the heat of all the people who kept
putting him down. He died an early death. I'm going to
outlast all you nay-sayers because when you write facts,
you don't have to remember what you previously wrote so
the liars can't hurt you.
You see, with the original idea of free software, it was free.
You were expected to leave any copyright notice alone. This
free software idea was picked up by UC Berkeley once the
Internet took hold.
The rest is history about a neat idea that became corrupted,
first by the likes of Stallman, then by others when it became
a religion.
> Sean
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 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 Thu, March 31, 2005 7:34 am, linux-os said:
>
> Sure it does. Before the GPL-only stuff the only problem one would
> have with a proprietary module, i.e., one that didn't contain
> the GPL "license" notice, was that the kernel would be marked
> "tainted". Everything would still work.
>
> With the ADDITIONAL RESTRICTION added, the module won't even work
> because an ARTIFICIAL CONSTRAINT was added to prevent its use
> unless a GPL "license" notice existed.
>
There are absolutely no additional restrictions for anyone that is in full
compliance with the spirit and intent of the GPL. Full Stop.
Runtime restrictions do not fall under the GPL anyway, otherwise it would
be illegal to impose _any_ security restrictions on a GPL system.
You are just DeadWrong(Tm) on this issue.
Sean
On Mar 31, 2005, at 07:34, linux-os wrote:
> Sure it does. Before the GPL-only stuff the only problem one
> would have with a proprietary module, i.e., one that didn't
> contain the GPL "license" notice, was that the kernel would
> be marked "tainted". Everything would still work.
Wait, you realize that the EXPORT_SYMBOL_GPL vs. EXPORT_SYMBOL
bit doesn't mean a damn thing with respect to the license,
right? The source code in entirety is licensed under the GPL.
From my point of view, the _only_ difference between the uses
of the two macros is that the "EXPORT_SYMBOL" macro states
that the developer who last touched that code either:
o Has no plans to sue anyone who infringes on their code
o Thinks that the interface is so common and so generic
that a lawsuit would be stupid.
Such a labeling is _only_ a bit of advice and a technical
warning, nothing else. It can be removed or added without any
issue, as long as you obey the GPL license. If somebody
disagrees and sues you over it, that's a problem between you
and your lawyers.
> With the ADDITIONAL RESTRICTION added, the module won't even
> work because an ARTIFICIAL CONSTRAINT was added to prevent its
> use unless a GPL "license" notice existed.
Umm, according technically to many interpretations of the GPL,
you can't link anyways unless you're GPL, so such labels are
just advice, and have no major legal bearing.
> [... excess flames snipped ...]
Please cut the worthless rhetoric and irrelevant statements and
either discuss useful information or stop posting.
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 Tue, Mar 29, 2005 at 11:00:30AM -0800, David Schwartz wrote:
> > Since the GPL permits their removal, removing them cannot
> > be circumventing
> > the GPL. Since the GPL is the only license and the license
> > permits you to
> > remove them, they cannot be a license enforcement mechanism. How can you
> > enforce a license that permits unrestricted functional modification?
> You misunderstand totally the EXPORT_GPL system.
No, I understand it perfectly.
> It does not mean
> "this is a technological system to prevent you to use it with non-gpl
> compatible code".
Right, which is precisely what I said. They are not a license enforcement
mechanism.
> It means "The author of that code consider that
> using this function makes your code so linux-specific that it must be
> a derivative work of the code implementing the function, so if you use
> it from non gpl-compatible code you'll be sued. And since he's nice,
> he uses a technical method to prevent you from doing such a copyright
> violation by mistake.".
If the author of the code is not a lawyer, his opinion about what does or
does not constitute a derived work should really not be of any interest. I
do agree that this is much closer to an accurate understandinf of EXPORT_GPL
than that it's a license enforcement mechanism.
> See the subtle difference? EXPORT_GPL is here to _help_ proprietary
> driver authors. Your lawyers should _love_ it and skin you alive if
> you try to get around it.
Why would any competent lawyer perfer the opinion of a layperson on a
purely legal matter over his own opinion? That's totally absurd.
In any event, I wasn't talking about what EXPORT_GPL is, just about what it
isn't. And you seem to agree with me that it's not a license enforcement
mechanism and that you're not violating the GPL if you remove it and
distribute the results.
I hope you would further agree that the legality of distributing code not
under the GPL that uses EXPORT_GPL symbols hinges on whether the works
distributed actually *are* derivative works of the covered works and not on
the author's opinion. Neither the authors of GPL'd works nor the GPL can set
out the scope of the GPL's authority -- that comes from copyright law.
DS
On 31/3/2005, at 08:30, John Pearson wrote:
>
> E.g.: suppose there are 2 snack bars within 100 yards of a school; one
> is out of sight, across an intersection and down a side street, and one
> is clearly visible across an empty lot. For years the lot has been
> unfenced and, human nature being what it is, kids just walk across the
> open lot. The owner of the lot then decides to put up a high fence
> around it with a combination lock on the gate (now he's raising
> chinchillas,
> or peaches; he won't say) so all the kids start going to the other
> snackbar,
> except for a few that he trusts with the combination. It seems to me
> you're suggesting that the snackbar owner who's lost out would have
> an action for restraint of trade; I can't see it myself.
Well in Austria there is a law: if you walk through an area that is not
public and do this for a very long time years and suddenly the owner
stops you from doing this, you could sue him for stopping you doing a
usual thing.
But real life issues and software laws are more than two kind of shoes.
They are two kind of universes.
Right and Code changes always happens, some approve i some not. And
there will be always people not like it.
Fact is the kernel is a GPL thing so logically the coders want to keep
it GPL,
lg, clemens
Zan Lynx wrote:
>
> That does not really make sense, as the driver model code could be used
> for ndiswrapper, for example. That would not make the Windows net
> drivers derived code of the Linux kernel. ndiswrapper, yes it would be.
> Binary driver blobs, no.
The Windows net drivers are not (we believe) compiled using GPL'd
header files and their included macros, asm code, etc..
Probably all Linux binary drivers *are* compiled using GPL'd header files,
and thus are themselves subject to the GPL.
Cheers
Mark wrote:
> Probably all Linux binary drivers *are* compiled using GPL'd header files,
> and thus are themselves subject to the GPL.
I doubt that there is a consensus that simply compiling something with
a GPL header necessarily and always subjects it to the GPL. See your lawyer.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373, 1.925.600.0401
On Sun, Apr 03, 2005 at 09:01:45PM -0700, Paul Jackson wrote:
> Mark wrote:
> > Probably all Linux binary drivers *are* compiled using GPL'd header files,
> > and thus are themselves subject to the GPL.
>
> I doubt that there is a consensus that simply compiling something with
> a GPL header necessarily and always subjects it to the GPL. See your lawyer.
For a header as in interface maybe not. For headers containing significant
code in inline functions the binary drivers is definitly a derived work.