The latest round of the Oracle/Google API copyright lawsuit has been an attention grabber to say the least. There's plenty of absurdity to go around, but in reading through the coverage and commentary, it became clear that part of the problem is actually in the nature of Java
as a statically typed, verbose language. To me
, the crux of the case has been in the fact that non-technical people don't seem to get that software and APIs are different things
. They don't get that an API is more like a map or a menu, rather than the actual stuff itself. The API is basically just explaining how
to get information, not what the information itself actually is.
But this distinction is lost on people who aren't very technical. Sarah Jeong, whose coverage of this case on both Twitter and Motherboard has been phenomenal
, wrote a great piece last week calling out this distinction
The problem with Oracle v. Google is that everyone actually affected by the case knows what an API is, but the whole affair is being decided by people who don’t, from the normals in the jury box to the normals at the Supreme Court—which declined to hear the case in 2015, on the advice of the normals at the Solicitor General’s office, who perhaps did not grasp exactly how software works.
In fact, during the jury selection process, it appears that an effort was made to make sure no one even remotely technical
got onto the jury. So much for a jury of your peers, right?
But, a further point drove home for me just how messed up this whole thing is -- along with the recognition that part of the problem is in just how verbose Java is
. Last week, one of the witnesses in the case was a top Android programmer, Dan Bornstein, who was actually asked to write some code
on a white board, to show what "declaring code" is, as compared to the actual implementation code. While no photos are allowed in the courtroom, EFF's Parker Higgins (who also has been known to guest post
here on occasion), did his best to recreate what Bornstein drew:
In response to this, on Twitter, programmer Aviv Ovadya, showed what the same thing would look like in Python, rather than Java:
And the even clearer, side-by-side version:
Python is a dynamically typed language, rather than statically typed, meaning that the declaring code is much more concise, and much more obviously a specification of what's needed, rather than code designed to do something directly. In the Java version, if you don't have a fair bit of experience with programming, the difference between the declaring code and the implementation is not that clear. It looks pretty similar. That's why it's probably no surprise that in asking the Supreme Court to reject hearing this case, the Solicitor General of the US wrote:
Nothing about the declaring code at issue here materially distinguishes it from other computer code
As we pointed out at the time, this is just wrong
. The declaring code explains the interface for communicating with computer code. The implementation is actual computer code. They're not the same. But in Java... they look pretty similar because Java is so verbose
, and requires much more detailed declaring code. In the Python version, the differences are much, much clearer
, and you can see how the declaring code is basically just a specification
for something you want, rather than a bit of creative coding to do something new
And thus, what we're left with is the fact that, in part because of how Java works, the declaring code looks too much like regular code and that confuses the hell out of basically anyone who's not a programmer. Remember how, in the first version of this trial, Judge William Alsup first had to teach himself Java
to understand why an API should not be covered by copyright? Unfortunately, the appeals court justices (and Supreme Court Justices) did no such thing, and couldn't understand the inherent difference here, sending the case back to Judge Alsup's courtroom.
And, now, even with it being "fact" that APIs are covered by copyright
in certain cases in the 9th Circuit (hopefully other courts have a chance to fix this at some point soon...), we're still facing the same kind of argument.
Technically, this round for the trial is supposed to focus solely on whether or not Google's use of the Java APIs is "fair use" under copyright law. But that has made for some weird discussions in the trial, because you don't need fair use if there's no copyright in the first place. And since many people involved were operating under the (reasonable!) assumption that there was no copyright in the API, it's made for some weird discussions in the trial, where everyone has to dance around the copyrightability question. In fact, there's been some discussion between the judge and the two companies over whether or not the jury should even be informed about the results of the first case and the subsequent appeals process.
In the end, it's creating a very messy case, and a big part of that mess is because code is confusing to non-techie folks, and Java's inherent design
appears to make it even more confusing -- which does not bode well for copyright and APIs going forward. And that could create a really big mess in the software world. Lots of people who dislike Java have claimed for a long time that it is inherently awful, in part because of how verbose it is. But perhaps they didn't realize that factor might wreck some important concepts in software development far beyond just Java programming itself.