Bradley M. Kuhn

• Contact
• Blog  
• Interviews / Articles  
• Software
• Résumé

The New Era of Big Company Forks

Monday 8 February 2010 by Bradley M. Kuhn

I was intrigued to read Greg Kroah-Hartman's analysis of what's gone wrong with the Android fork of Linux, and the discussion that followed on lwn.net. Like Greg, I am hopeful that the Android platform has a future that will work closely with upstream developers. I also have my own agenda: I believe Android/Linux is the closest thing we have to a viable fully FaiF phone operating system platform to take on the proprietary alternatives like the BlackBerry and the iPhone.

I believe Greg's comments hint at a “new era” problem that the FLOSS community hasn't yet learned to solve. In the “old days”, we had only big proprietary companies like Apple and Microsoft that had little interest in ever touching copylefted software. They didn't want to make improvements and share them. Back then (and today too) they prefer to consume all the permissively licensed Free Software they can, and release/maintain proprietary forks for years.

I'm often critical of Google, but I must admit Google is (at least sometimes) not afraid of dumping code on a regular basis to the public, at least when it behooves them to do it⁰. A source-available Android/Linux helps Google, because Google executives know the profit can be found in pushing proprietary user-space Android application programs that link to Google's advertising. They don't want to fight with Apple or Research in Motion to get their ads onto those platforms; they'll instead use Free Software to shift the underlying platform.

So, in this case, the interests of software freedom align a bit with Google's for-profit motive. We want a fully FaiF phone operating system, that also has a vibrant group of Free Software applications for that operating system. While Google doesn't care a bit about Free Software applications on the phone, they need a readily available phone operating system so that many hardware phone manufacturers will adopt it. The FLOSS community and Google thus can work together here, in much the same way various companies have always helped improve GNU/Linux on the desktop because they thought it would foil their competitors (i.e., Microsoft and Apple).

Yet, the problematic spot for FLOSS developers is Google doesn't actually need our development help. Sure, Google needs the FLOSS licenses we developed, and they need to get access to the upstream. But they have that by default; all that knowledge and code is public. Meanwhile, they can easily afford to have their engineers maintain Android's Linux fork indefinitely, and can more or less ignore Greg's suggestions for shepherding the code upstream. A small company with limited resources would have to listen to Greg, lest the endeavor run out of steam. But Google has plenty of steam.

We're thus left appealing to Google's sense of decency, goodwill, collaboration and other software freedom principles that don't necessarily make an impact on their business. This can be a losing battle when communicating with a for-profit company (particularly a publicly traded one). They don't have any self-interest nor for-profit reason to work with upstream; they can hire as many good Linux hackers as they need to keep their fork going.

This new era problem is actually harder than the old problem. In other words, I can't simply write an anti-Google blog post here like I'd write an anti-Apple one. Google is releasing their changes, making them available. They even have a public git repository for (at least) the HTC Dream platform. True, I can and do criticize both Google and HTC for making some hardware interface libraries¹ proprietary, but that makes them akin to NVidia, not Microsoft and Apple.

I don't have an answer for this problem; I suggest only that our community get serious about volunteer development and improvement of Android/Linux. When Free Software started, we needed people to spend their nights and weekends writing Free Software because there weren't any companies and for-profit business models to pay them yet. The community even donated to Free Software charitable non-profits to sponsor development that served the public. The need for that hasn't diminished; it's actually increased. Now, there is more code than ever available under FaiF licenses, but even more limited not-for-profit community resources to shepherd that code in a community-oriented direction. For-profit employers are beginning to control the destiny of more community developers, and this will lead to more scenarios like the one Greg describes. We need people to step forward and say: I want to do what's right with this code for this particular userbase, not what's right for one company. I hope someone will see the value in this community-directed type of development and fund it, but for the meantime, it has my nights and weekends. Just about every famous FLOSS hacker today started with that attitude. We need a bit more of that to go around.

(I don't think I can end a blog post on this topic without giving a little bit of kudos to a company whom I rarely agree with: Novell. As near as I can tell, despite the many negative things Novell does, they have created a position for Greg that allows him to do what's right for Linux with what (appears to be) minimal interference. They deserve credit for this, and I think more companies that benefit from FLOSS should create more positions like this. Or, even better, create such positions through non-profit intermediaries, as the companies that fund Linux Foundation do for Linus Torvalds.)

---

⁰Compare this to Apple, which is so allergic to copyleft licenses that they will do bizarre things that are clearly against their own interest and more or less a waste of time merely to avoid GPL'd codebases.

¹Updated: I originally wrote drivers here, but Greg pointed out that there aren't actually Linux drivers that are proprietary. I am not sure what to call these various .so files which are clearly designed to interface with the HTC hardware in some way, so I just called them hardware interface libraries.

Posted on Monday 8 February 2010 at 09:50 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.