LWN.net Logo

keeping the GPL out of userspace? Nope...

keeping the GPL out of userspace? Nope...

Posted Mar 31, 2011 21:01 UTC (Thu) by paulj (subscriber, #341)
In reply to: keeping the GPL out of userspace? Nope... by armijn
Parent article: Android and Honeycomb

Is there really *no* GPL code in Android user-space? Surely there must be some low-level system stuff?


(Log in to post comments)

keeping the GPL out of userspace? Nope...

Posted Mar 31, 2011 23:45 UTC (Thu) by cjb (guest, #40354) [Link]

> Is there really *no* GPL code in Android user-space? Surely there must be some low-level system stuff?

If they're going to all the trouble of having their own libc and API-incompatible desktop environment, I don't think "surely" counts for much. That said, dbus and bluez are examples of code shipped with Android that are GPL.

keeping the GPL out of userspace? Nope...

Posted Mar 31, 2011 23:47 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

dbus is dual licensed, so it doesn't really count and bluez is used only via a IPC mechanism that is supposed to enable proprietary apps to use it without being impacted by the license.

keeping the GPL out of userspace? Nope...

Posted Apr 1, 2011 1:04 UTC (Fri) by paulj (subscriber, #341) [Link]

IPC is not of itself sufficient to let dependent code escape the GPL..

keeping the GPL out of userspace? Nope...

Posted Apr 1, 2011 1:21 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

I am not a lawyer. I assume Google legal team have competent people who have done what it is necessary and this is what I heard.

keeping the GPL out of userspace? Nope...

Posted Apr 1, 2011 2:44 UTC (Fri) by paulj (subscriber, #341) [Link]

I'm not a lawyer either, but that's the advice I got from legal counsel at another large US tech corporate. ;)

keeping the GPL out of userspace? Nope...

Posted Apr 1, 2011 3:08 UTC (Fri) by elanthis (guest, #6227) [Link]

Neither of your lawyers are any more right than the other because the GPL language is vague, interpretations are shifty, and what specifically counts as a derivative work in the GPL's terms has not yet been vetted by a US court.

Which is yet another reason to avoid the GPL and the insanity it causes.</flame> :p

keeping the GPL out of userspace? Nope...

Posted Apr 4, 2011 1:47 UTC (Mon) by jhubbard (guest, #5513) [Link]

Your comment applies to any license or contract not just the GPL. If it's not been vetted by a court, it's open to interpretation. Most people try not to end up in court. While the specific clause about derivative work may not have been cleared up yet, there was a win against Westinghouse. Don't forget all of the victories in Germany as well.

keeping the GPL out of userspace? Nope...

Posted Apr 5, 2011 2:06 UTC (Tue) by cmccabe (guest, #60281) [Link]

I am also not a lawyer, but I think this comment is interesting:
http://lwn.net/Articles/435223/

P.S.
It might be better if the bluez people put in a specific exception for this kind of use, the way Linux has a clear statement that user-space code is not a derived work just because it uses the system interfaces.

It seems like these days you have to spell out everything, even if it's obvious, to keep from getting sued by unscrupulous people who want to waste your time in court.

keeping the GPL out of userspace? Nope...

Posted May 31, 2011 12:22 UTC (Tue) by Trelane (subscriber, #56877) [Link]

Jein. Relevant FAQ sections (http://www.gnu.org/licenses/gpl-faq.html bolding is original, italics are mine)

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Can I release a non-free program that's designed to load a GPL-covered plug-in?

It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

See also the question I am writing free software that uses a non-free library.

What is the difference between an “aggregate” and other kinds of “modified versions”?

An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

keeping the GPL out of userspace? Nope...

Posted May 31, 2011 12:04 UTC (Tue) by fusebox (guest, #75304) [Link]

"bluez is used only via a IPC mechanism"??????????

I thought when you build an app with BlueZ, you usually #include <bluetooth/bluetooth.h>.... and then -lbluetooth during the build process.

The BlueZ GPL is transmitted straight to your "proprietary" app with no delay!

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds