Google Calling: Inside Android, the gPhone SDK (O'ReillyNet) [LWN.net]

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

Posted Nov 13, 2007 8:20 UTC (Tue) by MattPerry (guest, #46341)
In reply to: Google Calling: Inside Android, the gPhone SDK (O'ReillyNet) by bangert
Parent article: Google Calling: Inside Android, the gPhone SDK (O'ReillyNet)

> the GPLv2 does not control use - it controls distribution.  while you are
> allowed to do whatever you want with your GPLv2 kernel, you may not
> distribute a kernel which is in violation to the GPLv2. IE. if it 
> contains binary modules it becomes non-distributable. 

I think it's given that anything that we're talking about here is something that ends up in
distributed products.

> So vodafone could put a binary module on its phones and give it to all
> their employee's (use) - they can't sell the device to customers 
> (distribution), though. vodafone could sell the device to ESA 
> (distribution) - ESA puts on it the binary driver and gives it to all
> their employees (use).

I do not believe that's correct.  The driver communicates via an API and the kernel will
indicate that it's tainted if a non-GPL driver is loaded.  But the kernel can still load and
use the non-free driver without the source to the driver having to be redistributed.  However,
if the kernel proper is changed then those changes must be licensed under the GPL and the
changes made available to customers.

(Log in to post comments)

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

Posted Nov 13, 2007 12:59 UTC (Tue) by filipjoelsson (subscriber, #2622) [Link]

You keep talking about the module using an API, would you mind linking to a site describing
this API?

The API is for userland, and if you can write a userland driver - fine. That's distributable.
However, if you write a kernel module you have to use kernel symbols (which may change from
one kernel release to another). Saying that those are part of an API (though unpublished) is
like saying that your custom function residing in a statically linked o-file is also using the
API. Otherwise you are boiling this question down to static vs dynamic linking.

Now, I'm not sure exactly how a court of law will decide on the question of dynamic linking.
But if the do decide that dynamic linking is the same as "using the API" - then a whole lot of
licenses are going to change (proprietary as well as open ones).

As an aside, if the licensors intent matters; it might be interesting to check Linus' view on
kernel modules...

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

Posted Nov 13, 2007 17:34 UTC (Tue) by sepreece (subscriber, #19270) [Link]

As noted in another comment, there is [US] case law suggesting that interfacing to the program
is fair use, no matter how it's done.

There clearly IS an API that drivers and modules use, it just isn't "stable" or "published".
Except that it's sort-of-published. And it clearly is stable for a given release of the kernel
(a device manufacturer is likely to use the same release for a number of products over an
extended period).

Again, this is a very gray area - assuming courts would come down one way or the other is
accepting significant risk.

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

Posted Nov 13, 2007 19:12 UTC (Tue) by MattPerry (guest, #46341) [Link]

if you write a kernel module you have to use kernel symbols (which may change from one kernel release to another). Saying that those are part of an API (though unpublished) is like saying that your custom function residing in a statically linked o-file is also using the API. Otherwise you are boiling this question down to static vs dynamic linking.

You are correct that I mean kernel symbols not API. I was using the wrong term. But for the record there is documentation at http://www.tldp.org/LDP/lkmpg/2.6/html/index.html that discusses using the MODULE_LICENSE() macro. You can read the comments for yourself in include/linux/module.h which reads as follows:

/*
 * The following license idents are currently accepted as indicating free
 * software modules
 *
 *      "GPL"                           [GNU Public License v2 or later]
 *      "GPL v2"                        [GNU Public License v2]
 *      "GPL and additional rights"     [GNU Public License v2 rights and more]
 *      "Dual BSD/GPL"                  [GNU Public License v2
 *                                       or BSD license choice]
 *      "Dual MIT/GPL"                  [GNU Public License v2
 *                                       or MIT license choice]
 *      "Dual MPL/GPL"                  [GNU Public License v2
 *                                       or Mozilla license choice]
 *
 * The following other idents are available
 *
 *      "Proprietary"                   [Non free products]
 *
 * There are dual licensed components, but when running with Linux it is the
 * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
 * is a GPL combined work.
 *
 * This exists for several reasons
 * 1.   So modinfo can show license info for users wanting to vet their setup 
 *      is free
 * 2.   So the community can ignore bug reports including proprietary modules
 * 3.   So vendors can do likewise based on their own policies
 */

So the kernel code itself makes provisions for specifying whether your module is GPL or proprietary.

As an aside, if the licensors intent matters; it might be interesting to check Linus' view on kernel modules...

He doesn't have a problem with binary kernel modules. You can read up on it at http://www.linuxdevices.com/news/NS3501846795.html and http://lkml.org/lkml/2006/12/14/218.