Google’s Supreme Court faceoff with Oracle was a disaster for Google • Hacker News Board

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#551

Post by gwright » Fri, Oct 09, 2020, 2:48 AM UTC

abvdasker wrote: post #545

Further proof that the Supreme Court of the United States has been captured by right-wing ideologues who view every problem as having a solution in property rights. Why anyone in the US would think it's a good idea to change the foundations of the software industry — one of the few remaining bright spots in the US's sputtering economy — is beyond me. I guess in the end Americans will get what they deserve.

This seems like shooting the messenger to me.

The problem is that the legislature hasn't done its job. It isn't the job of the judiciary to monkey-patch the law to get a desired outcome. They should be interpreting the law as written and any negative consequences should be addressed by legislation.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#552

Post by AnthonyMouse » Fri, Oct 09, 2020, 2:49 AM UTC

mantap wrote: post #502

AnthonyMouse wrote: post #383

Earlier quoted context omitted.

> What is the difference between an API (interface) and implementation? The algorithm. Not the algorithm. The algorithm is essentially the recipe. The algorithm is merge sort, or depth first search. It's the contract the API gives you, more or less. "This function does merge sort." But there are unlimited possible implementations of merge sort and each one is copyrightable. And one implementation doesn't infringe the…

I don't agree that the steps of an implementation are copyrightable. Different versions of an algorithm are different algorithms. One merge sort algorithm may perform much better than another despite both being merge sort and having the same asymptotic complexity. You could patent a particular version of merge sort. Copyright protects how code is written not what it does. And the how applies just as much to interface…

> Different versions of an algorithm are different algorithms.

Splitting hairs like that doesn't change anything because it's still not the algorithm which you get a copyright on. It's the work of authorship implementing it.

But you can certainly produce multiple implementations of source code that are not only functionally equivalent in practice but actually generate identical machine code.

> Copyright protects how code is written not what it does. And the how applies just as much to interfaces as implementations.

The issue is that the interface is strictly the what it does part. Given the implementation, or the need for compatibility with one, the API is purely a factual description of the call spec. You can't rewrite it or it changes the what, which means there is no room to change the how, and the code correspondingly required shouldn't be copyrightable because it's purely functional and leaves no room for alternative compatible implementations.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#553

Post by andrewjl » Fri, Oct 09, 2020, 2:54 AM UTC

wahern wrote: post #548

andrewjl wrote: post #440

Earlier quoted context omitted.

Having read multiple perspectives, some pro-Google and some pro-Oracle, I cannot reconcile this sort of argument with the Baker v. Selden precedent. [1] Perhaps my understanding of APIs is different because I'm an engineer and not a lawyer, but how is this not an open and shut case? The cookbook analogy is not applicable for the same reason one could not apply it in Baker , accounting methods are not of themselves co…

> I cannot reconcile this sort of argument with the Baker v. Selden precedent. Contemporary judges, including on the Supreme Court, aren't interested in reconciling Oracle's argument with Baker v. Selden; there's no love for Baker. Courts may pay lip service to the notion that ideas can't be copyrighted, but the prospect of ruling as a matter of law that specific, concrete categories of works are categorically not co…

Are there some cases you can cite where this movement occurred? They don't need to be software related. I'm VERY curious about this trend.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#554

Post by wbl » Fri, Oct 09, 2020, 3:01 AM UTC

mumblemumble wrote: post #524

andrewjl wrote: post #515

Earlier quoted context omitted.

I'll have to read on this further. Thanks for the references. > The Baker precedent says that the parts of a design that are strictly essential to its function are not copyrightable. Since all parts of the API code are strictly essential to its function than they are not copyrightable, right? The parts that are not essential to its function lie in the behavior of the system in question instead of the API code, this b…

So, going back to the max() function example: I believe, based on the way the courts are looking at it, that the parts that are essential to its function are the fact that it takes two numbers and returns the greater of the two, and perhaps also the fact that it is named "max". Its being placed into class named java.lang.Math, though, is not. That is a product of the way it is arranged, which is a matter of design, n…

No we wouldn't. Courts rejected these look and feel claims in Lotus v. Borderland.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#555

Post by [deleted] » Fri, Oct 09, 2020, 3:04 AM UTC

az226 wrote: post #378

az226 wrote: post #353

Earlier quoted context omitted.

The reason we have copyright protections to begin with is to reward and incentivize creation of new creative works with intellectual property protections. If you spent a large amount of resources in creating the library of Java code, why should only the implementation be protected? They've spent a lot of resources to come up with which methods to create, what to call them, how to describe them, how to organize them,…

Couldn't edit my comment above to add: The interoperability argument is also disingenuous because Google didn't copy all of Oracle's Java libraries. It only copied the ones it deemed necessary to provide sufficient coverage for the needs of the Android platform and that developers of Oracle's Java community were familiar with. As the justices pointed out, it's a one-way interoperability.

[deleted]

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#556

Post by nodamage » Fri, Oct 09, 2020, 3:04 AM UTC

AnthonyMouse wrote: post #527

nodamage wrote: post #501

Earlier quoted context omitted.

Perhaps I should not have used the recipe analogy as it might be causing unnecessary confusion. But I don't think the situations are all that similar. If an individual recipe is non-copyrightable because it describes a "process, procedure, or method" then a mega-recipe created by combining other recipes together will still be non-copyrightable for the same reason. That's not quite the same thing as curating a set of…

