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

torvalds at osdl

Dec 14, 2006, 8:52 AM

Post #51 of 214 (5563 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, David Woodhouse wrote:
>
> 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.

This is a total non-argument, and it doesn't get any betetr by being
mindlessly repeated over and over and over again.

The license on the code you released talked about "derived works".

Not "everything I want to".

If a module owner can argue successfully in a court of law that a binary
driver isn't a derived work, then the GPL simply DOES NOT COVER IT!

In other words, people CAN "honor the license" and still not be required
to put their code under the GPL.

And no, including one header file in order to compile against something
does not automatically make something a "derived work". It may, or it may
not. It really isn't up to you to decide whether it does (and notice how
I'm not saying that it's up to _me_ either!).

For example, all the same people who clamor for free software get
absolutely RABID about "fair use". Guess what "fair use" actually MEANS?

Think about it for a moment. It expressly _limits_ the right of copyright
authors to claim "derived work". So if you argue that anything that ever
includes your header file (but none of your code) and compiles against it
is a "derived work", then you are basically very close to arguing that
"fair use" does not exist.

Do you really want to argue that "everything that has touched anything
copyrighted AT ALL is a derived work"? Do you feel lucky, punk?

THAT is why I think this discussion is so hypocritical. Either you accept
that "fair use" and copyrights aren't black-and-white, or you don't.

If you think this is a black-and-white "copyright owners have all the
rights", then you're standing with the RIAA's and the MPAA's of the world.

Me, personally, I think the RIAA and the MPAA is a shithouse. They are
immoral. But guess what? They are immoral exactly _because_ they think
that they automatically own ALL the rights, just because they own the
copyright.

That is what it boils down to: copyright doesn't really give you "absolute
power". This is why I have been _consistently_ arguing that we're not
about "black and white" or "good against evil". It simply isn't that
simple.

I don't like binary modules. I refuse to support them, and if it turns out
that the module was written using Linux code, and just for Linux, I htink
that's a _clear_ copyright violation, and that binary module is obviously
a license violation.

But if the module was written for other systems, and just ported to Linux,
and not using our code, then it's very much debatable whether it's
actually a "derived work". Interfaces don't make "derived works" per se.

Now, is it something you could sue people over? Sure. I actually do
believe that it's very possible that a judge _would_ consider such a
module a derived work, and you can sue people. It probably depends on
circumstances too.

But don't you see the problem with a black-and-white technical measure?

Don't you see the problem with the DMCA and the DVD encryption?

Those kinds of things REMOVE the "reasonable thought" from the equation,
and turn a gradual process into a sharp "right or wrong" situation. AND
THAT IS WRONG. We simply do not LIVE in a world that is black and white.

So if you think somebody violates your copyright, send them a C&D letter,
and eventually take them to court. It's been done. Companies that mis-used
the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing.
I'm not arguing against that at all. What I'm arguing against is the
"blind belief" that you or I have the right to tell people what to do,
just because we own copyrights.

It's not a blind belief that I'm willing to subscribe to. Exactly because
I have _seen_ what that blind belief results in - crap like the DMCA and
the RIAA lawsuits.

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/

bunk at stusta

Dec 14, 2006, 8:54 AM

Post #52 of 214 (5576 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 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people
> > distributing the infringing software for 1 Euro at Ebay.
>
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.
>
> Save the atomic weapons for the people who are straight forward ripping
> off work in routers, tvs and all sorts of appliances.

I'm not saying that I would do it, but it's the way how it would be
done if anyone would do it.

It's not about whether that would be good or bad, the point is that the
ones that will most likely be affected if anyone will ever take legal
actions will not be the big distributions but people selling their old
distributions on Ebay or people operating mirrors.

Cease and desist letters are a lucrative business for lawyers here in
Germany, and such grey areas are simply a timebomb waiting for lawyers
and/or people wanting to harm Linux to (ab)use them.

> Alan

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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, 8:59 AM

Post #53 of 214 (5639 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 01:54:24PM +0100, Hans-J??rgen Koch wrote:
> Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan:
> > > > 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.
> >
> > And if you have a PCI or a hotplug card ? How many industrial I/O cards
> > are still ISA btw ?
>
> Who is talking about ISA? All cards we had in mind are PCI. Of course
> you have to do the usual initialization work in your probe/release or
> init/exit functions. These are just a few lines you find in any
> beginners device-driver-writing book. I don't think that the UIO
> framework could simplify that in a sensible way.

