Mailing List Archive: Linux: Kernel

GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

1 2 3 4 5 6 7 8 9

View All

Index | Next | Previous | View Threaded

gregkh at suse

Dec 13, 2006, 2:09 PM

Post #1 of 214 (10204 views)
Permalink

GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
> On Wed, 13 Dec 2006 13:32:50 -0800
> Martin Bligh <mbligh [at] mbligh> wrote:
>
> > So let's come out and ban binary modules, rather than pussyfooting
> > around, if that's what we actually want to do.
>
> Give people 12 months warning (time to work out what they're going to do,
> talk with the legal dept, etc) then make the kernel load only GPL-tagged
> modules.
>
> I think I'd favour that. It would aid those people who are trying to
> obtain device specs, and who are persuading organisations to GPL their drivers.

Ok, I have no objection to that at all. I'll whip up such a patch in a
bit to spit out kernel log messages whenever such a module is loaded so
that people have some warning.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gregkh at suse

Dec 13, 2006, 4:32 PM

Post #2 of 214 (10041 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, Dec 13, 2006 at 02:09:11PM -0800, Greg KH wrote:
> On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
> > On Wed, 13 Dec 2006 13:32:50 -0800
> > Martin Bligh <mbligh [at] mbligh> wrote:
> >
> > > So let's come out and ban binary modules, rather than pussyfooting
> > > around, if that's what we actually want to do.
> >
> > Give people 12 months warning (time to work out what they're going to do,
> > talk with the legal dept, etc) then make the kernel load only GPL-tagged
> > modules.
> >
> > I think I'd favour that. It would aid those people who are trying to
> > obtain device specs, and who are persuading organisations to GPL their drivers.
>
> Ok, I have no objection to that at all. I'll whip up such a patch in a
> bit to spit out kernel log messages whenever such a module is loaded so
> that people have some warning.

Here you go. The wording for the feature-removal-schedule.txt file
could probably be cleaned up. Any suggestions would be welcome.

thanks,

greg k-h

-----------
From: Greg Kroah-Hartmna <gregkh [at] suse>
Subject: Notify non-GPL module loading will be going away in January 2008

Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright. Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been set.

Signed-off-by: Greg Kroah-Hartman <gregkh [at] suse>

---
Documentation/feature-removal-schedule.txt | 9 +++++++++
kernel/module.c | 6 +++++-
2 files changed, 14 insertions(+), 1 deletion(-)

--- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
+++ gregkh-2.6/Documentation/feature-removal-schedule.txt
@@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI
Who: Venkatesh Pallipadi <venkatesh.pallipadi [at] intel>

