Could a GPL-style contribute-back clause be a reasonable compromise between Apple's walled garden and the Open App Markets Act?

It is interesting to watch how legislative initiatives, antitrust investigations, and litigation reinforce each other. Yesterday's announcement of the Open App Markets Act proposal by a bipartisan group of United States Senators marks a tipping point. It now seems rather unlikely that Apple can maintain its App Store monopoly on iOS. App store diversity is coming.

Apple may still be in a state of denial, and it can hire every lobbyist in DC and Brussels and elsewhere who isn't already working for its adversaries, but the time may have come to think about whether a reasonable compromise is possible.

I'm as independent as an Apple critic and complainant can be, and have recently remigrated to Android, which is the "lesser evil" in terms of the platform maker's control. I wrote my own antitrust complaints and my replies to Apple's (and Google's) responsive filings--every single word. When it comes to patent disputes, I've been sympathetic to Apple's desire for differentiation and to a certain attitude that could be described as exceptionalism. I do, however, draw the line where Apple denies app developers like me certain liberties that I believe are essential and very much in the interest of consumers.

On the one hand, I reject any arguments by Apple that come down to saying that its customers make the choice to deprive themselves of certain choices (such as access to apps not approved by Apple) and that this kind of choice deserves to be protected to the detriment of app developes and of all those Apple users who actually want more flexibility. Among one billion iOS users worldwide, there must be a diversity of views and positions. Even if they had only 1,000 and not 1,000,000,000 users, they wouldn't all share the same values and preferences.

On the other hand, it can't be reasonably denied that the Open App Markets Act in its proposed form would make the iOS app ecosystem less distinguishable from Android. In the end there would be cross-platform app stores, which would minimize switching costs (a consumer benefit) but further blur the distinction between the operating systems.

I don't claim to have the definitive answer, but I do wish to toss out an idea now: a GP-style reciprocity ("contribute back") clause in Apple's future IP license agreements with app developers.

Let me first describe what the net effect would be from a consumer's point of view:

• There would be more app stores than Apple's App Store.

• It's possible that competing app stores would undercut Apple's prices and/or outperform Apple on app curation.

• Some third-party app stores might do a better job serving a particular audience, such as gamers. That's called specialization.

• Still, under my proposed approach those who are religious about Apple's product philosophy--or simply trust no one as much as they do Apple--would find an Apple-aligned version of every app, except for apps that provide content or functionality Apple categorically disallows, on the App Store. As long as they don't install anything from other app stores, those users could continue to live in Apple's walled garden like before. By choice.

  There are people who don't trust a lot of companies. They are the ones who'd rather buy a new battery for their radio-based car key from an official Mercedes dealership than go to the next Best Buy and get a battery of the same quality at a fraction of the cost. And there are others who subscribe to a philosophy. I want freedom for app developers and users, but I don't want to deprive people of an "all in on Apple" type of choice.

Now some people may wonder how this "best of both worlds" situation could be achieved, given that

• competing app stores would normally have an incentive to enter into exclusive deals with app makers,

• some makers of extremely popular apps might leverage those titles to grow their own app stores, and

• some app developers might for whatever other reason (or just laziness) decide not to submit their apps to the App Store, but only to others (like itch.io).

The answer is a reasonable "contribute-back" obligation that Apple could impose by means of an intellectual property license.

Reciprocity clauses are found in the GPL (GNU General Public License), which is called a "copyleft" license for that reason and known for Linux (the technical basis of Android) and MySQL/MariaDB, and in the versions of the Creative Commons license that come with the "Share Alike" requirement. Those contractual structures have one key objective: whoever incorporates material into their own works under such a license should have to respect those values not only by lip service but also by contributing back to that values-based community the derivative work.

The GPL doesn't prohibit dual licensing. A long time ago I was an adviser to MySQL's CEO, and that company held all the copyrights (which no single entity does in the case of Linux), so they offered it to the whole world for free under the GPL--with the copyleft string attached--or, if you made a deal with them and paid license fees, you could incorporate it into your own products as a software component without having to publish your source code and allow free downloads.

What I'm proposing here for the iOS app ecosystem bears a strong resemblance to "copyleft" and to dual licensing:

• App developers would be free to submit a given app to as many iOS app stores as they please.

• Apple would not "tax" developers' revenues generated via other app stores. (A reasonable developer program fee is not what I mean by "tax.")

