In my entire career you could not copyright an API. There is good reason for this. If you wanted to do business with certain entities, the implementation had to be multisource. The new implementation had to come from a cleanroom, but in this case it came from open source (which seems equivalent). Therefore you have one judge making one decision that is an anomaly. It seems to me that a single judge should not be making a landmark decision.

This is the 2012 ruling: http://www.groklaw.net/pdf3/OraGoogle-1202.pdf

Alsup indicates that SSO isn't dead law, but finds that APIs aren't copyrightable because they are 'the only one way to write" things to get the key functionality. Copyright doesn't cover purely functional elements and since the expression and the function are the same, copyright bows out.

Note: I like Alsup, but this argument is based on obviously factually incorrect premises which are blown up on appeal.

Here's the appeal in 2014: http://www.cafc.uscourts.gov/sites/default/files/opinions-or...

They summarize the facts as follows: " And, the court informed the jury that Google conceded that it copied the declaring code used in the 37 packages verbatim. The court also instructed the jury that Google conceded copying the rangeCheck function and the eight decompiled security files, but that Google maintained that its use of those lines of code was de minimis. See Final Charge to the Jury (Phase One), Oracle Am., Inc. v. Google Inc., 3:10-cv3561 (N.D. Cal. Apr. 30, 2012), ECF No. 1018 at 14 (“With respect to the infringement issues concerning the rangeCheck and other similar files, Google agrees that the accused lines of code and comments came from the copyrighted material but contends that the amounts involved were so negligible as to be de minimis and thus should be excused.”). "

Ie: Google copied and admitted it copied. This isn't a cleanroom implementation.

For more details on why they found copyrightability, see the discussion starting on p.17. There's a lot in there, and having a discussion about it (or at least a proper one) requires people to look at the actual text.

Edit: Made the formatting better.

If this holds up, every programming language that was not originally produced under a suitable open source license will need to be dropped because all software written in those languages will be infringing an API copyright.

The case goes into discussing this directly, indicating that Google's cleanroom efforts give it evidence that it proceeded in good faith, but good faith alone does not intrinsically absolve you of admitted copying (which is an infringement) that's found elsewhere.

Now if you did an ACTUAL cleanroom and didn't take chunks that you thought were trivial, the argument to demonstrate infringement in the first place would need to be localized on the SSO level, where single-option design choices would again be exempted through the doctrine of merger, and we'd have a much different set of considerations.

As per the jury award to Oracle, you'll be happy to know they're going back to first instance to have another trial to determine the quantum. Maybe Oracle will get $1 again despite winning due precisely to the mitigating factors you've raised. Who knows. This case wasn't about that. It was about fair use.

There are two things in play here and they are NOT the same. The one the whole world cares about is weather APIs are copyrightable. Weather Google is guilty of copying part of Oracles implementation of the code behind the API is not relevant to API copyrightability. If you can't see the distinction you don't understand software or the real core of the case and should stop trolling. If you do see the distinction, why do you keep insisting on conflating the two?

Whether or not the supreme court agrees with the IPRs affirmed in this series of cases is another question entirely, but until that comes down, nothing has really changed.

Happy reading.

It's hard to overstate how difficult it is to separate what you want the law to be from what it is. This is why people do so badly at representing themselves, and even lawyers have this problem.

Oh well. I hope some people found it useful.

I read page 17 and it is clearly written by someone that doesn't understand software. My non-lawyer reading of the justification implies that polymorphism violates copyright law - which is an even deeper issue. This would destroy all modern software development. Yikes! I am now even more confused. Even Oracle would disagree with this point of view.

In your text, you are now making the argument that Google did not have a cleanroom implementation. This is a different discussion that should be on it's own thread.

Regarding your polymorphism point, you've got the cause and effect swapped. The LACK of polymorphism was the basis for Alsup saying APIs are uncopyrightable. Because there's only one way to do something, the words and the function are linked, and copyright does not protect function, ergo copyright wouldn't protect the word either. This line of reasoning doesn't flow in reverse - Polymorphism doesn't indicate that a work is copyrighted or subject to restrictions upon use, or that various safe harbour provisions/copyright exceptions do not apply.

2) There's no need for a separate discussion. I'm not making the argument; it's literally admitted by Google in the context of this case that they straight up copied chunks of code.

