Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

521–530 of 771 posts

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

#521

Post by doonesbury »

Trying to get up to speed on this whole issue .. but as a software engineer, I'm a little surprised APIs are not copyrightable. Putting aside the pedantically literal creative work that goes into documenting an API and naming functions, the chief engineering role of the API is,

- breaking the domain of work into well modeled types

- information hiding

- keeping dependencies together and/or variously keeping data dependencies apart

- leaving room for extensibility

- speed of operations

- and promoting the correct use i.e. single v. multi-threaded or one server vs. distributed

That's real work, and getting a "good API" i.e. recognized throughout industry as well adapted to the problem domain (say SQL for DB work) or copy-on-write for C++-strings almost always reflects a better implementation which bubbles into the API.

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

#522

Post by whatsmyusername »

mindcrime wrote: post #74

Maybe we get lucky and the SCOTUS ruling comes down against uncopyable API's. But while that seems questionable at the moment, it's important to remember one thing: there is always an "out" even in the "nuclear option" case and that is "have Congress change the law". It seems to me that now is the time to start thinking about putting together a mass effort to get Congress to change copyright law, to establish clearly…

Unless the democrats sweep I see little to nothing to imply that anything of note will happen in congress for the foreseeable future.

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

#523

Post by lmkg »

andrewjl wrote: post #515
mumblemumble wrote: post #500

Earlier quoted context omitted.

The 2014 decision, for one, hinges on it being a whole package structure and not just one method: Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages — the "overall system of organized names — covering 37 packag…

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…

The arguments and return value of Min and Max are strictly essential to their function. Their inclusion as top-level items in a Math package is not.

One could imagine alternate taxonomies where, e.g., the Math package is divided into Arithmetic, Trig, Comparison, and Advanced sub-packages. Or where they are placed into an Operators package insted of Math.

For example, Rust puts the Max function into the cmp (Comparison) crate of std. This associates them with comparison & equality rather than trigonometry and calculus like Java does.

This is the type of subjective decision-making that qualifies something as original and non-trivial.

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

#524

Post by mumblemumble »

andrewjl wrote: post #515
mumblemumble wrote: post #500

Earlier quoted context omitted.

The 2014 decision, for one, hinges on it being a whole package structure and not just one method: Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages — the "overall system of organized names — covering 37 packag…

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, not of necessity. It's hard to imagine any particular reason why a function would need to have "java" in its name in order correctly calculate the maximum of two numbers.

The crux of the case, then, is the copyrightability of those design decisions about how the API members are arranged. The set of specific functions it performs is, as per Baker not the focus of the argument.

To take a hypothetical that cuts much closer to the accounting analogy: imagine if H&R Block came out with tax preparation software with exactly the same capabilities as TurboTax. That would, I believe, be fine, in and of itself, because the functionality itself is not copyrightable. However, if the interface to their tax preparation software were arranged identically to TurboTax's, to the extent that a set of automated UI tests written against TurboTax would also work with H&R Block's app, then we would likely be looking at a case of copyright violation.

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

#525

Post by babesh »

ummonk wrote: post #290
babesh wrote: post #157

Earlier quoted context omitted.

That is a terrible analogy since the potential conceptual range of APIs is so wide and because it does disservice to the conceptual power of APIs. Good APIs embody the key architectural and conceptual decisions. They define the key concepts and how they interact. But at the level of a programming language, this is of immense scope and power. Java defines an imperative language with built in garbage collection with ab…

It's actually a great analogy in that respect, as there are substantial tradeoffs involved in the design of pipe connector types, and the design of a particular connection / thread standard embodies key architectural and conceptual decisions.

The post only commented on size and thread. There is far, far more than that. Also some connectors are patented for what it is worth.

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

#526

Post by nitrogen »

penteract wrote: post #511
tylersmith wrote: post #504

Earlier quoted context omitted.

He's right. The entire premise of open source licensing is that the work is copyrightable, so it uses the copyright system to enforce the authors distribution requirements.

It still seems like an overstatement to argue that use of open source licenses indicates a belief that method declarations are copyrightable.

Open source licenses have often included terms that were for other jurisdictions, or because the status of something is actually unknown, or just in case some future law changed the accepted belief.

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

#527

Post by AnthonyMouse »

nodamage wrote: post #501
AnthonyMouse wrote: post #368

Earlier quoted context omitted.

> As applied to Java, individual method signatures like min and max might not be copyrightable, but someone had to go in and organize those individual methods into classes, and organize those classes into packages. That act of organization likely implies that the Java API (taken as a whole) constitutes a copyrightable work, even if the individual method signatures are not. The problem with this theory is that class a…

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 copyrightable. You exercise creativity in choosing whether to specify chocolate chips or peanut butter chips or licorice bits etc.

APIs have hierarchy, but recipes have that too. You make butter from milk. You make cookies from butter. You make cookie crumb topping from cookies.

It's all already there in a recipe without reaching the result you want. You choose chocolate chips over peanut butter chips. You combine them with cookie ingredients to make cookies and brownie ingredients to make brownies. Selection, coordination, and arrangement. But the end result is still just a list of facts about how to make those cookies/brownies.

So why look at those things sometimes but not others? Because sometimes it applies to a work of authorship, but sometimes it applies to function, and you can't copyright function. So the functional part shouldn't count.

And that's what an API is. It's a formal functional specification. It's a list of facts about how to call those function implementations. It's the exact piece you don't get credit for.

Anything required for interoperability, is functional.

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

#528

Post by interpol_p »

AnthonyMouse wrote: post #470
interpol_p wrote: post #450

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 design an API for graphical coding and spend significant creative energy choosing the right words, calling conventions, result types to not only make something intuitive, but emotionally pleasurable to code with Sometimes I'll spend days writing out possible forms of t…

> 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 But that's not what it's about. Lots of things are a work of creative design but not copyrightable. Like a recipe for chocolate chip cookies.

Yes and I am on the Google side of this argument. I just wanted to point out that API design is a very creative area of programming

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

#529

Post by titzer »

SloopJon wrote: post #14

I saw one question from Gorsuch quoted in reports about the arguments that bothered me: "What do we do about the fact that the other competitors, Apple, Microsoft ... have, in fact, been able to come up with phones that work just fine without engaging in this kind of copying?" macOS and iOS (and indeed Apple itself) would not exist as we know them today, if at all, without very liberal cross pollination of APIs. In a…

> have, in fact, been able to come up with phones that work just fine without engaging in this kind of copying?

Which, of course, is completely false. All of them have many, many reimplementations of open APIs in their many layers of software. It's just that no one was stupid enough to copyright those APIs and try to sue someone else for implementing an API before.

Oracle's actions threaten to upend the common understanding of software ecosystems and throw everything into disarray.

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

#530

Post by wtallis »

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).

I've been saying for years that Oracle's objective here seems to be acquiring what is effectively patent protection with copyright duration.
Post reply on HN