• The values-centric "contribute back" clause, however, would impose an obligation on developers to simultaneously--and in good faith--submit their app to the App Store.

  The only exception would be if an app would undoubtedly be rejected by Apple (for example, certain types of adult content). In that case, a submission to Apple would just waste everyone's time.

  Note that there would be no requirement for the app to be actually approved by Apple before other app stores could carry it. It would be submitted to all stores near-simultaneously (such as on the same day). The requirement is just to submit it in good faith.

• "In good faith" means that the App Store version of an app would have to be reasonably compliant. For example, if Apple insists on ad tracking ("ATT"), then a submission that flagrantly and unnecessarily violates that rule would have to be considered a bad-faith submission.

This way, competitive constraints would discipline Apple in many ways. If users found the App Store too expensive, or if Apple rejected too many apps that are worth publishing, or if others made themselves a name by outperforming Apple on curation quality, that could reduce Apple's app market share. The number one issue that Judge Yvonne Gonzalez Rogers raised on the last day of the recent Epic Games v. Apple trial is that Apple may compete for end users, but doesn't have to compete for developers. That's why app store diversity is needed. But a "contribute back" requirement to preserve Apple's differentiation and exceptionalism isn't antithetical to competition--and it means more choice, not less, for consumers.

I believe it would be fair to require developers not to charge more for themselves on Apple's App Store than on others. Developers should just say how much they want, and then the different app stores will add their margins on top. (When I do consulting for financial investors through expert networks, it works that way and I don't even know what the markup is.)

To the extent that Apple dissuades end users from granting that ATT permission, apps should be allowed to give users the choice to either enable ad tracking (particularly with a view to rewarded ads, which are key to ad-based games business models) or pay for certain goodies.

Then there's the question of how easy it should be for users to switch from one app store to another if they wish to use a given app on a different app store's terms. For example, they might download a game from Apple's App Store first, but later have an incentive (such as lower IAP prices) to continue playing that game, but redownload it from a rival app store. One would have to think this through, but where there is a will, there is a way. Consumers should have that choice--and app developers should have the right to inform them of the potential benefits, for the sake of having a serious competitive constraint.

Could there be functional differences? Yes. If Apple disallowed something that other app stores permit, there might be additional features once users download an app from another app store. This goes both ways, of course.

Is this going to happen? I'll be perfectly honest: I think the two sides of the debate are so entrenched that in the end there'll be a winning camp and a losing one instead of a win-win-win-win (Apple, developers, consumers who are totally Apple-aligned, and consumers who are not absolutely loyal to Apple). But at least I wanted to outline my thinking, now that Apple may really begin to think about how to mitigate the damage.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Former Sun chief about Google: 'immune to copyright laws, good citizenship, they don't share'

The ongoing Oracle v. Google trial continues to bring interesting material to light on a daily basis. In a single document made public by Oracle yesterday, which contains Sun-internal communication about Google in connection with Android and Java, I found several interesting statements on Google's attitude toward copyright and licenses.

On page 4 of the PDF file, Sun co-founder and long-time CEO Scott McNeely wrote to his successor Jonathan Schwartz on March 8, 2007 (you can click to enlarge the image or read the text below the image):

Here's the text again (in case the device on which you're reading this doesn't display the image in a legible resolution):

"The Google thing is really a pain. They are immune to copyright laws, good citizenship, they don[']t share.

They don[']t even call back."

In yesterday's testimony, Jonathan Schwartz tried to do as much damage to Oracle's case as he could. But that doesn't mean he always felt good about what Google was and is doing. On March 26, 2008, in correspondence with former MySQL CEO Marten Mickos (who after Sun's $1 billion acquisition of MySQL served as senior vice president of Sun), Schwartz wrote to Mickos, in the context of Google's business strategy of taking without paying, that Google also "take[s] Java for Android, without attribution or contribution."

The email thread that culminated in that statement is found on pages 18 and 19 of the PDF file I linked to above. Since everyone replied at the top (the customary way), I'm now going to show the most interesting parts in chronological order. The thread started on March 25, 2008, with Schwartz writing to ensure that Mickos had seen a CNET article on an IBM investment in EnterpriseDB (Postgres Plus). Like MySQL, Postgres is an open-source database, but under a different license (BSD, not GPL). After Mickos listed other Postgres-related facts and events, Schwartz replied with a story about what a "Google buddy" told him about how Google's senior managers internally communicated their view of different open source licenses (you can click on the image to enlarge or read the text below the image):

Here's the text again:

"Jonathan Schwartz wrote:

...was with my Google buddy over the weekend, and we got to talking abuot licenses. He made some pretty interesting comments about their internal (as communicated by senior mgrs) view of licenses.

They hate GPL, they like Apache, and they love BSD.

Just like Microsoft..."

Concerning the last part, in recent years I haven't heard anything derogatory from Microsoft about the GPL. The official position appears to be that they "disagree" with it. Anyway, this here is about Google, not Microsoft.

The GPL has a contribute-back mechanism that Google seeks to avoid. That's why it doesn't use the Java code that Oracle/Sun made available under the GPL. Unlike the GPL, the Apache license allows software published under it to be incorporated into proprietary (closed-source) software. And the BSD family of licenses are tantamount to an author of a program saying, "I hereby dedicate this work to the public domain".

Mickos then described Google's business model, including its use of open source software, in the following way (you can click on the image to enlarge or read the text below the image):

Here's the text again:

"It's funny with Google. They take (without paying):

• the [Free and Open Source Software] code 10 million developers

• the web contents of 100 million websites

• the searches of 1,000 million web users

and add some magic of their own after which they sell ads on this to some 0.1 million companies. And everyone is happy."

I actually have a somewhat more favorable view. I don't see Google generally "taking" the content of websites by indexing it and generating traffic, except in some cases in which content (such as from vertical search portals) gets integrated into the search engine in a way that Google strengthens its own services at the expense of other companies' websites. I also do respect, to be clear on this, what Google itself does in terms of developing great technologies of its own. I really like many of their services (this blog is hosted by Google's Blogger service), and Android. At the same time, there are intellectual property and antitrust and even sometimes data privacy issues, and I call them out on some of that.

Schwartz had a less balanced perspective than mine. He totally agreed with Mickos and said they all (at Sun) agreed with his assessment, and went on to mention Android and Java (you can click on the image to enlarge or read the text below the image):

Here's the text again:

"I so totally agree with you. We all do.

They also take Java for Android, without attribution or contribution."

Finally, with respect to Google's attitude toward copyright and licenses, page 24 of the PDF file mentioned further above shows an email reply that Schwartz sent, on an off-the-record basis, to a New York Times reporter (click o the image to enlarge or read the text below the image):

Here's the text again -- but in chronological order, so let's start with the journalist's questions:

"On Nov 6, 2007, at 8:22 AM, John Markoff wrote:

Hi Jonathan,

how the heck is Java going to be part of the Apache distro that the Android software is being given away under? Is this a legal issue between you and Google? How come they are using Java and you aren't part of their Alliance?"

This clearly shows that the reporter was fully aware of the incompatibility of the GPL and the Apache software license as well as the fact that Sun never allowed the Apache Software Foundation to provide licensed Java APIs under the Apache license. 20 minutes later, Schwartz replied:

"Off the record..."

God knows. They didn't want us to open source Java - they've already made some stupid comments about the GPL (the license of both Java and Linux - the foundation of what they're building).

As for how they avoid those licenses, I don't know - they've shown a frankly stunning naivete about free software - even their 'alliance' seemed all over the map, with second tier hardware guys and carriers. They appear to be believing their own hype - in my mind, Apple got mindshare because they had a great product. Google's presuming their brand will carry to a phone... in my view, it actually has to *be* a phone, not an alliance. And they showed nothing...

But they did a great job of hyping Andy Rubin :-)"

That answer shows Schwartz underestimated Android at the time. He's right about what worked for Apple, but what Google did with Android also worked (in terms of appealing to application developers).

I think Schwartz was being overly diplomatic by referring to Google's approach to free software as naiveté. Scott McNealy's statement that they are "immune to copyright laws, good citizenship" was a more accurate description. In my opinion, a very consistent disregard for other people's and companies' intellectual property rights, whether it's in connection with Linux, some non-Linux GPL software, Java or most of YouTube's content, can't be attributed to naiveté. There comes a point when someone who's always naive when it benefits him is simply being reckless and possibly arrogant.

Anyway, those emails probably helped Oracle to demonstrate to the jury that Schwartz didn't genuinely believe Google had the right to make use of certain Java-related intellectual property the way it did and continues to do.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Open-sourcing of Java and API copyrightability are entirely unrelated issues

My list of Twitter messages from the Oracle v. Google trial shows that Jonathan Schwartz told the jury about how "open" Java was meant to be and in the very same context claims tha APIs are, according to his testimony, not copyrightable. This is not surprising: Google also argued in its opening presentation to the jury that Java was free and open, and "Google built Android using free and open technologies". Furthermore, the issue of licensing terms also came up in connection with Tim Lindholm's testimony.

I'd like to explain just quickly why Sun's publication of certain Java software under an open source license has nothing -- absolutely nothing -- to do with the question of whether the structure, sequence and organizations of API packages is protected by copyright law.

Sun never made the Java APIs available under a so-called permissive license, i.e., an open source license that allows the code published under it to be incorporated into software published under other permissive or proprietary (non-open-source) software licenses. Instead, Sun alienated its would-be ally, the Apache Software Foundation, by open-sourcing Java under the GPL (GNU General Public License), a license competing with the Apache Software License (ASL). The most important difference between the GPL and the ASL (or other permissive licenses) is copyleft, a mechanism under which any derivative works (programs incorporating GPL'd programs) must also be made available on the GPL's terms if they are published (if you only use them in-house, copyleft doesn't affect you). The ASF created Harmony, a Java implementation it chose to publish under its own license, but without a license from Oracle/Sun. This means that anyone who incorporates Harmony into his software still needs a license from Oracle/Sun.

There's no way that Google's use of the structure, sequence and organization of the asserted API packages can be justified by claiming that Google simply chose to benefit from the availability of Java software published by Oracle/Sun on free and open licensing terms. Either the relevant material is copyrightable, or it's not. That's a binary question. If we assume, only for the sake of the argument, that it's not copyrightable, then there's nothing that any open source license can do to make it more free or more open: in that case, it's simply not protected and, therefore, not subject to any license, even if someone says he licenses it under a given license. Copyleft can only attach itself to copyright. You can't put (or get) non-copyrightable material under a particular license any more than you can nail together water.

But in the other (more likely) event that this is copyrightable material, copyleft applies. Before the trial, Oracle briefed reporters on the case and said clearly that there are two acceptable ways to use its Java IP: on GPL terms, or by licensing the essential IP for a fully compatible implementation (be it a "clean room" implementation or one based on Java code licensed on commercial terms). In other words, Google would always be free to put all of Android under the GPL and incorporate Oracle's (Sun's) GPL'd code under the terms of the GPL -- but so far that's not what Google has done, nor is there any indication that it wants to do this in the future. That's why Google needs a commercial license, but it doesn't have one, and that's why the ongoing trial is taking place.

Simply put, Google can't use the GPL as a defense because it doesn't comply with the GPL.

Even the Classpath Exception, which was designed to ensure that other software could link to a GPL-based implementation of the Java APIs, couldn't solve Android's licensing problem. Android doesn't "link this library [GNU Classpath] with independent modules to produce an executable". Android incorporates the structure, sequence and organization of the asserted API packages, which Google then redistributes as a new API.

Sun never wanted to give away its intellectual property in Java to everyone and turn Java into a zero-revenue (or service-revenues-only) business. Sun always knew that there would be commercial players who wouldn't want to be bound by the terms of the GPL -- such as Google. Not only Sun. Google also knew it. Here's one of Oracle's opening slides, which shows an excerpt from an email Andy Rubin sent to other key Android players at Google on August 11, 2007 (click on the image to enlarge):

These passages are highlighted in Oracle's slide:

"The problem with GPL in embedded systems [such as smartphones and tablets] is that it's viral [...]"

"Sun chose GPL for this exact reason so that companies would need to come back to them and take a direct license and pay royalties."

The Android team over at Google knew more about Sun's Java business model than Sun's Jonathan Schwartz today claimed to know when he portrayed his business strategy as one of just giving the thing away to build a "big tent" (which wouldn't change the terms of the licenses under which Java was published, regardless of whether or not this was truly Sun's strategy for sustainability).

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

The Lindholm testimony and the reality of Java licensing options

Yesterday was day 4 of the Oracle v. Google trial, and all observers were particularly interested in the testimony of Tim Lindholm, author of the Lindholm email. It appears that the testimony fell far short of meeting the expectations that this "smoking gun" piece of evidence had raised. Lindholm, who may have spent more time with lawyers recently than with fellow software developers, wanted to downplay the significance of the email and of his own involvement with Android.

Three facts appear particularly interesting to me. I'll comment on two of them quickly and then talk in more detail about the third item, licensing.

All of the reports I read indicate that Lindholm was extremely evasive. He tried to deny everything he possibly could deny, and to downplay the remainder. In particular, he didn't want the jury to think that he had too much to do with Android. However, Oracle presented a whole collection of Lindholm emails, spanning a period of more than five years and indicating that he was involved with Android, from a Java angle, at different points in time during that period. I guess he was primarily concerned about not saying anything stupid that would make things even worse than his most famous email, but whether he convinced the jury of anything is at least doubtful.

ZDNet's Rachel King, who belongs to a small group of people that kept an eye on this litigation even at times when there wasn't much mainstream interest in it, noted in her report that Lindholm "dance[d] around questions about Java licences". In that article you can also a see a picture of Lindholm leaving the courthouse. The report says that, after an agreement between the parties that he wouldn't be called to testify again, Lindholm made "two peace signs to much laughter throughout the courtroom". That's the second point I wanted to comment on. I can't see what's funny about the fact that he had to testify. He certainly didn't anticipate all of this interest in that August 2010 email -- if he had understood the consequences, he wouldn't have written it in the first place. Sometimes there are funny situations, and humorous judges and lawyers, but if every witness made such signs or other gestures at the end of a testimony, the courtroom would turn into a circus.

Eight years ago, the then-CEO of Deutsche Bank, Josef Ackermann, made the V sign in court, which "was not well received" according to Der Spiegel, Germany's most influential newsweekly.

The single most puzzling statement that Lindholm made is that his internal recommendation to negotiate a Java license ("We conclude that we need to negotiate a license for Java under the terms we need.") allegedly did not refer "specifically [to] a license from anybody". But in practical terms, there's no way that this could have meant anything other than a license from Oracle, directly or indirectly.

As Google itself admits, "[f]or the 37 accused API packages, Android and Java 2 SE Version 5.0 have substantially the same selection, arrangement and structure of API elements."

There's no ownership dispute over the copyrights to those API packages (a fact that Oracle lawyer Michael Jacobs stressed when Google made a big deal out of the fact that some of the APIs were contributed by community members). So Google needs a license to this and other Oracle intellectual property.

There are only two ways to get a Java license. On the one hand, there are commercial licensing options, but all of those have two things in common: a requirement for full compliance with the standard (no supersetting, no subsetting etc.), and the fact that royalties are due. On the other hand, there is more flexibility for modifications, and no license fee involved, if a licensee makes use of Oracle's (originally Sun's) Java developer kits that are available under the GPL, the same license under which Linux, MySQL and other free and open source software is also published.

The second option can be ruled out quite easily in connection with what Lindholm wrote. He recommended "to negotiate a license", and with GPL code, there's no negotiation: there's a license, and you can take it or you can leave it. If Google had chosen, or decided to choose in the future, the GPL avenue, it would lose the control it currently has over Android. Its proprietary extensions (the Android Market, GMail, Google Talk, Google Maps, Google+ etc. clients) would have to be made available under the GPL as well, due to its "copyleft" (i.e., viral) nature. Not only would the GPL deprive Google of its ability to withhold those goodies from all those who refuse to accept its licensing terms designed to strengthen Google's dominant market position in search and other advertising-financed online services but its device maker partners would also be unhappy: many of them build proprietary extensions on top of Android (such as Samsung's Touchwiz and HTC Sense). It's not even clear whether Android in its current form complies with the GPL, but if Google decided to incorporate Java on a GPL basis, there would be no question about all of Android being subject to copyleft.

