>If companies can copyright an API and block competitors from implementing it, that would be very detrimental to the industry as a whole, for the sake of a few rent seekers profiting.

The practice of writing drop-in replacements for software products is as old as the software industry, even those replacements that diminish the original product's commercial value. E.g gnu/linux vs proprietary unix.

Writing drop-in replacements may very well fall under fair use and be allowed, but this is not what happened in this particular case the court ruled on:

> It was not ... intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason.) It was not transformative in the sense of a new platform either, since other Java smartphones predated Android.

https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...

And imagine how different the world would be if Microsoft Word couldn't just read/write WordPerfect files by reverse-engineering them?

Reverse engineering a file format is different from reimplementing an API.

In what way?

The crux of re-implementing an API is that the name and structure of the replacement has to be the same otherwise it won't work as a drop in replacement. If I reverse engineer a file format I don't have to name any of my code the same as the original or structure it in the same way.

You need to structure any files you read or write to the exact same way or they won't be compatible with the other software.

File formats are directly analogous to APIs.

A file format is just an api that gets saved to the drive. Many file formats are just json/XML files in a renamed zip

Except that you don't have a copy of a file format in your code. The code you have reads and writes to the format and does not need to be a copy.

True, but there's many parts that you do have to copy into your source code:

* magic numbers at the start of the file format

* all sorts of enums that you just have to know, names and numbers and the correspondence between them

* names of data types and classes are often needed

* there are often many "standard" things that will be in both the original source and the duplicate because it's the industry standard (things like bold text in any word format or parallel constraints in cad files). They will mostly match in all programs of the same time

And that's just the beginning. You could make an argument that all of those fall under copyright. And they shouldn't. So it really isn't that far from an API.

If you copyright all those things then you aren't copyrighting the file format. You're copyrighting a bunch of code you wrote to read/write the format. Which (virtually) everyone agrees is something subject to copyright.

If you copyright the magic numbers and xml tag names, how can anyone write a competing implementation?

You can't copyright something as simple as a number or tag names.

That's literally what this case is about, the tag names on functions. The appeals court already threw out one de mininis argument.

The point is that file formats are qualitatively different than APIs. If I have a doc file that is:

<doc>

  <author>

.....

Then in my code I have a parse method:

Def parse_doc(xml)

self.Owner = Person.new(xml[:author])

....

End

And a corresponding write method.

My code is original and contains nothing written by whoever created the file format beyond short and simple tag names. It's much different than copying a class structure and method signatures.

Other than the tags, the Harmony code was completely original too, with the exception of the nine line range check code that was the only literal copying Oracle could find.

Here is the only piece of code Oracle accuses Google of copying, out of slightly under one million lines of code:

  private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
       if (fromIndex > toIndex)
            throw new IllegalArgumentException("fromIndex(" + fromIndex +
                 ") > toIndex(" + toIndex+")");
       if (fromIndex < 0) 
            throw new ArrayIndexOutOfBoundsException(fromIndex);
       if (toIndex > arrayLen) 
            throw new ArrayIndexOutOfBoundsException(toIndex);
  }

Note that of course "rangeCheck", "arrayLen", "fromIndex" and "toIndex" are part of the function signature, as is "ArrayIndexOutOfBoundsException" and "IllegalArgumentException".

I think that assessment would be stretching the definition of "file format". Neither the file nor the thing producing/consuming the file "have a copy of [the] format", since a file format is an abstract thing to which the file itself and producer/consumer adhere.

The format of the file is not (last I checked) the thing that's copyrightable; rather, it's the specific producers and consumers which are. Same deal for an API; the API itself is not (supposed) to be copyrightable, while the producers and consumers are indeed copyrightable (as is the documentation).

> Except that you don't have a copy of a file format in your code.

Except you do in many cases - there are many serialization systems out there where you describe your structures as types, and they generate the serializers for you. Just look at protobuf as one example. Is a protobuf declaration an API? If not, how is it different from any other API that declares a bunch of structs?

I haven't used protobuf so I might be mistaken here, but it's not necessary to use the same variable name. In other words, I can use date_of_birth and you can use birthdate so long as we both agree that the first item in the message is the date a person was born. So you can reverse engineer a protobuf message without creating a direct copy.

Adding schema metadata to protobuf messages is a pretty common pattern.

> Google didn't do this to be interoperable.

This is a bold claim - but I suspect your definition of "interoperable" is stricter than common usage (i.e. executable)

> There is no set of software interoperable with Android's Java runtime.

Countless 3rd party libraries are interoperable with Android - the few that aren't probably rely on sun.* - I suspect google did do this to be interoperable with 3rd party libraries as well as Java developers' mental model of where to find things.

>This is a bold claim

No it's not. Google even conceded this in court.

Regardless of why Google did this, it does offer some interoperability - you can write Java libraries that compile and work on both J2SE and Android. That is valuable.

IANAL but wouldn’t a win for Google achieve the result of amending the law? Everyone will reference Google vs Oracle when challenged. Of course if Google looses then the longer process of amending the law could ensue but that sounds like an uphill battle.

What I'm saying is that all the people who are trying to make the "but it's bad!" argument are missing the point of the courts. Courts are not there to determine whether it's good or bad, only whether it's legal or illegal. If SCOTUS rules that APIs are copyrightable, it's not because they hate the software industry, it's because our law is stupid.