News

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Android Java Copyright Infringements?

Posted by Alex Blewitt on Jan 24, 2011

Sections: Enterprise Architecture,; Operations & Infrastructure,; Development
Topics: Java ,; Languages ,; Oracle ,; Licensing ,; Android ,; Google ,; Programming ,; Business ,; Operating Systems ,; Companies ,; Mobile

On Friday, Florian Mueller discovered two sets of files in the Android source code tree at http://android.git.kernel.org/ which may be damaging for Google's reputation and ongoing legal battle with Oracle.

There have been many responses to the post. The point of the recent allegations boils down to two separate findings in the source tree:

The inclusion of the MMAPI.zip, a multimedia API, which was free to download but without redistribution rights
Other files which appear to have been reverse engineered, possibly with a Java decompiler (much like the PolicyNodeImpl issue from before)

It's worth also emphasising that neither of these group of files are present in the shipping Android kernel; they are part of the testing source tree and so aren't in any final product. As a result, the option for Oracle to demand damages may be limited.

The MMAPI was included as part of a SONiVOX wrapper for Java ME, and included documentation to note that the MMAPI should not be redistributed. It seems to have been included in the source tree by mistake; lawyers will no doubt earn fees for arguing whether inclusion in a publicly readable source repository can be considered redistribution or not. Had the tree not been publicly readable, then this would not have broken the terms of the license. It's also worth explicitly noting that there was never a claim to relicense this code under the Apache License.

The second aspect is of the decompiled or regenerated files. Although the source code from Sun would have had an explicit license (including, potentially, GPL'd files), this does not apply to decompiled files. When code is decompiled (using a tool like JAD), the resulting source code is owned by whoever ran the decompilation tool. Generated source files using a decompiler, then, does not have to follow the same license as the code that it was decompiled from. Where Java makes this easy is that there's usually enough information in Java class files to convert compiled code back into similar looking Java code, even if the original source isn't available.

Of course, there is no proof that the source code was generated by a decompiler; that is simply a hypothesis. Many APIs that expect explicit constants or 'magic values' are part of an API contract and not merely some value added in to the code. And reverse engineering of software is sometimes used to create code under a different copyright (though usually a clean room design is introduced instead of direct decompilation). Since this doesn't side-step patents, though, any issues relating to the test code that infringe on patents may still be a problem.

This also highlights a potential problem with distributed version control systems, like Git. Even though the code is removed from the current head of the tree, it is still accessible by checking out a previous branch. Even if those branches are never accessed, just cloning the repository can bring down infringing code. Git has more flexibility than Hg in this regard, as the former has a git --filter-branch which can be used to re-write history to remove all traces of the code, something which appears not to have happened in the Android case. This isn't without its problems, since this will change the identifiers of all of the commits and cause problems for those wishing to continue development; but may be necessary in the case of detecting code which shouldn't be part of such a repository.

Since none of the questionable code is part of the shipping Android operating system, but merely on test code (which has since been removed from the master branch), Google may successfully argue that it removed inappropriate code as soon as it was notified and receive nothing more than a minor copyright infringement. It is unlikely to have a significant impact on the Oracle vs Google case, which is covered more by Groklaw as it unfolds.