Live data from Hacker News

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

supremecourt.gov

211–220 of 965 posts

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

#211
post #154

Earlier quoted context omitted.

This argument is hard to swallow: > declaring code would satisfy the general test for copyrightability.. they are expressed in “words, numbers, or other verbal or numerical symbols It is common knowledge that mathematical formulae & equations, which are also expressed in words, numbers, and symbols, do not have copyright protection. > Copyright protection is therefore not available for... mathematical principles; for…

When you get down to it, copyright is a whole bunch of contradictory rules. Courts decide every time there is a new kind of work, whether it is copyrightable or not. Trying to divine whether something is copyrightable by analogy to other kinds of works is a hopeless endeavour.

That was the case with computer software when it first became interesting to copyright. After all, it's just a series of instructions which are often not considered copyrightable. But, in general, copyright has carried over fairly naturally from the printed word to new types of media as technology advanced.

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

#212
post #16

This is one of the most important legal decisions in the history of software. The US Supreme Court has basically just saved the whole software industry (and FOSS projects) from being wrecked by patent trolls.

At least in the US

Did Oracle also sue Google in other countries outside of the US? To my knowledge we didn't need any saving in this respect in my country.

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

#213

Earlier quoted context omitted.

Can you copyright generated things? You probably could copyright the way you're generating it, but I doubt you have a legal standing about the generated text or melody itself.

My understanding is no. Copyright requires human authorship (the case of the monkey selfie found it to be public domain because a monkey did it, e.g.), and code written by a machine is likely to follow similar precedent and be uncopyrightable.

That law is not quite settled: https://en.wikipedia.org/wiki/Monkey_selfie_copyright_disput...

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

#214

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…

The 1990s Microsoft issues were antitrust. They tried "embrace-extend-extinguish" because they were in a monopolistic position, and this tactic was viewed as anticompetitive.

But Google (at least with respect to phone OS) was in the position of the startup, and Sun was the big market player. Now, Google had with ridiculous resources at its disposal, of course, but at the time not using a monopoly position to twist arms of carriers, for example. It's not anti-competitive to spend a lot of money to win.

Of course, things change....

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

#216

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

It is fascinating that code is now being measured quantitatively. Number of "lines of code".

Objective measures are better suited to uniform application of justice vs subjective ones.

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

#217

Earlier quoted context omitted.

It is fascinating that code is now being measured quantitatively. Number of "lines of code".

Now? I've personally heard quantities of code measured in "lines of code" (or, thousands of lines of code-- "K-LOCs") going back to the mid-90's. An acquaintance who worked for IBM in the 70's said it dates back at least that far (measuring developer productivity in the "K-LOCs" they produce).

It's been going on since the 1960s (maybe longer).

Personally, I think the best code is the code I don't write.

A significant part of my refactoring, is removing as much code as possible, by tweaking algorithms, deriving common base classes, and removing unused code branches.

Every line of code is a potential bug. The less code, the less bugs.

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

#218

Now can they please use a modern jdk on Android? It's about time

They are using a modern JDK on Android. The standard library is literally OpenJDK, and the runtime is the excellent ART JVM, which has super-fast GC and tons of mobile-specific optimizations (like zygote space support and switching to a different GC when the app goes into the background). IMHO, you really don't want HotSpot on mobile. ART is good work.

I am talking about C2 JIT support and other sota GCs. ART has an increasingly growing technical debt. No support for constant dynamic so no support for the upcoming pattern matching. No support for sub 1ms GC No support for the already available Vector API. No support for value types. No support for generic specialization. No support for Loom. ART is NIH and support with Java and Kotlin will explode into two worlds, the Android obscolete world and the modern, feature complete and optimized world. ART has custom improvments? Fine that's good, now let's gradually port them to openjdk (or a light openjdk fork). No custom improvement is gonna outweight the need of interoperability (and the order of magnitude performance improvement from the above features) ART is an AOT so I wonder if the android team has considered switching to GraalVM instead of hotspot, the transition might be easier. Please Google, it's time to show technical excellence.

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

#219

Earlier quoted context omitted.

I am not a lawyer, but I don't see why not. Have you ever used code generation as part of software you have built? Is there any reason why generated code could not be copyrighted as part of a larger system? For example, suppose I define a data model for a public-facing API and then generate SDKs in various popular programming languages to interact with the public-facing API. If I were a major corporation that owned s…

> I am not a lawyer, but I don't see why not. The involvement of actual human creativity is required for a work to be copyrightable.

In my code generated-SDK example, a human defined the data model and a human created the code generation algorithm, but an algorithm generated the SDK code itself.

So human creativity is involved, but is not the direct creator of the SDKs. Does that count? I am not really sure.

I bring up the generated SDK example because I have used just such a system when I worked at a major corporation: I created a data model in Web Services Description Language (https://en.wikipedia.org/wiki/Web_Services_Description_Langu...) and used a company-owned tool to generate SDKs in various programming languages. All of the generated SDKs had the company's copyright notice in the generated code.

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

#220
post #70

While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: > To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on…

I noticed that comment too early on. Breyer's opinion comes pretty close to saying "it's at best 'thin copyright'" but the fact that it's explicitly disclaimed makes me think that this is to some extent a compromise position: rather than arguing about whether SSO is copyrightable and risk a bigger split, just concede it because the fair use is sufficient here.
Post reply on HN