Now let's look at the two possibilities that exist in connection with the first option, a commercial license.

Like I said before, commercial licenses come with the requirement of full compatibility with the Java standard. It's possible that what Lindholm meant by "the terms we need" is a special license allowing Google to use Oracle's intellectual property without having to adhere to the standard. It's also possible that he meant, alternatively or additionally, that Google would need special financial terms because it wants to distribute Android free of charge (though in reality it's not free since most of the major Android device makers already pay patent royalties to third parties). At any rate, he meant a commercial license, possibly on non-standard terms, and in his testimony on Thursday he suggested that such a license could come from any of a number of companies offering Java virtual machines.

Without Oracle's consent, third parties can't offer incompatible versions of Java, and this very lawsuit shows just how unwilling Oracle is to accept fragmentation. But any compatible implementation, whether it's provided by Oracle or by a third party, inevitably infringes some of Oracle's intellectual property. There's just too much Oracle/Sun stuff in Java that one could do a so-called "clean room" implementation (which Android, for more than one reason, does not constitute, but that's a different story I'll discuss soon) and navigate around all of Oracle's intellectual property rights.

As the stipulation I reported on earlier today confirms, there is Oracle material in Android. Google may claim that it's not copyrightable, but it claimed this before and lost a summary judgment motion. There are also a couple of patent infringement issues, and we'll get to those in phase 2 of the trial. At any rate, Lindholm's suggestion that his reference to a Java license could have meant any company offering a Java virtual machine is, at best, misleading. Short of Google relinquishing its control over Android by going GPL, any other licensing option would have had to serve the purpose of giving Google the right to use Oracle's intellectual property in Android -- and for an incompatible implementation of Java, which is what Android is in its current form, there would have been no third-party option anyway (nor is there any indication of Oracle being prepared to tolerate fragmentation for more than maybe a transitional period).

