A position statement on closed-source kernel modules

I noticed that as well.  Based on past statements, I think he's rather 
more willing to deal with closed modules than some, and probably doesn't 
consider them so flatly "harmful and undesirable" under all conditions, at 
least not to the point he was willing to sign the statement.

Duncan

It's quite undermining of the whole position - after all, it is _his_ kernel (or a least,
commonly viewed as such).

Other notable missing names I noticed: Al Viro, David Miller.

In Linus's case, it could be that he doesn't want to take an official position (which could be
construed as being "on behalf of" the project), regardless of his own opinions.  This could be
because binary modules aren't being outlawed anytime soon...

Nothing worth doing gets done without Alexey Kuznetsov!

or garzik. or rusty.

Yes, it lacks the legal status on purpose.

Legal status varies depending on your local laws.

It's a shot across the bow.  Companies move slowly, and
if the kernel folk were to do something drastic like say
"no more binary modules", many companies would see at as
a bolt from the blue and be looking prevent being
vulnerable to such a thing again.

With this formal heads-up, companies have time to react
in ways they find acceptable.

The people supplying these modules (and the people supplying a lot of open source ones, too)
are only really concerns with what will make them money (what they're not legally allowed to
do is simply something that has a high chance of future financial risk, so a special case).

So the question they ask is: Will binary modules provide us enough income to cover the cost of
developing them? That seems these days to mean: Will OEMs that care about Linux support use
our hardware if there's a binary driver for it but no open source driver?

Now, if hardware vendors think that OEMs will accept this letter as the basis for deciding
whether hardware is suitable for inclusion in Linux-friendly systems, then it will have a huge
effect: providing a binary driver won't get a vendor any new sales; it'll only make unhappy
customers a bit less unhappy, but no more likely to buy from them again, and it will primarily
benefit users who didn't make the purchasing decision anyway.

The letter avoids the disputable question of whether you're allowed to write binary-only
modules, in favor of the more clear and applicable question of whether there's any point to
writing binary-only modules, to which the answer really is: nVidia can probably get some
benefit out of it for the chipsets in the pipeline currently; otherwise, don't bother. (If it
were only a question of legality, vendors would all switch to providing binary-only drivers
for BSD, where it's obviously legal but just as obviously pointless; everybody who wants
drivers for BSD doesn't want binary-only drivers)

I agree - the statement oddly without an operational conclusion. I suppose it does help to be
on the record and that there probably are some companies that would be swayed by the authors'
intentions. 

I suspect that a US lawyer could raise this statement ("it's a bad idea and bad for your
customers") as a concession that such modules aren't prohibited by the license, simply because
the developers argued against their use without arguing they are prohibited. On the other
hand, it might be that in countries that observe authors' moral rights, this statement might
have some weight [IANAL].

[Disclaimer: As a non-kernel developer, my opinion doesn't matter, but I'll share it anyway in
the interests of full disclosure - I strongly support this statement and would advise anyone
who asked to not create binary-only kernel modules, but I also believe that they are almost
certainly fair use and not license violations.]

"furthermore, we believe that the kernel license should be
changed to prohibit such modules"

It'll never happen. Breaking core functionality (graphics drivers, WiFi drivers, etc) on such
a wide scale would hurt users and make the community look utterly stupid. Totally
counter-productive.

> Copyright deals exclusively with *expressive* works, and only if a work
> is *expressively* derivative of another do we have a copyright
> infringement issue.

Let's try a thought experiment.

Take a kernel driver.  Link it against two sets of headers.  One is the standard set of Linux
kernel headers from the most recent stable kernel release.  Another is a complete clean-room
reimplementation of the same kernel headers.

If the two binary blobs produced differ by even one bit, then are the binary blobs not
derivative works of the headers?  The source code may not be derivative at all, but if your
clients wanted to distribute source code and never a binary blob, this wouldn't be an issue.

Larry, imagine if it were something like,

"We, the maintainers of the exampleware SMTP library, which is under the GPL, believe that
email spam is bad."

The maintainers aren't saying that they'll try to block spammers' right to use the library, or
that a particular spammer is or isn't breaking the law -- just that if you get on the
exampleware mailing list and ask for help using the library to send spam you're not likely to
get far.

Larry, I know you're a lawyer so you think legal things...
but this statement very deliberately is NOT about anything legal.

It's about the consequences and effects that binary modules have for users and Linux.

(This is essentially a side-issue, because no-one seems to be talking about trying to send
lawyers after the makers of binary modules, but it's worth addressing because it's about the
GPL vs LGPL rules which, contrary to lrosen's claim, I believe are important and beneficial)

The argument you've made for linking can be made about lots of processes in the production of
a literary work. But no-one has successfully made these arguments to a court in all these long
years, so either they don't believe it, or the judges don't.

The "creativity" component of copyright is whitewash. Maybe you'd argue that it shouldn't be,
but with courts content to determine arbitrary collections of information as "sufficiently"
creative for copyright protection I don't think your argument will stand up.

Actually I don't think we even need to go that far. You haven't mentioned distribution.
Neither the GPL nor LGPL care what you do with the protected code so long as you don't
distribute it. If you want to take a GPL'd program (say GCC) and re-factor it as a library for
integration into your own software no-one gives a hoot.

But if you distribute the resulting product under a proprietary license you are infringing
even if you rely on a third party to do the actual linking. This is for two reasons. Firstly
because the law doesn't only care who pulled the trigger (hiring someone else to kill your
wife doesn't make you innocent of murder). But secondly because you have no choice but to copy
"sufficiently" expressive/ creative elements like arbitrary human-readable identifiers from
the GPL'd software into your own product to make it work. Only if the sufficiency barrier is
raised considerably would it be a problem to meet it for external linking.

So far as I can tell your argument revolves around the idea that linking software resembles
binding two books together with cellophane for sales purposes. No copyright issue. This is
what the GNU GPL calls "mere aggregation". But compiling your software against a dynamic
library is not "mere aggregation". Let me suggest a different analogy...

Suppose I write a book criticising a popular novel, ah, let's say "Moby Dick" just after it
has been published. I am entitled to write whatever I like merely /about/ this book, and my
lawyer might advise me that I can quote small extracts from the book to illustrate a point, so
long as I'm not scared of going to court to argue fair use. But how about if I'd like to buy
copies of Moby Dick and apply stickers to each page with my commentary as footnotes to the
relevant parts of the story (ignore for a moment the logistical challenge, in an e-book this
would certainly be trivially overcome) ? Well, if I want to do this just for my own amusement
I'm protected by the First Sale doctrine (they're mine and I'll do as I please). However, if I
want to subsequently sell or otherwise distribute these copies (maybe give them away to
schools), they are clearly derived works and I think I will need permission from the copyright
holder (author or publisher) of the original Moby Dick.

So, Lawrence, would you advise me to proceed? Would you be happy to argue (on your own dollar)
that the stickered version of Moby Dick is not a derived work but merely an aggregation of two
separate works ?

>The notion that linking of any sort produces a derivative work is nonsense. 

The only thing that is clear is that anyone who claims there is a single clearcut way to
a-priori distinguish between infringement and non-infringement when it comes to copyright
applied to software (especially software covered by the GPL) is wrong.

>Linking is a functional thing, necessary solely to effectuate a functional interworking
between two programs.

The old joke about smuggling an elephant with two slices of bread comes to mind.