> We further find that the district court erred in focusing its merger analysis on the options available to Google at the time of copying. It is well-established that copyrightability and the scope of protectable activity are to be evaluated at the time of creation, not at the time of infringement.

The error is subtle, but crucial: when Sun/Oracle released their API, they gave rise to a new functionality: interoperability with whatever they just created. If someone wants to write a drop-in replacement, they have to read the declarations, copy them all, then write a conforming implementation.

Changing the order of those declarations would still be possible, but one would still have to start from the original files anyway. Assuming those were readable to begin with, any transformation would be a purely legal trick, so they can say "I didn't really copied it".

As far as I can tell the court either ignored or dismissed this interoperability issue. Agreeing with Oracle that Google could have renamed its function names, even though those names are part of the API they were conforming to (the `max` function is obviously part of the standard library), is ignorant at best, dishonest at worst.

I am not arguing that Google has an interoperability exemption. I am arguing that the API is not (or should not be) copyrightable in the first place, because any attempt at interoperability would instantly void it.

I would also argue that interoperability with the training of masses of developers is a thing. Saying it is not only strengthens the relevant network effects, which is bad for competition. I doubt that last one would hold up in court, but still. See how C++ became popular. Not quite compatible with C, but close enough to spur adoption.

And overall, it is very weird that Google's intent matters here. They should be judged on what they did, and maybe whether they did it on purpose. Why they did it should be no more than extenuating or aggravating circumstances.

The court specifically deals with this assertion and does not come to the conclusion that you do.

>And overall, it is very weird that Google's intent matters here.

No it isn't. This case was about Fair use, and intention matters for some of the test elements. A bunch of people think this case is about API copywritability. They're four years too late to complain.

I know. I did read their lengthy conclusion.

> A bunch of people think this case is about API copywritability.

Too bad it isn't. That ruling from 4 years ago is insane. And I recall people did complain at the time, did they not?

I just reread the document, and I think you are referring to page 36. I think Oracle is trying to get around the Sega vs Nintendo case which does protect the API. I believe the Oracle argument is tenuous since you still need to import the Math class to use it. If you don't import it, they you have to specify the Math class every time you use the method. Even if Oracle is correct, then it would mean the Math class is not in the API, it is an implementation detail. Then we are back to the discussion if an open source implementation is legitimate replacement for clean room implementation. Then this becomes an open source discussion and not an API discussion.

The whole Oracle discussion of API seems circular and might be a red herring. The real discussion is at the very end where Oracle says that Google only implemented a subset of the API and not the full API.

One function, rangechececk.

Which premises are you referring to? I am not a lawyer, but I am a programmer, and what you just paraphrased sounded obviously true (at least when "the functionality" means "replacing the old system", a.k.a. interoperability).

Which part of "let's find a small group of the least qualified people to decide on billion dollar cases" ever seemed like a good idea to anyone?

Then there's the judge, who has a background in law but NOT in programming.

Then there's the lawyers, who have a background in both (assuming the expensive lawyers G and O can afford), as well as years and years of practice influencing the decisions of small groups of laymen.

I don't understand how this is never brought up with regard to API copyright. API's are software, software has been deemed copyright-able, thus, API's are copyright-able.

Am I going crazy or missing something?

This is, essentially, the fallacy of division.

Interfaces to software have been rules non-copyrightable despite being an element of software and thr software itself being copyrightable; this is particularly the case for user interfaces (Lotus v. Borland is the landmark case here.)

There have been many comments from the legal community, including, IIRC, judges that sit on the 9th Circuit, that the Federal Circuit (which heard this case on appeal because of the patent claims in it) has misapplied binding Ninth Circuit precedent (which is supposed to control on coypright issues in this case because this came up from a district court under the 9th Circuit, and copyright law is not one of the areas where the Federal Circuit has exclusive subject matter jurisdiction.)

And yeah, I guess that IBM could start suing everybody... this whole situation is so ridiculous.

Other forms of structured metadata use cross-party?

Or IBM could realize if they start doing that, it might show the insanity of the current law, and result in the law changing back to what it was and should be, API's not copyrightable.

(And yes, I know: The overwhelming majority of the work was a clean room implementation, but not all. In retrospect, this was an unfortunate mistake by Google.)