Agreed, you still have to write a kernel driver to handle the pci
probe/disconnect functions and the pci id stuff to use the uio core
properly. That's not in question here at all and please don't think
that uio even attempts to handle this, as that is not what it's job is.

Think of uio as just a "class" of driver, like input or v4l. It's still
up to the driver writer to provide a proper bus interface to the
hardware (pci, usb, etc.) in order for the device to work at all.

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 14, 2006, 9:03 AM

Post #54 of 214 (5569 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, Jeff Garzik wrote:
>
> For the record, I also disagree with the sneaky backdoor way people want to
> add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need.

I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done
properly (and I think we use it fairly well).

I think we _can_ do things where we give clear hints to people that "we
think this is such an internal Linux thing that you simply cannot use this
without being considered a derived work".

It's really just a strong hint about what we consider to be internal. The
fact is, "intent" actually does matter, and as such our _intent_ in saying
"these are very deep and internal interfaces" is actually meaningful -
even in a court of law.

So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure",
I see it as being "documentation".

That said, I think that some people seem to be a bit over-eager to use it.
And I actually think that weakens the rest of them too (imagine a lawyer
saying in front of a judge:

"Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd,
but look, it's a standard function available everywhere else too, and
you can implement it as one line of code, so a module that uses it
clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not
something that means anything"

So this is why I've actually argued in the past for some
EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly
because over-using them actually _weakens_ them, and makes them pointless
both from a documentation _and_ from a legal standpoint.

Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal
sense and has actually made people happier, for what its worth. Of course,
you can get <n*2> different opinions from <n> lawyers, so that may not be
all that meaningful ;)

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/

cw at f00f

Dec 14, 2006, 9:08 AM

Post #55 of 214 (5547 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 09:03:57AM -0800, Linus Torvalds wrote:

> I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> done properly (and I think we use it fairly well).
>
> I think we _can_ do things where we give clear hints to people that
> "we think this is such an internal Linux thing that you simply
> cannot use this without being considered a derived work".

Then why not change the name to something more along those lines?
-
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/

jengelh at linux01

Dec 14, 2006, 9:17 AM

Post #56 of 214 (5548 views)
Permalink

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

On Dec 14 2006 14:10, Arjan van de Ven wrote:
>On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
>> >On Thu, 14 Dec 2006 12:31:16 +0100
>> >Hans-Jürgen Koch wrote:
>> >
>> >You think its any easier to debug because the code now runs in ring 3 but
>> >accessing I/O space.
>>
>> A NULL fault won't oops the system,
>
>.. except when the userspace driver crashes as a result and then the hw
>still crashes the hw (for example via an irq storm or by tying the PCI
>bus or .. )

hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers
(dangling references f.ex.)
However, if the userspace part is dead, no one acknowledges the irq, hence an
irq storm (if not caused by writing bogus stuff into registers) should not
happen.
>
>

-`J'
--

tytso at mit

Dec 14, 2006, 9:17 AM

Post #57 of 214 (5543 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 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people
> > distributing the infringing software for 1 Euro at Ebay.
>
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.

.... or like Microsoft, who is threatening to make war on end-users
instead of settling things with vendors. (One of the reasons why I
personally find the Microsoft promise not to sue _Novell_'s end users
so nasty. Microsoft shouldn't be threatening anyone's users; if they
have a problem, they should be taking it up with the relevant vendor,
not sueing innocent and relatively shallow-pocketed end-users and
distributors.)

One of the things that I find so interesting about how rabid people
get about enforcing GPL-only modules is how they start acting more and
more like the RIAA, MPAA, and Microsoft every day....

- Ted
-
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/

jengelh at linux01

Dec 14, 2006, 9:20 AM

Post #58 of 214 (5548 views)
Permalink

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

> > 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.
>
>Thing is, if kernel.org kernels get patched to disallow binary modules,
>whats to stop Ubuntu (or anyone else) reverting that change in the
>kernels they distribute ? The landscape doesn't really change much,
>given that the majority of Linux end-users are probably running
>distro kernels.

And even if the distros don't change it (all legal issues aside), there's
probably some free user who repacks the distro kernel.

/me eyeballs myself...

-`J'
--
-
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/

jengelh at linux01

Dec 14, 2006, 9:21 AM

Post #59 of 214 (5549 views)
Permalink

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