In short, Lindholm's denial of his most famous email having referred to any particular licensor comes down to this: Google needed (and still needs) to negotiate a license with Oracle or with Oracle.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Follow @FOSSpatents

Share with other professionals via LinkedIn:

Share|

Google's Android faces a serious Linux copyright issue (potentially bigger than its Java problem)

Intellectual property issues continue to cloud Google's mobile operating system. More than a dozen patent suits over Android are already underway. In one of them, Oracle additionally claims that Android infringes on large amounts of copyrighted Java code. And now there is grave concern over the legality of a central element of its architecture: the library that connects Android and its applications with the underlying Linux kernel.

Google copied 2.5 megabytes of code from more than 700 Linux kernel header files with a homemade program that drops source code comments and some other elements, and daringly claims (in a notice at the start of each generated file) that the extracted material constitutes "no copyrightable information".

It is much more likely that Google is wrong and this is, instead, a very serious violation of the GPL, the open source license under which Linux is published.

The GPL's copyleft nature requires all derivative works of a GPL'd program to be made available on the same terms. Google, however, very intentionally publishes Android as a multi-license potpourri of

• GPL'd software (the Linux kernel),

• permissively-licensed open source software (programs under open source licenses such as the Apache Software License or BSD/MIT licenses, which don't come with copyleft), such as the Dalvik virtual machine (which is at the heart of Oracle's lawsuit), and

