The New Era of Big Company Forks

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html

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
it0. 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
libraries1
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.)


0Compare
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.

1Updated:
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.