On Dec 14 2006 08:46, Ben Collins wrote:
>I have to agree with your your whole statement. The gradual changes to
>lock down kernel modules to a particular license(s) tends to mirror the
>slow lock down of content (music/movies) that people complain about so
>loudly. It's basically becoming DRM for code.
>
>I don't think anyone ever expected technical mechanisms to be developed
>to enforce the GPL. It's sort of counter intuitive to why the GPL
>exists, which is to free the code.

"""To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights"""

>Let the licenses and lawyers fight to protect the code. The code doesn't
>need to do that itself. It's got better things to do.

-`J'
--
-
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 14, 2006, 9:33 AM

Post #60 of 214 (5568 views)
Permalink

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

Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver")
and our proprietary
non derived code we sell with our appliances. He is right, everyone else
should just accept
it and get on with life or cry linus a river.

Jeff

Linus Torvalds wrote:

>On Thu, 14 Dec 2006, David Woodhouse wrote:
>
>
>>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.
>>
>>
>
>This is a total non-argument, and it doesn't get any betetr by being
>mindlessly repeated over and over and over again.
>
>The license on the code you released talked about "derived works".
>
>Not "everything I want to".
>
>If a module owner can argue successfully in a court of law that a binary
>driver isn't a derived work, then the GPL simply DOES NOT COVER IT!
>
>In other words, people CAN "honor the license" and still not be required
>to put their code under the GPL.
>
>And no, including one header file in order to compile against something
>does not automatically make something a "derived work". It may, or it may
>not. It really isn't up to you to decide whether it does (and notice how
>I'm not saying that it's up to _me_ either!).
>
>For example, all the same people who clamor for free software get
>absolutely RABID about "fair use". Guess what "fair use" actually MEANS?
>
>Think about it for a moment. It expressly _limits_ the right of copyright
>authors to claim "derived work". So if you argue that anything that ever
>includes your header file (but none of your code) and compiles against it
>is a "derived work", then you are basically very close to arguing that
>"fair use" does not exist.
>
>Do you really want to argue that "everything that has touched anything
>copyrighted AT ALL is a derived work"? Do you feel lucky, punk?
>
>THAT is why I think this discussion is so hypocritical. Either you accept
>that "fair use" and copyrights aren't black-and-white, or you don't.
>
>If you think this is a black-and-white "copyright owners have all the
>rights", then you're standing with the RIAA's and the MPAA's of the world.
>
>Me, personally, I think the RIAA and the MPAA is a shithouse. They are
>immoral. But guess what? They are immoral exactly _because_ they think
>that they automatically own ALL the rights, just because they own the
>copyright.
>
>That is what it boils down to: copyright doesn't really give you "absolute
>power". This is why I have been _consistently_ arguing that we're not
>about "black and white" or "good against evil". It simply isn't that
>simple.
>
>I don't like binary modules. I refuse to support them, and if it turns out
>that the module was written using Linux code, and just for Linux, I htink
>that's a _clear_ copyright violation, and that binary module is obviously
>a license violation.
>
>But if the module was written for other systems, and just ported to Linux,
>and not using our code, then it's very much debatable whether it's
>actually a "derived work". Interfaces don't make "derived works" per se.
>
>Now, is it something you could sue people over? Sure. I actually do
>believe that it's very possible that a judge _would_ consider such a
>module a derived work, and you can sue people. It probably depends on
>circumstances too.
>
>But don't you see the problem with a black-and-white technical measure?
>
>Don't you see the problem with the DMCA and the DVD encryption?
>
>Those kinds of things REMOVE the "reasonable thought" from the equation,
>and turn a gradual process into a sharp "right or wrong" situation. AND
>THAT IS WRONG. We simply do not LIVE in a world that is black and white.
>
>So if you think somebody violates your copyright, send them a C&D letter,
>and eventually take them to court. It's been done. Companies that mis-used
>the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing.
>I'm not arguing against that at all. What I'm arguing against is the
>"blind belief" that you or I have the right to tell people what to do,
>just because we own copyrights.
>
>It's not a blind belief that I'm willing to subscribe to. Exactly because
>I have _seen_ what that blind belief results in - crap like the DMCA and
>the RIAA lawsuits.
>
> 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/

jengelh at linux01

Dec 14, 2006, 9:34 AM

Post #61 of 214 (5548 views)
Permalink

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

>You know what I think hurts us more than anything? You know what
>probably keeps companies from writing drivers or releasing specs? It's
>because they know some non-paid kernel hackers out there will eventually
>reverse engineer it and write the drivers for them. Free development,
>and they didn't even have to release their precious specs.

I don't get them either. If reverse-engineering will release their
precious trade secrets they wanted to protect by making the thing
closed, they could have just asked someone to write a linux driver
for free if they don't have the guts to actually pay
qualified/experienced developers.

-`J'
--
-
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/