• closed-source programs.

Google's "no copyrightable material" claim, which plays a central role in enabling this potpourri, is at best questionable. If Google is proven wrong, pretty much that entire software stack -- and also many popular third-party closed-source components such as the Angry Birds game and the Adobe Flash Player -- would actually have to be published under the GPL. In some cases, such as Dalvik, that would be hard to do for technical and licensing reasons, but in any case, a fully GPL'd Android would completely run counter to Google's Android strategy. Everyone would be free to use, modify and redistribute all of the affected software.

As a result, there would be no more revenue opportunity for the developers of the affected applications, and the makers of Android-based devices would lose their ability to differentiate their products through proprietary add-ons. Whatever software they publish would become available to their competitors on GPL terms. Prices and margins would inevitably come down.

To eliminate the risk of a collapse of the Android ecosystem and navigate around copyleft, the misappropriated Linux code would have to be replaced. The only real viable alternative is a library called glibc (GNU C library). That library is the industry standard and is used by Android’s major mobile Linux competitors, MeeGo and WebOS.

It wouldn’t be easy, though. Due to architectural differences between Bionic and glibc, thousands of Android components would have to be rewritten and rebuilt by Google and third parties. In some cases that could prove very difficult and time-consuming. There would also be significant compatibility issues with legacy versions of Android. Painful as it may be, there's no legally safe alternative that would shield Android from the implications of GPL copyleft.

Let me now

• explain why Google's denial of copyright is unlikely to hold water in court (at least in the US),

• describe the wide-ranging implications this hazardous approach -- which is either downright illegal or at least irresponsibly risky -- could have for Android device makers and application developers, and

• look more closely into what Google should do to fix this problem -- sooner rather than later.

Copyright is more resilient than Google thinks

Google openly admits that it wanted to "keep [the] GPL out of user-space" (userspace is whatever runs on top of Linux). You can find that statement on page 36 of this official Android presentation (PDF). So the Android development team came up with a library named Bionic, which contains a set of Linux kernel header files. Each of them starts with the following notice:

"This header was automatically generated from a Linux kernel header of the same name, to make information necessary for userspace to call into the kernel available to libc. It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information."

Note that the text mentions libc, which is a different library than glibc. It's BSD-licensed. Bionic is based on libc, and the header files with the above notice are added to Bionic.

The above notice is Google's way to say that the GPL doesn't affect Android because copyleft legally depends on copyright to be enforceable.

