LWN.net Logo

keeping the GPL out of userspace? Nope...

keeping the GPL out of userspace? Nope...

Posted Mar 31, 2011 18:23 UTC (Thu) by armijn (subscriber, #3653)
Parent article: Android and Honeycomb

"Android userspace does not contain GPL licensed code" is a myth. I really wish it were that simple, but it is not, unfortunately. The system that Google ships it to third parties is indeed just the Linux kernel, plus a userspace that does not contain GPL code (so don't use this as a stick to beat Google with 'incompliance').

Then it goes to companies who make an SDK so real products can be made out of it and this is where A LOT goes wrong. You would be surprised to see how much GPLv2 licensed code then slips back in.

So, it is not as simple as everyone says it is.


(Log in to post comments)

keeping the GPL out of userspace? Nope...

Posted Mar 31, 2011 19:47 UTC (Thu) by karim (subscriber, #114) [Link]

That's interesting, because it raises a few rarely-mentioned issues.

However, I wonder how applicable this is in the specific case of Honeycomb tablets. One would understand that 3rd parties creating SDKs out of the AOSP have "value-added" software (i.e. mostly stuff they pulled off the web and put in their SDK -- which is where the GPLv2 software you mention likely comes from, Busybox et al. presumably.) In the case of Honeycomb, though, which apparently Google has only given source access to a handle of pre-vetted companies, such 3rd party SDKs would likely not exist (right?). And, therefore, the actual Honeycomb shipped by said manufacturers should be snow white, so to speak.

And in the other cases, those of GPLv2-"contaminated" SDKs, this is likely no different from what embedded Linux vendors have been doing for over a decade now (i.e. a mix of packages from all different directions which still require the company shipping the product to make sure it actually understands what it's really shipping.) IOW, copyright holders still need to be on the lookout for potentially infringing parties. Which is no different from the way it was before Android ...

Any complementary info you could provide here would be great.

keeping the GPL out of userspace? Nope...

Posted Mar 31, 2011 21:01 UTC (Thu) by paulj (subscriber, #341) [Link]

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

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