from the this-whole-case-is-fucked-up dept
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:
Here's my artist's rendition of the Bornstein sketch. Not perfect, but his handwriting and drawing aren't better. pic.twitter.com/aNu8ZAyXMP— Parker Higgins ☔ (@xor) May 13, 2016
Nothing about the declaring code at issue here materially distinguishes it from other computer codeAs 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.