posted by Thom Holwerda on Fri 4th Jan 2013 18:29 UTC
IconA blog post on the Free Software Foundation Europe site is making the rounds around the web. The blog post, written by Torsten Grote, claims that 'the Android SDK is now proprietary', because upon download, you have to agree to terms and conditions which are clearly not compatible with free and/or open source software. What Grote fails to mention - one, these terms have mostly always been here, and two, they only apply to the SDK binaries. The source is still freely available.

The terms and conditions covering the Android SDK contains several restrictions and limitations that are incompatible with free/open source software. There's an anti-fragmentation clause in there which prohibits forking, and a number of other troublesome clauses. However, many of these have been in the SDK's terms and conditions for years now, so this can hardly be called news. The Android SDK is proprietary - it always has been.

However, there's a crucial aspect that will most likely get overlooked as this blog posts makes its way around the web. These terms and conditions only apply to the SDK binaries. The source code, licensed under the Apache 2 license, is still freely available, so you are free to build the SDK on your own and bypass the terms and conditions of the SDK altogether. In fact, Replicant does just that, and you can download the latest version of the SDK (API level 15) they compiled from the source starting today.

The situation around Android, its open source nature, and the licenses and restrictions Google has attached to the Android brand have long been a source of misunderstandings, which is to be expected with complicated matters like this. In its simplest form, the Android code is open source under the Apache 2 and GPLv2 licenses, while Google's own suite of applications is not.

However, there's also the compatibility requirements you have to adhere to in order to carry the Android brand. While this is entirely unrelated to the Android source code, people often conflate the two. To further complicate things, there's also pieces of code in Android which are not open source, mostly drivers for which Google does not own the rights.

All this is not uncommon in the open source world. Haiku, for instance, employs essentially the same scheme.

Haiku, Inc. owns the 'Haiku'™ name, HAIKU logo®, HAIKU Background Leaf™, and HAIKU Leaf™ (registered) trademarks. As an open source project, the name and brand that is associated with the Project is vital to the Project's reputation and the sense of familiarity that end-users expect from the Software. Anyone is able to freely use the code that comprises Haiku, however the trademarks of Haiku cannot freely be used in the same liberal manner.

A more famous example is Red Hat, which employs this scheme for its Linux distribution.

It is important to understand that, although Red Hat allows third parties to replicate its open source software under the GNU GPL, absent a written agreement or other express permission it does not allow third parties to use its trademarks. For example, absent a trademark license from Red Hat, a party would have the right to copy, modify and sell Red Hat’s open source software, but they would have to call it by another name.

The additional restrictions imposed upon the SDK binaries - as non-Free/open as they might be - do not make Android any more or less proprietary. The code is out there for anyone to download and use. While it would be great if Android were developed using an open model, there's no requirement to do so. The Android 3.x situation was a massive cop-out, as I've said before.

I guess this story will continue to pop up every now and then in various forms, perpetuated by traffic-hungry blogspammers, people cheering for one particular team only, and those with little to no understanding of how open source works. It joins the stories about security on the Mac, iPhone whatever-gates, Linux on the desktop, and so on - a long list of recurring themes that no matter how many times we go over it, it just refuses to die down.

e p (1)    19 Comment(s)

Technology White Papers

See More