---

Editor’s Note: God’s Laundry Day

By Brian Proffitt
Managing Editor

It reminded me of a summer squall–a nice, humid day suddenly
replaced by black skies, blowing wind, and stinging rain, pummeling
the ground by way of what my departed grandmother used to call
“God’s Laundry Day.”

The discussion that broke out on the Linux kernel mailing list
this week was just like a squall: a quiet technical discussion that
suddenly grew into a deep conversation about the nature of the
Linux kernel itself. Would the finest example of GPL software
continue to allow proprietary software to be encoded within? The
initial answer seemed to be yes.

Eventually, Linus Torvalds weighed in on the matter and in his
blunt statements made everyone stop and think. Perhaps, was the
conclusion reached, it is not a good idea to make a political
stance when you are trying to get a good piece of software out the
door. For the most part, the kernel developers seemed to agree with
Torvalds, or at least agreed to let the matter lie, and the drive
towards kernel 2.6.20 slowly started up again.

But the issue of whether proprietary device modules belong in
the kernel is still unresolved. And it may be more complicated than
just a group of freedom-lover wanting free software for its own
sake.

An aside, if I may, before I continue: there are several pundits
on the Internet who are mocking this discussion as just another way
Linux developers are cutting their noses off to spite their faces.
Look at the idealists, they laugh, they’ll never learn to what it
takes to sell more software. To those people, I would rejoin a
heartfelt “kiss off.” However this discussion turns out, at least
the discussion is being held in the open, instead of inside an
autocratic corporation where ideas are couched in market-speak
within memos and e-mails that never see the light of day… unless
they’re subpoenaed.

Back to the kernel. It dawned on me that proprietary modules
were more than just an anathema to some kernel developers when I
read the comments of Greg Kroah-Hartman, when he withdrew the patch
that would warn everyone about no proprietary modules starting in
January 2008:

“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 two-line patch, I jumped in and took it,”
Kroah-Hartman wrote.

That doesn’t sound like someone waving the patriotic flag to me.
It sounds like someone who’s ticked off watching the work he truly
cares about get pilfered by vendors when they take his kernel code,
weave it into a device driver, then plug that driver as a
proprietary module back into the kernel.

Kroah-Hartman continues:

“And yes, it is crap that I deal with every day due to the
lovely gray 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 damn 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 okay to violate those kernel developers rights because no one
seems to be stopping them so far,” he writes.

Right now, it’s hard to argue with Torvalds; the Linux kernel is
not the place to make a political stand. But the current system
also seems to be causing a great deal of stress on kernel
developers who are trying to create something good and are unhappy
with how their works are used.

It seems to me that something is really wrong here, and I think
we should risk cubbyholing it into a freedom vs. proprietary
argument. That’s a symptom of a larger problem. There are too many
voices and too many goals in the Linux community for everyone to be
happy. That will always be true, since you can’t please everybody.
But without an overall goal, without some sort of plan, I think it
will soon be impossible to please anybody.

I would maintain that there should be a centralized,
vendor-neutral body that could manage and focus the direction of
the community at large. If there is a need to eliminate non-GPL
modules from the kernel, let such a body help the developers figure
out how to do it without alienating every hardware or software
vendor with an interest in Linux. Let there be a single touch point
for software vendors to port their apps to Linux.

In the past, I would assert the Open Source Development Labs
(OSDL) would have filled this role. But they have been
self-diminished, indicating that the time has come for corporations
to step into the role of funding and guiding Linux.

This, I think, was a premature move–if that is indeed the
reason for OSDL’s workforce reduction. We need a stronger OSDL–or
a better centralized body altogether–to help developers and users
alike solve the big problems facing Linux. Discussions will still
be open, but the goals will be more focused.

Or the storms will just keep on coming.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis