On December 29, tech-news outlets reported that engineers at Google had quietly committed a potentially important change to the Android codebase, moving the platform from Google's in-house Java Class Library to one based on Oracle's OpenJDK. In light of Google's legal battle with Oracle over Java's APIs, this struck some as a peculiar move indeed.

Prior to the change, Android had included a class library based on Apache Harmony. The library only supported that subset of Java 6 SE needed to run Android apps and, notably, it was released under the Apache 2.0 license it inherited from the Harmony project. In 2010, IBM (which had been one of the primary contributors to Harmony) announced that it was leaving Harmony and moving its development team over to the OpenJDK project. About a year later, Harmony was officially "retired."

That event was shortly after the Android 4.0 (Ice Cream Sandwich) release. Since then, Google developers have continued to maintain the Android library, though it was not updated to keep up with subsequent Java releases. As most people following Java are aware, Google and Oracle (which holds the copyright on OpenJDK) got embroiled in a bitter legal battle over Android's use of Java.

So it surprised many people when Google engineers made a commit to the Android Open Source Project (AOSP) that replaced the in-house class library with a new one derived from OpenJDK. The change was first pointed out on Hacker News (HN). The original commit in question was made in November, importing the OpenJDK code. The HN discussion thread uncovered a December 18 commit that implemented the dependency change (thus eliminating ambiguity about whether or not AOSP developers intended to keep both library implementations available in parallel).

After the HN piece was first published, Emil Protalinski at VentureBeat posted a story about the change that included a quote from an unidentified Google spokesperson: "In our upcoming release of Android, we plan to move Android’s Java language libraries to an OpenJDK-based approach, creating a common code base for developers to build apps and services." The spokesperson also told VentureBeat that the rationale for making the change was to take advantage of newer Java-language features like lambda expressions.

Nevertheless, both the VentureBeat story and the HN discussion thread asked whether or not the move was related to the Oracle–Google Java lawsuit as well as how using Oracle-copyrighted code in Android might impact the platform going forward. Regarding the lawsuit, some speculated that incorporating OpenJDK code was a sign that the suit had been settled out of court; others that it was a move designed to blunt Oracle's claims against Google. Thus far, neither company has made any public statement on that issue.

Mozilla's former CTO Andreas Gal wrote a blog post predicting dire consequences for Google due to Oracle's control of the OpenJDK codebase and roadmap:

Swing will now sit on every Android phone, using up resources. Its unlikely that Oracle will try to force Google to actually use Swing, but Google has to make sure it works and is present and apps can use it. And, Oracle can easily force Google to include pretty much any other code or service that pleases Oracle. How about Java Push Notifications, specified and operated by Oracle? All Oracle has to do is add it to OpenJDK, and it will make its way into Android. Google is now on Oracle’s Hamster wheel.

Swing, of course, is the GUI toolkit in Java; clearly a component that one would not think Google was interested in rolling into Android.

Gal went on to say that he has "a very hard time imagining Android N coming out on time" and speculating that Android device makers will purchase proprietary OpenJDK licenses from Oracle in order to optimize Android performance on their hardware for competitive advantage. The rationale for the latter comment is that hardware OEMs have grown accustomed to their ability to make changes to Apache-licensed Android components while not publishing the changes. Because OpenJDK is a GPLv2-licensed project, Gal contended, OEMs would not have such freedom unless they acquired a separate, proprietary license from Oracle.

The commenters on the post took issue with several of Gal's statements—pointing out, for example, that Google is free to drop whatever portions of OpenJDK it wants to (e.g., Swing) just as it did with Harmony. Providing a fully compliant Java implementation has never been the goal. Google could even maintain its OpenJDK-based class library as an independent fork.

As to the licensing issue, Bradley Kuhn of the Software Freedom Conservancy published a response on his own blog. He points out that significant portions of the OpenJDK code (including files found in the actual commits) are, in fact, published under GPLv2 plus the Classpath exception.

The Classpath exception grants users the right to copy and redistribute code that links to independent modules, regardless of what licenses those modules are under. Normally, linking to GPL-incompatible modules would risk running afoul of the GPL's combined-works requirements. Kuhn notes that the Classpath exception weakens the "viral copyleft" requirements on the code and thus makes OpenJDK's license-compliance requirements "not that much different" than Harmony's:

I urge you to ask anyone who says that this change will have any serious impact on licensing obligations and analysis for Android redistributors to please prove their claim with an actual example of a piece of code added in that commit under pure GPL that will combine in some way with Android userspace applications. I admit I haven't dug through the commit to prove the negative, but I'd be surprised if some Google engineers didn't do that work before the commit happened.

Kuhn acknowledges that there are still some "quite nuanced" distinctions between the Apache and GPLv2-with-Classpath-exception licensing requirements, but concludes that the change was probably made for technical reasons. "Google made a technical switch to the superior codebase, as it gives API users technically what they want while also reducing maintenance burden."

In the absence of additional evidence, it would appear that using OpenJDK code in the Android Java class library is unlikely to alter the licensing situation of Android. Whether or not Oracle finds a way to hinder Android development by manipulating OpenJDK (or, for that matter, whether it finds a way to profit from the new arrangement) simply remains to be seen.

In contrast, one can already see indications in the AOSP Git repository that Google has been working on adding lambda support. This commit, for instance, notes that work in underway to support new opcodes required for lambda-expression support. Other work in the area of lambda-expression support was noted as early as March 2015. While this may be the less dramatic interpretation of events, such work lends weight to the notion that the move from Harmony to OpenJDK is driven by technical, rather than legal or licensing, considerations. In the long run, that is a driving force that many developers are likely to find satisfactory.

Comments (22 posted)

The hurdles of pushing new software releases out to users via Linux distribution mechanisms have been well-documented in recent years. The sometimes lengthy delay between an upstream release and a new package being available from distributions motivated Mozilla's Extended Support Release (ESR) program and to various efforts at application sandboxing (such as GNOME's xdg-app). But sometimes the gulf between the upstream developers and the distribution is more fundamental, as a recent debate about ownCloud packages for Debian revealed.

Jos Poortvliet, community manager for the ownCloud project, posted a blog entry on January 4 recommending that users eschew distribution-provided ownCloud packages and install only those packages released by ownCloud itself. He cited the lag between the release and the distribution's package update, along with several other complaints. Distributions, he said, sometimes "don't grab the right code (like relying on a git tag rather than final zip files) or miss changes in dependencies which can break installations."

In addition, distribution packages can make upgrading problematic, he said, since:

[O]ur upgrade code looks at the ownCloud version to know how to upgrade - good luck if you run a Frankenstein version. Also, we don't support skipping ownCloud releases on upgrade. So once you're ready to upgrade your distribution with ownCloud 7.0.ancient to a new distro with ownCloud 8.2.shiny, well, it won't work.

Finally, he contended that:

The distribution packagers try to do weird shit, shoehorning ownCloud (and other web apps) into their rules made for C/C++ apps. You'll find packagers trying to move the ownCloud configuration php file out into the /etc folder or split up ownCloud core in separate packages because we maintain some external components as part of our setup. Of course, this breaks in beautifully surprising ways and provides few if any of the benefits they are hunting for.

Not surprisingly, some in the distribution community took umbrage at Poortvliet's characterization of the situation. Martin Steigerwald brought the post to the attention of the Debian ownCloud package maintainers, noting in his message that he had tried both the official Debian package and the one provided by ownCloud. The ownCloud package, he said, "was a *complete* disaster."

In particular, he said it was "like a tar.gz inside a Debian package. It just unpacks everything to /var/www/htdocs or something like that." The configuration files were not placed in /etc (as they are in the official Debian package), and it required the user to manually perform upgrade tasks like updating the application's database—another task that is automated in the Debian package. Apart from the shortcomings he saw in the upstream package, though, Steigerwald asked Poortvliet why he seemingly did not try to fix any of the problems he encountered with Debian's packages, asking "how about trying to find a way to *work* together and thus stop splitting man power? How about providing properly packaged packages that actually meet the Debian Policy for them? Did you ever talk to the distro teams about this?"

He also mentioned that he had talked to the maintainer of Debian's ownCloud package, David Prévot, who said it was unlikely that Debian could backport the current ownCloud release (version 8) to "jessie" (which includes ownCloud 7) because such a backport would pull in backports of other potentially problematic packages, like PHP. It would be better, Steigerwald said, for ownCloud to provide Debian-compatible backports. Doing so for security fixes is vital, while doing so for regular releases would help end users stay current. He invited further participation:

I understand the different policies and goals here. Upstream wants to move fast, Debian wants to provide a stable experience for its users. [...] What about looking for common ground and ways to cooperate instead – for the benefit of everyone involved?

There were commenters on Poortvliet's blog post who raised concerns as well. For instance, Nicolás Alvarez said: "If your git tags and your tarballs / zip files differ, you are doing things wrong, not the packagers." Prévot also replied to Steigerwald's email and said that he had tried in the past to work with ownCloud, providing patches to ownCloud's Debian packages, but without success.

Poortvliet wrote back in reply to the thread with a message that did not seem to improve the spirit of collaboration. He called concern over where a package stores its configuration files "because of some outdated policy," then advised the list that:

It is 2016. This is a web app. Your conventions do not apply. Live with it or become irrelevant. I know, the choice for option 2 was already made. Sorry, this is a flame, but there is a reason for Docker's popularity: the distributions have failed to keep up.

Much of the remainder of the email reiterated his criticisms of distribution packaging, while dismissing ideas raised by Steigerwald. He closed by suggesting that Debian create a set of guidelines for packaging web apps, moving to "an open, transparent platform where distribution and upstream people can collaborate on creating packages" (having suggested GitHub and the Open Build System earlier) and synchronizing such efforts with other distributions so as to reduce work.

Steigerwald then replied with surprise at the level of frustration expressed in Poortvliet's email. Debian, he said, has principles that make moving to a proprietary platform like GitHub impossible, and it is not reasonable to ask a distribution to drop its own project infrastructure for the sake of working with one upstream project.

In the exchange that followed, Poortvliet made it clear that he regards the "packaging problem" as one that distributions need to fix from their side. To his eye, the future of packaging is in projects like Docker, while "Debian and other distributions are going to be that thing you run docker on, little more." He also rejected a call to work with Debian's packaging team as:

Doing it all on your own, private infrastructure, closed off from other folks. Yes, if we want to collaborate with you, we have to be on Debian infrastructure, following Debian rules. And on Fedora infrastructure following Fedora rules. And on Arch and on openSUSE and on Ubuntu and on 10 more. You're saying that is "a middle ground"???

Steigerwald, however, contended that packaging trends come and go, and said he would rather help shape a solution than simply react.

I still hope that at some time ownCloud upstream and distro packagers can work more closely together again – maybe there is a common ground between using distro infrastructure and using Github, Open Build Service and other key points where goals and needs differ.

Eventually, Poortvliet did note that ownCloud's packaging team believes that its own packages could stand improvement, but he reiterated that he is interested in solutions that make packaging uniform across Linux distributions.

The discussion wound down shortly thereafter, when both sides concluded that there was little to be gained by retreading the same ground yet again. It remains to be seen whether any minds will be changed with the addition of more time to reflect on the question. Certainly there are many (particularly from the web-development community) who would agree with Poortvliet that existing Linux packaging rules do not fit their software's needs.

But there are certainly others with valid reasons to be suspicious of claims that Docker-style containers represent the zenith of package evolution. There have been other pretenders to that throne in past, after all. Perhaps the saddest outcome of the debate is the fact that neither side seemed to be able to persuade the other to commit to long-term collaboration. In the end, that represents a lost opportunity for both the projects and end users alike.

Comments (52 posted)

Another new year begins; that must mean that it's time for another try at the "predictions for the year exercise." Your editor doesn't know any more than anybody else on this score, but he has gotten so used to being wrong on the Internet that the prospect of being spectacularly so causes little fear. So, without further ado, here's a list of things that may or may not happen in 2016.

GPL enforcement will become a hotter topic this year. Developer frustration with GPL violations has been slowly increasing for years; in 2015, that frustration finally led to the VMware lawsuit. That particular action will probably be resolved this year, but it seems unlikely that things will stop there. Chances are good that another high-profile GPL-enforcement suit will be launched in 2016.

