Live data from Hacker News

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

supremecourt.gov

401–410 of 965 posts

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

#401

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

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

Do you feel like Wine, Linux, or any web browser is also "stealing a platform" from Windows, Unix, or Netscape?

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

#402

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.

It is going to open a big door for people who reimplement APIs.

In particular, social-media aggregators (one app to display your Twitter, FB, Instagram, etc.) may have new protections.

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

#403

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.

I assume this means that Amazon can ignore the Elastic and Mongo licenses when building compatible implementations?

So can other vendors with S3's api.

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

#404

Earlier quoted context omitted.

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

I don't think it's fair to compare a programming interface, which is more analogous to designing something like the plumbing architecture for a house, to a movie script, which is art. Yes, a well-written API can be considered art, but with the plumbing analogy, a "copy-cat" would just be making sure the same pipes are connected to the toilets in the same positions. What's going on under behind the dry-wall wouldn't m…

Bad analogy, architecture schematics are subject to copyright and you can't just take them and use them, either.

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

#405
post #363
post #242

Earlier quoted context omitted.

>As it currently stands, APIs absolutely fall under copyright laws. This opinion doesn't say so. "We shall assume, but purely for argument’s sake, that the entire Sun Java API falls within the definition of that which can be copy-righted. We shall ask instead whether Google’s use of part of that API was a “fair use."

It would be dumb to declare true the opponent’s case in the argument, wouldn’t it?

No, it is a sidestep. Even if the code is copyrightable, it doesn't matter. The majority decided it was better to make a case for fair use than for the uncopyrightability of APIs. That's all.

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

#406
post #238

Earlier quoted context omitted.

Why should it have been evaluated first? I understand the intuition you're getting at: logically, the first question could make the second irrelevant. But if the second question resolves the issue even when the first is construed in favor of the other party, what's the rationale for demanding the court focus on the first question?

IANAL, but I can imagine something like the following: A. We decide this is fair use based on the small number of LOC used and call it a day B. OR we can decide that APIs are not copyrightable even though they're self-evidently creative works because of the importance of interoperability based on something something related to Borland v. Lotus, a case that we couldn't agree on the last time it came up. Hey folks. Let…

While I agree that APIs should not be copyrightable, the Supreme Court has been criticized for "legislating from the bench".

Avoiding the temptation to set bigger and more far-reaching precedents than is strictly necessary for the case at hand avoids giving the impression that the judicial branch is doing the job of the legislative branch.

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

#407

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

An alternative take, which I'm sure won't be popular, is that now, with an interpretation taken to the extreme, a megаcorporation can basically steal your (let's say a small startup's) platform (in case you refuse to sell it for ethical or some other reasons), by re-implementing it and investing much more resources which you don't have, to make it more attractive to customers.

I'm ok with either decision, but, depending on how this precedent going to be interpreted, it could have far reaching consequences, maybe unintentional/undesired ones too.

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

#408

Earlier quoted context omitted.

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

Maybe it is the same as using a similar plot, but with 0.4% of code lines being the same I think the analogy doesn’t carry through to using a script word for word.

How many lines is a script? Is it more than the 11500 lines Google copied? It's actually way less.

And it's literally word for word.

Can we be intellectually honest and not lie about the vast amount of work being copied here?

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

#409

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.

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…

> as part of a larger system

I think this is the key statement that will make a difference. If you want to copyright a larger system, generated code is not a problem. If you want to copyright an individual, generated piece of code, I doubt you'll get copyright for that. But IANAL either.

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

#410

Earlier quoted context omitted.

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

> Declaring code defines subprograms Absolutely not. No points awarded. Declaring code declares subprograms. They are defined by the implementation. > A declaration provides basic attributes of a symbol: its type and its name. A definition provides all of the details of that symbol--if it's a function, what it does; if it's a class, what fields and methods it has; if it's a variable, where that variable is stored. ht…

"Declaring code" is a specific term of art used in this case. For an example of what they consider declaring code vs. implementation code, see page 38 of the decision which has a handy diagram and example.

> That's nonsense. I have no idea what this means.

He's referring to how the workflow for an API generally involves gathering requirements, writing the "defining code", and then finally implementing the functionality promised by the interface. From that perspective, the defining code determines what implementation code is created, rather than linking up already existing implementation code.

Post reply on HN