Having looked at many of those files, I don't think Google is right. There are potentially copyrightable elements in those files, such as inline functions, and even a collection of individually non-copyrightable elements can as a whole be protected by copyright.

Linus Torvalds himself has clearly rejected the idea of using the original Linux kernel headers in programs that aren't licensed under the GPL. In a posting to the official Linux kernel mailing list, he made the following unequivocal statements:

"In short: you do _NOT_ have the right to use a kernel header file (or any other part of the kernel sources), unless that use results in a GPL'd program."

"So you can run the kernel and create non-GPL'd programs [...]
BUT YOU CAN NOT USE THE KERNEL HEADER FILES TO CREATE NON-GPL'D BINARIES.
Comprende?"

That statement was made in 2003 and looks abundantly clear. I don't think it was based on the assumption that cutting out source code comments and some functions, with the subtlety of a chain saw, would ever be sufficient to circumvent the GPL. If this served its purpose, the GPL would be reduced to absurdity, resulting in proprietary forks and extensions of Linux and other GPL'd software such as MySQL.

Neither Linus nor I are lawyers. However, two high-profile US copyright experts -- an academic and a practitioner -- have also expressed doubts about Google's claims.

Professor Raymond Nimmer stated on his blog that "[t]he Linux core header files [...] are almost certainly copyrighted" and while he points out that he hasn't examined the facts, he finds a removal of "the expressive features involved in the structure of the header files [...] difficult to achieve since the goal was to borrow the effectiveness of the Linux system at least in part."

But the presence of expressive features would make the output of the script copyrightable, and consequently it would have to be published under the GPL.
On the Huffington Post I saw a post by Edward Naughton, a prominent IP litigator. The article is entitled "Google's Android Contains Legal Landmines for Developers and Device Manufacturers" and links to a much more detailed legal analysis, in which he describes Google's approach to the Linux kernel headers as "unusually audacious" and sees it as part and parcel of Google's overall questionable approach to software reuse in Android:

"Google's position is a bold assault on copyright protection for software and source code. There are cases, to be sure, that have permitted some copying of very small snippets of code when that is necessary to achieve interoperability. [...] Those cases do not provide much support for Google's argument that copyright law allows it to copy entire source code files, and even less for its suggestion that entire APIs [application programming interfaces] are not copyrightable."

In summary, Naughton argues that Google is very likely violating the GPL with Bionic because it incorrectly assumed it can simply "clean" the Linux headers of copyrightable information and repurpose them as it wants. On a "micro" (or individual file) level, he explains that most legal experts recognize that header files can contain copyrightable material. He points out that some, if not many, of the Linux headers that Google used in Bionic do indeed contain copyrightable material and that despite Google's claim to the contrary, it did not (and probably cannot) fully remove that material. As a result -- he concludes -- there are very likely files in Bionic that are still subject to the GPLv2.

He also makes an argument at the "macro" level based on the fact that, under US copyright law, API files are copyrightable. He argues that the overall collection of over 700 headers would likely qualify for copyright protection as a whole based on their "complex overarching structure." That would, therefore, preclude Google's ability to take those files as a group and strip them of their GPLv2 license.

Naughton's argument regarding the Bionic headers is straightforward, and I recommend reading it in full because I believe it explains very well what Google has done in a technical and legal sense. While I am not a copyright lawyer, I think the argument is compelling, and bears examining by those who are looking to use Android commercially.

In light of what experts like Nimmer and Naughton say, at the very least, I don't think anyone in the Android ecosystem can rely on Google's "no copyrightable information" claim. For a platform like Android, on which so many products depend, there has to be legal certainty. Anything less wouldn't do.

Widespread risk and far-reaching implications

The header file issue described herein affects many thousands of files (it pervades the Android codebase), and there are thousands of contributors to the Linux kernel -- independent programmers as well as companies -- who could sue Google and other companies in the Android ecosystem, alleging a violation of the GPL.

Litigants could have all sorts of motivations, be it the defense of software freedom, hopes of lucrative settlements, or competitive conflicts with Google, certain device makers, or particular application developers. Someone might act next month, next year, or later on.

If a court of law finds that the Bionic library indeed contains copyrightable GPL'd software, the distribution of all software compiled against Bionic -- and of devices containing such software -- will have to stop until there is full compliance with the GPL.

