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

alan at lxorguk

Dec 14, 2006, 4:42 AM

Post #26 of 214 (6141 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 12:31:16 +0100
Hans-Jürgen Koch <hjk [at] linutronix> wrote:
> You think it's easier for a manufacturer of industrial IO cards to
> debug a (large) kernel module?

You think its any easier to debug because the code now runs in ring 3 but
accessing I/O space.

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

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, 4:54 AM

Post #27 of 214 (5970 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 13:42 schrieb Alan:
> On Thu, 14 Dec 2006 12:31:16 +0100
> Hans-Jürgen Koch <hjk [at] linutronix> wrote:
> > You think it's easier for a manufacturer of industrial IO cards to
> > debug a (large) kernel module?
>
> You think its any easier to debug because the code now runs in ring 3 but
> accessing I/O space.

For the intended audience, yes.

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

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/

jengelh at linux01

Dec 14, 2006, 4:55 AM

Post #28 of 214 (5955 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 12:42, Alan wrote:
>On Thu, 14 Dec 2006 12:31:16 +0100
>Hans-Jürgen Koch <hjk [at] linutronix> wrote:
>> You think it's easier for a manufacturer of industrial IO cards to
>> debug a (large) kernel module?
>
>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, but of course the wrong inb/inw/inl() or
outb* can fubar the machine.

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

Something called PC104 out there.

