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

["Martin J. Bligh" <mbligh@mbligh.org>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/