New alleged evidence of Android infringement isn't a smoking gun
arstechnica.com
By Ryan Paul | Last updated 30 minutes ago
Patent reform activist Florian Mueller has published what he believes to be new evidence of copyright infringement in Google's Android software platform. He has found files in the Android code repository that have Sun copyright headers identifying them as proprietary and confidential.
A close look at the actual files and accompanying documentation, however, suggest that it's not a simple case of copy and paste. The infringing files are found in a compressed archive in a third-party component supplied by SONiVOX, a member of Google's Open Handset Alliance (OHA). SONiVOX, which was previously called Sonic, develops an Embedded Audio Synthesis (EAS) framework and accompanying Java API wrappers which it markets as audioINSIDE.
When EAS was first published into to the Android Open Source Project (AOSP) code repository in 2008, one of the files that was included in the initial code commit was MMAPI.zip, which is stored in a subdirectory called misc. The zip archive appears to contain SONiVOX's implementation of a Java ME Mobile Media API (MMAPI) wrapper for EAS and a set of tools for porting and testing the implementation.
Some of the files included in the archive for testing purposes were adapted from code that originated in Sun's MMAPI reference implementation (MMAPI RI) and the J2ME Wireless Toolkit (JWT). This code from Sun is publicly available and can be downloaded at no cost from the Sun Developer Network website, but it's distributed under licensing terms that restrict redistribution. SONiVOX's documentation is very clear about which components come from Sun and includes text in several places indicating that certain parts of the stack should not be redistributed.
It's not clear how the zip file got included in the AOSP, but it's obvious that it wasn't intended to be there and isn't actually used by Android in any capacity. Android is using SONiVOX's EAS code, but doesn't use or need the MMAPI wrapper. This incident is very clearly not a case of Android stealing code from Sun or J2ME. It's a handful of test cases from an unrelated and publicly available Sun reference implementation that got uploaded by accident to AOSP in a zip archive supplied by a third party. It's a tacky mistake, but it's hardly serious or damaging. At worst, it warrants a takedown notice. It's certainly not a smoking gun as one might assume when viewing the code out of context.
It's worth noting that this particular new evidence supplied by Mueller isn't at issue in the litigation between Oracle and Google. Oracle's claims regarding Google infringement are related to certain files in AOSP that appear to be based on decompiled versions of classes from Sun's own Java implementation. Oracle's filings show an example of this, a module called PolicyNodeImpl. Mueller has also recently found a handful of additional files that similarly appear to be based on decompiled Sun classes in a nearby directory.
A close inspection leaves little doubt that, as Mueller alleges, it is decompiler output and that it closely resembles Sun's code. However, it's worth noting that this code isn't actually shipped in Android. The offending code has comment headers indicating that it's part of Apache Harmony, but it doesn't appear to be in the upstream Harmony tree and the Apache Software Foundation has already denied any knowledge about it. It definitely doesn't look good for Google to have this stuff in the Android code repository, but it also doesn't represent the direct copying of Sun code into the shipping Android platform.
Mueller's new findings offer several new files that weren't known before, but it's still basically the same stuff that Oracle presented in its previous filing that everyone dissected back in October. You can see Groklaw's untangling of the issue from last year.
The additional decompiler-generated files are an interesting find that compounds Oracle's existing evidence regarding the PolicyNodeImpl file, but the status of this evidence is still somewhat ambiguous. The 37 "proprietary/confidential" files in the SONiVOX component are marginally relevant—the zip archive is hosted in the Android code repository, but its contents are not part of the Android codebase itself. These finds demonstrate a need for more rigorous code auditing to avoid such cases of incidental infringement, but don't support the contention that Android itself, in the form that is shipped on devices, is cribbing from J2ME. The copyright allegations on their own simply aren't as strong as Oracle's patent claims. |