What if I named my function 015342342(String 123949)? How does that change anything?

Without endorsement, there is definitely a line between text in which one can be "creative" and numbers in copyright law as written.

The problem here isn't the line between creative and non-creative, the problem here is the introduction of copyright, a concept created for expressive works, into a field that consists of functional works. It should not be a surprise to anyone, not even lawyers, that this isn't going to "just work". The surprise to me is that it has taken this long for this foundational clash to start emerging at a big scale.

The choice of call name in an API are arbitrary, the reuse of those names to interface with that API is not a creative copy it's a technical requirement.

If I make a toothed belt to fit a pair of gears, that's not an artistic expression no matter the the tooth pitch is an exact duplicate of that on the gears. If the gear is purple and orange spots, in a distinctive pattern, and I make my belt the same pattern then that's a copyright issue.

If the API calls were like "thisIsTheSummerOfOurDiscoTents(banana)" - such that the names are sufficient to be individual works of art, and weren't following a technical function, then perhaps you have an argument that the API is a work of literature, or otherwise an artistic creation.

It just sounds like a wrong decision was previously made and should now be overturned.

The real key point is in the second half, though. Arguing over whether or not a particular micro-decision is "creative" is the entirely wrong track to be taking when we're discussing something that is functional, that performs some real task in a way that a movie or song simply does not. Why would we expect standards based on "creativity" to apply to that in any sensible way?

It's impossible for a collection of letters to be creative but for that collection of letters when represented numerically to be no longer creative. If I make up some BS for how there's a correspondence between these symbols and other symbols (1=alpha, 2=bravo, ...; or 1=sandwich, 2=wellington, ...) - then 1383() is just sandwichBiscuitAppleBiscuit(). Then it's clear the creative aspects of the program, API, or whatever, don't lie in the specific choice of tokens.

Would a judge agree that providing a dictionary/key that says an arbitrary name for each number (easy to do programmatically) makes a program creative that otherwise wouldn't be. It's clearly ridiculous. Not least because it would mean that duplicating a work that was compressed, or represented in binary, would then no longer be a tort, because apparently numerical representation would rule out a work from being creative.

Seems pretty straightforward.

So a Google employee was donating code to Oracle, and they sued them for it. It's absolutely shameful behaviour.

They literally admit to having copied it.

All the hypotheticals trying to find the end of cleanroom dev in this case keep missing the point: They didn't do cleanroom dev. They admit to not having done it. Their defenses aren't organized around them doing it. So what's the furor about?

Alsup: "I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There's no way you could say that was speeding them along to the marketplace. You're one of the best lawyers in America, how could you even make that kind of argument?"

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—"

Probably about the absurdity of being hit with potentially astronomical penalties for "copying" 9 lines of trivial code that's barely worth hitting ctrl-c for.

Obviously, common sense is - as always - distant from the pedantic nature of law and laywers, but just about anyone sane is gonna look at this and go "well that's just stupid".

IIRC, the literal copying of code was something for which the parties stipulated to $0 in damages; the potential liability is about copying the API, not the one trivial 9-line function.

Obviously that sounds pretty crazy, but if it's true, it would at least be an approach that I could understand.

Uhhh. No. Just no. I don't think you understand the meaning of "clean room" in this context. In this context, clean room means that the person in the room is untainted by any copyrighted information full stop.

The problem I'm describing is that in this case the kind of thing you'd typically want to write in that documentation is exactly the signatures of methods, which would amount to copying the copyrighted material and would taint the whole clean room. I'm trying to think of a way you could even do clean room engineering if the signatures of methods are copyright information. The reimplement from usage examples is the only thing I can come up with.

These $9 Billion dollars will look great on Oracles bottom line. The mega-billions in possible lost trade and efficiency make me think this ruling gets reversed with a vengeance.

There's nothing legally stopping you from doing the same; Disney does not own these stories.

This is ridiculous. An argument supporting a fair use defense in a copyright proceeding is a very different thing from a patentability argument. Google is not trying to claim patent rights to its Android API.

So don't think of Java being in Android. The Android toolchain uses Java, but the Android runtime is not a Java runtime.

