I would imagine if the ruling went the other way, IBM might want to talk to all the BIOS companies. Luckily, that didn't happen.
and Amazon could talk to Oracle who "borrwed" the S3 API for their cloud storage.
Google’s copying of the Java SE API was fair use [pdf]
251–260 of 965 posts
Re: Google’s copying of the Java SE API was fair use [pdf]
#252Earlier quoted context omitted.
I don't know why people are acting like this is some victory of open source I don't know that anybody is saying that Google did anything specifically Good or Just or Noble or anything. The celebratory aspect is more based on all the Bad Things that would have happened in the future if this decision had come down in favor of Oracle.
That's literally the next sentence that you intentionally omitted. And I've seen plenty of people paint Oracle as some evil boogeyman like this is some good vs evil struggle. Oracle wasn't trying to make Bad Things happen. They were seeking damages from a damaging situation, and if bad things had happened... I'd blame the patent trolls and judges that enable them. Their insanity continues regardless of the verdict af…
> I've seen plenty of people paint Oracle as some evil boogeyman
“Don't anthropomorphize the lawnmower.”
Re: Google’s copying of the Java SE API was fair use [pdf]
#253"The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market....the jury also heard evidence that Sun foresaw a benefit from the broader use of the Java programming language in a new platform like Android, as it would further expand the network of Java-trained programmers...and because there are two markets at issue, programmers learning the…
Except that Android is a fkup of “Java” that is so old that repositories have to create an android and a normal version. Kotlin spread into android development pretty much because android java is so bad.
That is exactly what was the “damage” Oracle sued for.
Re: Google’s copying of the Java SE API was fair use [pdf]
#254Earlier quoted context omitted.
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...
All of the appeals courts that heard appeals in that situation agreed that animals could not hold copyright, and there are no appeals still pending since then. That's pretty settled--there's no courts with binding precedent arguing for animals being able to hold copyright.
(Appeals courts can still settle case law, even if SCOTUS doesn't hear the case. There are several precedents that are set by appeals courts and not SCOTUS itself.)
Re: Google’s copying of the Java SE API was fair use [pdf]
#255Earlier quoted context omitted.
> 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 W…
IANAL, but:
The code generated SDK is a derivative work of the human-defined data model - just like the binary for any piece of software is derivative of the source code. (Otherwise where'd the copyright for the binary come from?)
The generator's copyright (or the compiler's) doesn't directly flow in. (But if the generator/compiler incorporates pieces of itself, like a support library, that does. Also, the generator/compiler might have terms of use...)
If you write a generator that just generates random APIs, those are basically machine generated garbage and wouldn't be copyrightable. The human input to the generator is missing.
[FWIW, I had to research this due to an "ill-behaved" community member on an open source project a few years back; I'm not completely making this up out of thin air. That still doesn't make me a lawyer though ;)]
Re: Google’s copying of the Java SE API was fair use [pdf]
#256Earlier quoted context omitted.
I suppose it makes sense from the perspective of copyright law, which protects artifacts. After all, one could say the same for quoting from a famous literary work .."ha now they're valuing literature in terms of number of words of prose!"
The dissent clearly highlights the fallacy of the ruling, where it discussed the importance of the "heart" of the work, rather than the portion of exact lines copied. Aka, that you could clone Harry Potter's plot, characters, and story while not copying each word of the book verbatim, and it still be a copy of Harry Potter.
They do state, copy-write isn't the same in the programming world. Programming is always functional in nature, unlike a book.
Re: Google’s copying of the Java SE API was fair use [pdf]
#257Which 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?
Re: Google’s copying of the Java SE API was fair use [pdf]
#258Earlier quoted context omitted.
True, but it's such a strong precedent in favor of copying API's being "fair use" that it at least partly moots the more general question of "are API's copyrightable in the first place." I think this was a good decision all in all. AIUI, the SCOTUS try to limit the scope of their decisions as much as possible, to avoid over-generalization.
I don’t think it moots the point at all. * Google’s API copying can’t be fair use if they weren’t copyrightable in the first place. * If you do copy an API because of it’s beauty and not for either interoperability with software or interoperability with developers then it seems that you would run afoul of copyright.
Of course fair use is moot if API cannot be copyrighted in the first place. But the court seems to say that this case would be fair use even if API is copyrighted.
"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.” Unlike the Federal Circuit, we conclude that it was"
Re: Google’s copying of the Java SE API was fair use [pdf]
#259Earlier quoted context omitted.
Not surprised at all the Thomas and Alito are in that dissent..
Why is it that you aren't surprised?
Because they tend to take extreme or simplistic positions in opposition to any sort of nuanced or interpretive view of the law.
In this case it's "Hey, it's Oracle's code, end of story."
Re: Google’s copying of the Java SE API was fair use [pdf]
#260It's interesting reading Thomas' dissent. As per typical Thomas appears to be arguing that it's the letter of the law that matters, whereas it's the majority opinion that the motivations and substance of the law are primary. Hackers and programmers tend to try and read the law like computer code to be "hacked" and exploited based on the letter of the law. So you'd expect us to be more sympathetic to Thomas' view. So…
No, when the code allows an exploit, that's a bug. Thomas is supposed to help us understand the intent of the code - what the Requirement was. Yes, it's better for us if the code reflects the intent perfectly. But to the degree that's not possible, we need someone to Interpret the code. Textualists are trying to ignore the fact that there's a difference between intent and implementation. The Legislature should do a f…
> Textualists are trying to ignore the fact that there's a difference between intent and implementation.
I would say that they are not so much trying to ignore the fact as acknowledging the fact but taking the position that it the court's role to interpret the implementation, not to guess at the intent.