The more I hear about this case, the more I realize it's just a bunch of lawyers trying to pad their bank accounts. No sane engineer would claim this is infringement.
The relevance of rangeCheck isn't that it's some crucial functionality that Google couldn't have written themselves. The relevance of rangeCheck--and Google's admission that it literally copied the code instead of developing it "organically"--is proving that Google was looking at JDK code while developing the Android JVM.
Oracle would never sue on rangeCheck by itself because the damages would be trivial. They're hammering on the literal copying of rangeCheck because of what it says about Google's state of mind.
[1] The fundamental legal question is actually pretty interesting and has implications beyond this case. Remember Microsoft's policy of "embrace, extend, extinguish" in the 1990s? If SSO is protectable, then "embrace, extend, extinguish" tactics may cross the line from simply distasteful to actionable unfair competition.
This ecosystem doesn't belong to Oracle. It comprises of thousands of companies and individuals, who actually welcome that their existing investment into Java code can be reused on additional platform.
If Oracle's argument is accepted, it becomes a gatekeeper to the platform who decides, where and for what purpose you can run your own code or not. It greatly increases the risk of using the Java platform.
This case increases the risk of using platforms, libraries, and services in general.
Google used Apache Harmony implementation of Java.
Why Oracle never sued Apache Foundation?
What makes this case different? That APIs aren't protectable has been bandied about as gospel truth in the nerdosphere for decades. Was that assumption just wrong all along or is there something about this case that seems to make it subject to re-litigation?
Very good question though.
I appreciate that this feels like an arbitrary distinction from the programmer's point of view. The way to think about it, I think, is this: what creativity is required to design the API? Designing a class with particular methods and appropriate names requires at least minimal creativity. Putting the disk I/O routines at INT 13h instead of INT 12h doesn't; it's arbitrary.
To be creative,
Sunshine.Unicorn13(spaceshipIsFunnyPants);
would be how you'd set permissions on a directory. Do you see why? No, of course not - if it was at all obvious it wouldn't be creative.
This is still very much an open question and right now not true. Core to this case (and a ruling Oracle has won) is the copyright of the Java API itself.
https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court...
I think that's the crux of it or at least, of my confusion because I don't see the fundamental distinction in creativity (or really, fixedness of media although that seems like an easily avoided technicality). A BIOS API is still an API in purpose and intent. It has structure, design choices (parameters and returns, what calls to and not to provide), a specification, etc. Is the legally significant difference really that methods in classes have names and interrupts don't?
A BIOS API has purpose and intent and structure and design choices, but all that is implicit in the code. You can write up a specification describing those conventions, and that is copyrightable. But you can clone the BIOS without copying a single word from the specification.
Of course, the only reason code is copyright-protected is because it's text, and text can have expressivity and code can be creative. But that does not mean code has creative expression. Most code does not express anything, not in the way other artworks do -- most code exists only to solve specific problems and hence is functional. Sure we can use whatever names we want for the methods and variables but you'll notice they all tend to be very descriptive of what they do. Not much creativity in the text of the code itself (at least for "good" code). All the creativity in software is in the technical ideas, approaches, algorithms and abstractions we use to solve those problems, but unfortunately only patents protect that, if at all.
The real problem here is the use of copyright to protect code. It's a legal hack, enacted because there was nothing better around to use. And to make the hack uglier, binaries enjoy copyright protection because they are "derivative works" from copyright-eligible program code. We need something more appropriate, lying between patents and copyright to protect software.
Also, creativity is irrelevant here - it's a collection of fact. 'Hermione' may have taken creativity to come up with but it's a fact that Harry Potter stars a character of that name. As long as the names are the signatures, the names can't be protected.
As for arbitrary, whatever. That's your line in the sand. But it's wrong. As in, outcomes based on that reasoning are less functional. If it ends up being upheld it's yet another case of our legal system weakening us, not strengthening us.
Is it related to whatever dynamic requires companies to "clean room reimplement" something?
Which is part of the whole rationale of unfair competition law. It hits a moral button when someone takes advantage of someone else's work to make themselves a bunch of money. The more intentional and purposeful that copying is, the more wrong it seems.
I license you a black box with 3 switches on it and 3 lights. The license dictates you may not look inside. The clean room implementation is, I right down what the effect of each switch has upon the lights. I then give that specification to an engineer who's never seen the box. They build a copy of the box, based on the spec.
Let's step back a bit. There's a software product in use today that embraced an open standard, extended it and in doing so "extinguished" other implementations in a way that has much greater implications for software development (especially in the present tense) than anything Microsoft ever did.
What product am I thinking of? The GNU C Compiler, of course! And the GNU tools in general (which have thoroughly "EEE'd"[0] competing POSIXes), while we're at it.[1]
If "SSO" or "EEE" are "actionable unfair competition," then whoever is the current owner of the Bell Labs IP has every right, and every monetary incentive, to get the whole GNU/Linux ecosystem shut down.
[0] "EEE" isn't bad! You could just as easily call it "beating the competition by making a product with better features."
[1] Assuming you agree with me that compiler lock-in and operating system lock-in have greater implications for software development than for example web browser lock-in.
It's not a phrase for winning by doing a better job.
Over the past 20 years GCC and GNU/Linux have gone from negligible to overwhelming market share in the fields of C compilers and POSIX-on-the-server, thanks in large part to the massive software ecosystem that has developed which can only be compiled using GCC and its non-standard language extensions, and/or can only run on GNU/Linux and its non-standard extensions to POSIX.
Once enormously-popular competing implementations, Borland C, Solaris, etc, have been "extinguished." Surviving and new implementations treat GCC and GNU/Linux as the reference standards more than anything the ISO puts out.
Again, I'm not saying that's a bad thing; just the opposite. Inferior products (which can and do include the published standards themselves) were beaten out by superior ones.
Um, sure, but EEE is important because it was a strategy and one that was executed repeatedly by Microsoft. On the other hand, just because some products have been "extinguished" (debatable) does not mean that was the strategy employed by GNU, nor does applying EEE here seem to serve any predictive function.
David Boies (counsel for Oracle): "I want to come back to rangeCheck."
Alsup: "rangeCheck! All it does is make sure the numbers you're inputting are within a range, and gives them some sort of exceptional treatment. That witness, when he said a high school student could do it—"
Boies: "I'm not an expert on Java—this is my second case on Java, but I'm not an expert, and I probably couldn't program that in six months."
Any other way to write that method, short of changing the exception text and variable names would be silly. The truly astonishing thing is that enough people could be fooled to think otherwise.
Of course that still leaves two other arrangements of the remaining code.
Adorably, the Judge's full name is William Haskell Alsup.
> [Oracle]: even Java programmers don't learn about Java bytecode.
Uh, what? I'd hardly call myself a dedicated Java programmer and I've learned about Java bytecode. I had to, and wanted to. I'd guess most professional Java programmers would consider it a point of pride to do the same!
While it might not be required to dig deep into the bytecode, the fact that Java comes completely with a suite of tools for dealing with bytecode suggests Sun did expect developers to understand and work with the JVM bytecode at some level.
(And in fact they did not get a meaningful win on rangeCheck, and the case is back before Judge Alsup with his view of structure-sequence-and-organization overturned.)
While I also disagree with the lawsuit, if you are coming at it from the mindset that code you have a copyright to was used elsewhere, Oracle has a compelling case. Certainly not a $9 billion case, and not one that takes up 6 years of time to decide, but that's not for me to decide.
Indeed, quite a lot, but I dont think that was the point.
Dirt simple 9 line functions don't "organically grow" over time, they're just pounded out and the programmer moves on.
Bonus points for conceptual issues that demonstrate a natural convergence to the same solution as understanding of the domain increases.
"Original, as the term is used in copyright, means only that the work was independently created by the author (as opposed to copied from other works), and that it possesses at least some minimal degree of creativity. ... To be sure, the requisite level of creativity is extremely low; even a slight amount will suffice. The vast majority of works make the grade quite easily, as they possess some creative spark, 'no matter how crude, humble or obvious' it might be. ... Originality does not signify novelty; a work may be original even though it closely resembles other works, so long as the similarity is fortuitous, not the result of copying."
> Microsoft focuses on Oracle's argument that copyright supports "non-literal" elements of software. In other words, Google can be found a copyist—even if there's no actual copying of code. The "structure, sequence, and organization" (or SSO) of software "can, in some instances, be protected by the copyright in the work." Copyright violations can be found in a software case "even when the defendant did not copy the underlying developers' code," Microsoft insists, because the defendant has copied "some other, non-literal element of the software."
http://arstechnica.com/tech-policy/2013/02/microsoft-foresee...
So it's not just literal "copying" (accidental or not) that must be punished/paid for, but companies or developers should be forced to pay for making "similar" APIs as well.
I don't think SSO should qualify for this sort of protection, for a number of reasons (it has significant functional constraints on how its expressed, it's a tiny fraction of an overall creative work of software, etc.). But it's not obviously nuts to claim it should either.