| |||||||||||||
|
| |||||||||||||
Google Calling: Inside Android, the gPhone SDK (O'ReillyNet)Google Calling: Inside Android, the gPhone SDK (O'ReillyNet)Posted Nov 13, 2007 12:59 UTC (Tue) by filipjoelsson (subscriber, #2622)In reply to: Google Calling: Inside Android, the gPhone SDK (O'ReillyNet) by MattPerry Parent article: Google Calling: Inside Android, the gPhone SDK (O'ReillyNet)
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...
(Log in to post comments)
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.
|
|
||||||||||||