Live data from Hacker News

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

arstechnica.com

621–630 of 771 posts

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

#621

Earlier quoted context omitted.

SQL is an ISO standard. IBM would only have grounds if any part of Oracle's implementation implemented a proprietary portion of an IBM database implementation. This is the positive thing about standards, it removes ambiguity around what people can/should implement and present to users of the systems.

The IBM implementation of SQL far predates the ISO standard. Does something being standardized somehow relinquish the copyright? The idea of APIs being copyrightable is new, has IBM somehow relinquished its copyright claims for SQL to ISO? This article discusses the possibility at length https://arstechnica.com/tech-policy/2020/03/before-it-sued-g...

Yeah but what did Oracle copy here? They made the language compatible, but did they copy the API too? Cleanrooms have been a thing for a long time.

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

#622

Earlier quoted context omitted.

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

I'm not sure I understand your point about the difference between the API code (where the names are mangled and meaningless) and the API design. Surely the API code is irrelevant here because it is not the part that humans interact with? In this case the naming is an important factor, as that is the competitive advantage leveraged by Google in copying Oracle's Java API. They were able to tap into a developer resource…

> difference between the API code (where the names are mangled and meaningless) and the API design.

API Code = header file or interface files or source code artifacts you need to include in order to make use of the system underlying the API.

API design = a behavioral specification which the system represented by the API implements

> In this case the naming is an important factor, as that is the competitive advantage leveraged by Google in copying Oracle's Java API.

My point is it's an important factor in the design specification, not the code. This makes it an invention. Inventions cannot be copyrighted per Baker; they can however be patented.

> They were able to tap into a developer resource who was familiar with the style, naming and conventions of Java

The Baker case specifically addresses this point by saying embodied practices cannot be copyrighted. Java isn't a book, it's an invention so the proper avenue for protection is a patent and not copyright.

> The API is the interface between the human and the code, and so copying a familiar interface design can be an advantage when building a platform

Again this would be arguable as a patent infringement, but here we are discussing copyright and not patents. What you're describing applies to design patents IMO. [IANAL]

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

#623

I started reading this article today thinking that the case was clear-cut - Oracle's wrong and Google is right. As I read the article and the comments I'm now not at all sure. We all are trying to come up with a good analogy to explain why APIs are distinct from implementations, why it's 'obvious' to a programmer how they're distinct, and how their rules should be distinct. But the more I think about it, and read fee…

I does not matter if your API design is good, all we need is compatibility.

Microsoft Word .doc format claimed to be awful [1] and yet there are a lot of clients.

[1] https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...

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

#624

I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…

> the cookbook itself becomes copyrightable.

But what is discussed here is not the cookbook but just the table of contents. The actual recipes are different.

Making another cookbook with chapter 1: salads, chapter 2: soups etc. is common practice. The question is how much detail you are allowed to copy in order to allow for interoperability.

For instance, a dinner might call for the Oracle potato salad of Section 1.3 and Oracle tomato soup of Section 2.2. If your cookbook has your recipes (not Oracle's) in the same Sections in your book, that is useful for your readers/chefs, since they can easily switch their menus to your book.

Are you allowed to do that? That is the question.

> arguing that APIs are non-copyrightable is essentially carving out an exception for a specific type of code.

Disagree. APIs are talking about code but not code by themselves alone. Just like "The potato salad recipe is in Section 1.3" talks about a recipe but is decidedly not a recipe by itself.

If the law currently thinks that should be copyrightable, then the law should be changed.

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

#625

I started reading this article today thinking that the case was clear-cut - Oracle's wrong and Google is right. As I read the article and the comments I'm now not at all sure. We all are trying to come up with a good analogy to explain why APIs are distinct from implementations, why it's 'obvious' to a programmer how they're distinct, and how their rules should be distinct. But the more I think about it, and read fee…

I agree; a big part of the problem is that the whole concept of what an API is and what it does has really grown in the last 40 years. The original IBM PC BIOS exposed an API but it was far simpler than the Java API. When we draw an analogy between a large industrial machine and all of it's levers and switches and buttons and the interrupt calls on an IBM PC BIOS, the analogy seems somewhat reasonable. It certainly f…

Great example with IBM PC BIOS, there was source code, there was infringement suit, yet clean reimplementation won [1].

[1] https://retrocomputing.stackexchange.com/questions/12018/why...

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

#626

I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…

> the cookbook itself becomes copyrightable. But what is discussed here is not the cookbook but just the table of contents. The actual recipes are different. Making another cookbook with chapter 1: salads, chapter 2: soups etc. is common practice. The question is how much detail you are allowed to copy in order to allow for interoperability. For instance, a dinner might call for the Oracle potato salad of Section 1.3…

>> the cookbook itself becomes copyrightable.

> But what is discussed here is not the cookbook but just the table of contents.

You probably can't copy that either. That's like Oracle's example of making a new Harry Potter book with all the same chapter titles.

I don't know if there are any good examples of APIs one can make based on books..

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

#628

I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…

Is file format copyrightable? That's a cookbook how to extract data. Is binary API copyrightable? That's a cookbook too. Is API as build target copyrightable? I just want this code to run. Is processor ISA copyrightable? I have to put gas in tank, oil in engine, water in cooling system for car to run. I have to press clutch, turn a key for engine to start. Is this copyrightable? Every thing is creative. There are man…

> Is {X} copyrightable?

Evidently yes, to the extent that {X} includes subjective properties that go beyond the fundamental function of {X}.

To use file formats as an example, the fundamental function of an archive file format is to bundle a set of otherwise-independent files together. A basic archive file format that simply concatenates file contents together (and I guess the necessary header to identify the boundaries between them) wouldn’t be copyrightable. But a more advanced format that includes an index of included files might be, since the addition of the index is a product of some artistry by someone who thought it would be a helpful convenience for users. [1]

Extended to the car example, “putting gas in tank” wouldn’t be copyrightable because no tank can function without gas. But improvements to the method of transferring that gas might be. Engaging a clutch is fundamental to the operation of a transmission and not copyrightable, but a clutch that is specially-designed to require less force might be.

The key is an interesting case though... I suppose I’d have to say that mechanism would have been copyrightable, since one could start an engine in ways other than a key (maybe a crank or a push button), or perhaps because the idea to couple the unlocking mechanism to the engine start signal was a clever idea rather than a fundamental necessity.

[1]: To my understanding, this is exactly the situation with “tar” and “zip,” though fortunately for us the “zip” format was contributed to the public domain rather than copyrighted.

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

#629

I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…

>What's worse for Google is that code has always been considered copyrightable so arguing that APIs are non-copyrightable is essentially carving out an exception for a specific type of code.

That's another aspect. API isn't code, only implementation produces executable code, API only helps ensure that those chunks of code fit together, like book's spine holds pages together and in order.

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

#630

I'm not sure why so many people here seem to be surprised by this, I got the exact same impression from the hearing. The problem for Google on the copyrightability front is that "compilations" of non-copyrightable items can be copyrightable even if the underlying items themselves are not, if the "selection, coordination, or arrangement" of those items involves sufficient creativity to be considered an "original work…

>What's worse for Google is that code has always been considered copyrightable so arguing that APIs are non-copyrightable is essentially carving out an exception for a specific type of code. That's another aspect. API isn't code, only implementation produces executable code, API only helps ensure that those chunks of code fit together, like book's spine holds pages together and in order.

If APIs are like book spine I don't know why teams are spending so much time designing and thinking about their APIs. Just slap on a "book spine" and get to writing code you procrastinating devs.
Post reply on HN