Summary: The ongoing legal battle between Google and Oracle is complicated. My ZDNet colleague Steven J. Vaughan-Nichols is eager to step up to Google’s defense, but his “history” is incomplete and inaccurate. Don’t take my word for it. Here’s what Google’s own lawyers have to say.
My ZDNet colleague Steven J. Vaughan-Nichols is eager to step up to Google’s defense in the company’s legal battle with Oracle.
To that end, he has written “A Google Android and Java history lesson” that attempts to debunk some of the issues I raised in my post last night about the latest documents filed in that case. (See Latest filings in Oracle patent case spell trouble for Google.)
Here’s the thing about history, though. In order to write it, you have to start with facts. And I hate to say it, but Steven just plain has his facts wrong.
Don’t take my word for it, either. I’ll let Google’s own defense attorneys dismantle Steven’s flawed history.
Here’s what Steven writes:
Oh dear. If this is true, then how on earth did this lawsuit ever get past the first day?
Perhaps because virtually none of that history actually matches up with the facts. The following quotations are taken, verbatim, from Google Inc.’s Answer to Oracle’s Amended Complaint. (I’ve bold-faced the interesting parts.) If you want to follow along, please turn to pages 16 and 17. And remember, this is what Google’s lawyers said. This isn’t an accusation by Oracle or a loose summary by some blogger:
So, yes, Sun released some, but not all of the source code. That’s not quite as clear-cut as the history Steven is using. Google’s lawyers even criticize Sun and its successor Oracle America for not being open enough:
If this were a simple matter of some code being open and some not, this wouldn’t be a multi-billion-dollar lawsuit. But the precise details of how Sun chose to write its licensing terms are extremely important. Let’s continue:
So, no, that part about anyone being able to “look, use, and, yes, copy Java’s code too”? Not true. In fact, there’s the crux of the copyright case. If it were really permissible to simply copy the Sun/Oracle code, Google’s lawyers would be able to raise a big middle finger as their primary defense. Instead, this is what they argue on page 12 of their Answer:
They had to say that, of course. The definition of a “clean room” implementation is that the engineers writing the code have no direct exposure to the original, copyrighted material, incuding code, specifications, and other documentation. Here’s the Wikipedia definition, which is consistent with the claims in this case:
That’s a problem for Google, as I noted in yesterday’s post, because there is substantial evidence that the engineers working on the project had direct access to the copyrighted material. A number of Google employees and contractors who worked on Android previously had access to Sun’s Java code. One, Joshua Bloch, “was an architect of the Java platform at Sun [and] now works for Google … his name appears in the source code of several Java library files.” The copyrighted documentation was available to the so-called “clean room” engineers. That spells trouble for Google.
And even if Google followed those procedures, they were not guaranteed to succeed. Once again, I quote from Google’s own defense team:
Those were impossible restrictions for Google. As Professor John C. Mitchell noted in his expert report, filed under oath and made public earlier this week:
My ZDNet colleague Steven J. Vaughan-Nichols is eager to step up to Google’s defense in the company’s legal battle with Oracle.
To that end, he has written “A Google Android and Java history lesson” that attempts to debunk some of the issues I raised in my post last night about the latest documents filed in that case. (See Latest filings in Oracle patent case spell trouble for Google.)
Here’s the thing about history, though. In order to write it, you have to start with facts. And I hate to say it, but Steven just plain has his facts wrong.
Don’t take my word for it, either. I’ll let Google’s own defense attorneys dismantle Steven’s flawed history.
Here’s what Steven writes:
Recently, some people were shocked-shocked I tell you-to discover that Google had looked at Java to help create Android’s Dalvik …
First, there’s the accusation that Android used Java code in creating its Dalvik virtual machine (VM). This is news? When Android first came out, Sun CEO Jonathan Schwartz, then Java’s owner, greeted the news of Android’s birth with “heartfelt congratulations.”
Oh, by the way, anyone could look, use, and, yes, copy Java’s code too. You see, Sun had open-sourced Java under the GPLv2 in November 2006. Sun wanted Google and anyone else to use and copy its code. That’s kind of the whole point of open-sourcing a program don’t you know.
Oh dear. If this is true, then how on earth did this lawsuit ever get past the first day?
Perhaps because virtually none of that history actually matches up with the facts. The following quotations are taken, verbatim, from Google Inc.’s Answer to Oracle’s Amended Complaint. (I’ve bold-faced the interesting parts.) If you want to follow along, please turn to pages 16 and 17. And remember, this is what Google’s lawyers said. This isn’t an accusation by Oracle or a loose summary by some blogger:
[I]n response to the urging of open-source advocates and in the hopes of increasing the number of Java users, Sun officially announced that Java would become open-source. In 2006 and 2007, Sun released some but not all of the source code for Java SE (as well as the other editions of the Java Platform) under the terms of the GNU Public License, version 2 (“GPLv2”) open source license. This open-source aspect of Java contributed to its widespread acceptance among software developers.
So, yes, Sun released some, but not all of the source code. That’s not quite as clear-cut as the history Steven is using. Google’s lawyers even criticize Sun and its successor Oracle America for not being open enough:
Only two months later, in April of 2009, Oracle Corp. announced that it would be acquiring Sun (renamed Oracle America after the acquisition was completed in January of 2010). Since that time, and directly contrary to Oracle Corp.’s public actions and statements, as well as its own proposals as an executive member of the JCP, Oracle Corp. and Sun (now Oracle America) have ignored the open source community’s requests to fully open-source the Java platform.
If this were a simple matter of some code being open and some not, this wouldn’t be a multi-billion-dollar lawsuit. But the precise details of how Sun chose to write its licensing terms are extremely important. Let’s continue:
Sun also released the specifications for Sun’s Java platform, including Sun’s Java virtual machine, under a free-of-charge license… [links here and here] The license allows developers to create “clean room” implementations of Sun’s Java specifications. If those implementations demonstrate compatibility with the Java specification, then Sun would provide a license for any of its intellectual property needed to practice the specification, including patent rights and copyrights.
So, no, that part about anyone being able to “look, use, and, yes, copy Java’s code too”? Not true. In fact, there’s the crux of the copyright case. If it were really permissible to simply copy the Sun/Oracle code, Google’s lawyers would be able to raise a big middle finger as their primary defense. Instead, this is what they argue on page 12 of their Answer:
The Android Platform, including the Android operating system, the Android Software Development Kit and the Dalvik Virtual Machine, was created independently and without reference to any works protected by the Asserted Copyrights.
They had to say that, of course. The definition of a “clean room” implementation is that the engineers writing the code have no direct exposure to the original, copyrighted material, incuding code, specifications, and other documentation. Here’s the Wikipedia definition, which is consistent with the claims in this case:
Clean room design is useful as a defense against copyright and trade secret infringement because it relies on independent invention. However, because independent invention is not a defense against patents, clean room designs typically cannot be used to circumvent patent restrictions.
The term implies that the design team works in an environment that is ‘clean’, or demonstrably uncontaminated by any knowledge of the proprietary techniques used by the competitor.
That’s a problem for Google, as I noted in yesterday’s post, because there is substantial evidence that the engineers working on the project had direct access to the copyrighted material. A number of Google employees and contractors who worked on Android previously had access to Sun’s Java code. One, Joshua Bloch, “was an architect of the Java platform at Sun [and] now works for Google … his name appears in the source code of several Java library files.” The copyrighted documentation was available to the so-called “clean room” engineers. That spells trouble for Google.
And even if Google followed those procedures, they were not guaranteed to succeed. Once again, I quote from Google’s own defense team:
The only way to demonstrate compatibility with the Java specification is by meeting all of the requirements of Sun’s Technology Compatibility Kit (“TCK”) for a particular edition of Sun’s Java. Importantly, however, TCKs were only available from Sun, initially were not available as open source, were provided solely at Sun’s discretion, and included several restrictions, such as additional licensing terms and fees. In essence, although developers were free to develop a competing Java virtual machine, they could not openly obtain an important component needed to freely benefit from Sun’s purported open-sourcing of Java.
Those were impossible restrictions for Google. As Professor John C. Mitchell noted in his expert report, filed under oath and made public earlier this week:
Developers creating compatible, independent implementations can obtain a license from Oracle on these or similar terms. Google could have entered into a license such as this, but chose not to. Google’s Android is not a complete implementation, without subsetting or supersetting. In addition, I understand that Android has not passed the relevant Java compatibility test suites that would check for and ensure total compatibility and Google has not attempted to complete this process. As Android founder and chief Andy Rubin wrote, “They [Sun] will never certify our VM, or put another way, I will not submit Dalvik for certification.” (GOOGLE-01-00026813.) Of course, there is no sense in submitting Android for certification — because it is intentionally incompatible, it would fail.
This is dummy text. It is not meant to be read. Accordingly, it is difficult to figure out when to end it. But then, this is dummy text. It is not meant to be read. Period.
ConversionConversion EmoticonEmoticon