hch at infradead

Dec 14, 2006, 9:38 AM

Post #62 of 214 (5538 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 09:08:41AM -0800, Chris Wedgwood wrote:
> On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
>
> > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> > done properly (and I think we use it fairly well).
> >
> > I think we _can_ do things where we give clear hints to people that
> > "we think this is such an internal Linux thing that you simply
> > cannot use this without being considered a derived work".
>
> Then why not change the name to something more along those lines?

Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
-
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/

ben.collins at ubuntu

Dec 14, 2006, 9:49 AM

Post #63 of 214 (5554 views)
Permalink

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

On Thu, 2006-12-14 at 18:21 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 08:46, Ben Collins wrote:
> >I have to agree with your your whole statement. The gradual changes to
> >lock down kernel modules to a particular license(s) tends to mirror the
> >slow lock down of content (music/movies) that people complain about so
> >loudly. It's basically becoming DRM for code.
> >
> >I don't think anyone ever expected technical mechanisms to be developed
> >to enforce the GPL. It's sort of counter intuitive to why the GPL
> >exists, which is to free the code.
>
> """To protect your rights, we need to make restrictions that forbid
> anyone to deny you these rights"""
>
> >Let the licenses and lawyers fight to protect the code. The code doesn't
> >need to do that itself. It's got better things to do.

And these restrictions are in the letter of the GPL, not the function
prototypes of my code. Anyone willing to write libgpl-enforcement?

I don't care if someone wants to take my code and blatantly make use of
it in their own projects. I encourage it. I wrote it so people could do
whatever the hell they wanted to with it. It's when that project is made
available to others where I expect the GPL to enforce my copyrights and
licenses. I don't expect my code to be self checking for it, and then
add conditions that this portion of the code cannot be removed, because
then it isn't really GPL anymore, because then it isn't really free
either.

Maybe people will be happy if it ends up like this:

Booting Linux...
Please insert your original GNU/Linux source CD...

-
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/

cw at f00f

Dec 14, 2006, 9:52 AM

Post #64 of 214 (5555 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 05:38:27PM +0000, Christoph Hellwig wrote:

> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.

A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
disruptive (though we could support both during a transition and
migrate them over time).
-
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 14, 2006, 10:01 AM

Post #65 of 214 (5572 views)
Permalink

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

Jeff V. Merkey wrote:
>
> Again, I agree with EVERY statement Linus made here. We operate exactly
> as Linus describes, and
> legally, NO ONE can take us to task on GPL issues. We post patches of
> affected kernel code
> (albiet the code resembles what Linus describes as a "skeleton driver")
> and our proprietary
> non derived code we sell with our appliances.

Yeah, like this one?

ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch

@@ -1316,8 +1316,8 @@

mod->license_gplok = license_is_gpl_compatible(license);
if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
- printk(KERN_WARNING "%s: module license '%s' taints
kernel.\n",
- mod->name, license);
+// printk(KERN_WARNING "%s: module license '%s' taints
kernel.\n",
+// mod->name, license);
add_taint(TAINT_PROPRIETARY_MODULE);
}
}
@@ -1691,10 +1691,10 @@
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));

- if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint(TAINT_PROPRIETARY_MODULE);
- if (strcmp(mod->name, "driverloader") == 0)
- add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod->name, "ndiswrapper") == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod->name, "driverloader") == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);

/* Set up MODINFO_ATTR fields */
setup_modinfo(mod, sechdrs, infoindex);

-
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/

jengelh at linux01

Dec 14, 2006, 10:09 AM

Post #66 of 214 (5539 views)
Permalink

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

On Dec 14 2006 09:52, Chris Wedgwood wrote:
>On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
>
>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>
>A quick grep shows that changing this now would require updating
>nearly 1900 instances, so patches to do this would be pretty large and
>disruptive (though we could support both during a transition and
>migrate them over time).

I'd prefer to do it at once. But that's not my decision so you anyway do what
you want.

That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL
is somehow contrary. Just a wording issue.