---------------------------
+
+What: non GPL licensed modules will able to be loaded successfully.
+When: January 2008
+Why: Numerous kernel developers feel that loading non-GPL drivers into the
+ kernel violates the license of the kernel and their copyright.
+
+Who: Greg Kroah-Hartman <greg [at] kroah> or <gregkh [at] suse>
+
+---------------------------
--- gregkh-2.6.orig/kernel/module.c
+++ gregkh-2.6/kernel/module.c
@@ -1393,9 +1393,13 @@ static void set_license(struct module *m
license = "unspecified";

if (!license_is_gpl_compatible(license)) {
- if (!(tainted & TAINT_PROPRIETARY_MODULE))
+ if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
printk(KERN_WARNING "%s: module license '%s' taints "
"kernel.\n", mod->name, license);
+ printk(KERN_WARNING "%s: This module will not be able "
+ "to be loaded after January 1, 2008 due to its "
+ "license.\n", mod->name);
+ }
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

corbet at lwn

Dec 13, 2006, 4:43 PM

Post #3 of 214 (10017 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Greg's patch:

> + printk(KERN_WARNING "%s: This module will not be able "
> + "to be loaded after January 1, 2008 due to its "
> + "license.\n", mod->name);

If you're going to go ahead with this, shouldn't the message say that
the module will not be loadable into *kernels released* after January 1,
2008? I bet a lot of people would read the above to say that their
system will just drop dead of a New Year's hangover, and they'll freak.
I wouldn't want to be the one getting all the email at that point...

jon

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gregkh at suse

Dec 13, 2006, 4:55 PM

Post #4 of 214 (10040 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, Dec 13, 2006 at 05:43:29PM -0700, Jonathan Corbet wrote:
> Greg's patch:
>
> > + printk(KERN_WARNING "%s: This module will not be able "
> > + "to be loaded after January 1, 2008 due to its "
> > + "license.\n", mod->name);
>
> If you're going to go ahead with this, shouldn't the message say that
> the module will not be loadable into *kernels released* after January 1,
> 2008? I bet a lot of people would read the above to say that their
> system will just drop dead of a New Year's hangover, and they'll freak.
> I wouldn't want to be the one getting all the email at that point...

Heh, good point.

An updated version is below.

Oh, and for those who have asked me how we would enforce this after this
date if this decision is made, I'd like to go on record that I will be
glad to take whatever legal means necessary to stop people from
violating this.

Someone also mentioned that we could just put a nice poem into the
kernel module image in order to be able to enforce our copyright license
in any court of law.

Full bellies of fish
Penguins sleep under the moon
Dream of wings that fly

thanks,

greg k-h

--------------

From: Greg Kroah-Hartmna <gregkh [at] suse>
Subject: Notify non-GPL module loading will be going away in January 2008

Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright. Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been set.

Signed-off-by: Greg Kroah-Hartman <gregkh [at] suse>

---
Documentation/feature-removal-schedule.txt | 9 +++++++++
kernel/module.c | 7 ++++++-
2 files changed, 15 insertions(+), 1 deletion(-)

--- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
+++ gregkh-2.6/Documentation/feature-removal-schedule.txt
@@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI
Who: Venkatesh Pallipadi <venkatesh.pallipadi [at] intel>

---------------------------
+
+What: non GPL licensed modules will able to be loaded successfully.
+When: January 2008
+Why: Numerous kernel developers feel that loading non-GPL drivers into the
+ kernel violates the license of the kernel and their copyright.
+
+Who: Greg Kroah-Hartman <greg [at] kroah> <gregkh [at] novell>
+
+---------------------------
--- gregkh-2.6.orig/kernel/module.c
+++ gregkh-2.6/kernel/module.c
@@ -1393,9 +1393,14 @@ static void set_license(struct module *m
license = "unspecified";

if (!license_is_gpl_compatible(license)) {
- if (!(tainted & TAINT_PROPRIETARY_MODULE))
+ if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
printk(KERN_WARNING "%s: module license '%s' taints "
"kernel.\n", mod->name, license);
+ printk(KERN_WARNING "%s: This module will not be able "
+ "to be loaded in any kernel released after "
+ "January 1, 2008 due to its license.\n",
+ mod->name);
+ }
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 13, 2006, 5:00 PM

Post #5 of 214 (10011 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 13 Dec 2006, Greg KH wrote:
>
> Full bellies of fish
> Penguins sleep under the moon
> Dream of wings that fly

Snif. That touched me deep inside.

Linus

PS. Or maybe it was the curry I ate yesterday.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

medwards.linux at gmail

Dec 13, 2006, 5:08 PM

Post #6 of 214 (10014 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

fish for birds alone?
no, teach suits how to leave more
fish to go around

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

kangur at polcom

Dec 13, 2006, 5:30 PM

Post #7 of 214 (10035 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Hi,

I think that...

On Wed, 13 Dec 2006, Greg KH wrote:
> From: Greg Kroah-Hartmna <gregkh [at] suse>

... (most probably) there...

> Subject: Notify non-GPL module loading will be going away in January 2008
>
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright. Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh [at] suse>

... or (less probably) there...

is a typo in your name. :-)

Thanks,

Grzegorz Kulewski

PS. Are you _really_ sure you want this change accepted into mainline
kernel?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gregkh at suse

Dec 13, 2006, 5:58 PM

Post #8 of 214 (10032 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Thu, Dec 14, 2006 at 02:30:26AM +0100, Grzegorz Kulewski wrote:
> Hi,
>
> I think that...
>
> On Wed, 13 Dec 2006, Greg KH wrote:
> >From: Greg Kroah-Hartmna <gregkh [at] suse>
>
> ... (most probably) there...
>
> >Subject: Notify non-GPL module loading will be going away in January 2008
> >
> >Numerous kernel developers feel that loading non-GPL drivers into the
> >kernel violates the license of the kernel and their copyright. Because
> >of this, a one year notice for everyone to address any non-GPL
> >compatible modules has been set.
> >
> >Signed-off-by: Greg Kroah-Hartman <gregkh [at] suse>
>
> ... or (less probably) there...
>
> is a typo in your name. :-)

Heh, thanks. I've also fixed up the wording in the
feature-removal-schedule.txt file to say:
What: non-GPL-licensed modules will no longer be loaded.

The wording I had before was not very easy to understand.

> PS. Are you _really_ sure you want this change accepted into mainline
> kernel?

Yes, I do.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

torvalds at osdl

Dec 13, 2006, 8:15 PM

Post #9 of 214 (10014 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 13 Dec 2006, Greg KH wrote:
>
> Numerous kernel developers feel that loading non-GPL drivers into the
> kernel violates the license of the kernel and their copyright. Because
> of this, a one year notice for everyone to address any non-GPL
> compatible modules has been set.

Btw, I really think this is shortsighted.

It will only result in _exactly_ the crap we were just trying to avoid,
namely stupid "shell game" drivers that don't actually help anything at
all, and move code into user space instead.

What was the point again?

Was the point to alienate people by showing how we're less about the
technology than about licenses?

Was the point to show that we think we can extend our reach past derived
work boundaries by just saying so?

