Hello!
It have come to my attention that a patch has been committed to the
kernel with the explicit purpose of tainting ndiswrapper - the kernel
module allowing Windows NDIS drivers for Ethernet and Wireless cards to
be used by the kernel.
That's the commit in question:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9
It is not the first time it has happened. The same was done in October
2006. A heated discussion ensued, and the patch was reverted as
erroneous. For those wishing to refresh their memories, this LWN story
would be a great starting point:
http://lwn.net/Articles/205644/
I'd like to see this mistake to be fixed without lengthy arguments this
time around.
Just to reiterate some points from the old discussion:
- ndiswrapper is licensed under GPL
- ndiswrapper needs GPL-only symbols
- tainting ndiswrapper denies its access to GPL-only symbols
- denying ndiswrapper access to GPL-only symbols is unfair and not based
on any copyright law
- denying ndiswrapper access to GPL-only symbols makes it impossible for
ndiswrapper to function
- no copyright violation is involved, as Windows drivers are not derived
from Linux sources
- Windows drivers don't call GPL-only symbols directly; ndiswrapper
stands in the middle and sanitizes the access
- it's a fair game to taint the kernel in some way if ndiswrapper has
been loaded at some point, since tainting per se is just an indicator
that the kernel has been used in an unsupportable way
- if this change stands, ndiswrapper will be renamed, which would only
create more confusion and would thus defeat the purpose of tainting
- ndiswrapper is used by kernel developers to create native drivers
- ndiswrapper is a stepping stone towards a completely free OS; take it
away and see less users, less testers and less reverse engineering
efforts
--
Regards,
Pavel Roskin
On Tue, 29 Jan 2008 16:22:45 EST, Pavel Roskin said:
> Hello!
>
> It have come to my attention that a patch has been committed to the
> kernel with the explicit purpose of tainting ndiswrapper - the kernel
> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> be used by the kernel.
At some point, a compromise position of "Have ndiswrapper do the tainting
if it loads something with contentious licensing" was suggested - whatever
happened to that?
(If for no other reason than if you load ndiswrapper for testing, and then
do *not* actually load something, your kernel should remain untainted...)
--- [email protected] wrote:
> At some point, a compromise position of "Have ndiswrapper do the tainting
> if it loads something with contentious licensing" was suggested - whatever
> happened to that?
>
> (If for no other reason than if you load ndiswrapper for testing, and then
> do *not* actually load something, your kernel should remain untainted...)
ndiswrapper does taint the kernel when a Windows driver is loaded.
Giri
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
> - it's a fair game to taint the kernel in some way if ndiswrapper has
> been loaded at some point, since tainting per se is just an indicator
> that the kernel has been used in an unsupportable way
That's all the patch appears to do. Se the taint flag.
> - if this change stands, ndiswrapper will be renamed, which would only
> create more confusion and would thus defeat the purpose of tainting
Not a productive approach. It will only harm support for everyone.
On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
> Hello!
>
> It have come to my attention that a patch has been committed to the
> kernel with the explicit purpose of tainting ndiswrapper - the kernel
> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> be used by the kernel.
>...
> Just to reiterate some points from the old discussion:
>...
> - no copyright violation is involved, as Windows drivers are not derived
> from Linux sources
>...
It is interesting that someone posting with an @gnu.org address claims
that dynamic linking of not GPLv2 compatible code into GPLv2 code was
not a copyright violation.
Is it an official statement of the FSF that such linking is considered
legal?
(RMS added to Cc)
> Regards,
> Pavel Roskin
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 Jan 30 2008 00:57, Adrian Bunk wrote:
>> Hello!
>>
>> It have come to my attention that a patch has been committed to the
>> kernel with the explicit purpose of tainting ndiswrapper - the kernel
>> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
>> be used by the kernel.
>>...
>> Just to reiterate some points from the old discussion:
>>...
>> - no copyright violation is involved, as Windows drivers are not derived
>> from Linux sources
>>...
>
>It is interesting that someone posting with an @gnu.org address claims
>that dynamic linking of not GPLv2 compatible code into GPLv2 code was
>not a copyright violation.
>
How about you see this as syscall linkage or pipe linkage^2 instead?
Linux and GNU, respectively, allow these.
^2 gplprogram <input.txt | proprietaryprogram >output.txt
> It is interesting that someone posting with an @gnu.org address claims
> that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> not a copyright violation.
>
> Is it an official statement of the FSF that such linking is considered
> legal?
Probably in the same way that gmail represents official google policy ;)
Alan
On Tue, 2008-01-29 at 17:27 -0500, [email protected] wrote:
> On Tue, 29 Jan 2008 16:22:45 EST, Pavel Roskin said:
> > Hello!
> >
> > It have come to my attention that a patch has been committed to the
> > kernel with the explicit purpose of tainting ndiswrapper - the kernel
> > module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> > be used by the kernel.
>
> At some point, a compromise position of "Have ndiswrapper do the tainting
> if it loads something with contentious licensing" was suggested - whatever
> happened to that?
>
> (If for no other reason than if you load ndiswrapper for testing, and then
> do *not* actually load something, your kernel should remain untainted...)
We should distinguish kernel tainting and module tainting. Kernel
tainting affects the stack dumps. Module tainting affects access to
GPL-only symbols.
Kernel tainting for "ndiswrapper" is in the code already. The patch I'm
complaining about is replacing kernel tainting with both kinds of
tainting.
Of course, ndiswrapper could taint itself as a module, but it would be a
purely symbolic act, since the module would be loaded already, and the
GPL-only symbols resolved.
--
Regards,
Pavel Roskin
Adrian Bunk <[email protected]> writes:
> On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
>> Hello!
>>
>> It have come to my attention that a patch has been committed to the
>> kernel with the explicit purpose of tainting ndiswrapper - the kernel
>> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
>> be used by the kernel.
>>...
>> Just to reiterate some points from the old discussion:
>>...
>> - no copyright violation is involved, as Windows drivers are not derived
>> from Linux sources
>>...
>
> It is interesting that someone posting with an @gnu.org address claims
> that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> not a copyright violation.
As long as you don't distribute /proc/kcore, I can't see how the GPL
would have any say in the matter. The Windows drivers are (unrelated
violations aside) clearly not derived from GPL code.
IANAL
--
M?ns Rullg?rd
[email protected]
On Wed, 2008-01-30 at 00:57 +0200, Adrian Bunk wrote:
> On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
> > Hello!
> >
> > It have come to my attention that a patch has been committed to the
> > kernel with the explicit purpose of tainting ndiswrapper - the kernel
> > module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> > be used by the kernel.
> >...
> > Just to reiterate some points from the old discussion:
> >...
> > - no copyright violation is involved, as Windows drivers are not derived
> > from Linux sources
> >...
>
> It is interesting that someone posting with an @gnu.org address claims
> that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> not a copyright violation.
No, I'm representing myself only. I don't think you represent all
kernel developers when posting from the kernel.org address.
I'm actually surprised that you are raising this issue. If the
motivation to ban ndiswrapper is based on the copyright law, doesn't it
meant that we have DRM in the kernel now? Is Linux going to enforce
copyright laws across the world?
> Is it an official statement of the FSF that such linking is considered
> legal?
Absolutely not.
> (RMS added to Cc)
I, for one, would welcome an informed position of the FSF. It may have
interesting implications for Wine, ReactOS, mplayer, qemu, Java and many
other programs loading non-free compiled code at the run time.
--
Regards,
Pavel Roskin
On Tue, 2008-01-29 at 22:45 +0000, Alan Cox wrote:
> > - it's a fair game to taint the kernel in some way if ndiswrapper has
> > been loaded at some point, since tainting per se is just an indicator
> > that the kernel has been used in an unsupportable way
>
> That's all the patch appears to do. Se the taint flag.
There are two taint flags. Let's see:
if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint(TAINT_PROPRIETARY_MODULE);
+ add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
And that's add_taint_module():
static inline void add_taint_module(struct module *mod, unsigned flag)
{
add_taint(flag);
mod->taints |= flag;
}
The module taint is set before the symbols are resolved. Therefore, the
GPL-only symbols won't be resolved.
> > - if this change stands, ndiswrapper will be renamed, which would only
> > create more confusion and would thus defeat the purpose of tainting
>
> Not a productive approach. It will only harm support for everyone.
I know. But ndiswrapper is a maintained program, which is regularly
updated to work with the latest kernels. If the author fails to make
the necessary updates for the next kernel for whatever reason, somebody
will fork it and make such updates.
--
Regards,
Pavel Roskin
On Tue, 2008-01-29 at 16:22 -0500, Pavel Roskin wrote:
> Hello!
>
> It have come to my attention that a patch has been committed to the
> kernel with the explicit purpose of tainting ndiswrapper - the kernel
> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> be used by the kernel.
>
> That's the commit in question:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9
Yup. There was (what I thought was) a bug in the existing logic (an
explicit match on "ndiswrapper", and a setting of the global kernel
taint flags) and I corrected it to do what I thought it was actually
intending to do, but hadn't been. Was I mistaken? What's the point of
setting the global taint if we don't know why we set that?
> - ndiswrapper is licensed under GPL
Yes it is. But I thought the existing code was intending to taint the
kernel (that's what it does), so it would really help to identify why it
tainted the kernel, by calling add_taint_module instead of add_taint. I
didn't put the existing match in there...don't shoot the messenger :)
> - ndiswrapper needs GPL-only symbols
Another fix would be for ndiswrapper to explicitly set the taint when it
loads a tainted driver? Or do we just want to go back to globally
"tainting" the kernel without assigning the blame to any module?
Jon.
On Tue, Jan 29, 2008 at 06:44:27PM -0500, Pavel Roskin wrote:
> On Wed, 2008-01-30 at 00:57 +0200, Adrian Bunk wrote:
> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
> > > Hello!
> > >
> > > It have come to my attention that a patch has been committed to the
> > > kernel with the explicit purpose of tainting ndiswrapper - the kernel
> > > module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> > > be used by the kernel.
> > >...
> > > Just to reiterate some points from the old discussion:
> > >...
> > > - no copyright violation is involved, as Windows drivers are not derived
> > > from Linux sources
> > >...
> >
> > It is interesting that someone posting with an @gnu.org address claims
> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> > not a copyright violation.
>
> No, I'm representing myself only. I don't think you represent all
> kernel developers when posting from the kernel.org address.
I'm not using my @kernel.org address except for kernel issues and I'm
not using a company address in linux-kernel discussions.
Mailing lists of a project or a company are something completely
different from using a project or company address outside of the
project.
> I'm actually surprised that you are raising this issue. If the
> motivation to ban ndiswrapper is based on the copyright law, doesn't it
> meant that we have DRM in the kernel now? Is Linux going to enforce
> copyright laws across the world?
>
> > Is it an official statement of the FSF that such linking is considered
> > legal?
>
> Absolutely not.
>
> > (RMS added to Cc)
>
> I, for one, would welcome an informed position of the FSF. It may have
> interesting implications for Wine, ReactOS, mplayer, qemu, Java and many
> other programs loading non-free compiled code at the run time.
Wine is licenced under the terms of the LGPL.
ReactOS is licenced under the terms of the GPL with a licence
exception for runtime linking of non-free modules.
QEMU is licenced under the terms of the GPL with a licence exception for
runtime linking with libqemu.a.
GNU classpath (and libgcj) are licenced under the terms of the GPL with
a licence exception for runtime linking with it.
As you can see, all of the above explicitely address this issue.
The only program from your list that has a fishy licencing is mplayer.
> Regards,
> Pavel Roskin
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 Tue, 2008-01-29 at 18:21 -0500, Pavel Roskin wrote:
> Of course, ndiswrapper could taint itself as a module, but it would be a
> purely symbolic act, since the module would be loaded already, and the
> GPL-only symbols resolved.
I think that might be an acceptable alternative to the current explicit
matching on "ndiswrapper" in the kernel. Something should say "hey, the
kernel is tainted, and I'm the reason why", not just set a global taint.
Note: personal opinion aside, I actually wasn't trying to start a huge
copyright debate here. I just thought the taint flag logic was wrong (if
we're going to match on specific modules, we should mark them) - an
alternative would be a new type of taint flag?
Jon.
On Tue, Jan 29, 2008 at 11:25:22PM +0000, Måns Rullgård wrote:
> Adrian Bunk <[email protected]> writes:
>
> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
> >> Hello!
> >>
> >> It have come to my attention that a patch has been committed to the
> >> kernel with the explicit purpose of tainting ndiswrapper - the kernel
> >> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
> >> be used by the kernel.
> >>...
> >> Just to reiterate some points from the old discussion:
> >>...
> >> - no copyright violation is involved, as Windows drivers are not derived
> >> from Linux sources
> >>...
> >
> > It is interesting that someone posting with an @gnu.org address claims
> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> > not a copyright violation.
>
> As long as you don't distribute /proc/kcore, I can't see how the GPL
> would have any say in the matter. The Windows drivers are (unrelated
> violations aside) clearly not derived from GPL code.
Someone might sell a laptop with Linux installed?
> IANAL
>
> Måns Rullgård
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 Jan 29 2008 19:20, Jon Masters wrote:
>On Tue, 2008-01-29 at 16:22 -0500, Pavel Roskin wrote:
>>
>> It have come to my attention that a patch has been committed to the
>> kernel with the explicit purpose of tainting ndiswrapper - the kernel
>> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
>> be used by the kernel.
>>
>> That's the commit in question:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9
>
>Yup. There was (what I thought was) a bug in the existing logic (an
>explicit match on "ndiswrapper", and a setting of the global kernel
>taint flags) and I corrected it to do what I thought it was actually
>intending to do, but hadn't been. Was I mistaken? What's the point of
>setting the global taint if we don't know why we set that?
ftr, as a by-stander, I perceived the past discussions as a lack of
trust from other kernel developers that Ndiswrapper will always set
the taint flags correctly. (ndiswrapper code does not go through lkml
review so the magic line might just change between tarballs.)
>> - ndiswrapper is licensed under GPL
>
>Yes it is. But I thought the existing code was intending to taint the
>kernel (that's what it does), so it would really help to identify why it
>tainted the kernel, by calling add_taint_module instead of add_taint. I
>didn't put the existing match in there...don't shoot the messenger :)
>
>> - ndiswrapper needs GPL-only symbols
>
>Another fix would be for ndiswrapper to explicitly set the taint when it
>loads a tainted driver? Or do we just want to go back to globally
>"tainting" the kernel without assigning the blame to any module?
I think the global taint flag is always needed because you never know
what the proprietary module actually did to our memory. Unloading
the driver and ndiswrapper should retain some sort of taintedness
should it oops much later.
--- Adrian Bunk <[email protected]> wrote:
> It is interesting that someone posting with an @gnu.org address claims
> that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> not a copyright violation.
There is no copyright violation: ndiswrapper is licensed under GPLv2. And the
Windows driver is not linked to kernel code - only ndiswrapper functions are
linked to kernel.
In case that is not clear, ndiswsrapper is an implementation of NDIS and some
Windows kernel API functions in Linux kernel. The Windows driver is linked to
these functions so the driver works as if it is working under Windows.
Giri
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
On Wed, 2008-01-30 at 01:35 +0100, Jan Engelhardt wrote:
> On Jan 29 2008 19:20, Jon Masters wrote:
> >Another fix would be for ndiswrapper to explicitly set the taint when it
> >loads a tainted driver? Or do we just want to go back to globally
> >"tainting" the kernel without assigning the blame to any module?
>
> I think the global taint flag is always needed because you never know
> what the proprietary module actually did to our memory. Unloading
> the driver and ndiswrapper should retain some sort of taintedness
> should it oops much later.
It will. The module taint variant also sets the global taint. But it
helps to know why you set that if you oops now and get a list of
modules. Yeah, we know about ndiswrapper, I just mean in general.
Man, that'll teach me to send one-liners without checking the entire
history of LWN stories beforehand. I'm going to the gym to escape :)
Jon.
Adrian Bunk <[email protected]> writes:
> On Tue, Jan 29, 2008 at 11:25:22PM +0000, M?ns Rullg?rd wrote:
>> Adrian Bunk <[email protected]> writes:
>>
>> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
>> >> Hello!
>> >>
>> >> It have come to my attention that a patch has been committed to the
>> >> kernel with the explicit purpose of tainting ndiswrapper - the kernel
>> >> module allowing Windows NDIS drivers for Ethernet and Wireless cards to
>> >> be used by the kernel.
>> >>...
>> >> Just to reiterate some points from the old discussion:
>> >>...
>> >> - no copyright violation is involved, as Windows drivers are not derived
>> >> from Linux sources
>> >>...
>> >
>> > It is interesting that someone posting with an @gnu.org address claims
>> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
>> > not a copyright violation.
>>
>> As long as you don't distribute /proc/kcore, I can't see how the GPL
>> would have any say in the matter. The Windows drivers are (unrelated
>> violations aside) clearly not derived from GPL code.
>
> Someone might sell a laptop with Linux installed?
Not a problem, unless it is booted when sold. Even that might not be
a problem, since it would be a matter of transferring ownership of a
single copy, not creating and distributing new copies, and the GPL
does is only concerned with the latter.
--
M?ns Rullg?rd
[email protected]
On Tue, 2008-01-29 at 19:48 -0500, Jon Masters wrote:
> On Wed, 2008-01-30 at 01:35 +0100, Jan Engelhardt wrote:
> > On Jan 29 2008 19:20, Jon Masters wrote:
>
> > >Another fix would be for ndiswrapper to explicitly set the taint when it
> > >loads a tainted driver? Or do we just want to go back to globally
> > >"tainting" the kernel without assigning the blame to any module?
> >
> > I think the global taint flag is always needed because you never know
> > what the proprietary module actually did to our memory. Unloading
> > the driver and ndiswrapper should retain some sort of taintedness
> > should it oops much later.
>
> It will. The module taint variant also sets the global taint. But it
> helps to know why you set that if you oops now and get a list of
> modules. Yeah, we know about ndiswrapper, I just mean in general.
Then we can move add_taint_module() for ndiswrapper closer to the end of
load_module(), so that it's not prevented from using GPL-only symbols.
driverloader should stay where it is, since we don't trust its license.
> Man, that'll teach me to send one-liners without checking the entire
> history of LWN stories beforehand. I'm going to the gym to escape :)
I'm actually so relieved that it has been mistake, just like it was the
last time. Good luck!
--
Regards,
Pavel Roskin
On Tuesday 29 January 2008 19:46:06 M?ns Rullg?rd wrote:
> Adrian Bunk <[email protected]> writes:
> > On Tue, Jan 29, 2008 at 11:25:22PM +0000, M?ns Rullg?rd wrote:
> >> Adrian Bunk <[email protected]> writes:
> >> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
> >> >> Hello!
> >> >>
> >> >> It have come to my attention that a patch has been committed to the
> >> >> kernel with the explicit purpose of tainting ndiswrapper - the kernel
> >> >> module allowing Windows NDIS drivers for Ethernet and Wireless cards
> >> >> to be used by the kernel.
> >> >>...
> >> >> Just to reiterate some points from the old discussion:
> >> >>...
> >> >> - no copyright violation is involved, as Windows drivers are not
> >> >> derived from Linux sources
> >> >>...
> >> >
> >> > It is interesting that someone posting with an @gnu.org address claims
> >> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> >> > not a copyright violation.
> >>
> >> As long as you don't distribute /proc/kcore, I can't see how the GPL
> >> would have any say in the matter. The Windows drivers are (unrelated
> >> violations aside) clearly not derived from GPL code.
Only because of the distribution of the windows driver. As I understand US and
International copyright law, dynamic linking cannot create a new, derivative
work and hence cannot carry its own license. (It's a "machine translation")
What that means is that there is no violation of the GPL if GPL'd code is
linked to proprietary code and then distributed. However, the GPLv3 does have
language in it that would require the proprietary code to also be
distributed.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
On Tue, 2008-01-29 at 19:20 -0500, Jon Masters wrote:
> Yes it is. But I thought the existing code was intending to taint the
> kernel (that's what it does), so it would really help to identify why it
> tainted the kernel, by calling add_taint_module instead of add_taint. I
> didn't put the existing match in there...don't shoot the messenger :)
So, it's the same thing as in year 2006. Good intentions, unexpected
side effects, and a long discussion.
> > - ndiswrapper needs GPL-only symbols
>
> Another fix would be for ndiswrapper to explicitly set the taint when it
> loads a tainted driver? Or do we just want to go back to globally
> "tainting" the kernel without assigning the blame to any module?
It taints the kernel, but not the module. I could add tainting the
module to the ndiswrapper code, but it would reply on the internals of
the "struct module". And I think we really don't want modules tainting
and untainting themselves by changing THIS_MODULE->taints. It's a
Pandora's box that's better kept closed.
--
Regards,
Pavel Roskin
On Wed, 2008-01-30 at 02:25 +0200, Adrian Bunk wrote:
> > > It is interesting that someone posting with an @gnu.org address claims
> > > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> > > not a copyright violation.
> >
> > No, I'm representing myself only. I don't think you represent all
> > kernel developers when posting from the kernel.org address.
>
> I'm not using my @kernel.org address except for kernel issues and I'm
> not using a company address in linux-kernel discussions.
>
> Mailing lists of a project or a company are something completely
> different from using a project or company address outside of the
> project.
OK, I'll think about it.
> > I, for one, would welcome an informed position of the FSF. It may have
> > interesting implications for Wine, ReactOS, mplayer, qemu, Java and many
> > other programs loading non-free compiled code at the run time.
>
> Wine is licenced under the terms of the LGPL.
>
> ReactOS is licenced under the terms of the GPL with a licence
> exception for runtime linking of non-free modules.
>
> QEMU is licenced under the terms of the GPL with a licence exception for
> runtime linking with libqemu.a.
>
> GNU classpath (and libgcj) are licenced under the terms of the GPL with
> a licence exception for runtime linking with it.
>
> As you can see, all of the above explicitely address this issue.
>
> The only program from your list that has a fishy licencing is mplayer.
Thanks for the detailed analysis!
Anyway, as far as I know, copyright covers copying of works, and dynamic
linking never creates anything suitable for copying. The "derived work"
stays in memory, just like it does when a proprietary program runs on
top of the Linux kernel. Memory dumps might be illegal to distribute
though.
I'm not a lawyer and the above is not a legal advice. I don't represent
Free Software Foundation.
--
Regards,
Pavel Roskin
On Jan 29 2008 20:48, Pavel Roskin wrote:
>On Tue, 2008-01-29 at 19:20 -0500, Jon Masters wrote:
>
>> Yes it is. But I thought the existing code was intending to taint the
>> kernel (that's what it does), so it would really help to identify why it
>> tainted the kernel, by calling add_taint_module instead of add_taint. I
>> didn't put the existing match in there...don't shoot the messenger :)
>
>So, it's the same thing as in year 2006. Good intentions, unexpected
>side effects, and a long discussion.
Perhaps module.c needs more comments explaining why the ndis line
is there, and why it's correct and noone should touch it.
Pavel Roskin <[email protected]> writes:
>
> static inline void add_taint_module(struct module *mod, unsigned flag)
> {
> add_taint(flag);
> mod->taints |= flag;
> }
>
> The module taint is set before the symbols are resolved. Therefore, the
> GPL-only symbols won't be resolved.
I think using a separate taint flag that does not disable GPL symbols
for the ndiswrapper case would be a fair solution. After all the main
motivation for tainting ndiswrapper is to make it visible in oopses, but not
prevent it from loading in the first place.
How about you submit an incremental patch to do that?
-Andi
On Tue, Jan 29, 2008 at 08:48:21PM -0500, Pavel Roskin wrote:
> On Tue, 2008-01-29 at 19:20 -0500, Jon Masters wrote:
>
> > Yes it is. But I thought the existing code was intending to taint the
> > kernel (that's what it does), so it would really help to identify why it
> > tainted the kernel, by calling add_taint_module instead of add_taint. I
> > didn't put the existing match in there...don't shoot the messenger :)
>
> So, it's the same thing as in year 2006. Good intentions, unexpected
> side effects, and a long discussion.
I wouldn't quite say that. I wasn't going to comment, but...personally,
I actually disagree with the assertions that ndiswrapper isn't causing
proprietary code to link against GPL functions in the kernel (how is
an NDIS implementation any different than a shim layer provided to
load a graphics driver?), but I wasn't trying to make that point.
Rusty - shall we just move the taint to post symbol resolution?
Jon.
On Wed, Jan 30, 2008 at 04:24:50AM +0100, Andi Kleen wrote:
> Pavel Roskin <[email protected]> writes:
> >
> > static inline void add_taint_module(struct module *mod, unsigned flag)
> > {
> > add_taint(flag);
> > mod->taints |= flag;
> > }
> >
> > The module taint is set before the symbols are resolved. Therefore, the
> > GPL-only symbols won't be resolved.
>
> I think using a separate taint flag that does not disable GPL symbols
> for the ndiswrapper case would be a fair solution. After all the main
> motivation for tainting ndiswrapper is to make it visible in oopses, but not
> prevent it from loading in the first place.
>
> How about you submit an incremental patch to do that?
I'll happily submit a patch to do whateve is wanted, and add comments
(I'm also debugging seveal module issues right now, so I have a
good opportunity to look over some of the code).
But do we want to:
*). Add a new taint?
*). Move it later?
It's all trivial, but a policy should be established for the future.
Jon.
On Wed, 2008-01-30 at 05:07 +0000, Jon Masters wrote:
> *). Add a new taint?
> *). Move it later?
>
> It's all trivial, but a policy should be established for the future.
I'd prefer a new taint. It's less likely to break. It provides more
information in the stack dumps. It makes it clear the difference
ndiswrapper and driverloader.
Here's the patch:
---
Introduce a new taint flag for ndiswrapper
Although ndiswrapper loads proprietary code, it's under GPL itself.
Introduce a different taint flag for this case, so that ndiswrapper
retains access to GPL-only symbols.
Add comments to show the difference between driverloader and
ndiswrapper.
Signed-off-by: Pavel Roskin <[email protected]>
---
include/linux/kernel.h | 1 +
kernel/module.c | 5 ++++-
kernel/panic.c | 2 ++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index a7283c9..861a6ae 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -240,6 +240,7 @@ extern enum system_states {
#define TAINT_BAD_PAGE (1<<5)
#define TAINT_USER (1<<6)
#define TAINT_DIE (1<<7)
+#define TAINT_BLOB_WRAPPER (1<<8)
extern void dump_stack(void) __cold;
diff --git a/kernel/module.c b/kernel/module.c
index f6a4e72..a64380c 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1925,8 +1925,11 @@ static struct module *load_module(void __user *umod,
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
+ /* GPL, but may load proprietary code */
if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+ add_taint_module(mod, TAINT_BLOB_WRAPPER);
+
+ /* Wrongly claims to be under GPL */
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
diff --git a/kernel/panic.c b/kernel/panic.c
index da4d6ba..b040812 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -152,6 +152,7 @@ EXPORT_SYMBOL(panic);
* 'M' - System experienced a machine check exception.
* 'B' - System has hit bad_page.
* 'U' - Userspace-defined naughtiness.
+ * 'W' - Wrapper for untrusted binary blobs has been loaded.
*
* The string is overwritten by the next call to print_taint().
*/
@@ -162,6 +163,7 @@ const char *print_tainted(void)
if (tainted) {
snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c",
tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
+ tainted & TAINT_BLOB_WRAPPER ? 'W' : ' ',
tainted & TAINT_FORCED_MODULE ? 'F' : ' ',
tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
tainted & TAINT_FORCED_RMMOD ? 'R' : ' ',
--
Regards,
Pavel Roskin
Jon Masters wrote:
> I wouldn't quite say that. I wasn't going to comment, but...personally,
> I actually disagree with the assertions that ndiswrapper isn't causing
> proprietary code to link against GPL functions in the kernel (how is
> an NDIS implementation any different than a shim layer provided to
> load a graphics driver?), but I wasn't trying to make that point.
Well, as long as *any* part of the kernel ever links to proprietary
code, then GPL functions link to it in exactly the same way ndiswrapper
enables. It's only a matter of how many steps of separation.
A perfectly GPL USB network driver linked to GPL-only functions feeds
data into the kernel where it swirls about and emerges from a
proprietary network filesystem driver, for example.
Pavel Roskin <[email protected]> writes:
> */
> @@ -162,6 +163,7 @@ const char *print_tainted(void)
> if (tainted) {
> snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c",
> tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
> + tainted & TAINT_BLOB_WRAPPER ? 'W' : ' ',
Are you sure you don't need to add a new '%c' to the format string too?
I think gcc should have warned.
-Andi
> tainted & TAINT_FORCED_MODULE ? 'F' : ' ',
> tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
> tainted & TAINT_FORCED_RMMOD ? 'R' : ' ',
>
Quoting Andi Kleen <[email protected]>:
> Pavel Roskin <[email protected]> writes:
>> */
>> @@ -162,6 +163,7 @@ const char *print_tainted(void)
>> if (tainted) {
>> snprintf(buf, sizeof(buf), "Tainted: %c%c%c%c%c%c%c%c",
>> tainted & TAINT_PROPRIETARY_MODULE ? 'P' : 'G',
>> + tainted & TAINT_BLOB_WRAPPER ? 'W' : ' ',
>
>
> Are you sure you don't need to add a new '%c' to the format string too?
> I think gcc should have warned.
You are right! Thanks.
--
Regards,
Pavel Roskin
On Wed, 30 Jan 2008, M?ns Rullg?rd wrote:
> Adrian Bunk <[email protected]> writes:
> > On Tue, Jan 29, 2008 at 11:25:22PM +0000, M?ns Rullg?rd wrote:
> >> As long as you don't distribute /proc/kcore, I can't see how the GPL
> >> would have any say in the matter. The Windows drivers are (unrelated
> >> violations aside) clearly not derived from GPL code.
> >
> > Someone might sell a laptop with Linux installed?
>
> Not a problem, unless it is booted when sold. Even that might not be
> a problem, since it would be a matter of transferring ownership of a
> single copy, not creating and distributing new copies, and the GPL
> does is only concerned with the latter.
Interesting... I never heard about this `transferring ownership of a
single copy not involving GPL'.
Note that some lawyers claim that at trade shows, you should not hand over
a demo device running GPLed code to any interested party, as it would be
distribution...
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 Tue, 29 Jan 2008, Zan Lynx wrote:
> Jon Masters wrote:
> > I wouldn't quite say that. I wasn't going to comment, but...personally,
> > I actually disagree with the assertions that ndiswrapper isn't causing
> > proprietary code to link against GPL functions in the kernel (how is
> > an NDIS implementation any different than a shim layer provided to
> > load a graphics driver?), but I wasn't trying to make that point.
>
> Well, as long as *any* part of the kernel ever links to proprietary code, then
> GPL functions link to it in exactly the same way ndiswrapper enables. It's
> only a matter of how many steps of separation.
>
> A perfectly GPL USB network driver linked to GPL-only functions feeds data
> into the kernel where it swirls about and emerges from a proprietary network
> filesystem driver, for example.
A proprietary network filesystem driver _on a different system_, you
mean? In this case the proprietary code has no direct access to your
kernel data, except through the communication protocol. No tainting is
involved, as all corruption in your kernel is caused by kernel bugs in
visible code that can be debugged.
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
Geert Uytterhoeven <[email protected]> writes:
> On Wed, 30 Jan 2008, Mans Rullgard wrote:
>> Adrian Bunk <[email protected]> writes:
>> > On Tue, Jan 29, 2008 at 11:25:22PM +0000, Mans Rullgard wrote:
>> >> As long as you don't distribute /proc/kcore, I can't see how the GPL
>> >> would have any say in the matter. The Windows drivers are (unrelated
>> >> violations aside) clearly not derived from GPL code.
>> >
>> > Someone might sell a laptop with Linux installed?
>>
>> Not a problem, unless it is booted when sold. Even that might not be
>> a problem, since it would be a matter of transferring ownership of a
>> single copy, not creating and distributing new copies, and the GPL
>> is only concerned with the latter.
>
> Interesting... I never heard about this `transferring ownership of a
> single copy not involving GPL'.
In the US, the first sale doctrine allows one to do pretty much
anything with a given copy of a work, so long as no duplication is
taking place. This includes modifying the work and selling it.
> Note that some lawyers claim that at trade shows, you should not hand over
> a demo device running GPLed code to any interested party, as it would be
> distribution...
Lawyers tend to be overly cautious at times. That said, I am not a
lawyer, and may have misunderstood something. If that is the case, I
apologise for any confusion I may have caused.
--
M?ns Rullg?rd
[email protected]
Geert Uytterhoeven <[email protected]> writes:
> On Tue, 29 Jan 2008, Zan Lynx wrote:
>> Jon Masters wrote:
>> > I wouldn't quite say that. I wasn't going to comment, but...personally,
>> > I actually disagree with the assertions that ndiswrapper isn't causing
>> > proprietary code to link against GPL functions in the kernel (how is
>> > an NDIS implementation any different than a shim layer provided to
>> > load a graphics driver?), but I wasn't trying to make that point.
>>
>> Well, as long as *any* part of the kernel ever links to proprietary
>> code, then GPL functions link to it in exactly the same way
>> ndiswrapper enables. It's only a matter of how many steps of
>> separation.
>>
>> A perfectly GPL USB network driver linked to GPL-only functions
>> feeds data into the kernel where it swirls about and emerges from a
>> proprietary network filesystem driver, for example.
>
> A proprietary network filesystem driver _on a different system_, you
> mean? In this case the proprietary code has no direct access to your
> kernel data, except through the communication protocol. No tainting is
> involved, as all corruption in your kernel is caused by kernel bugs in
> visible code that can be debugged.
Untrusted code doesn't necessarily violate the GPL. The two issues
are orthogonal.
--
M?ns Rullg?rd
[email protected]
I think you'd be impressed at how little I care about this, and how little I
value my fellow hacker's legal opinions except for humor value.
Let ndiswrapper do the taint itself, let's revert the patch and add a damn
comment: Jon was right to clean up such unexplained crap.
Rusty.
On Tue, Jan 29, 2008 at 09:02:35PM -0500, Pavel Roskin wrote:
> On Wed, 2008-01-30 at 02:25 +0200, Adrian Bunk wrote:
>
> > > > It is interesting that someone posting with an @gnu.org address claims
> > > > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> > > > not a copyright violation.
> > >
> > > No, I'm representing myself only. I don't think you represent all
> > > kernel developers when posting from the kernel.org address.
> >
> > I'm not using my @kernel.org address except for kernel issues and I'm
> > not using a company address in linux-kernel discussions.
> >
> > Mailing lists of a project or a company are something completely
> > different from using a project or company address outside of the
> > project.
>
> OK, I'll think about it.
>
> > > I, for one, would welcome an informed position of the FSF. It may have
> > > interesting implications for Wine, ReactOS, mplayer, qemu, Java and many
> > > other programs loading non-free compiled code at the run time.
> >
> > Wine is licenced under the terms of the LGPL.
> >
> > ReactOS is licenced under the terms of the GPL with a licence
> > exception for runtime linking of non-free modules.
> >
> > QEMU is licenced under the terms of the GPL with a licence exception for
> > runtime linking with libqemu.a.
> >
> > GNU classpath (and libgcj) are licenced under the terms of the GPL with
> > a licence exception for runtime linking with it.
> >
> > As you can see, all of the above explicitely address this issue.
> >
> > The only program from your list that has a fishy licencing is mplayer.
>
> Thanks for the detailed analysis!
>
> Anyway, as far as I know, copyright covers copying of works,
The GPL might only talk about distribution.
But copyright law is not restricted to copying of work.
IANAL, and I don't know abou the laws in other countries, but at least
in Germany modifications of a copyrighted work require the permission of
the copyright holder.
It's e.g. a not so uncommon problem that someone wants to modify a 30 or
80 years old building, and since the original contract with the
architect did not grant the owner of the building the rights to modify
it he needs to ask the architect (or the architect's heirs) who has the
(nontransferable) copyright on the building for the permission to modify
the building. [1]
> and dynamic
> linking never creates anything suitable for copying. The "derived work"
> stays in memory, just like it does when a proprietary program runs on
> top of the Linux kernel. Memory dumps might be illegal to distribute
> though.
Look at what Geert quoted in this thread as opinion of actual lawyers.
> I'm not a lawyer and the above is not a legal advice. I don't represent
> Free Software Foundation.
>
> Regards,
> Pavel Roskin
cu
Adrian
[1] The building must be above the threshold of originality for giving
the architect a copyright and there are other laws that might
force the copyright holder to allow some modifications.
--
"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 Tue, Jan 29, 2008 at 04:48:10PM -0800, Giridhar Pemmasani wrote:
> --- Adrian Bunk <[email protected]> wrote:
>
> > It is interesting that someone posting with an @gnu.org address claims
> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was
> > not a copyright violation.
>
> There is no copyright violation: ndiswrapper is licensed under GPLv2. And the
> Windows driver is not linked to kernel code - only ndiswrapper functions are
> linked to kernel.
>...
IANAL, but I have serious doubts whether putting some glue layer between
the GPL'ed code and the code with a not GPL compatible licence is really
a legally effictive way of circumventing the GPL.
> Giri
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Jan 30, 2008 at 07:54:35PM +0200, Adrian Bunk wrote:
> The GPL might only talk about distribution.
>
> But copyright law is not restricted to copying of work.
>
> IANAL, and I don't know abou the laws in other countries, but at least
> in Germany modifications of a copyrighted work require the permission of
> the copyright holder.
>
> It's e.g. a not so uncommon problem that someone wants to modify a 30 or
> 80 years old building, and since the original contract with the
> architect did not grant the owner of the building the rights to modify
> it he needs to ask the architect (or the architect's heirs) who has the
> (nontransferable) copyright on the building for the permission to modify
> the building. [1]
Germany does seem to be an odd case that really makes it very difficult
to do perfectly reasonable, desirable and sane things. I am not even
sure the GPL necesarily makes sense under German copyright law. I am
not German so I haven't had to deal with it.
--
Len Sorensen
Adrian Bunk wrote:
> IANAL, but I have serious doubts whether putting some glue layer between
> the GPL'ed code and the code with a not GPL compatible licence is really
> a legally effictive way of circumventing the GPL.
It may depend on the details of the "code with a not GPL compatible
licence".
It's pretty hard to argue that a binary driver written for another OS is
a derivative work of the linux kernel.
Chris
On Wed, Jan 30, 2008 at 01:15:30PM -0500, Lennart Sorensen wrote:
> On Wed, Jan 30, 2008 at 07:54:35PM +0200, Adrian Bunk wrote:
> > The GPL might only talk about distribution.
> >
> > But copyright law is not restricted to copying of work.
> >
> > IANAL, and I don't know abou the laws in other countries, but at least
> > in Germany modifications of a copyrighted work require the permission of
> > the copyright holder.
> >
> > It's e.g. a not so uncommon problem that someone wants to modify a 30 or
> > 80 years old building, and since the original contract with the
> > architect did not grant the owner of the building the rights to modify
> > it he needs to ask the architect (or the architect's heirs) who has the
> > (nontransferable) copyright on the building for the permission to modify
> > the building. [1]
>
> Germany does seem to be an odd case that really makes it very difficult
> to do perfectly reasonable, desirable and sane things. I am not even
> sure the GPL necesarily makes sense under German copyright law. I am
> not German so I haven't had to deal with it.
http://www.jbb.de/judgment_dc_munich_gpl.pdf
http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf
> Len Sorensen
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Jan 30, 2008 at 12:26:00PM -0600, Chris Friesen wrote:
> Adrian Bunk wrote:
>
>> IANAL, but I have serious doubts whether putting some glue layer
>> between the GPL'ed code and the code with a not GPL compatible licence
>> is really a legally effictive way of circumventing the GPL.
>
> It may depend on the details of the "code with a not GPL compatible
> licence".
>
> It's pretty hard to argue that a binary driver written for another OS is
> a derivative work of the linux kernel.
Read the paragraph starting with "These requirements apply to the
modified work as a whole." of the GPLv2.
IANAL, and I would therefore ask a lawyer whether, and if yes under
which circumstances, shipping a binary driver written for another OS
dynamically linked into the Linux kernel would not be a criminal offense.
> Chris
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 Jan 30, 2008 1:54 PM, Adrian Bunk <[email protected]> wrote:
> IANAL, and I would therefore ask a lawyer whether, and if yes under
> which circumstances, shipping a binary driver written for another OS
> dynamically linked into the Linux kernel would not be a criminal offense.
>
Please stop throwing around words like "criminal". If this is in fact
illegal it would be a civil matter.
Lee
On Wed, Jan 30, 2008 at 08:45:38PM +0200, Adrian Bunk wrote:
> http://www.jbb.de/judgment_dc_munich_gpl.pdf
> http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf
Good point. They seem to be the place that actually has enforced the
GPL.
--
Len Sorensen
On Wed, 30 Jan 2008 14:43:27 EST, Lennart Sorensen said:
> On Wed, Jan 30, 2008 at 08:45:38PM +0200, Adrian Bunk wrote:
> > http://www.jbb.de/judgment_dc_munich_gpl.pdf
> > http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf
>
> Good point. They seem to be the place that actually has enforced the
> GPL.
An alternate reading is that it's the only place that has a legal system
so whacked that a case actually went to trial rather than the offending
party just going "Oh foo.. yeah, that *is* what it says, we better comply
in one way or another"...
It all depends what sort of legal system you have/want - I saw a statistic
for our local police department that said that 98% of all their cases last
year ended in plea agreements before going to trial (although to be fair,
that includes traffic violations where the driver just paid the fine before
the trial date came up and similar minor cases). If things actually go to
trial all the time, things get even more bogged down than they already are...
On Wed, Jan 30, 2008 at 02:36:19PM -0500, Lee Revell wrote:
> On Jan 30, 2008 1:54 PM, Adrian Bunk <[email protected]> wrote:
> > IANAL, and I would therefore ask a lawyer whether, and if yes under
> > which circumstances, shipping a binary driver written for another OS
> > dynamically linked into the Linux kernel would not be a criminal offense.
>
> Please stop throwing around words like "criminal". If this is in fact
> illegal it would be a civil matter.
You are living in a country where copyright violations can't bring
people into jail?
> Lee
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
> I wouldn't quite say that. I wasn't going to comment, but...personally,
> I actually disagree with the assertions that ndiswrapper isn't causing
> proprietary code to link against GPL functions in the kernel (how is
> an NDIS implementation any different than a shim layer provided to
> load a graphics driver?), but I wasn't trying to make that point.
By that logic, the kernel should always be tainted since it could
potentially always be linked to non-GPL code.
The ndiswrapper code is just like the kernel. It is GPL, but it could be
linked to non-free code. Any reason why ndiswrapper should be tainted would
equally well argue that any kernel with module-loading capability should be
tainted. Somebody might load a non-free module.
DS
Combined reponses to many fragmented comments in this thread. No two consecutive excerpts are from the same person.
> Interesting... I never heard about this `transferring ownership of a
> single copy not involving GPL'.
>
> Note that some lawyers claim that at trade shows, you should not hand over
> a demo device running GPLed code to any interested party, as it would be
> distribution...
In the United States, 17 USC 109 specifically permits this:
"Notwithstanding the provisions of section 106 (3), the owner of a particular copy or phonorecord lawfully made under this title, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord."
> IANAL, and I don't know abou the laws in other countries, but at least
> in Germany modifications of a copyrighted work require the permission of
> the copyright holder.
Ah, so coloring books are illegal in Germany? Or it's just illegal to color them in? Or you need a special license to do so?
> IANAL, but I have serious doubts whether putting some glue layer between
> the GPL'ed code and the code with a not GPL compatible licence is really
> a legally effictive way of circumventing the GPL.
The GPL has no power to control works that are neither GPL nor derived from GPL works. There is no need to circumvent situations the GPL has no business applying to.
This is a use of the GPL'd code. It's not a distribution and it's not a creative combination. It is, and should be, outside the GPL's scope.
> Read the paragraph starting with "These requirements apply to the
> modified work as a whole." of the GPLv2.
There is no "modified work as a whole" in this case. A machine combination of two or more works produces those two or more works, not a work. Otherwise, the linker itself would be entitled to copyright on the new work, which is nonsense.
For copyright purposes, a work can only be created by creative effort. There is no creative effort in linking the kernel, ndiswrapper, and a Windows driver, so no "modified work as a whole" is created.
A linker cannot create a work because it is incapable of creative effort. If it cannot create a work, it cannot create a derivative work. There is no "modified work as a whole".
Section 2 of the GPL is about creative modifications that form a "work based on the Program". Only a human can do that. GPL section 2 actually makes that fairly clear:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it."
Note that it is only when you distribute the "same sections" as part of a "whole which is a work based on the Program". So these requirements only apply when someone creates a single work.
DS
On Wed, Jan 30, 2008 at 03:26:27PM -0500, [email protected] wrote:
> On Wed, 30 Jan 2008 14:43:27 EST, Lennart Sorensen said:
> > On Wed, Jan 30, 2008 at 08:45:38PM +0200, Adrian Bunk wrote:
> > > http://www.jbb.de/judgment_dc_munich_gpl.pdf
> > > http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf
> >
> > Good point. They seem to be the place that actually has enforced the
> > GPL.
>
> An alternate reading is that it's the only place that has a legal system
> so whacked that a case actually went to trial rather than the offending
> party just going "Oh foo.. yeah, that *is* what it says, we better comply
> in one way or another"...
>
> It all depends what sort of legal system you have/want - I saw a statistic
> for our local police department that said that 98% of all their cases last
> year ended in plea agreements before going to trial (although to be fair,
> that includes traffic violations where the driver just paid the fine before
> the trial date came up and similar minor cases). If things actually go to
> trial all the time, things get even more bogged down than they already are...
If you go to http://www.gpl-violations.org you'll see that Harald has
also successfully enforced his rights under the terms of the GPL as one
of the copyright holders of the Linux kernel in many more cases without
having to go to (German) courts.
There were people who were claiming the GPL was not enforcible at court,
and there are many grey areas of the GPL left where people claim this
and that - and only court decisions will bring clarifications.
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
> > > IANAL, and I would therefore ask a lawyer whether, and if yes under
> > > which circumstances, shipping a binary driver written for another OS
> > > dynamically linked into the Linux kernel would not be a criminal offense.
> >
> > Please stop throwing around words like "criminal". If this is in fact
> > illegal it would be a civil matter.
>
> You are living in a country where copyright violations can't bring
> people into jail?
AFAICS you are misunderstanding the words "criminal" and "civil matter".
AFAIK in german law the difference between the two is that "criminal"
offences are prosecuted by the government out of their own accord while
"civil matters" require someone else to sue.
Murder and robbery are criminal offences.
Assuming the above is correct then copyright violations definitely are
"civil matters" in germany regardless whether you could go into jail or not.
Best,
Michael
--
Michael Gerdau email: [email protected]
GPG-keys available on request or at public keyserver
Adrian Bunk wrote:
> IANAL, but I have serious doubts whether putting some glue layer between
> the GPL'ed code and the code with a not GPL compatible licence is really
> a legally effictive way of circumventing the GPL.
Just to refresh my memory, I re-read the GPLv2, and specifically the
licence (COPYING file) that comes with Linux 2.6.23, and I see nothing
in it that suggests shims, wrappers or other glue-layers are forbidden.
I see exactly the opposite. This idea that some symbols may only be
dynamically bound to GPL code is fallacy. In the preamble to GPLv2 are
words which make the position clear:
"the GNU General Public icense is intended to guarantee your freedom
to share and change free software"
Childish games, for example blacklisting ndiswrapper, can be defeated,
using patches, by authors of affected programs or anyone else. That's
the freedom guaranteed by GPL.
David Newall wrote:
> This idea that some symbols may only be
> dynamically bound to GPL code is fallacy.
As I understand it, the point of EXPORT_SYMBOL_GPL is not so much the
technical restriction (as you say, the module can lie or the user can
patch the kernel) but to indicate that the kernel developers consider
such interfaces to be internal to the kernel such that anything using it
would be highly likely to be a "derived work" of the kernel.
It's a hint to other developers rather than a prevention measure.
Chris
On Wed, 2008-01-30 at 15:53 -0500, Richard Stallman wrote:
> I don't know what the circumstances are in this case, since the
> description quoted was quite sketchy. I suggest that someone send a
> clear description of the case to [email protected] to find out what
> GPLv2 implies about it.
I don't think anyone implies that there are any real copyright issues
with ndiswrapper, at least in the US. With all differences in
intonations, everybody seems to understand that.
It's understandable that kernel developers feel uncomfortable about
ndiswrapper, which loads non-free Windows drivers into the kernel
memory. It's understandable that kernel developers don't want to
support systems where such code has been running at any time.
It's understandable that ndiswrapper can be considered as an unwelcome
alternative to free drivers, although it's actually used for reverse
engineering and it allows to check that the unsupported hardware is
functional without having to boot to a non-free OS. A kernel that did
something unsupportable becomes "tainted".
Unfortunately, the code for making ndiswrapper taint the kernel is
similar to the code that makes non-free modules (i.e. non-free software
specifically designed to work with Linux) taint the kernel. That's why
is has happened for the second time already that ndiswrapper was lumped
together with non-free modules and disallowed to use certain kernel
facilities that were only meant for free software.
Even though it was done by mistake both times, it looked as an
intentional change every time. It is an emotional issue, but it has
little to do with copyright issues and more with understandable
antipathy of the kernel developer towards non-free software running with
the kernel privileges.
I think the whole idea to bring you into the discussion was based on
misunderstanding of my use of the word "linking". There is a difference
between compiling and linking a non-free program from the source code
against free headers and free libraries and loading non-free code and
making it work by emulating non-free interfaces with free software.
I was merely saying that the later is OK. I was not advocating the
former.
> If my message does not appear on [email protected],
> would one of you please forward it?
It did appear on the list.
> It is not in general the case that "dynamic linking cannot violate the
> GPL". It depends on circumstances. Running a non-free program in a
> process in a GNU/Linux system is not linking of any kind with Linux.
> The program probably links with GNU libc, but the license of GNU libc
> permits that.
A better analogy would be running a non-free program in a free emulator.
I don't have any issues with ndiswrapper. If anyone does, they should
write to FSF, or maybe to FSF Europe if the concern are about European
laws.
--
Regards,
Pavel Roskin
On Wed, 30 Jan 2008 14:36:19 -0500
"Lee Revell" <[email protected]> wrote:
> On Jan 30, 2008 1:54 PM, Adrian Bunk <[email protected]> wrote:
> > IANAL, and I would therefore ask a lawyer whether, and if yes under
> > which circumstances, shipping a binary driver written for another OS
> > dynamically linked into the Linux kernel would not be a criminal offense.
> >
>
> Please stop throwing around words like "criminal". If this is in fact
> illegal it would be a civil matter.
Actually in large parts of europe multiple repeated infractions of
copyright law are criminal matters.
Alan
On Mon, Feb 04, 2008 at 12:42:08PM +0000, Alan Cox wrote:
> On Wed, 30 Jan 2008 14:36:19 -0500
> "Lee Revell" <[email protected]> wrote:
>
> > On Jan 30, 2008 1:54 PM, Adrian Bunk <[email protected]> wrote:
> > > IANAL, and I would therefore ask a lawyer whether, and if yes under
> > > which circumstances, shipping a binary driver written for another OS
> > > dynamically linked into the Linux kernel would not be a criminal offense.
> > >
> >
> > Please stop throwing around words like "criminal". If this is in fact
> > illegal it would be a civil matter.
>
> Actually in large parts of europe multiple repeated infractions of
> copyright law are criminal matters.
"multiple repeated infractions" might not be required.
I remember one case in Germany where offering 272 songs in a P2P network
once resulted in a fine based on criminal law. [1]
Convictions under civil law seem to be easier and result in higher costs
for the copyright violators, so the music industry tends to use the
reportings of offences in Germany only for getting the names of the
people from the IP addresses they have (happened in a five digit number
of cases), don't care about whether the criminal law cases proceed, and
focus on the civil law cases.
But if you are doing more than just filesharing, or even make a profit
out of it, the maximum penalties go up to 5 years in jail...
> Alan
cu
Adrian
[1] http://www.jurpc.de/rechtspr/20040236.pdf
--
"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 Thu, Jan 31, 2008 at 02:00:31AM +0100, Michael Gerdau wrote:
> > > > IANAL, and I would therefore ask a lawyer whether, and if yes under
> > > > which circumstances, shipping a binary driver written for another OS
> > > > dynamically linked into the Linux kernel would not be a criminal offense.
> > >
> > > Please stop throwing around words like "criminal". If this is in fact
> > > illegal it would be a civil matter.
> >
> > You are living in a country where copyright violations can't bring
> > people into jail?
>
> AFAICS you are misunderstanding the words "criminal" and "civil matter".
>
> AFAIK in german law the difference between the two is that "criminal"
> offences are prosecuted by the government out of their own accord while
> "civil matters" require someone else to sue.
>
> Murder and robbery are criminal offences.
>
> Assuming the above is correct then copyright violations definitely are
> "civil matters" in germany regardless whether you could go into jail or not.
Please read a book or ask someone who knows what he is talking about to
explain the basics of legal systems to you.
> Best,
> Michael
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 Fri, Feb 01, 2008 at 12:08:30AM -0500, Pavel Roskin wrote:
> On Wed, 2008-01-30 at 15:53 -0500, Richard Stallman wrote:
> > I don't know what the circumstances are in this case, since the
> > description quoted was quite sketchy. I suggest that someone send a
> > clear description of the case to [email protected] to find out what
> > GPLv2 implies about it.
>
> I don't think anyone implies that there are any real copyright issues
> with ndiswrapper, at least in the US. With all differences in
> intonations, everybody seems to understand that.
>
> It's understandable that kernel developers feel uncomfortable about
> ndiswrapper, which loads non-free Windows drivers into the kernel
> memory. It's understandable that kernel developers don't want to
> support systems where such code has been running at any time.
>
> It's understandable that ndiswrapper can be considered as an unwelcome
> alternative to free drivers, although it's actually used for reverse
> engineering and it allows to check that the unsupported hardware is
> functional without having to boot to a non-free OS. A kernel that did
> something unsupportable becomes "tainted".
>
> Unfortunately, the code for making ndiswrapper taint the kernel is
> similar to the code that makes non-free modules (i.e. non-free software
> specifically designed to work with Linux) taint the kernel. That's why
> is has happened for the second time already that ndiswrapper was lumped
> together with non-free modules and disallowed to use certain kernel
> facilities that were only meant for free software.
>
> Even though it was done by mistake both times, it looked as an
> intentional change every time. It is an emotional issue, but it has
> little to do with copyright issues and more with understandable
> antipathy of the kernel developer towards non-free software running with
> the kernel privileges.
>
> I think the whole idea to bring you into the discussion was based on
> misunderstanding of my use of the word "linking". There is a difference
> between compiling and linking a non-free program from the source code
> against free headers and free libraries and loading non-free code and
> making it work by emulating non-free interfaces with free software.
>
> I was merely saying that the later is OK. I was not advocating the
> former.
>...
The Linux kernel is licenced under the GPLv2.
Ndiswrapper loads and executes code with not GPLv2 compatible licences
in a way in the kernel that might be considered similar to a GPLv2'ed
userspace program dlopen() a dynamic library file with a not GPLv2
compatible licence.
IANAL, but I do think there might be real copyright issues with
ndiswrapper.
> Regards,
> Pavel Roskin
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, 2008-02-06 at 12:50 +0200, Adrian Bunk wrote:
> The Linux kernel is licenced under the GPLv2.
>
> Ndiswrapper loads and executes code with not GPLv2 compatible
> licences
> in a way in the kernel that might be considered similar to a GPLv2'ed
> userspace program dlopen() a dynamic library file with a not GPLv2
> compatible licence.
>
> IANAL, but I do think there might be real copyright issues with
> ndiswrapper.
There are issue as soon as ndiswrapper loads a proprietary NDIS. But a
system with just ndiswrapper loaded shouldn't be tainted.
Xav
Adrian Bunk wrote:
> The Linux kernel is licenced under the GPLv2.
>
> Ndiswrapper loads and executes code with not GPLv2 compatible licences
> in a way in the kernel that might be considered similar to a GPLv2'ed
> userspace program dlopen() a dynamic library file with a not GPLv2
> compatible licence.
>
> IANAL, but I do think there might be real copyright issues with
> ndiswrapper.
Neither the kernel+ndiswrapper nor the non-free driver were developed with knowledge of the other, so there is simply no way one could be a derivative work of the other. Since no creative effort is required to link them together, and the linked result is not fixed in a permanent medium, a derivative work cannot be created by the linking process itself.
In any event, even if it was, this is the normal use of ndiswrapper, and normal use cannot be encumbered by copyright. Otherwise, it would be unwise to color in a coloring book.
So if there is a possible copyright issue, I for one can't imagine what it could be. There simply *cannot* be a copyright issue when one merely uses a work in the normal, intended and expected way.
DS
On Wed, Feb 06, 2008 at 03:38:52AM -0800, David Schwartz wrote:
> >
> > Ndiswrapper loads and executes code with not GPLv2 compatible licences
> > in a way in the kernel that might be considered similar to a GPLv2'ed
> > userspace program dlopen() a dynamic library file with a not GPLv2
> > compatible licence.
> >
> > IANAL, but I do think there might be real copyright issues with
> > ndiswrapper.
>
> Neither the kernel+ndiswrapper nor the non-free driver were
> developed with knowledge of the other, so there is simply no way one
> could be a derivative work of the other. Since no creative effort is
> required to link them together, and the linked result is not fixed
> in a permanent medium, a derivative work cannot be created by the
> linking process itself.
Indeed, there is a similar issue with libss, which was originally
written for use with Kerberos v5, and licensed under an MIT (BSD-style
plus you must not use MIT's name in advertising) license. Kerberos V5
was adapted by Sun to create a propietary product called SEAM (Sun
Enterprise Authentication Mechanism), and contains a program called
kadmin, which uses libss as part of its user interface.
In the meantime, libss was enhanced to use a search path to dlopen the
first readline library it can find (some are GPL, some are
BSD-licensed), so that people could use debugfs while being able to
have command-line editing, and this is shipping in e2fsprogs. I used
dlopen so that use of libreadline is optional; so if it doesn't fit on
a rescue floppy, it's no big deal; you can still use debugfs to edit
an ext2/3/4 filesystem. So there was very much a valid technical
reason for doing what I did; I wasn't trying to circumvent any license
requirements, but trying to solve a perfect valid problem when you
only have 1440k on a 3.5" floppy (and libreadline is 296k, or 21% of
total amount of space available).
But if you compile and install e2fsprogs on Solaris, and then run
kadmin, you can have in one address space the proprietary kadmin
binary from SEAM, the BSD-licensed libss shared library from
e2fsprogs, and the GPL-licensed libreadline shared library.
Answer quickly! Is there a license violation, and if so, who was
responsible for comitting the license violation? This is my favorate
real-life case study that I roll out when I want to torture people who
claim that dynamic linking with a GPL shared library automatically
results a GPL violation. :-)
The bottom line is that you should ask a lawyer, and not believe
anyone who has claimed to give you legal advice, whether or not they
have talked to "dozens of lawyers". What's most important is the
lawyer with whom you have paid money so he can take the facts specific
to your case, and apply them to the relevant legal statues in those
legal jurisdictions applicable for the software/product in question.
Regards,
- Ted