Bionic is at the heart, not at the periphery, of the Android architecture. Thousands of Android software components depend on it. I have discussed this with a Linux programmer I trust and he generated an automated analysis for me that I have uploaded to Scribd and Crocodoc. The document contains a table that shows Android components that have a so-called file dependency on Bionic, meaning they can't run without Bionic. It shows which particular parts of Bionic are used, and how many times. That table has 1,276 pages and more than 27,000 rows, and isn't even complete because only the open source components of Android were analyzed. In the event of a court ordering an injunction due to GPL infringement, the distribution of Android could not resume until each and every one of those rows -- and similar dependencies in files not yet examined -- has been properly addressed.

In terms of third-party applications, the more powerful and sophisticated they are, the more likely they are to be written in C or C++, and, therefore, the more likely they are to use Bionic. When device makers add their own components (for example, Motorola adds a program named Motoblur on top of Android), they will in most cases use C or C++ as the programming language, and consequently the Bionic libary.

Major third-party apps like Angry Birds and the Adobe Flash Player also appear to be written in C or C++.

The only realistic way to fix the problem: replace Bionic with glibc

Theoretically -- but not practically -- Google could try to solve the problem by giving up on its mixed-source strategy in favor of a GPL-only approach. Proponents of free software would be very happy about that. In fact, some of them have already started the ambitious IcedRobot project to build a GPL-only Android fork. But the price for Google to pay for this would be prohibitive.

For many components of Android, Google owns the copyrights, so it could relicense them under the GPL. However, for some very essential code Google doesn't have that option. In particular, its Dalvik virtual machine includes code from the Apache Harmony project. The Apache license and the GPL are inherently incompatible. Without that virtual machine, Google couldn't make most Android apps run. It would therefore have to replace the Harmony code with something already available or potentially relicensable under the GPL. This might take too long.

Even if Google -- hypothetically speaking -- managed to put all of the essential code under the GPL, it would thereby abandon the commercial strategy it has been pursuing so far, at least to a very large extent. On the current basis, Google uses proprietary licensing terms for closed source apps such as Google Earth -- in addition to its control over the Android trademark -- to control what device makers do. If those components had to be GPL'd, what Google would be left with to control the ecosystem would basically come down to the Android trademark.

Device makers would, as I explained further above, find themselves unable to differentiate their products through proprietary add-ons. They might invest a lot of money in extensions like Motorola's Motoblur only to find their competitors -- such as low-cost manufacturers from China -- building such code into competing products on free software terms. That's the death of differentiation.

Developers of applications using Bionic would only be able to charge (via the Android Market) those customers who don't know what rights they have under the GPL. All others would find ways to download and install those apps on GPL terms, i.e., free of charge.

In view of all of that, I think the only viable option will be for Google to recognize its error with Bionic and to replace it as soon as possible with glibc (GNU C library). That library is licensed under the LGPL ("Lesser GPL"), which has the effect that applications can access the Linux kernel without necessarily being subjected to copyleft if certain criteria are fulfilled.

Using glibc is the industry-standard approach, and it is the approach used by those in the open source world who are trying to "play by the rules." As I said before, even Google's major mobile Linux competitors use glibc. I have found documents that prove this: a MeeGo technical overview, a webOS license information document (Palm was acquired by HP), and a blog post by a sr. webOS developer relations engineer. In fact, Google's decision to forego glibc is one of the reasons Android is considered a Linux fork rather than a true Linux implementation.

However, it's apparent that even the LGPL'd glibc is too much of a copyleft risk from Google's point of view, so Google decided to build Bionic in the dubious way I described herein, essentially going its own way and thumbing its nose at the industry convention.

But replacing all references to Bionic with references to glibc throughout the entire Android codebase would be a daunting task. There wouldn't be the licensing issue Google would face if it wanted to put Dalvik under the GPL, but probably a large number of manual edits would be needed in many of those countless Android files making use of Bionic. Some files might just recompile right away against glibc, but I doubt that all of them would. I understand that there are important architectural differences.

This replacement would have to take place not only on Google's part but also be required of all developers of Android add-ons and applications written in C/C++, and by now a lot of such software has been developed by a large number of companies. Moreover, even if Google could resolve these issues going forward, there would still be problems with products running legacy versions of Android. Nonetheless, Google needs to do something because the sooner Google gets its act together, the more likely it is to pre-empt GPL enforcement by any Linux kernel copyright holder.

I'm sure Google would rather spend the same resources on the development of new features for future Android versions. That's what the ecosystem -- of which I'm actually a part, as a user -- would also like to see happen. But what must be done must be done. Continuing on the current, highly hazardous basis is not a viable option as far as I can see.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents.

Share with other professionals via LinkedIn:

Share|