-`J'
--
-
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 14, 2006, 10:12 AM

Post #67 of 214 (5556 views)
Permalink

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

Martin J. Bligh wrote:

> Jeff V. Merkey wrote:
>
>>
>> Again, I agree with EVERY statement Linus made here. We operate
>> exactly as Linus describes, and
>> legally, NO ONE can take us to task on GPL issues. We post patches of
>> affected kernel code
>> (albiet the code resembles what Linus describes as a "skeleton
>> driver") and our proprietary
>> non derived code we sell with our appliances.
>
>
>
> Yeah, like this one?

Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.

Jeff

>
> ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch
>
>
> @@ -1316,8 +1316,8 @@
>
> mod->license_gplok = license_is_gpl_compatible(license);
> if (!mod->license_gplok && !(tainted &
> TAINT_PROPRIETARY_MODULE)) {
> - printk(KERN_WARNING "%s: module license '%s' taints
> kernel.\n",
> - mod->name, license);
> +// printk(KERN_WARNING "%s: module license '%s' taints
> kernel.\n",
> +// mod->name, license);
> add_taint(TAINT_PROPRIETARY_MODULE);
> }
> }
> @@ -1691,10 +1691,10 @@
> /* Set up license info based on the info section */
> set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>
> - if (strcmp(mod->name, "ndiswrapper") == 0)
> - add_taint(TAINT_PROPRIETARY_MODULE);
> - if (strcmp(mod->name, "driverloader") == 0)
> - add_taint(TAINT_PROPRIETARY_MODULE);
> +// if (strcmp(mod->name, "ndiswrapper") == 0)
> +// add_taint(TAINT_PROPRIETARY_MODULE);
> +// if (strcmp(mod->name, "driverloader") == 0)
> +// add_taint(TAINT_PROPRIETARY_MODULE);
>
> /* Set up MODINFO_ATTR fields */
> setup_modinfo(mod, sechdrs, infoindex);
>
>

-
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/

sandeen at sandeen

Dec 14, 2006, 10:15 AM

Post #68 of 214 (5536 views)
Permalink

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

Chris Wedgwood wrote:
> On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
>
>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>
> A quick grep shows that changing this now would require updating
> nearly 1900 instances, so patches to do this would be pretty large and
> disruptive (though we could support both during a transition and
> migrate them over time).

Please don't use that name, it strikes me as much more confusing than
EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey
what it means, either.

EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least something
which is not internally inconsistent would be good (how is something
which is exported "internal?")

And, as long as EXPORT_SYMBOL_GPL continues to check that the module
using it has a GPL license, then it really -is- exactly descriptive of
what it's doing and probably shouldn't be changed. IIMHO.

-Eric
-
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, 10:18 AM

Post #69 of 214 (5545 views)
Permalink

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

> One of the things that I find so interesting about how rabid people
> get about enforcing GPL-only modules is how they start acting more and
> more like the RIAA, MPAA, and Microsoft every day....

There is a saying

"That which you fight you become"

It's a warning that is well worth heeding in a lot of situations
-
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, 10:22 AM

Post #70 of 214 (5550 views)
Permalink

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

> Think of uio as just a "class" of driver, like input or v4l. It's still
> up to the driver writer to provide a proper bus interface to the
> hardware (pci, usb, etc.) in order for the device to work at all.

Understood. That leads me to ask another question of the folks who deal
with a lot of these cards. How many could reasonably be described by the
following

bar to map, offset, length, ro/rw, root/user, local-offset
(x n ?)
interrupt function or null

It seems if we have a lot of this kind of card that all fit that pattern
it might actually get more vendors submitting updates if we had a single
pci driver that took a struct of the above as the device_id field so
vendors had to write five lines of IRQ code, a struct and update a PCI
table ? That seems to have mostly worked with all the parallel/serial
boards.

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/

jmerkey at wolfmountaingroup

Dec 14, 2006, 10:30 AM

Post #71 of 214 (5560 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 Thu, 14 Dec 2006, Jeff V. Merkey wrote:
>
>
>>Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
>>
>>
>
>No. That's really a purely technical thing.
>
>
>
>
I'm not certain I understand what you mean here. Nasty messages using
the word "taint" is purely subjective.
(as is your opinion or anyone else's about the use of the word,
including my opinion). Based upon the way the GPL is worded, "taint"
actually goes the other way in legal circles when corporate attorneys
talk about using GPL code with non-GPL code.

i.e. "... If we use that linux code it will TAINT our development
process and CONTAMINATE and POULLTE our proprietary
development efforts with GPL code and we do not know the IP sources of
such code...".

You should change it to "non-GPL" rather than "tainted" since the use of
this word is actionable and inaccruate of reality.
Free GPL code is what it is. The GPL is the only thing that "taints" IP.
The use of the word is reversed. Also Linus, we do
open source and promote certain projects outside of the Linux Kernel --
and we fully support the GPL.

You can still do whatever you want, but people who support the resulting
mess know that they shouldn't.

BULLSHIT. I diagree and you are talking out of both sides of your mouth.

:-)

Jeff

> 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/

torvalds at osdl

Dec 14, 2006, 10:37 AM

Post #72 of 214 (5551 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, Jeff V. Merkey wrote:
>
> Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.

No. That's really a purely technical thing.

You can still do whatever you want, but people who support the resulting
mess know that they shouldn't.

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/

cw at f00f

Dec 14, 2006, 10:39 AM

Post #73 of 214 (5550 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:15:20PM -0600, Eric Sandeen wrote:

> Please don't use that name, it strikes me as much more confusing
> than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> convey what it means, either.

Calling internal symbols _INTERNAL is confusing?

> EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least
> something which is not internally inconsistent would be good (how is
> something which is exported "internal?")

But those symbols aren't, they're about internal interfaces that might
change.

> And, as long as EXPORT_SYMBOL_GPL continues to check that the module
> using it has a GPL license, then it really -is- exactly descriptive
> of what it's doing and probably shouldn't be changed. IIMHO.

Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about
documenting things, why restrict who can use them based on the
license?

Surely the licence is more about tainting the kernel and debugging not
politics?

Do we even need to check the license at all in that case? Maybe a
better idea would be to embed where the source code is located and use
the non-existence of that for a tainting?

-
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 14, 2006, 10:51 AM

Post #74 of 214 (5546 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, Chris Wedgwood wrote:
>
> Calling internal symbols _INTERNAL is confusing?

Well, I'm not sure the _INTERNAL name is all that much better than the
_GPL one.

In many ways, the _GPL one describes the _effects_ better, and also points
out the reason _why_ something is marked differently. Sure, it's marked
becasue it's internal, but why is does that have to be pointed out at all?
Why not use the same EXPORT_SYMBOL? The answer to that is the "GPL" part,
ie the expectation that internal symbols are so internal that they have
license effects.

And if you were an external vendor doing binary only modules, would you
react to "internal"? It wouldn't have the same "oh, _that_ is what it is
all about" thing, would it?

So I do agree that we have probably done a bad job of explaining why that
_GPL thing makes sense, and what it means on a deeper level (the license
thing is a very superficial thing, but its worth naming just because the
superficial thing is also the biggest _impact_ - even if it may not be the
underlying deeper _reason_ for it).

So which makes more sense from a naming standpoint: the superficial impact
that is what _matters_ for people, or the more subtle issue that causes it
to have that impact?

I think that question is what it boils down to, and at least personally,
while I see both things as being worthwhile, I think the superficial thing
is the one that needs pointing out, because it's the one that may change
your behaviour (while the deeper _meaning_ is more of just an
explanation).

But I don't personally care that deeply. I mostly care about the fact that
changing the name now would just be inconvenient and unnecessary churn,
and that's probably my biggest reason to not want to do it ;)

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/

mb at bu3sch

Dec 14, 2006, 11:29 AM

Post #75 of 214 (5561 views)
Permalink

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

On Thursday 14 December 2006 15:12, Ben Collins wrote:
> You can't talk about drivers that don't exist for Linux. Things like
> bcm43xx aren't effected by this new restriction for GPL-only drivers.
> There's no binary-only driver for it (ndiswrapper doesn't count). If the
> hardware vendor doesn't want to write a driver for linux, you can't make
> them. You can buy other hardware, but that's about it.

Not that is matters in this discussion, but there are binary Broadcom
43xx drivers for linux available.

> Here's the list of proprietary drivers that are in Ubuntu's restricted
> modules package:
>
> madwifi (closed hal implementation, being replaced in openhal)
> fritz

Well, that's not just one, right?
That's like, 10 or so for the different AVM cards.
I'm just estimating. Correct me, if I'm wrong.

(And if I didn't mention it yet; AVM binary drivers are
complete crap.)

> ati
> nvidia
> ltmodem (does that even still work?)
> ipw3945d (not a kernel module, but just the daemon)

> Don't get me wrong, I'm not bashing reverse engineering, or writing our
> own drivers. It's how Linux got started. But the problem isn't as narrow
> as people would like to think. And proprietary code isn't a growing
> problem. At best, it's just a distraction that will eventually go away
> on it's own.

Well, I _hope_ that, too.

--
Greetings 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/

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