For one thing, this makes it different from Amazon using an Oracle Java runtime. But the total set of differences is deep and significant.

Google had little interest in expanding the reach of the Java platform—they wanted to attract Java developers to their “looks like Java, but isn’t” platform while benefiting from the years of work that went into the JDK.

I don’t necessarily think APIs should be copyrightable, but since they now are as a matter of law, I’m leaning towards Google’s actions constituting infringement.

While this may hit on our sense of fairness, it has no relation to legal "fair use". My political parody show owes no profits to the subjects of my derision, IoW.

The same could have been said of Visual J++ but Sun killed that opportunity before it could really flourish.

-) Are Networking protocols copywritable ?

-) Are REST APIs copywritable ?

I am not sure if this is the way open source world should work.

I don’t necessarily agree with the decision but I can see where they’re coming from.

Edit: And particularly there's tons of case law that this stuff isn't copyrightable, see Sony v. Bleem, where a company literally wrote an emulator of a PS1, and courts said that was fine. Even to straight up sell as a competing product, and for running on competitors machines.

Edit2: And the otherwise shitty DMCA even has explicit exemptions for software interoperability purposes.

There is a bit of a "intellectual property" slippy slope going on here. Whether or not something is useful or non-trivial is inconsequential.

You could design an engine to have an artistic structure. What you couldn't then do is stop anyone copying the functional parts of the engine and leaving out the purely artistic elements.

PS: I am not a lawyer. Above piece of knowledge is coming just from what I read, perhaps on HN during the previous ruling on the case.

At the time, though, I don't believe it was open source and OpenJDK originated as a cleanroom rewrite of it, and has since been integrated.

> The Java API is a collection of “pre-written Java source code programs for common and more advanced computer functions.”

I'm not too familiar with Java, but I believe they are mistaking APIs for libraries there. Did Google infringe on the libraries or the actual API?

Like did Google actually infringe on what Oracle calls the "Java API" (but is actually a library), and are we all talking past each other when discussing "API copyrightability" when Google may have actually been found of infringing a library?

I think the CAFC may be just as confused about which one is which and on which it's ruling.

Additionally, how would this relate to the Java programming language being "free" and why would Google infringe on anything if it was free?

I don't know the actual details of Sun's licensing, though, but even from what Oracle is claiming now, it seems that Oracle's case is quite weak, and I don't see how its license specifically banned Google from doing whatever they think they did.

Finally, the CAFC's pro-patent rulings are almost always overturned by the Supreme Court, and if I believe they wouldn't even have gotten this case if Oracle hadn't also accused Oracle initially of patent infringement. If Oracle had only accused Google of copyright infringement, I think some other court would have gotten the case, maybe a court with less of a bad record in understanding IP law (going by Supreme Court's rulings at least). It's just a shame that Obama's pro-IP laws lawyers got in the way and convinced the Supreme Court to reject the case.

Supposedly, both. They made an API with the same structure, names, etc. They also copied a nine-line function called rangeCheck.

Additionally, how would this relate to the Java programming language being "free" and why would Google infringe on anything if it was free?

"Free" is not a legal license. Google would have to start from the OpenJDK implementation, and be subject to its license, which they didn't.

Was this a mistake or did Oracle actually accuse themselves of infringing their own patents?

IANAL, but doesn't this contradict case law elsewhere?

Bzzt. You really need to make a citation for that statement. Without it there is no point in considering your other 3. The case law around that issue is exactly Oracle vs Google.

That Federal Circuit decision has not been reviewed by the Supreme Court, does not establish binding precedent outside the context of this case, and is widely seen by outsiders as being in error for not matching what the Ninth Circuit would have ruled.

It is incorrect to make any categorical statement that APIs are copyrightable. That question is still pending. All that's been settled is that this one case is being conducted under the assumption that APIs are copyrightable, until such time as the Supreme Court decides to review this issue.

The Supreme Court need not weigh in in order to make the law what it is.

The 2018 decision is not the same as the 2014 decision or the 2012 decision.

1) AMD chips aren't free and the usage is totally for a commercial purpose.

2) ISAs are an API.

3) While the implementation is probably clean-room, it's still a total copy of the ISA structure and function call/return value.

4) Intel has been directly harmed by AMD competition, which results in them needing to be price competitive in certain markets.