Google Calling: Inside Android, the gPhone SDK (O'ReillyNet)

There are other exceptions to this.  For instance I used to work on an embedded system with a
home grown OS.  The home grown OS was created back in 1992, and the original version of the
kernel driver in 1993 before anyone at the company ever heard of Linux.  We decided to create
a new version on new hardware running under Linux.  In response to this we added code to call
the pertinent symbols in the Linux Kernel, but we maintained support for our custom OS.

As far as I can tell this does not magically make this a derivative work of Linux.  There are
a number of other modules I have encountered in the past that have similar origins.  

Note that copyright only covers expression, not function. There is a bunch of recent case law
(in the US) that suggests that interfacing to a program is non-infringing.

This is all really gray area, both in terms of what constitutes a derived work of a piece of
software and in terms of what is allowed by fair use regardless. Coupling that with the terms
of the GPL that don't exactly align with copyright (using permission to distribute the covered
work as a lever to also control the way its distributed and what's distributed with it), it's
really hard to predict what would happen in a court test of issues like proprietary drivers.
It's best (and most polite to authors) to just avoid questionable practices.

Device manufacturers, in many cases, don't really care that much about exposing their drivers.
Their value-add is usually in more domain-specific areas, usually above the kernel.

I think the key points that handset manufacturers and carriers will want to lock down are
around (a) access to the air stack and RF control, (b) access to middleware services that use
the network (placing calls, sending messages), and (c) IP-control mechanisms (DRM, content
copying). (a) because it affects whether the FCC will let them ship the device, (b) because
they potentially can be used for DoS attacks on the network and can make users very unhappy
about unexpected charges, and (c) because they want to be able to offer access to content that
they can't get without guaranteeing (with substantial financial penalties) that their access
controls work. Their key GPL question will be around whether they can allow replacing the
kernel while still meeting those guarantees. Drivers are not that big a deal.

> That's gratuitous talk - could you show me a case backing your saying ?

Just butting in here.  This sort of argument annoys me, as it puts pressure for evidence on
the other guy.  Requiring evidence for every statement can very quickly turn discussions into
PhD level papers.  

In my opinion, it'd be fair if the guy calling for evidence also provides evidence.

In other words, I think that if xav wants case law references from drag, xav should provide
references of his own.

It's not a case, but djb's oft-expressed opinion that anyone has the right to release a patch
to his software guaranteed to them by copyright law, without any further intervention from
him, is applicable here too. As far as I am aware, the licensing problems with qmail do not
stem from that - otherwise, netqmail would be in trouble.

In any case, as far as I'm aware, nVIDIA do it the way they do for technical reasons - it
means they don't have to support a different binary module for every single kernel version out
there, instead relying on their thunk to be recompiled for the particular kernel under which
it finds itself installed. It might also make redistribution of the driver with a precompiled
kernel permissible - strictly speaking, the closed-source part is not derived from Linux; only
the thunk is, and that is GPL'd - but that's one for lawyers.

"A (non-trivial) driver NEVER does everything itself. It includes headers from kernel, which
in turn include more headers, which ..., in addition to using declarations from GPL-ed code,
results also in inlining GPL-ed code."

Yes, but if those things are found to be functional rather than expressive (that is, they're
just what you need to do to interface with the system), then including them arguably doesn't
make the module either infringing or derivative. 

Again, not a slam dunk one way or the other.