Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s copying of the Java SE API was fair use [pdf]

supremecourt.gov

Post reply on HN
Print view View original

321–330 of 965 posts

Re: Google’s copying of the Java SE API was fair use [pdf]

#321

Post by tephra »

jcranmer wrote: post #262
jpdb wrote: post #249

Earlier quoted context omitted.

Are you referring to the S3 API? I believe the S3 API is explicitly licensed under Apache. Disclaimer: I was previously employed by Amazon and currently Google. Opinions are my own, I'm not a lawyer, etc.

And OpenJDK is GPLv2 with a classpath exception. So why is Google unable to use Java's API here while Oracle able to use Amazon's API?

IIRC (this case has been going on for way to long) they didn't cope the GPLed version of the code (oracle/sun had another proprietary version).

Re: Google’s copying of the Java SE API was fair use [pdf]

#322

Post by kaba0 »

jaywalk wrote: post #191
kaba0 wrote: post #165

Earlier quoted context omitted.

Why? It wasn’t about whether APIs are under copyright (they are), but whether this particular case constitutes fair use. I think the effect of this decision was way overblown.

If this wasn't fair use, nothing of any substantial value could be considered fair use.

Wine would be a much better example of fair use. It is explicitly made to allow users of linux to run programs written against win APIs. It is not so clear in the Oracle vs Google case, because it is questionable whether Google’s case was really fair use (google pretty much didn’t want to pay Sun for the mobile license and the whole thing was done as cost saving) - hence the very long timeline of the case.

Re: Google’s copying of the Java SE API was fair use [pdf]

#323

Post by jcranmer »

throwaway8581 wrote: post #161

The interesting question is how broad this fair use ruling is. According to the Supreme Court's other fair use cases, fair use is highly fact-specific and therefore case-specific. What kinds of actions and motivations by Google could have led to a determination that the use was not fair? Or is Embrace/Extend/Extinguish as practiced by the big tech companies now always protected by fair use?

The centerpoint of the analysis is recognizing that declaring code is different from implementing code. From this key distinction, it pretty much follows that most copying of declaring code that does not also copy implementing code is inevitably fair use, so it can effectively be argued that copying APIs is inherently fair use. Kind of like how we say that commentary or parody is inherently fair use--it's always case-specific, but there are broad categories where you're almost always going to agree that it's fair use.

Re: Google’s copying of the Java SE API was fair use [pdf]

#324

Post by thedevelopnik »

throwaway3699 wrote: post #147
thedevelopnik wrote: post #110

Earlier quoted context omitted.

I had the opportunity once to talk to an IP lawyer for Oracle and brought this up. I specifically brought up the S3 compatibility of their cloud storage among other instances. His reply was “without admitting anything specific, how do you know we haven’t purchased private licenses for anything you just mentioned?”

It's still silly. Imagine if you needed to purchase a license for the shape of plug that fits inside a standard plug socket - to build any appliance.

Oh yeah he and I still fundamentally disagreed, but it gave me some insight into Oracle’s position.

Re: Google’s copying of the Java SE API was fair use [pdf]

#325

Post by marcosdumay »

stickfigure wrote: post #267
AshamedCaptain wrote: post #126

For better or worse, the same arguments ( "API is copyrightable" ) is what was used in the past to prevent 98's Microsoft from doing embrace-extend-extinguish to Java with their "JavaVM with P/Invoke'd Win32 API". The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java…

I led the development of a large GUI app using J++ in the late 90s. This fear you describe is unwarranted. It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working. Perhaps you have noticed that you aren't reading this page in an ActiveX control. This is a boogeyman. Don't be afraid of it. [1]: http…

> It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working.

Looks like the successful examples were successful enough for everybody to forget about the originals. There is basically no other YP/Kerberos/SMB implementation in use that didn't follow from the MS copy. Netscape was successfully lead to bankruptcy. All the EEE days platform independent dev-tools were successfully lead to bankruptcy. All the EEE days competing office suites were successfully lead to bankruptcy...

Re: Google’s copying of the Java SE API was fair use [pdf]

#326

Post by pseudo0 »

tantalor wrote: post #74

From the dissent: > The Copyright Act expressly protects computer code. It recognizes that a “computer program” is protected by copyright... And it defines “‘computer program’” as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.” §101. That definition clearly covers declaring code—sets of statements that indirectly perform computer function…

> Thomas seems confused here. An API (declaring code) is not a computer program. A computer cannot execute declaring code - by definition - because it is missing the implementation.

This standard doesn't really make sense, and the legal standard says nothing about executability. What about programs with external dependencies, or a code snippet? Those won't necessarily be executable in a self-contained sandbox, but I'd certainly consider them computer programs.

Also, per Thomas's dissent:

> The majority also belittles declaring code by suggesting it is simply away to organize implementing code. Not so. Declaring code defines subprograms of implementing code, including by controlling what inputs they can process. Similarly, the majority is wrong to suggest that the purpose of declaring code is to connect pre-existing method calls to implementing code. Declaring code creates the method calls.

He clearly has a much better understanding of APIs than some software engineers I've worked with.

Re: Google’s copying of the Java SE API was fair use [pdf]

#327

Post by franklampard »

hammock wrote: post #308
teruakohatu wrote: post #7

> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as…

So if I copy the entire A volume of Encyclopedia Britannica, but leave B-Z alone, I'm good?

No but it’s okay to copy all the entry names in the encyclopedia and fill in the content yourself

Re: Google’s copying of the Java SE API was fair use [pdf]

#328

Post by shadowgovt »

lisper wrote: post #311

Although I applaud the effect of this decision, I can't help but agree with Clarence Thomas that the reasoning behind it is not sound. It waffles back and forth between arguments for fair use and arguments that APIs are not (or at least should not be) copyrightable in the first place. You can't have it both ways. If APIs are copyrightable (and a plain reading of the text of the law appears to indicate that they are)…

IANAL, but there is definitely such a thing as commercial fair use. The music industry is rife with "they stole my riff" cases that hinge on whether the copying was transformative and the amount that was copied. I wouldn't go so far as to say this undermines the rule of law (rather, the Court's precedent-setting power is part of the rule of law. It may undermine rule by Congress, but nothing about the US system makes Congress a king, and if they want to take back their power on this topic, they need only craft a clearer law addressing these issues directly).

I think reasonable people can agree with Justice Thomas on this (sidebar: this is why I love reading SCOTUS rulings - they're generally wise people and both the majority and dissent sides are usually reasonable takes). The tests of "is it transformative" and "how much was taken" are probably the most subjective tests in the copyright precedent.

Re: Google’s copying of the Java SE API was fair use [pdf]

#329

Post by tephra »

CarelessExpert wrote: post #128
jahnu wrote: post #16

Earlier quoted context omitted.

At least in the US

US copyright law and interpretation tends to get exported through trade deals and other forms of political and economic pressure.

While true, APIs have specifically not been copyrightable in the EU for some time, I'm not sure about the cad else in other countries and regions.

Re: Google’s copying of the Java SE API was fair use [pdf]

#330

Post by Natanael_L »

stickfigure wrote: post #267
AshamedCaptain wrote: post #126

For better or worse, the same arguments ( "API is copyrightable" ) is what was used in the past to prevent 98's Microsoft from doing embrace-extend-extinguish to Java with their "JavaVM with P/Invoke'd Win32 API". The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java…

I led the development of a large GUI app using J++ in the late 90s. This fear you describe is unwarranted. It's worth pointing out that the list of examples of "Embrace, Extend, Extinguish" on the wikipedia page of that name [1] contains zero actual successful examples of it working. Perhaps you have noticed that you aren't reading this page in an ActiveX control. This is a boogeyman. Don't be afraid of it. [1]: http…

Their failure to take control over those markets is not the same as a failure to cause damage. They slowed down development of web standards by many many years, as one example.
Post reply on HN