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.

 

> Define "successfully". Just because kernel people have not stopped a
> company from distributing proprietary kernel modules doesn't mean they
> won't.  You're basically arguing, "It must be OK because they haven't
> been caught."

I define successfully as distributing the module for a minimum length of time (say, six to
twelve months) without legal challenges being brought against you.  That's my personal
definition.

> if you read the GPL you'll find it has a lot to say about how you can
> distribute GPL'd code and non-GPL code that is derived from it.

Then you get into the quagmire of defining derived.  Even Linus Torvalds stated that,
"including one header file in order to compile against something does not automatically make
something a 'derived work'."[1]  There is also the fact that the comments in
include/linux/module.h specifically mention the ability to define the license used for the
module, including using "Proprietary" as an example of a non-free module license identifier.
See my other post at http://lwn.net/Articles/258419/ which has a copy of the comments from
module.h.

These public statements combined with the comments in the module.h header file show explicit
intent to allow non-free modules to be used with the kernel.

> I suggest you look toward sources related to copyright law rather than
> toward whether the kernel provides an API.  

If you know of any case law that I can read that addresses this type of issue I would be happy
to read it.

> Your API talk just demonstrates that you're new here and don't begin to
> understand the real issues.

I will admit that I misused the term API; however, I have a strong understanding of the real
issues even if I'm not a kernel programmer.  I have also cited primary sources to support my
statements.

1. http://lkml.org/lkml/2006/12/14/218