The silly thing is, the people who tend to push most for this are the
exact SAME people who say that the RIAA etc should not be able to tell
people what to do with the music copyrights that they own, and that the
DMCA is bad because it puts technical limits over the rights expressly
granted by copyright law.

Doesn't anybody else see that as being hypocritical?

So it's ok when we do it, but bad when other people do it? Somehow I'm not
surprised, but I still think it's sad how you guys are showing a marked
two-facedness about this.

The fact is, the reason I don't think we should force the issue is very
simple: copyright law is simply _better_off_ when you honor the admittedly
gray issue of "derived work". It's gray. It's not black-and-white. But
being gray is _good_. Putting artificial black-and-white technical
counter-measures is actually bad. It's bad when the RIAA does it, it's bad
when anybody else does it.

If a module arguably isn't a derived work, we simply shouldn't try to say
that its authors have to conform to our worldview.

We should make decisions on TECHNICAL MERIT. And this one is clearly being
pushed on anything but.

I happen to believe that there shouldn't be technical measures that keep
me from watching my DVD or listening to my music on whatever device I damn
well please. Fair use, man. But it should go the other way too: we should
not try to assert _our_ copyright rules on other peoples code that wasn't
derived from ours, or assert _our_ technical measures that keep people
from combining things their way.

If people take our code, they'd better behave according to our rules. But
we shouldn't have to behave according to the RIAA rules just because we
_listen_ to their music. Similarly, nobody should be forced to behave
according to our rules just because they _use_ our system.

