Supreme Court denies review of Google v. Oracle API copyright case [pdf]
supremecourt.gov
supremecourt.gov
I don't want to claim that the law is a trivial matter and that it could be replaced with software, but I do think our legal system could be greatly enhanced with some ideas in math and software development. There are always going to be ambiguity in legal matters, but that doesn't mean we can't greatly reduce that ambiguity with good tools.
I know this is a really tall order, but one idea in particular I'd like to see is the introduction of some sort of unit testing or model checking during the legislative process where legal scenarios are parameterized and enumerated to act as a guide for legislators, lawyers and judges. I'd love to see something like Alloy (http://alloy.mit.edu/alloy/) be implemented in a way that non-programmers could use to model check things like bylaws by guiding the user through ambiguous and conflicting scenarios. I'm not suggesting we try to make laws satisfiable. What I am suggesting is that we model them in a way that highlight and distinguish the laws that are poorly crafted from those which are clearly interpreted.
Legal ambiguity is really expensive weight on our society. Not only does this sort of ruling create investment uncertainty, it benefits incumbents who can buy armies of lawyers and intimidate competitors with drawn out lawsuits. Our legal system should be the great equalizer, but it will never be as long as we let judges and lawyers convince us to resign that our current system "is as good as it gets".
The issue here is two fairly unambiguous provisions of 17 USC 102: https://www.law.cornell.edu/uscode/text/17/102
Subsection (a) says that copyright extends to "original works of authorship." Subsection (b) says that copyright does not extend to "any idea, procedure, process, system, method of operation, concept, principle, or discovery."
Where does an "original work of authorship" end and where does "method of operation" begin? How would you propose to define those concepts in a way that is less ambiguous? That is, without arbitrarily throwing away the distinction the law is trying to make just because you can't model it?
This particular case could have been anticipated at least as far back as the 1970s.
On the other hand, maybe a less charitable analogy would be prototyping in a dynamic language. Thinking through edge cases only when running on some input causes an exception to be thrown.
Relying extensively on the courts to lazily evaluate ambiguous laws biases outcomes toward those who have capital. Since I do not belong to the capital class, I would prefer less ambiguous laws.
I think being able to test cases pre-emptively has a tremendous value because it forces one to pre-emptively consider and define things. By opening up such a system, it might allow software associations to work with legislators to pre-emptively clarify test cases and definitions by creating a process where legislators can define things more specifically so it could be used as a guide for judges ruling in esoteric areas.
I don't imagine we'd ever be able to create a satisfiable legal system, but I do think we could concoct a system that highlights ambiguity and legal risk so that it prompts individuals and associations to get legislators to clarify messy laws.
Like I said, this is a tall order, but I think we should be thinking about systems like this.
Software has layers of conflicting code too, but you wouldn't say software engineering doesn't have the concept.
But the people who write software professionally must be held to a higher standard, just as we expect so much more from professional writers (but we expect everybody to be able to read street signs and write shopping lists.)
I don't wish to be provocative but anyone who can't understand factoring shouldn't be writing software. DRY is an oxymoron.
Putting flippancy to one side, the issues here will not be solved by any form of notation. The difficulty lies with concepts enshrined in law that will forever be soft and in need of reinterpretation as the context changes.
It would be nice if lawmakers used some tools from code - eg. some kind of version control for laws which are being batted between different houses and have amendments added and removed. And perhaps the language could be a little more formalized.
Take a look at this "diff" from a real law that the UK govt is trying to pass now: http://www.publications.parliament.uk/pa/bills/lbill/2015-20...
I just wanted to point out that we should be wary of any false dreams of precision.
"One technical problem with Computational Law, familiar to many individual with legal training, is due to the open texture of laws. Consider a municipal regulation stating "No vehicles in the park". On first blush this is fine, but it is really quite problematic. Just what constitutes a vehicle? Is a bicycle a vehicle? What about a skateboard? How about roller skates? What about a baby stroller? A horse? A repair vehicle? For that matter, what is the park? At what altitude does it end? If a helicopter hovers at 10 feet, is that a violation? What if it flies over at 100 feet?
The resolution of this problem is to limit the application of Computational Law to those cases where such issues can be externalized or marginalized. We allow human users to make judgments about such open texture concepts in entering data or we avoid regulatory applications where such concepts abound.
A different sort of challenge to Computational Law stems from the fact that not all legal reasoning is deductive. Edwina Rissland [Rissland et al.] notes that, "Law is not a matter of simply applying rules to facts via modus ponens"; and, when regarding the broad application of AI techniques to law, this is certainly true. The rules that apply to a real-world situation, as well as even the facts themselves, may be open to interpretation, and many legal decisions are made through case-based reasoning, bypassing explicit reasoning about laws and statutes. The general problem of open texture when interpreting rules, along with the parallel problem of running out of rules to apply when resolving terms, presents significant obstacles to implementable automated rule-based reasoning."
However, while it's an interesting idea, how about we deal with the ambiguities of things like programming languages (this program runs differently in these two different environments) and computer programs in general ("things stopped working after the update" - that wouldn't happen if programs depended on a formally defined and verified set of things from their environment)? And maybe tackle more complex things like precisely defining the line between flirting and sexual harassment later?
An article currently trending on the front page about "C in practice" (https://news.ycombinator.com/item?id=9799069) helps make my point (that we barely understand the dark corners of our tools, so perhaps venturing into other territory is a bit premature.)
(Also - the extent to which almost every real-life programming language makes simple things unbelievably complicated sounds like a good example of "impenetrable silos of epistemology"... "language lawyer" is an idiom for a reason. And BTW we have waaaaay less excuses for the huge barriers to understanding that we continuously erect around our work since our subject matter is not nearly as inherently fuzzy as the stuff lawyers, lawmakers and judges deal with.)
There are as many elements in the set of laws that are clearly interpreted as there are programs with zero bugs. This is not an analogy. These are direct expressions of the same root cause.
There is no algorithm for "distinguish[ing] the laws that are poorly crafted from those which are clearly interpreted." Law is an imperfect tool for managing human wickedness. No symbolic perfection can force a person to be good. The essence of the problem is that people just like to be cussed bastards. Math won't help.
The German language is much less fuzzy than English.
Yes, I'm attributing a big chunk of the law imperfection to the language it is written in.
At that point, if SCOTUS does not take up an appeal, the computer science world will have a big problem. If APIs are copyrighted and reimplementing libraries violates copyright, then:
What of all the projects that have implemented LIBC, and used glibc's API and headers? e.g.: Is musl now GPL?
What of any OS or project that has implemented a POSIX layer? (Is this the decision SCO needed to finally sue someone for Linux finally violating SCO's copyright?)
What of any project that implements x-plat APIs? As another comment pointed out, Microsoft's Project Islandwood re-implements iOS APIs. But Xamarin, Cordova and other projects all ingest APIs and reconfigure them to make them accessible on multiple platforms. Are they contaminated by copyright now?
If the Federal Circuit decision stands, software might have finally encountered the lump it can't digest as it eats the world.
Now, using a language which is owned by one company, Google's lawyers really dropped the ball in terms of risk.
I would say it's Google's executives and engineers who have dropped the ball if the moment Oracle won the case the last time, they didn't start planning and working on stripping Java out of Android. If they still have a "let's wait and see" attitude about it for another 2-3 years or how long these Court battles will take to settle, then THAT would be a major fail on their part. Because by then they would have to pay who knows how many billions of dollars and it would take yet a few more years (5+?) to do the whole transition.
It is prudent to note that Google didn't write its own implementation from scratch: they took advantage of Apache Harmony (by erstwhile Sun frenemy: IBM). This is the same Apache Harmony that Sun repeatedly refused to provide the TCK for
When the Federal Circuit court overturned District Court's decision on the copyrightability of SSO, they remanded the issue of fair use back to the lower courts. After all, both Google and Oracle's goal through all this is not an academic exercise in establishing the general boundaries of copyright; their question is, "Are we/they going to have to pay in this case?".
Which is funny, because Microsoft played a big role in helping Oracle win this one:
http://arstechnica.com/tech-policy/2013/02/microsoft-foresee...
Sure, as far as languages go, I there are many tasks more beneficial to the platform than changing its language, but the legal issues they are encountering sound like another good motivation.
invokedynamic is a bytecode. Not supporting it means Dalvik / ART can't accept valid bytecode.
> I think the lack of nio is an annoyance that can be fixed tho.
Apparently not. A quick check also suggests that ClassLoader#registerAsParallelCapable is missing.
† In the United States.
The apparent legal position following this result seems crazy to me. Even in the world of intellectual property law, there has been some recognition that the interests of interoperability and ability to communicate may outweigh the benefits of monopoly protection as an incentive to create and share. The US, for example, takes this view in declining copyright protection on the design of typefaces (as distinct from font files that contain software describing those designs in one specific way). And in Europe, good luck getting a software patent that blocks anyone from using your file format or communications protocol.
Given that programming to an interface is essentially the way we enable interoperability between different software products, allowing the protection of such interfaces to stand seems absurdly counter-productive. This is particularly true if the protection holds retrospectively for APIs that were previously believed not to be protected in that way by those who chose to write code against them, which would presumably be the case here.
If the US allows this position to remain, it could cripple the US software development industry very quickly if the lawyers start throwing their weight around. In practice, as often happens under the US legal system, I expect it would be particularly damaging to the little guy, while the big players would all cross-license their respective portfolios somehow to make the issue go away.
In my opinion implementing someone else's API should be allowed under the fair use provision of the copyright law. This is needed so that whoever came up with the API does not hoard applications developed for the API and stifle innovation and competition at the platform level, as Microsoft did for many years with the Win32 API.
So the previous point still stands, with one minor modification. The giants will come to terms and the small-fry will be screwed.
It was much copied, e.g. I'm think the Lisp Machine had the same basic GUI working by the time work on the Apple Lisa started, it was certainly reliable and somewhat polished as of the fall of 1979/1980.
If you're a student of this sort of history, it's a bit sobering how little "new" stuff we're really doing, it was all conceptualized and generally at least prototyped by the end of the '60s.
It's going to turn around and sting Oracle just as quickly as they think they profit from it.
No, wait, that won't work. To make composition work, you still need to be able to share interfaces.
In the late 1970s, Relational Software, Inc. (now Oracle Corporation) saw the potential of the concepts described by Codd, Chamberlin, and Boyce, and developed their own SQL-based RDBMS with aspirations of selling it to the U.S. Navy, Central Intelligence Agency, and other U.S. government agencies. In June 1979, Relational Software, Inc. introduced the first commercially available implementation of SQL, Oracle V2 (Version2) for VAX computers.
Does IBM have a case to go after Oracle for using the SQL API SSO in their database products?
http://www.opensecrets.org/pfds/assets.php?year=2013&cid=N99...
It's common for politicians to keep assets in a blind trust only while they are in office.
private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");
if (fromIndex < 0)
throw new ArrayIndexOutOfBoundsException(fromIndex);
if (toIndex > arrayLen)
throw new ArrayIndexOutOfBoundsException(toIndex);
}
The function is obviously trivial, is something which could be pretty easily recalled exactly from memory, and could be easily recreated by accident; given the constraints on what it's supposed to do, there aren't many degrees of freedom. At the district court level, Judge Alsup ruled that copying of this function was "de minimis". At the Federal Circuit level, Justices O'Malley, Plager and Taranto overturned this part of the district court ruling (https://www.docketalarm.com/cases/US_Court_of_Appeals_Federa...).On the issue of "structure, sequence, and organization", Google copied the class and method names from Java, so that their reimplementation of Java, Dalvik, would be interoperable with existing Java programs and Java programmers' habits. Judge Alsup ruled that is a "command structure, a system or method of operation" and not copyrightable 17 USC 102(b) (https://www.law.cornell.edu/uscode/text/17/102) (http://www.groklaw.net/pdf3/OraGoogle-1202.pdf). This, too, was overturned by the district court.
There is a fairly key difference here between Judge Alsup and the District judges. Part-way through the trial, Alsup revealed that he has actually programmed; that he understood what was going on, and would not be easily fooled. At the time, this being revealed was a dramatic event.
The District judges, however, hold no such distinction. It is no surprise, then, that it was them, and not Alsup, who made a ruling that to actual programmers is prima facie unreasonable and dangerous. They are outsiders. If you read their opinion (https://www.docketalarm.com/cases/US_Court_of_Appeals_Federa...) you can see little errors in terminology creep in to reveal their lack of background and understanding. And, lacking that understanding, I don't see how they can be seen as having moral authority. They only have legal authority, and the ability to do damage with it.
(EDIT: This was incorrect; the original case was Oracle v Google but the appeal is the reverse.)
Thus in the familiar "certiorari" ... where the Court is responding to the request of the party seeking review."
Source:
https://books.google.com/books?id=lLHBCQAAQBAJ&pg=PT70&lpg=P...
http://www.supremecourt.gov/Search.aspx?FileName=/docketfile...