> Perhaps I should not have used the recipe analogy as it might be causing unnecessary confusion. It's hard not to use it when it's the one from the case law. > That's not quite the same thing as curating a set of recipes into a cookbook and thereby exercising creativity in the "selection, coordination, and arrangement" of those recipes. Exercising creativity can't be the hook if recipes have that and aren't copyrigh…

> Exercising creativity can't be the hook if recipes have that and aren't copyrightable.

Sure, creativity is a requirement but it isn't the only requirement. But think about why a cookbook of selected recipes is copyrightable even if the recipes individually aren't.

> And that's what an API is. It's a formal functional specification.

The problem for Google is the Java API is also code, which is generally copyrightable. You seem to be saying that since this particular code happens to form a specification it should be treated differently under copyright law, but I'm not sure the court would find that argument very convincing.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#557

Post by Dylan16807 » Fri, Oct 09, 2020, 3:05 AM UTC

az226 wrote: post #378

az226 wrote: post #353

Earlier quoted context omitted.

The reason we have copyright protections to begin with is to reward and incentivize creation of new creative works with intellectual property protections. If you spent a large amount of resources in creating the library of Java code, why should only the implementation be protected? They've spent a lot of resources to come up with which methods to create, what to call them, how to describe them, how to organize them,…

Couldn't edit my comment above to add: The interoperability argument is also disingenuous because Google didn't copy all of Oracle's Java libraries. It only copied the ones it deemed necessary to provide sufficient coverage for the needs of the Android platform and that developers of Oracle's Java community were familiar with. As the justices pointed out, it's a one-way interoperability.

> If this wasn't protected, you would have zero incentive to build high quality libraries or to invest in making the platform popular if someone else can just come along and copy it.

I guess I must be hallucinating all those S3-compatible libraries and services.

> As the justices pointed out, it's a one-way interoperability.

It makes a large majority of the same code work on both. That's not one-way. Porting in either direction is vastly improved versus them making their own APIs.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#558

Post by andrewjl » Fri, Oct 09, 2020, 3:06 AM UTC

interpol_p wrote: post #532

andrewjl wrote: post #458

Earlier quoted context omitted.

> I'm not going to argue whether I think APIs should be copyrightable, but I believe creating a good API is a work of creative design, and is artistic I disagree. I think the specification can be, but the API code itself is a mechanical translation of the specification into computer code. Note that abstractions, names, etc are conceived in the specification and are then translated into computer code. Even if you skip…

To be clear I am on the Google side of this argument But certainly the API code contains naming, which is a creative aspect of API design, and in this case naming is used by developers to code against either Oracle's Java implementation, or Google's. In order to allow this Google had to copy the naming created by Oracle for their version of the API in order to attract the large pool of developers who liked and were f…

With respect to naming, I think the details of the Baker case make it clear that names are not copyrightable. Nevertheless I agree that naming is a creative aspect of API design. It's not a creative aspect of API code though! There it is just an affordance.

The names that we given our APIs are inherent to their behavior and not necessarily the code. Some languages, such as Swift, even mangle API names when they are used so that their names are non-sensical without de-mangling. So why is the name important? It's important for us to understand what the system is doing, but not to the function of the system itself. This might not seem important for us when doing our work, but in the case of copyrightability it's an important fact based on precedent law.

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#559

Post by gerash » Fri, Oct 09, 2020, 3:06 AM UTC

AnimalMuppet wrote: post #514

gerash wrote: post #479

Earlier quoted context omitted.

I find it frustrating that, say, Kavanaugh can go ahead and imply that all these 83 notable people in your field are having a knee jerk reaction but the sky isn't falling. Why does he think he has any better understanding than 83 notable computer scientists? https://www.supremecourt.gov/DocketPDF/18/18-956/128391/2020...

I don't think that's what Kavanaugh was doing. If you're thinking of taking those 83 into account in your ruling, but you aren't exactly sure that they're solid, you ask a question: Hey, Google, explain to me why these are important. It doesn't mean that he's dismissing them. It is at least as likely that he's considering relying on them, and wants to have a solid justification for doing so. (Remember, Oracle also cl…

Fair enough. I hope that was indeed the case. I also think that Google lawyer went into legal technicalities with merger doctrine, etc. (which I don't understand) without trying to provide real life analogies (with all their caveats) which some justices tried to do instead.

One analogy that comes to my mind is that the steering wheel, gas and brake pedals, hand brake, etc. are like APIs of a car and are implemented differently in a gas car vs. an electric car. It makes sense for an electric car company to stick to that API rather than replace the steering wheel with a joystick or buttons and have all drivers learn this new method to drive a new car. It would've made more intuitive sense

Re: Google’s Supreme Court faceoff with Oracle was a disaster for Google

#560

Post by Dylan16807 » Fri, Oct 09, 2020, 3:08 AM UTC

pdonis wrote: post #350

dragonwriter wrote: post #316

Earlier quoted context omitted.

> An API is literally just a table of contents. An API is more like a set of mechanical gears that just happen to be shaped a little like words. If I change the names of things in a table of contents to synonyms, I can still use it to find what I am looking for. If I change the names of things my implementation of an API, it no longer functions as an interface for the things that worked with it previously. An API, de…

> An API, despite looking like works, is not a literary expression of a process, it is a machine If this argument is valid, it means that APIs are not copyrightable, they are patentable, because copyright is only for expressions of ideas, not for machines; patents are what apply to machines. And Oracle has already lost on the question of patent infringement in this case (back in 2015, IIRC).

As a machine, it would be patentable if the machine was made of something other than abstract concepts.