Perhaps ironically, increased GPL enforcement may well be accompanied by a reduction in fear of the GPL in general. Projects like Android have gone to considerable pain to avoid GPL-licensed software, with no real associated gains to speak of other than a reduction in (generally needless) worries. The use of the Linux kernel in Android has shown that GPL-licensed software can be used without giving away the farm — even when vendors go to the trouble of abiding by its provisions. Android's move to OpenJDK will further open the door, and any enforcement actions that happen will show what it takes to actually get into trouble with the GPL. Meanwhile, there are companies that increasingly see advantages in copyleft licensing. The end result of this is that, by the end of the year, the apparent move toward permissive licenses may just have slowed or reversed.

Attempts to create new, relatively free mobile devices will continue, despite the retreat of the Firefox OS project and the apparent invulnerability of Android. There is a lot of room for improvement in this area, with freedom and privacy topping the "to do" list for many, and the prize for success in this area could be huge.

Certain members of our community have given up on the idea of a new, free mobile system; many of these are also the ones who have loudly aligned themselves with the most proprietary alternative. It is true that challenging Android and iOS is a daunting prospect, but it may not be as ill-advised as one might think. After all, it's not that long ago that challenging Blackberry seemed like a poor idea.

More to the point, there can be room for new competitors even in mature, established markets. Few markets are more established than the automotive industry, for example, but some of the most prominent Android-alternative critics are certainly the ones pricing out Tesla configurations when their spouses aren't looking. Phones and tablets are replaced far more often than cars, and there are limits to brand loyalty, especially outside of the Apple garden. There should be room for a competitor — but that competitor will have to offer something more compelling than "doesn't run popular apps but might be a little freer."

The year-2038 problem will be mostly solved by the end of the year, though fully transitioning distributions to a 2038-safe code base will take longer. This issue shows how effectively free software can even deal with problems that won't strike for over 20 years. Before we celebrate our long-term vision too much, though, we should remember that the BSDs dealt with their year-2038 problems years ago.

We will hear a lot about blockchains as projects with extensive financing move forward. There will be numerous applications for a verifiable public ledger. Bitcoin may or may not share in this success, though; it may be starting on a path toward just being the first proof of concept for blockchain technology.

If 2015 was the year when the development community began to understand that we need to take our security problems more seriously, 2016 will be the year we begin to act seriously on security. There will be fights and disagreements over the specifics, for sure. Some will resent the overhead — in both development and code-execution terms — of the security measures that are adopted, while others will feel that far too little has been done. We will not have solved our problems by the end of the year, but there will be more progress made in that direction than has been seen for some time.

Efforts by governments to ban robust encryption will continue, as will attempts to force the addition of backdoors to hardware and software products. This may bring more attention to free-software solutions, which are naturally more resistant to the insertion of backdoors. While governments are working to reduce security, the stream of high-profile compromises will continue unabated.

The ongoing Volkswagen scandal, perhaps augmented by revelations of hostile behavior built into other devices, will bring more attention to the problem of hidden antifeatures in embedded systems. The prospect of machines like self-driving cars making life-and-death decisions will sharpen this attention. If we are lucky, the result will be demands for free (or at least open) software in many of these systems. Experience with other high-stakes settings (voting machines, for example) suggests that optimism on this point should be limited, though.

The 4.9 kernel will be released on November 27. The kernel development cycle, once wildly unpredictable, has become nearly boring. Almost every one of them now completes in 63 days. This prediction may miss by a week or so, but the chances of it being off by more than two weeks seem slim indeed. During this year we will also see the first development cycle that incorporates work from over 1,600 developers. We are not only able to incorporate tens of thousands of patches from thousands of contributors, but we can do it on a tight schedule.

Non-volatile memory (NVM) devices will make their presence felt as their capacity and availability grows while their price shrinks. Much of our software, from the kernel level upward, is designed around the idea that CPUs are fast while I/O devices are slow. The result is that we trade off a lot of CPU time to be able to cleverly cache data and avoid I/O operations. NVM looks likely to turn things around the other way, to the point where spending that CPU time is not only unwarranted, but it becomes overtly harmful to performance. The ongoing reevaluation of fundamental design decisions is going to be interesting to watch; we should see its pace picking up this year.

And finally, LWN will celebrate its 18th birthday later this month. That we would be doing this for so long was an outcome that none of us had predicted back at the beginning. But, as with Linux as a whole, it has been an amazing ride and it shows no signs of stopping anytime soon. Best wishes for the new year to all of our readers; we couldn't do this without you.

Comments (11 posted)