Android, forking, and control

Posted Jun 7, 2011 3:06 UTC (Tue) by swetland (guest, #63414)
Parent article: Android, forking, and control

We considered using a BSD kernel very early on (in the early days of the startup), but pretty quickly decided that the very strong industry support (particularly from ARM SoC vendors) around the Linux kernel made it a more logical choice. License was not a major factor in this decision.

The GPL does create a compliance burden for OEMs (compared to Apache2, BSD, or MIT licenses) and OEMs certainly seem to have a lot of difficulty with this burden, based on complaints I've seen about their handling of license compliance for both Android and non-Android systems. That's a simple fact.

The kernel's "bright line" exception of userspace code making syscalls from being part of it for license compliance purposes is quite helpful in justifying the use of a GPL'd kernel to OEMs and silicon vendors that have severe concerns about GPL "tainting" (be they real or imagined).

Android, forking, and control

Posted Jun 7, 2011 6:05 UTC (Tue) by idupree (guest, #71169) [Link] (4 responses)

Can you compare the GPL's burden on OEMs to a typical commercial licensing agreement? (That's the comparison our article/speaker makes: "The GPL, he said, is far easier to comply with than most commercial licensing arrangements".) Or if not, is my question wrong, or else who might know the answer?

It's both easier and simpler

Posted Jun 7, 2011 8:15 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

Can you compare the GPL's burden on OEMs to a typical commercial licensing agreement?

It's different. And it's much, much, MUCH easier for the OEM to comply with typical commercial license. Not because it's intrinsically harder but because it's totally different.

Commercial licensing agreement is typically imposes lots of burdens (you must count number of licenses sold, you sometimes need to certify your changes or are not allowed to do them at all, etc), but this is the exact some burden hardware suppliers will ask for! Any OEM has well-oiled machinery to talk with suppliers - or it'll not be OEM for long.

GPL does not place any such obligations on OEM - but instead it tasks them with simpler but very unfamiliar task: now they must track their own changes and make them available to customer. This is not something they were ever prepared to do. The most they expected from customers is returns of broken or unsold goods - and even then they can just throw them away and replace with newer models if they so decide. Often they don't even have anyone who's responsibilities are even remotely similar (the sales people they have talk with retailers, not with customers).

So in short: it is easier to comply with GPL, but it's requirements put OEMs in the very unfamiliar position.

It's both easier and simpler

Posted Jun 7, 2011 8:40 UTC (Tue) by mjthayer (guest, #39183) [Link]

> So in short: it is easier to comply with GPL, but it's requirements put OEMs in the very unfamiliar position.

I think part of the problem for OEMs is that with a "typical commercial licensing agreement" they have a single, usually friendly, person to talk to (this is a slight simplification in some cases, but still). With a GPL product they may potentially have to deal with any of the people who contributed to it, without even being sure how many people that may be, and they certainly can't be sure that some of those won't be actively looking for ways to hurt them. Which usually won't be the case of course, but I think the risk is still worrying for them.

It's both easier and simpler

Posted Jun 7, 2011 13:49 UTC (Tue) by lutchann (subscriber, #8872) [Link]

Exactly. Commercial licensing places the compliance burden on the legal and accounting departments. Copyleft licensing places most of the burden on the engineers. And since engineering is always, always, always the bottleneck when getting a consumer electronics product out the door, it greatly amplifies the cost of compliance.

Also, GPL violations are ubiquitous in the CE world and almost everyone gets away with it. It's just not something most small and mid-sized OEMs are concerned with in the least.

Android, forking, and control

Posted Jun 7, 2011 11:46 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, commercial licenses are actually quite simple. All they boil down to is: "You pay us money and redistribute our components". There might be other conditions: a percentage of gross from hardware sales, fees for each developer working on a product, etc. But in general they are fairly simple to comply.

Besides, commercial licenses are something business is accustomed to deal with, paying for stuff to produce other stuff is the core of our economy.

Android, forking, and control

Posted Jun 7, 2011 13:53 UTC (Tue) by karim (subscriber, #114) [Link] (1 responses)

Thanks for this nugget. Very insightful.

Totally agree on the "be they real or imagined"part. The downside of that, though, is that a lot of "standard" packages and modus operandi were thrown out the window (Busybox, uClibc, ...) I mean no offense, but Toolbox is nowhere near Busybox in terms of capabilities. In fact, the first thing I do when starting work on an AOSP tree is get Busybox in there ... Nothing major really, but an annoyance still.

Android, forking, and control

Posted Jun 7, 2011 15:49 UTC (Tue) by swetland (guest, #63414) [Link]

No offense taken. Toolbox was never intended to be a full-featured environment, simply some minimal tools for debugging. The reason /data/local is writeable by the "shell" user is that the expectation was that you'd throw whatever commandline goodies you want in /data/local/{bin,lib,etc}.

Android, forking, and control

Posted Jun 7, 2011 22:15 UTC (Tue) by linusw (subscriber, #40300) [Link] (2 responses)

Thanks Brian, love your posts here. Now this quote about "very strong industry support" look a bit odd since when the Nexus came out it seem to me like the MSM kernel was written to a large extent by the Android startup and Google rather than the chipset vendor, actually. I understand that it is different now, but was the support really that great in the beginning?

Android, forking, and control

Posted Jun 8, 2011 0:06 UTC (Wed) by swetland (guest, #63414) [Link] (1 responses)

Qualcomm was very supportive of us and provided documentation, technical support, etc, while we did the coreLinux port for MSM7X0X and MSM8X50. Since then they've become much more involved and are not working directly with the community, submitting patches on lkml, etc. Which is great!

Obviously some vendors already had code in mainline or patchsets available and others were not as far along, but overall Linux had a lot of momentum and there was plenty of interest in enabling it, even back in 2005. Since then it's only picked up even more steam, between Android, WebOS, MeeGo, etc.

Android, forking, and control

Posted Jun 8, 2011 0:10 UTC (Wed) by swetland (guest, #63414) [Link]

Blargh... s/coreLinux/core Linux/ s/are not working/are now working/ ... pardon the typos...