-`J'
--

davej at redhat

Dec 14, 2006, 5:04 AM

Post #29 of 214 (5967 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 08:15:59PM -0800, Linus Torvalds wrote:

> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first.

You don't think I already get enough hatemail from binary-module users ? :)

Dave

--
http://www.codemonkey.org.uk
-
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/

davej at redhat

Dec 14, 2006, 5:07 AM

Post #30 of 214 (5952 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 09:39:11PM -0800, Martin J. Bligh wrote:

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

Dave

--
http://www.codemonkey.org.uk
-
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/

arjan at infradead

Dec 14, 2006, 5:10 AM

Post #31 of 214 (5966 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 13:55 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 12:42, Alan wrote:
> >On Thu, 14 Dec 2006 12:31:16 +0100
> >Hans-Jürgen Koch <hjk [at] linutronix> wrote:
> >> You think it's easier for a manufacturer of industrial IO cards to
> >> debug a (large) kernel module?
> >
> >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 .. )

-
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, 5:46 AM

Post #32 of 214 (5938 views)
Permalink

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

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

I can probably speak for Ubuntu in saying we wont include any sort of
patch like this unless it's forced on us.

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.

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

riel at redhat

Dec 14, 2006, 6:02 AM

Post #33 of 214 (5944 views)
Permalink

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

Greg KH wrote:

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

Pretty much every license under the sun is getting violated,
and people are getting away with it. The GPL is not special
in this regard.

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

However, users do not like running unsupportable software
when the shit hits the fan - which it will always do with
any piece of software, eventually :)

Maybe we should just educate users and teach them to
avoid crazy unsupportable configurations and simply buy
the hardware that has open drivers available?

In the laptop space, I already try to avoid everything
non-Centrino, because chances are a closed source video
or network driver would be needed with something else[1].

Judging from how much vendor drivers tend to get improved
when they get merged upstream, I don't see how vendors
think they can get away with not merging their code upstream.

I'm not talking about this from a legal standpoint (millions
of people get away with blatantly illegal stuff every day),
but from a technical and market point of view.

Why would users buy a piece of hardware that needs a binary
only driver that's unsupportable, when they can buy a similar
piece of hardware that has a driver that's upstream and is
supported by every single Linux distribution out there?

Sure, the process of getting drivers merged upstream[2] can
take some time and effort, but the resulting improvements in
driver performance and stability are often worth it. It's
happened more than once that the Linux kernel community's
review process turned up some opportunities for a 30% performance
improvement in a submitted driver.

Hardware companies: can you afford to miss out on the stability
and performance improvements that merging a driver upstream tends
to get?

Can you afford to miss out when your competitors are getting these
benefits?

[1] other vendors: fix your stuff, so I can recommend your hardware too!
[2] http://kernelnewbies.org/UpstreamMerge
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
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, 6:12 AM

Post #34 of 214 (5952 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 21:39 -0800, Martin J. Bligh wrote:
> 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.

Yes, people have been worried about this for years, and to my knowledge,
it seems like things have been getting better with drivers, not worse
(look at Intel). And yet, people want to enforce more and more
restrictions against binary-only drivers, when it appears that we are
already winning.

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.

Here's the list of proprietary drivers that are in Ubuntu's restricted
modules package:

madwifi (closed hal implementation, being replaced in openhal)
fritz
ati
nvidia
ltmodem (does that even still work?)
ipw3945d (not a kernel module, but just the daemon)

In over a year that list has only grown by ipw3945d. None of our users
are asking for new proprietary drivers. Believe me, if they needed them,
I'd hear about it. We have more cases of new unsupported hardware than
we do of new hardware with binary-only drivers. This proposed
restriction doesn't fix that.

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.

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.

The whole hardware vendor landscape is showing this, and it's not
because we locked down the kernel, it's because we've shown how well we
play with others, and how easy it is to get along with the whole
community. Do we want to destroy this good will?
-
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/

tytso at mit

Dec 14, 2006, 6:53 AM

Post #35 of 214 (5939 views)
Permalink

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

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

It's not a question of "honoring the license"; it's a matter of what
is the reach of the license, as it relates to derivitive works. It's
a complicated subject, and very dependent on the local law; certainly
in the U.S., when I asked a Law Professor from the MIT Sloan School of
Management, who specialized in IP issues about the FSF theory of GPL
contamination by dynamic linking, after I explained all the details of
how dynamic linking work, she told me that it would be "laughed out of
the courtroom".

Now, is that a legal opinion? No, because the facts of every single
case are different, and it was an opinion from someone over a decade
ago, and case law may have changed (although as far as I know, there
has been no court ruling directly on this particular point since
then).

The bottom line though is that it is not _nearly_ so clear as some
people would like to believe. There is a lot of gray --- and that's a
GOOD thing. If copyright contamination via dynamic linking was the
settled law of the land, then all of the Macintosh extensions that
people wrote --- WHICH WORK BY PATCHING THE OPERATING SYSTEM --- would
be illegal. And given how much Apple hated people implying that the
UI as handed down from the mountain by the great prophet Steve Jobs
wasn't good enough, would we really have wanted Apple hounding
developers with lawsuits just because "they weren't honoring the
license" by daring to patch MacOS, and extending the OS by linking in
their code?

And what about people who link in a debugger into the Microsoft HAL or
other Microsoft DLL's in order to reverse engineer USB drivers for
Linux or reverse engineer protocols for Samba --- that's dynamic
linking of a sort too --- should that be illegal as well? Imagine the
power that Microsoft could put into their EULA if copyright
contamination could be as easily achieved by dynamic linking.

Please, let's try to have a little sanity here,

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

bunk at stusta

Dec 14, 2006, 6:57 AM

Post #36 of 214 (5960 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 10:36:13AM +0000, Alan wrote:
> > 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.

But make it easier when it comes to court...

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

bunk at stusta

Dec 14, 2006, 7:05 AM

Post #37 of 214 (5957 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 08:07:04AM -0500, Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
>
> > 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.

If a kernel developer or a competitor sends a cease&desist letter to
such a distribution, the situation changes from a complicated "derived
work" discussion to a relatively clear "They circumvented a technical
measure to enforce the copyright.".

> Dave

cu
Adrian

--

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

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

Post #38 of 214 (5950 views)
Permalink

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

Ben Collins wrote:
>
> Here's the list of proprietary drivers that are in Ubuntu's restricted
> modules package:
>
> madwifi (closed hal implementation, being replaced in openhal)
> fritz
> ati
> nvidia
> ltmodem (does that even still work?)
> ipw3945d (not a kernel module, but just the daemon)
>

More items will be added to that list soon.
E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
http://opensource.creative.com/

> In over a year that list has only grown by ipw3945d. None of our users
> are asking for new proprietary drivers. Believe me, if they needed them,
> I'd hear about it. We have more cases of new unsupported hardware than
> we do of new hardware with binary-only drivers. This proposed
> restriction doesn't fix that.

Is there a list of "new unsupported hardware" ?
Reverse engineering or datasheets is the only way out of that.
As Linux becomes more and more popular on the desktop, manufacturers
will start feeling the pain of Linux "unsupported hardware" and have to
back down and release datasheets. Ubuntu is helping a lot in that direction.

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

Well, once a device has been reverse engineered and GPLed, the specs are
then in public domain and the IP does not exist any more. It actually
helps the company release the specs once the information is already out
there. The company then sees less reason to hold onto their specs in the
first place, and tends to release them earlier next time.

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

I agree, as time goes by, more and more devices are reverse engineered
or the manufacturer finally sees sense and releases the specs/datasheets.

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/

mbligh at mbligh

Dec 14, 2006, 7:36 AM

Post #39 of 214 (5968 views)
Permalink

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

Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
>
> > 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.

I don't think they'd dare spit in our faces quite that directly.
They think binary modules are permissible because we don't seem to have
consistently stated an intent contradicting that - some individual
developers have, but ultimately Linus hasn't.

I'm not talking about any legal issues to do with derived works,
copyrights or licenses - a clear statement of intent is probably all
it'd take to tip the balance.

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/

bunk at stusta

Dec 14, 2006, 7:39 AM

Post #40 of 214 (5949 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 03:03:10AM -0500, James Morris wrote:
> 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.
>...

Unfortunately, we are living in an economic system with the strong
tendency to create oligopolys.

Situations with only 1-3 manufacturers you can choose from are quite
common (consider e.g. the 3D graphics market).

If you aren't a big company with big market power but a simple costumer
who needs such hardware you have zero choice if all manufactorers only
offer binary-only drivers at best.

And there's also the common misconception all costumers had enough
information when buying something. If you are a normal Linux user and
buy some hardware labelled "runs under Linux", it could turn out that's
with a Windows driver running under ndiswrapper...

> - James

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/

cfriesen at nortel

Dec 14, 2006, 7:42 AM

Post #41 of 214 (5972 views)
Permalink

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

Rik van Riel wrote:

> Why would users buy a piece of hardware that needs a binary
> only driver that's unsupportable, when they can buy a similar
> piece of hardware that has a driver that's upstream and is
> supported by every single Linux distribution out there?

In my experience it falls into a number of categories:

1) The system that requires the binary driver has other hardware on it
that is required for the app.

2) The system that requires the binary driver costs significantly less,
enough that they decide to bite the bullet on the software support side.

3) The system that requires the binary driver is the *only* one
available in the specified form factor with the specified cpu architecture.

4) The team that decides on the hardware is totally divorced from the OS
guys, so they don't know/care what is supported by open source drivers
in the first place.

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

jeff at garzik

Dec 14, 2006, 7:46 AM

Post #42 of 214 (5954 views)
Permalink

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

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

ACK, I agree completely. I think its a silly, political, non-technical
decision being pushed here.

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.
EXPORT_SYMBOL_GPL() is more to emphasize that certain symbols are more
'internal' or frequently changed, and therefore use of them would imply
you are using a derived work of the kernel. EXPORT_SYMBOL_GPL() is
/not/ a place for political activism either.

Jeff

-
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, 7:47 AM

Post #43 of 214 (5941 views)
Permalink

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

> Pretty much every license under the sun is getting violated,
> and people are getting away with it. The GPL is not special
> in this regard.

That may begin to change in time. There are a lot of people getting very
angry at the political level about the way large companies in particular
flout copyright law and claim to "not know" because they just bought
something in, often from Taiwan or China, with stolen code in it.

There are proposals on the table in the EU to make commercial piracy a
criminal not a civil matter in the case of copyright. (The original
proposal also suggested for patents which would have been rather dumb but
that seems to have been killed off for now). So in a couple years a GPL
violating product in the EU may entail a walk down to the local police
station rather than a private court case.

In the UK also trading standards whose remit right now is trademark abuse
will also be getting enforcement powers and funding for copyright stuff.
The powers that be are mostly thinking "pirate DVD in the local market
stall", but some of us have other ideas.

We do need to distinguish between the blatant violators and the
borderline people - there's a difference between the folks shipping Linux
rip-offs binary only in random unlabelled routers and people like Nvidia
and Novell who are on the edge of the license corner cases.

Another thing we should do more is aggressively merge prototype open
drivers for binary only hardware - lets get Nouveau's DRM bits into the
kernel ASAP for example.

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/

jeff at garzik

Dec 14, 2006, 7:48 AM

Post #44 of 214 (5942 views)
Permalink

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

Alan wrote:
> Another thing we should do more is aggressively merge prototype open
> drivers for binary only hardware - lets get Nouveau's DRM bits into the
> kernel ASAP for example.

ACK++ We should definitely push Nouveau[1] as hard as we can.

Jeff

[1] http://nouveau.freedesktop.org/

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

davej at redhat

Dec 14, 2006, 8:09 AM

Post #45 of 214 (5956 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 03:10:57PM +0000, James Courtier-Dutton wrote:
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/

Wow. That wins 'most ironic hostname' award for 2006.
Thankfully onboard hardware is "good enough" for most end-users
these days, leaving just the high-end audio professionals in the lurch.

Dave

--
http://www.codemonkey.org.uk
-
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/

davej at redhat

Dec 14, 2006, 8:11 AM

Post #46 of 214 (5941 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:05:14PM +0100, Adrian Bunk wrote:
> On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
> > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> >
> > 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.
>
> If a kernel developer or a competitor sends a cease&desist letter to
> such a distribution, the situation changes from a complicated "derived
> work" discussion to a relatively clear "They circumvented a technical
> measure to enforce the copyright.".

C&D's don't work that way. They can enforce "don't ship my code"
but not "ship my code, or else". The modification would be just like
any other thats allowable by the GPL.

Dave

--
http://www.codemonkey.org.uk
-
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:17 AM

Post #47 of 214 (5956 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 08:15:59PM -0800, Linus Torvalds wrote:
>...
> 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.
>...

One important question is:
Who gets in danger due to this grey area?

E.g. if I'd consider it important enough to stop Ubuntu from
distributing kernels and binary-only modules, I wouldn't try the
difficult task to take legal actions against a company located on the
Isle of Man.

The trick is to let a lawyer send cease and desist letters to people
distributing the infringing software for 1 Euro at Ebay.

The nice thing about cease and desist letters is that the one who
accepts one has to pay the > 1000 Euro costs for the lawyer for this
letter.

Another lucrative task for the lawer would be to send cease and desist
letters to people running mirrors located in Germany distributing the
infringing software.

> Linus

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/

galibert at pobox

Dec 14, 2006, 8:31 AM

Post #48 of 214 (5941 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 11:11:33AM -0500, Dave Jones wrote:
> On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
> > If a kernel developer or a competitor sends a cease&desist letter to
> > such a distribution, the situation changes from a complicated "derived
> > work" discussion to a relatively clear "They circumvented a technical
> > measure to enforce the copyright.".
>
> C&D's don't work that way. They can enforce "don't ship my code"
> but not "ship my code, or else". The modification would be just like
> any other thats allowable by the GPL.

Careful here. The "technical measure" protection is something
unrelated to the copyright license itself. Cf the streambox vcr
lawsuit for instance (settled though) where not implementing the
handling of one bit that said "don't save to disk" in original code
seemed to be illegal.

OG.

-
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, 8:33 AM

Post #49 of 214 (5957 views)
Permalink

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

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

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/

ben.collins at ubuntu

Dec 14, 2006, 8:36 AM

Post #50 of 214 (5947 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 15:10 +0000, James Courtier-Dutton wrote:
> Ben Collins wrote:
> >
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> >
> > madwifi (closed hal implementation, being replaced in openhal)
> > fritz
> > ati
> > nvidia
> > ltmodem (does that even still work?)
> > ipw3945d (not a kernel module, but just the daemon)
> >
>
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/

I haven't even caught wind of this not being supported yet. No demand ==
no reason to include it when it does become available.

> > In over a year that list has only grown by ipw3945d. None of our users
> > are asking for new proprietary drivers. Believe me, if they needed them,
> > I'd hear about it. We have more cases of new unsupported hardware than
> > we do of new hardware with binary-only drivers. This proposed
> > restriction doesn't fix that.
>
> Is there a list of "new unsupported hardware" ?
> Reverse engineering or datasheets is the only way out of that.
> As Linux becomes more and more popular on the desktop, manufacturers
> will start feeling the pain of Linux "unsupported hardware" and have to
> back down and release datasheets. Ubuntu is helping a lot in that direction.

I've not kept a list. Would be non-trivial to go through the bug tracker
to find this info. Mostly it's things like webcams, and wacky little
hardware that starts cropping up in laptops.

> >
> > 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.
>
> Well, once a device has been reverse engineered and GPLed, the specs are
> then in public domain and the IP does not exist any more. It actually
> helps the company release the specs once the information is already out
> there. The company then sees less reason to hold onto their specs in the
> first place, and tends to release them earlier next time.

Right, I think reverse engineering does help in that aspect. The other
aspect is that they now have a driver that sort of works for their
hardware. Most of the work is done, and they decide to help things along
to make it stable. So laying ground work like this can have advantages.

I think hardware vendors are a lot like users. Once they see the
advantages to opening up their drivers, they wonder why they didn't do
it a long time ago. Sort of like how users need that one push to use
Linux, and they start to wonder why they should go back to Windows.

-
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