There's a big difference between "copy" and "use". It's exatcly the same
issue whether it's music or code. You can't re-distribute other peoples
music (becuase it's _their_ copyright), but they shouldn't put limits on
how you personally _use_ it (because it's _your_ life).

Same goes for code. Copyright is about _distribution_, not about use. We
shouldn't limit how people use the code.

Oh, well. I realize nobody is likely going to listen to me, and everybody
has their opinion set in stone.

That said, I'm going to suggest that you people talk to your COMPANY
LAWYERS on this, and I'm personally not going to merge that particular
code unless you can convince the people you work for to merge it first.

In other words, you guys know my stance. I'll not fight the combined
opinion of other kernel developers, but I sure as hell won't be the first
to merge this, and I sure as hell won't have _my_ tree be the one that
causes this to happen.

So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
first. This is not something where we use my tree as a way to get it to
other trees. This is something where the push had better come from the
other direction.

Because I think it's stupid. So use somebody else than me to push your
political agendas, please.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

notting at redhat

Dec 13, 2006, 9:10 PM

Post #10 of 214 (10029 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Greg KH (gregkh [at] suse) said:
> An updated version is below.

If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL
for removal at the same time, as this essentially renders that irrelevant.

That being said...

First, this is adding the measure at module load time. Any copyright
infringment happens on distribution; module load isn't (necessarily)
that; if I write random code and load it, without ever sending it
to anyone, I'm not violating the license, and this would prevent that.
So it seems somewhat misplaced.

Secondly...

> Oh, and for those who have asked me how we would enforce this after this
> date if this decision is made, I'd like to go on record that I will be
> glad to take whatever legal means necessary to stop people from
> violating this.

There's nothing stopping you undertaking these means now. Addition of
this measure doesn't change the copyright status of any code - what was
a violation before would still be a violation. Copyright's not something
like trademark, where it's sue-or-lose - there's no requirement for
constant action, and there's no requirement for enforcement measures.
If I reproduce and start selling copies of the White album, it doesn't
matter that there wasn't a mechanism on the CD that prevented me doing
that - it's still a copyright violation.

Hence, the only purpose of a clause like this legally would seem to be
to *intentionally* go after people using the DMCA. Which seems... tacky.

Of course, I don't have significant code of note in the kernel, so I can't
really prevent you from doing this if you want...

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

mbligh at mbligh

Dec 13, 2006, 9:39 PM

Post #11 of 214 (10013 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Linus Torvalds wrote:
>
> On Wed, 13 Dec 2006, Greg KH wrote:
>> Numerous kernel developers feel that loading non-GPL drivers into the
>> kernel violates the license of the kernel and their copyright. Because
>> of this, a one year notice for everyone to address any non-GPL
>> compatible modules has been set.
>
> Btw, I really think this is shortsighted.
>
> It will only result in _exactly_ the crap we were just trying to avoid,
> namely stupid "shell game" drivers that don't actually help anything at
> all, and move code into user space instead.

I don't think pushing the drivers into userspace is a good idea at all,
that wasn't what I was getting at. Pushing the problem into a different
space doesn't fix it. IMHO, we're not a microkernel, and drivers for
hardware belong in the kernel.

Whether we allow binary kernel modules or not, I don't think we should
allow an API for userspace drivers - obviously that's not my call, it's
yours, but at least I don't want my opinion / intent misinterpreted.

> What was the point again?
>
> Was the point to alienate people by showing how we're less about the
> technology than about licenses?

The point of banning binary drivers would be to leverage hardware
companies into either releasing open source drivers, or the specs for
someone else to write them. Whether we have that much leverage is
debatable ... I suspect we do in some cases and not in others. It'll
cause some pain, as well as some gain, but I think we'd live through
it pretty well, personally.

The details of the legal minutiae are, I feel, less interesting than
what goal we want to acheive. If we decided to get rid of binary
drivers, we could likely find a way to achieve that. Is it a worthwhile
goal?

I've done both Linux support, where binary drivers are involved, before,
as well as supporting Sequent's Dynix/PTX in the face of a similar
situation with CA Unicenter. It makes life extremely difficult, if not
impossible for a support organisation, for fairly obvious and well known
reasons. When there are two binary drivers from different vendors in
there, any semblence of support becomes farcical.

The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
going. If we don't stand up at some point, and ban binary drivers, we
will, I fear, end up with an unsustainable ecosystem for Linux when
binary drivers become pervasive. I don't want to see Linux destroyed
like that.

I don't think the motive behind what we decide to do should be decided
by legal stuff, though I'm sure we'd have to wade through that to
implement it. It's not about that ... it's about what kind of ecosystem
we want to create, and whether that can be successful or not. Indeed,
there are good arguments both for and against binary drivers on that
basis.

But please can we have the pragmatic argument about what we want to
achieve, and why ... rather than the legal / religious arguments about
licenses? The law is a tool, not an end in itself.

If you don't feel it's legitimate to leverage that tool to achieve a
pragmatic end, fair enough. But please don't assume that the motivation
was legal / religious, at least not on my part.

Perhaps, in the end, we will decide we'd like to ban binary drivers,
but can't. Either for pragmatic reasons (e.g. we don't have enough
leverage to create the hardware support base), or for legal ones
(we don't think it's enforcable). But we seem to be muddled between
those different reasons right now, at least it seems that way to me.

I think allowing binary hardware drivers in userspace hurts our ability
to leverage companies to release hardware specs. The 'grey water' of
binary kernel drivers convinces a lot of them to release stuff, and
Greg and others have pushed that cause, all credit to them. In one way,
it does make the kernel easier to support, but I don't think it really
helps much to make a supportable *system*.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

nigel at nigel

Dec 13, 2006, 9:58 PM

Post #12 of 214 (10011 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Hi.

Good arguments have already been put against it, so I'll just keep it
short and sweet (FWIW)

Nacked-by: Nigel Cunningham <nigel [at] suspend2>

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hzhong at gmail

Dec 13, 2006, 10:01 PM

Post #13 of 214 (10022 views)
Permalink

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

> I think allowing binary hardware drivers in userspace hurts
> our ability to leverage companies to release hardware specs.

If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jmerkey at wolfmountaingroup

Dec 13, 2006, 11:24 PM

Post #14 of 214 (10017 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Well said, and I agree with ALL of your statements contained in this
post. About damn time this was addressed.

Jeff

Linus Torvalds wrote:

>On Wed, 13 Dec 2006, Greg KH wrote:
>
>
>>Numerous kernel developers feel that loading non-GPL drivers into the
>>kernel violates the license of the kernel and their copyright. Because
>>of this, a one year notice for everyone to address any non-GPL
>>compatible modules has been set.
>>
>>
>
>Btw, I really think this is shortsighted.
>
>It will only result in _exactly_ the crap we were just trying to avoid,
>namely stupid "shell game" drivers that don't actually help anything at
>all, and move code into user space instead.
>
>What was the point again?
>
>Was the point to alienate people by showing how we're less about the
>technology than about licenses?
>
>Was the point to show that we think we can extend our reach past derived
>work boundaries by just saying so?
>
>The silly thing is, the people who tend to push most for this are the
>exact SAME people who say that the RIAA etc should not be able to tell
>people what to do with the music copyrights that they own, and that the
>DMCA is bad because it puts technical limits over the rights expressly
>granted by copyright law.
>
>Doesn't anybody else see that as being hypocritical?
>
>So it's ok when we do it, but bad when other people do it? Somehow I'm not
>surprised, but I still think it's sad how you guys are showing a marked
>two-facedness about this.
>
>The fact is, the reason I don't think we should force the issue is very
>simple: copyright law is simply _better_off_ when you honor the admittedly
>gray issue of "derived work". It's gray. It's not black-and-white. But
>being gray is _good_. Putting artificial black-and-white technical
>counter-measures is actually bad. It's bad when the RIAA does it, it's bad
>when anybody else does it.
>
>If a module arguably isn't a derived work, we simply shouldn't try to say
>that its authors have to conform to our worldview.
>
>We should make decisions on TECHNICAL MERIT. And this one is clearly being
>pushed on anything but.
>
>I happen to believe that there shouldn't be technical measures that keep
>me from watching my DVD or listening to my music on whatever device I damn
>well please. Fair use, man. But it should go the other way too: we should
>not try to assert _our_ copyright rules on other peoples code that wasn't
>derived from ours, or assert _our_ technical measures that keep people
>from combining things their way.
>
>If people take our code, they'd better behave according to our rules. But
>we shouldn't have to behave according to the RIAA rules just because we
>_listen_ to their music. Similarly, nobody should be forced to behave
>according to our rules just because they _use_ our system.
>
>There's a big difference between "copy" and "use". It's exatcly the same
>issue whether it's music or code. You can't re-distribute other peoples
>music (becuase it's _their_ copyright), but they shouldn't put limits on
>how you personally _use_ it (because it's _your_ life).
>
>Same goes for code. Copyright is about _distribution_, not about use. We
>shouldn't limit how people use the code.
>
>Oh, well. I realize nobody is likely going to listen to me, and everybody
>has their opinion set in stone.
>
>That said, I'm going to suggest that you people talk to your COMPANY
>LAWYERS on this, and I'm personally not going to merge that particular
>code unless you can convince the people you work for to merge it first.
>
>In other words, you guys know my stance. I'll not fight the combined
>opinion of other kernel developers, but I sure as hell won't be the first
>to merge this, and I sure as hell won't have _my_ tree be the one that
>causes this to happen.
>
>So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
>first. This is not something where we use my tree as a way to get it to
>other trees. This is something where the push had better come from the
>other direction.
>
>Because I think it's stupid. So use somebody else than me to push your
>political agendas, please.
>
> Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo [at] vger
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

davids at webmaster

Dec 13, 2006, 11:54 PM

Post #15 of 214 (10025 views)
Permalink

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

> Someone also mentioned that we could just put a nice poem into the
> kernel module image in order to be able to enforce our copyright license
> in any court of law.
>
> Full bellies of fish
> Penguins sleep under the moon
> Dream of wings that fly
>
> thanks,

Whoever says that has no understanding of copyright law. Copyright law
*only* protects something when there are a large number of equally-good ways
to accomplish the same thing. If there is only one way to accomplish a
particular function, it cannot be protected by copyright.

The Lexmark v. Static Controls case made this pretty clear. Lexmark did
pretty much the same thing with their toner cartridges. You cannot copyright
a password to get the effect of a patent (ownership of every way to
accomplish a particular function).

By the way, the GPL seems to prohibit this. Why is this not an "additional
restriction"? Where does the GPL say that you cannot create and use a
derivative work unless you put a notice in it stating that it is licensed
under the GPL?

I agree with Linus that this is insane hypocrisy. To be totally blunt, the
want to do this -- to control the way other people use the works they own --
is the same evil impulse that drives the RIAA. Shame on you. It's supposed
to be about free as in freedom.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

jmorris at namei

Dec 14, 2006, 12:03 AM

Post #16 of 214 (10023 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 13 Dec 2006, Martin J. Bligh wrote:

> The point of banning binary drivers would be to leverage hardware
> companies into either releasing open source drivers, or the specs for
> someone else to write them.

IMHO, it's up to the users to decide if they want to keep buying hardware
which leads to inferior support, less reliability, decreased security and
all of the other ills associated with binary drivers. Let them also
choose distributions which enact the binary driver policies they agree
with.

Linux is precisely not about forcing people to do things.

- James
--
James Morris
<jmorris [at] namei>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dwmw2 at infradead

Dec 14, 2006, 12:21 AM

Post #17 of 214 (10026 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> If a module arguably isn't a derived work, we simply shouldn't try to say
> that its authors have to conform to our worldview.

I wouldn't argue that _anyone_ else should be exposed to my worldview; I
think the Geneva Convention has something to say about cruel and unusual
punishments.

But I would ask that they honour the licence on the code I release, and
perhaps more importantly on the code I import from other GPL sources.

If they fail to do that under the 'honour system' then I'm not averse to
'enforcing' it by technical measures. (For some value of 'enforcement'
which is easy for them to patch out if their lawyers are _really_ sure
they'll win when I sue them, that is.)

That's the big difference I see between this and the RIAA case you
mention -- in the case of Linux refusing to load non-GPL modules, if the
user _really_ thinks they'll win in court they can just hack it to load
the offending modules again. We are giving a _very_ strong indication of
our intent, but we aren't actually _forcing_ it on them in quite the
same way. With DRM-crippled players and hardware it's not so easy to get
around.

I'm very much in favour of Greg's approach. Give 12 months warning and
then just prevent loading of non-GPL modules.

That way, we get back from the current "binary modules are the status
quo even though some people are currently psyching themselves up to sue
for it" to "binary modules are possible if you're _very_ sure of your
legal position and willing to defend it". I think that's a very good
thing to do.

> We should make decisions on TECHNICAL MERIT. And this one is clearly being
> pushed on anything but.

Not on my part. The thing that makes me _particularly_ vehement about
binary-only crap this week is a very much a technical issue -- in
particular, the fact that we had to do post-production board
modifications to shoot our wireless chip in the head when it goes AWOL,
because the code for it wasn't available to us.

It's come back time and time again -- closed code is undebuggable,
unportable, unimprovable, unworkable. It's a detriment to the whole
system. That's very much a _technical_ issue, to me.

For non-kernel code I'm happy enough to release what I write under a BSD
licence. I'll default to GPL but usually respond favourably to requests
to do otherwise. It _isn't_ a religious issue.

> Same goes for code. Copyright is about _distribution_, not about use.
> We shouldn't limit how people use the code.

And we don't need to. Aside from the fact that they can patch out the
check if they have a genuine need to, they can also mark their module as
GPL without consequences as long as they don't _distribute_ it. We still
don't limit their _use_ of it.

> Oh, well. I realize nobody is likely going to listen to me, and everybody
> has their opinion set in stone.

My opinion is fairly much set from all the times I've come up against
_technical_ issues, I'll admit. But I did listen, and I agree with what
you say about the RIAA 'enforcement'. But I do see that as _very_
different to our 'enforcement', because ours is so easy to patch out
it's more of a 'hint' than a lockdown.

> That said, I'm going to suggest that you people talk to your COMPANY
> LAWYERS on this, and I'm personally not going to merge that particular
> code unless you can convince the people you work for to merge it first.

We've already merged EXPORT_SYMBOL_GPL. Is there a difference other than
one of extent? What about just marking kmalloc as EXPORT_SYMBOL_GPL for
a start? :)

> In other words, you guys know my stance. I'll not fight the combined
> opinion of other kernel developers, but I sure as hell won't be the first
> to merge this, and I sure as hell won't have _my_ tree be the one that
> causes this to happen.
>
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first. This is not something where we use my tree as a way to get it to
> other trees. This is something where the push had better come from the
> other direction.

It's better to have a coherent approach, and for all of us to do it on
roughly the same timescale. Getting the distributions do so this is
going to be like herding cats -- having it upstream and letting it
trickle down is a much better approach, I think.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dwmw2 at infradead

Dec 14, 2006, 12:21 AM

Post #18 of 214 (9993 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 2006-12-13 at 16:55 -0800, Greg KH wrote:
> Oh, and for those who have asked me how we would enforce this after this
> date if this decision is made, I'd like to go on record that I will be
> glad to take whatever legal means necessary to stop people from
> violating this.

I see no _overriding_ reason to wait. This is a technical measure which
they'd need to deliberately work around, and which might make the case
easier to win -- but I think I'm on record already as planning to sue
someone soon for binary-only modules, even without this particular
technical measure to prevent them.

The only reason it hasn't happened so far is because lawyers make me
itch.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

gregkh at suse

Dec 14, 2006, 12:48 AM

Post #19 of 214 (10042 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Thu, Dec 14, 2006 at 12:10:15AM -0500, Bill Nottingham wrote:
>
> Greg KH (gregkh [at] suse) said:
> > An updated version is below.
>
> If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL
> for removal at the same time, as this essentially renders that irrelevant.
>
> That being said...
>
> First, this is adding the measure at module load time. Any copyright
> infringment happens on distribution; module load isn't (necessarily)
> that; if I write random code and load it, without ever sending it
> to anyone, I'm not violating the license, and this would prevent that.
> So it seems somewhat misplaced.

Yes, as Linus points out, this is the main point here, my apologies.
GPL covers distribution, not usage, no matter how much the people
working on v3 want to change that :)

Even if we change the kernel this way, it prevents valid and legal
usages of the kernel. So I am wrong, sorry.

> Secondly...
>
> > Oh, and for those who have asked me how we would enforce this after this
> > date if this decision is made, I'd like to go on record that I will be
> > glad to take whatever legal means necessary to stop people from
> > violating this.
>
> There's nothing stopping you undertaking these means now. Addition of
> this measure doesn't change the copyright status of any code - what was
> a violation before would still be a violation.

Agreed, and I have done this in the past. I only stated this because it
seems that some people keep just wishing this whole issue would go away
if they ignore it.

> Hence, the only purpose of a clause like this legally would seem to be
> to *intentionally* go after people using the DMCA. Which seems... tacky.

Despite my wardrobe consisting mainly of old t-shirts and jeans, I still
never want to be called tacky :)

It's just that I'm so damn tired of this whole thing. I'm tired of
people thinking they have a right to violate my copyright all the time.
I'm tired of people and companies somehow treating our license in ways
that are blatantly wrong and feeling fine about it. Because we are a
loose band of a lot of individuals, and not a company or legal entity,
it seems to give companies the chutzpah to feel that they can get away
with violating our license.

So when someone like Andrew gives me the opportunity to put a stop to
all of the crap that I have to put up with each and every day with a
tiny 2 line patch, I jumped in and took it. I need to sit back and
remember to see the bigger picture some times, so I apologize to
everyone here.

And yes, it is crap that I deal with every day due to the lovely grey
area that is Linux kernel module licensing these days. I have customers
that demand we support them despite them mixing three and more different
closed source kernel modules at once and getting upset that I have no
way to help them out. I have loony video tweakers that hand edit kernel
oopses to try to hide the fact that they are using a binary module
bigger than the sum of the whole kernel and demand that our group fix
their suspend/resume issue for them. I see executives who say one thing
to the community and then turn around and overrule them just because
someone made a horrible purchasing decision on the brand of laptop wifi
card that they purchased. I see lawyers who have their hands tied by
attorney-client rules and can not speak out in public for how they
really feel about licenses and how to interpret them.

And in the midst of all of that are the poor users who have no idea who
to listen to. They don't know what is going on, they "just want to use
their hardware" and don't give a damm about anyone's license. And then
there's the distros out there that listen to those users and give them
the working distro as they see a market for it, and again, as a company,
justify to themselves that it must be ok to violate those kernel
developers rights because no one seems to be stopping them so far.

[.side diversion, it's not the video drivers that really matter here
everyone, those are just so obvious. It's the hundreds of other
blatantly infringing binary kernel modules out there that really matter.
The ones that control filesystems, cluster interconnects, disk arrays,
media codecs, and a whole host of custom hardware. That's the real
problem that Linux faces now and will only get worse in the future.
It's not two stupid little video drivers, I could honestly care less
about them...]

But it's all part of the process, and I can live with it, even if at
times it drives me crazy.

But I know we will succeed, it will just take us a little longer to get
there, so I might as well learn to enjoy the view more.

Even though I really think I can get that patch by the Novell lawyers
and convince management there that it is something we can do, it's not
something that I want to take on, as I think my time can be better spent
coding to advance Linux technically, not fight legal battles.

I'll go delete that module.c patch from my tree now.

thanks,

greg k-h

p.s. I still think the UIO interface is a valid and good one. And yes,
it might cause people to move stuff to userspace that they really should
not be just to get around the GPL issues. But like loots of tools, it
can be used in good and bad ways, we shouldn't prevent the good usages
of it. I'll work to get more real examples using it before
resubmitting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

James at superbug

Dec 14, 2006, 1:34 AM

Post #20 of 214 (9752 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Linus Torvalds wrote:
>
> On Wed, 13 Dec 2006, Greg KH wrote:
>> Numerous kernel developers feel that loading non-GPL drivers into the
>> kernel violates the license of the kernel and their copyright. Because
>> of this, a one year notice for everyone to address any non-GPL
>> compatible modules has been set.
>
> Btw, I really think this is shortsighted.
>
> It will only result in _exactly_ the crap we were just trying to avoid,
> namely stupid "shell game" drivers that don't actually help anything at
> all, and move code into user space instead.
>
> What was the point again?
>
> Was the point to alienate people by showing how we're less about the
> technology than about licenses?
>
> Was the point to show that we think we can extend our reach past derived
> work boundaries by just saying so?
>
> The silly thing is, the people who tend to push most for this are the
> exact SAME people who say that the RIAA etc should not be able to tell
> people what to do with the music copyrights that they own, and that the
> DMCA is bad because it puts technical limits over the rights expressly
> granted by copyright law.
>
> Doesn't anybody else see that as being hypocritical?
>
> So it's ok when we do it, but bad when other people do it? Somehow I'm not
> surprised, but I still think it's sad how you guys are showing a marked
> two-facedness about this.
>
> The fact is, the reason I don't think we should force the issue is very
> simple: copyright law is simply _better_off_ when you honor the admittedly
> gray issue of "derived work". It's gray. It's not black-and-white. But
> being gray is _good_. Putting artificial black-and-white technical
> counter-measures is actually bad. It's bad when the RIAA does it, it's bad
> when anybody else does it.
>
> If a module arguably isn't a derived work, we simply shouldn't try to say
> that its authors have to conform to our worldview.
>
> We should make decisions on TECHNICAL MERIT. And this one is clearly being
> pushed on anything but.
>

I agree with Linus on these points. The kernel should not be enforcing
these issues. Leave the lawyers to do that bit. If companies want to
play in the "Grey Area", then it is at their own risk. Binary drivers
are already difficult and expensive for the companies because they have
to keep updating them as we change the kernel versions. If they do open
source drivers, we update them for them as we change the kernel
versions, so it works out cheaper for the companies involved.

The open source community tends to be able to reverse engineer all
drivers eventually anyway in order to ensure compatibility with all
kernel versions and also ensure that the code is well reviewed and
therefore contains fewer security loopholes, e.g. Atheros Wireless open
source HAL. This also tends to make it rather pointless for companies to
do binary drivers, because all it does is delay the open source version
of the driver and increase the security risk to users. One other example
I have, is that I reverse engineered a sound card driver so that we had
an open source driver for it. Once I had manually documented the sound
card, so we had details of all the registers and how to use them, the
manufacturer finally sent the datasheet to me! A bit late really, but it
certainly did encourage the manufacturer to pass datasheets to
developers. I now have a large array of datasheets from this
manufacturer that save me having to reverse engineer other sound cards
in their range.
Making binary drivers is therefore not a viable way to protect IP. We
are slowly removing the excuses that companies can hide behind as
reasons for not releasing datasheets to open source driver developers.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

Dec 14, 2006, 2:36 AM

Post #21 of 214 (9995 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

> 2008? I bet a lot of people would read the above to say that their
> system will just drop dead of a New Year's hangover, and they'll freak.
> I wouldn't want to be the one getting all the email at that point...

I wouldn't worry. Everyone will have patched it back out again by then,
or made their driver lie about the license. Both of which make the
problem worse not better when it comes to debugging.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

xavier.bestel at free

Dec 14, 2006, 2:49 AM

Post #22 of 214 (9993 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> That said, I'm going to suggest that you people talk to your COMPANY
> LAWYERS on this, and I'm personally not going to merge that particular
> code unless you can convince the people you work for to merge it first.

That's quoting material :) Who's your master, by Linus.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

Dec 14, 2006, 3:14 AM

Post #23 of 214 (9995 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Wed, 13 Dec 2006 22:01:15 -0800
"Hua Zhong" <hzhong [at] gmail> wrote:

> > I think allowing binary hardware drivers in userspace hurts
> > our ability to leverage companies to release hardware specs.
>
> If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?

The FUSE file system interface provides a clean disciplined interface
which allows an fs to live in user space. The uio layer (if its ever
fixed and cleaned up) provides some basic hooks that allow a user space
program to arbitarily control hardware and make a nasty undebuggable mess.

uio also doesn't handle hotplug, pci and other "small" matters.

Now if you wanted to make uio useful at minimum you would need

- PCI support
- The ability to mark sets of I/O addresses for the card as
"unmappable", "read only", "read-write", "any read/root write", "root
read/write"
- A proper IRQ handler
- A DMA interface
- The ability to describe sharing rules

Which actually is a description of the core of the DRM layer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

Dec 14, 2006, 3:25 AM

Post #24 of 214 (9993 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

On Thu, 14 Dec 2006 08:21:20 +0000
David Woodhouse <dwmw2 [at] infradead> wrote:

> If they fail to do that under the 'honour system' then I'm not averse to
> 'enforcing' it by technical measures. (For some value of 'enforcement'
> which is easy for them to patch out if their lawyers are _really_ sure
> they'll win when I sue them, that is.)

There are specific rules against removal of technical measures *even if
the result is legal*. It is an offence in many countries thanks to the
RIAA lobbyists and their corrupt pet politicians to remove technical
measures applied to a -public domain- work.

So your argument doesn't fly.

> Not on my part. The thing that makes me _particularly_ vehement about
> binary-only crap this week is a very much a technical issue -- in
> particular, the fact that we had to do post-production board
> modifications to shoot our wireless chip in the head when it goes AWOL,
> because the code for it wasn't available to us.

Consider it an education process. Hopefully the contracts for the
chips/docs were watertight enough you can sue the offending supplier for
the total cost of the rework. If not then you are really complaining
about getting contract negotiations wrong.

> It's better to have a coherent approach, and for all of us to do it on
> roughly the same timescale. Getting the distributions do so this is
> going to be like herding cats -- having it upstream and letting it
> trickle down is a much better approach, I think.

I doubt any distribution but the FSF "purified" Debian (the one that has
no firmware so doesn't work) would do it.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hjk at linutronix

Dec 14, 2006, 3:31 AM

Post #25 of 214 (9995 views)
Permalink

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] [In reply to]

Am Donnerstag, 14. Dezember 2006 12:14 schrieb Alan:
> On Wed, 13 Dec 2006 22:01:15 -0800
> "Hua Zhong" <hzhong [at] gmail> wrote:
>
> > > I think allowing binary hardware drivers in userspace hurts
> > > our ability to leverage companies to release hardware specs.
> >
> > If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?
>
> The FUSE file system interface provides a clean disciplined interface
> which allows an fs to live in user space. The uio layer (if its ever
> fixed and cleaned up) provides some basic hooks that allow a user space
> program to arbitarily control hardware and make a nasty undebuggable mess.

You think it's easier for a manufacturer of industrial IO cards to
debug a (large) kernel module?

>
> uio also doesn't handle hotplug, pci and other "small" matters.

uio is supposed to be a very thin layer. Hotplug and PCI are already
handled by other subsystems.

>
> Now if you wanted to make uio useful at minimum you would need
>

The majority of industrial IO cards have registers and/or dual port RAM
that can be mapped to user space (even today). We want to add a simple
way to handle interrupts for such cards. That's all.
The fact that there might be some sort of hardware/interrupts/situations
where this is not possible or not so simple isn't that important at the
moment. We can extend the UIO system if somebody actually requires these
extensions.

Hans

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3 4 5 6 7 8 9

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads