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

541–550 of 965 posts

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

#541

Post by ChrisMarshallNY »

beckingz wrote: post #511
ChrisMarshallNY wrote: post #217

Earlier quoted context omitted.

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.

Negative lines of code are a good day's work. https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

Love that story!

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

#542

Post by [deleted] »

dmitryminkovsky wrote: post #233
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…

I'm glad about this outcome, because I agree the other outcome would have had a devastating effect on software development. I also appreciate this fair use argument, especially when you point out the code in question was 0.4% of the entire API. Still, I'll always struggle with the idea that "the amount and substantiality of the portion used" when copying an interface is comparable to copying an implementation. The in…

[deleted]

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

#543

Post by curt15 »

BoorishBears wrote: post #356
simonh wrote: post #203

Earlier quoted context omitted.

That's a thorough miss-understanding and misrepresentation of the situation. It also has nothing to do with open source specifically. Google never promoted Dalvik as being a licensed Java VM implementation and never claimed it was a compatible Java runtime. The license was for logos and trademarks. As long as they didn't use those logos and trademarks, there's no violation of the license for those things. The API cas…

This sounds like you read Jonathan Schwartz's testimony and almost misinterpreted it. The license included using Java's name and trademark and that was for Sun's benefit, not Google. Google wasn't asking to call it a Java phone. That's why part of the testimony is actually Sun saying they'd pay for that And the rest of your comment is completely missing the mark here. You're saying MS was in the wrong with J++ becaus…

If Android's "Java" is so different, then how does Google benefit? The whole point of reusing an existing language is to jump-start the app ecosystem by allowing developers to make use of their existing experience.

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

#544

Post by tyingq »

nullifidian wrote: post #407
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…

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, depend…

Happens today, like AWS Elasticache and AWS Aurora. I do think you're right in that it will make those decisions easier. Particularly for AGPL/GPL things. Now they can be reasonably sure that cloning the end user facing API bit is "fair use".

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

#545

Post by coldtea »

luckylion wrote: post #537
coldtea wrote: post #464

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. What would be the difference between a "generated text or melody" you present to copyright, to one you've written yourself? What would be the mark of "automatic generation" that would be used to identify them as such and disqualify them?

> What would be the mark of "automatic generation" that would be used to identify them as such and disqualify them? None, but you wouldn't get copyright, much like you can present the works of others as your own but won't actually get the copyright if you're not the creator.

Huh? For one, nothing stops you from saying you are the creator, and nobody would have any way to say you're not.

Second, even if you have used a generator tool, regardless of if you wrote it or just run it, you're the creator of the works it produced, and you can trivially get copyright for it, unless somebody else copyrighted the same work.

Half of Brian Eno's output is generated works, where he sets some rules on a music synthesis system, and lets it create a work. Never had any issue copyrighting them...

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

#546

Post by JumpCrisscross »

moron4hire wrote: post #515
dmitryminkovsky wrote: post #233

Earlier quoted context omitted.

I'm glad about this outcome, because I agree the other outcome would have had a devastating effect on software development. I also appreciate this fair use argument, especially when you point out the code in question was 0.4% of the entire API. Still, I'll always struggle with the idea that "the amount and substantiality of the portion used" when copying an interface is comparable to copying an implementation. The in…

Substantiality was only one factor in the decision. There were lots of others, such as raison d'être of copyright, "promoting the progress of science and art". Because allowing copying of APIs is more important to the "progress of science and art" than the economic impact on the creator of the API, APIs are thusly not copyrightable.

> APIs are thusly not copyrightable

This is NOT what the Court found. At the very top of the Opinion, it says "we assume, for argument’s sake, that the material was copyrightable. But we hold that the copying here at issue nonetheless constituted a fair use."

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

#547

Post by FlyMoreRockets »

rrrrrrrrrrrryan wrote: post #451
LogicUpgrade wrote: post #391

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…

> This judgment is the equivalent of someone taking a movie script, shooting a new movie out of it without changing a word, and the court declaring this "fair use" of the script. Ethics aside, as a viewer, it'd be kind of cool if this were a thing. Small-time movie makers might like it too.

Shot for shot remakes have been a thing for half a century. https://en.wikipedia.org/wiki/Shot-for-shot

In fact, they've become a fannish pastime the past few years: https://www.theverge.com/2017/7/20/16006112/revenge-of-the-s...

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

#548

Post by The_rationalist »

quotemstr wrote: post #246
The_rationalist wrote: post #218

Earlier quoted context omitted.

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

If you think ART is an AOT system, you might want to refresh your understanding of the system. ART has had a JIT for a long time now. Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash. (And ART already has sub-millisecond GC pause times.) It's good and healthy for a language to have multiple implementations and there's no obligation whatsoever on the part of the…

Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash.

The ART features are not exposed to the language design. The JVM features in addition to the order of magnitude performance impact it will have (cf previous comment) needs to be supported in order to maintain interop with future JVM languages versions. (cf previous comment)

It's good and healthy for a language to have multiple implementations no it's much healthier to have one that reap most of the benefits through collaboration. Hence why Android try to merge its patchset in the Linux kernel instead of duplicating it's million commits.

Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash. Technical excellence unfortunately isn't an obligation. Or at least until the system becomes unsustainable (Cf interop) but then when it comes it is too late.

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

#549

Post by smsm42 »

lillecarl wrote: post #257
abhv wrote: post #21

Which of Breyer's clerks drafted this? They clearly understand many tech issues and I hope they find their place on some Federal circuit to herald an era of logic in tech law. "Google’s limited copying of the API is a transformative use. Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language. Google’s purpose…

"Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE." Does this mean that companies copying the S3 API as a substitute for S3 are still untested territory?

Strictly speaking, yes - this decision, as many other SCOTUS decisions, is tailored to specific case and leaves the other situations to be argued on their own merits. But having definite precedent in the situation where API has been recognized as non-copyrightable both sends signal to the lower courts about where SCOTUS leans, and to the potential plaintiffs about their chances to ultimately prevail. It is not a definite solution for all cases, but it shifts the calculus to the side of "if you sue for copyright infringement about S3 API, it'd be an uphill battle for you and probability to lose is high".

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

#550

Post by fulafel »

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.

There is a tendency, but it's not deterministic. When it does happem, it's more often for the broad strokes than this kind of detail, see eg sw patents.
Post reply on HN