This gets into really critical concerns around APIs. If commercial product A sucks and I'm in a shop where we made our own drop in replacement that implement's A's APIs .. then we open source that drop-in replacement and put it on Github so anyone can use it, are we no violating their copyright just by implementing their API?

This can set dangerous prescient when it comes to interoperability and reverse engineering.

SQL standard and the respective certifications have to be payed for.

Before that, Oracle ripped off Chamberlin and Boyce's work. Which they should be able to do, because APIs shouldn't be copyright-able.

At least Oracle payed something back, unlike Google, ripped off Sun and then stepped on it on their dying breath.

If it wasn't for Oracle we would be stuck porting Java 6 to other languages.

That is certainly an issue if you reverse engineer anything. Google went out of their way to NOT reverse engineer it.

The issue is can a public API be copyrighted. That is the scary issue.

That is not how copyright works. You almost got it right with your comment "anyone reading the manuals to understand the BIOS was tainted and couldn't write a competitor."

Copyright protects against copying. It does not protect against independent development. Hence the clean room set up.

To the extent that it's relevant here, that appears to be untrue. This hinges on the fact that with an API, you have to match it exactly, and there's no reasonable way to argue that someone could sit down and do a clean room implementation of the Java APIs that perfectly matched all 3000 classes and all the public interfaces of all those classes.

You can do a clean room implementation of the Java Platform, but you can't do a clean room design of the Java APIs. The whole point you're trying to solve is to make something that's compatible with Java, and that requires knowing the Java APIs, i.e., it's not a clean room. If we extrapolate that back to IBM and clones, as long as the clone makers must come up with the same external API as the IBM BIOS, then this court would say that IBM absolutely could use copyright law to prohibit clones, because the clones would have to have copied the APIs -- not the code, but the names and types used in the APIs themselves, and IBM holds copyright to those names.

Coypright covers derivative works of copyright-protected works, as well as literal copies. If APIs are copyrightable, there is a very good case to be made that a reimplementation of an API implementation (not an API that serves a similar function, but an actual reimplementation) is a derivative work of the API itself.

The Copyright Act, however, is; if APIs are protected by copyright, than making a derivative work of an API is an exclusive right of the copyright owner.

Which is a key reason why there is widespread concern about the CAFCs ruling on API copyright. (OTOH, Google losing on fair use at the CAFC makes it more likely that the API copyright issue gets to the Supreme Court in this case rather than a later one, so it might be a good thing for resolving that concern.)

No literal copying of text is required for something to be a derivative work. Transforming a work implementing an API into documentation describing the API would produce a derivative work of that API, if the API is protected by copyright. Transforming that documentation of the API into another implementation of that API would also produce another derived work of the API.

I disagree. However, I am not aware of any caselaw on this point. It is an interesting logical twist you have added, but I fail to see how it must be that way in view of the fact that copyright explicitly allows clean-room type reverse engineering.

The legal status of reverse engineering is not at all clear-cut. There are many nuances depending on the circumstances, and much of it is determined by case law rather than statute. There's no clear basis for you to make claims about how this new class of copyright (on APIs) will interact with reverse engineering. However, it is much simpler to state that if APIs are a work subject to copyright, then it must be possible to make derivative works of APIs that are also subject to copyright absent any explicit exception or fair use right.

You have not at all established this point. What makes you think that the API of a reverse engineered implementation is not tainted by the copyright of the original API? It's clear that clean room reverse engineering produces an independent implementation, but it also seems clear that such a technique does not prevent the structure, sequence and organization of the original API from strongly influencing the structure, sequence and organization of the reimplementation's API.

Silly Example: you design a phone book containing all the names and phone numbers of everyone in the city. To the extent that any subjective decisions were made in the design, it is a copyrighted work. I design a phone book. If I copy yours, it is a violation of your copyright. If I collate the underlying information and then make my own phone book it is not copying, even if it looks exactly the same.

If I take your picture of a building and copy that's a copyright violation.

If I take a picture of a building from the exact same angle you did, that's not a copyright violation.

Similarly, if you copy the definitions of all functions/methods/classes/etc from one API, nobody will believe you independently came up with it.

So "add(a, b) returning the sum of the two" is probably not copyrightable by itself, but a whole namespace full of functions might be.

That's not how it works for copyright. Beyond that, how do you independently arrive at an API that you are trying to have an exact copy of? Photography is not programming. I cannot run a bunch of words through a program until it prints out some book I want and then say I arrived at it independently. You honestly need to read the copyright laws as you are missing some information.

[edit: the original premise of all this thread is IBM didn't try to copyright the BIOS API]

Your original post was about IBM not being able to copyright the PC Bios. Which is simply not true in any way shape or form. https://www.allaboutcircuits.com/news/how-compaqs-clone-comp...

Relevant portion "But one problem remained with their IBM-compatible machine. How would they recreate the IBM BIOS without breaching the copyright? Why did they need a compatible BIOS (basic input output system)? . . . Some companies, such as Eagle, copied the BIOS either by reading the IBM manual to understand which interrupt codes did what or by simply copying the hard-coded ROM chip that holds the BIOS. This breached the copyright that IBM had over the BIOS and so did not take IBM long to prevent such companies from selling more of those machines. However, there is a way to bypass these types of copyrights with the use of a “clean room”."

The API of a BIOS is not the whole thing! It just specifies the interface by which the BIOS can be called by the OS.

For a crude analogy, consider the interface specification that most modern cars adhere to: there will be a steering wheel with a certain shape, size, and position relative to the driver's seat; there will be two or three pedals, with the accelerator on the right, the brake pedal to its left, and the clutch pedal, if present, to the left of the brake; etc. etc. None of this tells you whether the car runs on gasoline, diesel, CNG, or electricity, or whether the motor is in the back or the front, how many cylinders it has, etc. — all these are implementation details that do not usually affect the interface much.

The implementation of the BIOS — the code that actually performs its various functions — is clearly copyrightable, and always has been. But the API is just the specification of what those functions are and how they can be invoked. Imagine if one car manufacturer had been able to copyright the steering wheel and pedal arrangement that we're all familiar with!

No, no, no, that is not what I said. I was talking about the API of the BIOS. The BIOS source code is, of course, copyrightable. That is why IBM was able to make it very hard for people to copy it until folks did a proper clean room. Why would I go into detail about the counter measure if it was not copyrightable? That makes no sense.

What "different way" are we talking about here? IBM asserted their copyright quite forcefully against Eagle and shut them down.

Eagle directly copied the source code of the BIOS, they were not sued for copying the API.

Blackbox testing -> API Specification -> Implementation

and

Copy API Specification -> Implementaton

In the first case, you will come up with something similar but ultimately original. In the second case you are blatantly copying someone else's work.

Copying APIs is strictly necessary for interoperability. Allowing APIs to be copyrightable encourages monopolies by legally prohibiting newcomers' software from being compatible with their competition.

It'd be like if Microsoft were allowed to sue Google Docs and Libreoffice for making their software able to open Word documents. (Except in this case the "documents" are source code.)

How can it "capture" the calls without knowing what it's capturing? It has to know that there's a windows API function called "CreateWindowEx" that takes particular parameters, otherwise how could it possibly "translate" it? And the fact that CreateWindowEx takes particular parameters is precisely the API.

Of course the implementation of that API will be different in WINE, just as Google's implementations of the Java API are different from Sun's (aside from the 9-line rangeCheck which is a separate issue). In fact it would be fair to describe what Android does as "capture the API calls and transform them into a different Dalvik API call that ends up performing the same function".

So... you're saying it needs to implement the Windows API? If APIs are copyrightable, then that's a violation of Microsoft's copyright. You've included a copy of Windows' API in WINE.

To make that more concrete: if Oracle's string concatenation function is called `String.concat` and Google's is called `String.append`, then code which calls `String.concat` isn't going to work with Google's implementation, and code which calls `String.append` isn't going to work with Oracle's implementation. It doesn't matter if the APIs are "similar" or not, they have to be _identical_ in order for code written for one system to be interoperable with the other.

So, barring this case being both heard and affirmed by the Supreme Court, this interpretation of copyright law, while potentially decisive in the outcome of the present case, isn't, substantially, law, so much as an idea of what the law might be.

But, because Oracle v. Google case had an ancillary patent question in an earlier appeal, the appeals are instead going to the Court of Appeals for the Federal Circuit. This court is really only supposed to answer patent questions. The CAFC can't set precedent in these matters, and overwhelmingly defers to the district courts' precedent. Bot for some reason they have chose to ignore all of that this time and make their own, fresh (and super weak) precedent that only applies to copyright cases with patent questions.

That is just not true. According to the well-pleaded complaint rule, the Federal Circuit had jurisdiction.

The Federal Circuit has the right to hear and decide this particular case, but they do not have the right to establish binding precedent on lower courts or other appeals courts in matters of copyright law. This has been explained to you repeatedly.

Not all types of reverse engineering is considered copying. See IBM PC BIOS cases.

That's one of the most important issues with this ruling; it effectively bans even black box reimplementations.

That is why telephone books and others things are not copyrightable. They are lists of facts. API's are lists of facts, a functional specification for use.

There are consequences if this stands and it will not be to our benefit as programmers, developers, designers, etc. Nor will it be to the benefit of society as a whole.

In other words, if it does feature the same selection and arrangement, it is a violation of copyright.

Your statement that APIs are not copyrightable is not true as well.

What if I create my own smart home server that can be a drop in replacement for some commercial product using just what I've gather from their public API? Is that infringement, when the underlying implementation is entirely my own?

It depends on how you create your server. If you go to their website, look at their API, and start typing identical code then that's not ok. It's pretty clearly copying. If you do black box testing and then write your own API that's fine. It's clearly not copying but a new original work.

Take this as an example: https://docs.us-phoenix-1.oraclecloud.com/Content/Object/Tas...

Here is an example of a potential copyright infringer copying the API for another competing service. I'd hope they acquired a license for it, otherwise.

Using this as an analogy for the API would mean anything that was part of the technical implementation could be copied but inconsequential or artistic parts couldn't. This has been interpreted to mean that the actual code is "creative", so you'd have the framework of the code but not the non-essential parts that could be different and still allow the API to work.

In Roman Law there is the principle "In dubio pro reo" (https://en.wikipedia.org/wiki/In_dubio_pro_reo), which means that if there are doubts whether the culprit is guilty or not, he/she may not be convicted.

In the US, it at least seems that something similar does, in so far as we require a unanimous vote by the jury to convict someone in a criminal trial, but a simple majority for a civil.

That's not quite right - Google adopted Apache Harmony[1] (an open source project, and if you want to attribute an organisation responsible for Harmony's success - such as it was - it would be IBM). Apache Harmony would have been 100% API compatible with Java had Sun (and later Oracle) not refused to provide the Technology Compatibility Kit (TCK).

The Android runtimes (Dalvik, then ART) never had compatibility with Java bytecode, instead, Android build-tools use(d) Java bytecode as an intermediate pipeline step; the ultimate executable had 0% compatibility with the Java runtime.

1. https://arstechnica.com/tech-policy/2016/01/android-n-switch...

There's no doubt that if it is established that APIs are subject to copyright, then someone owns copyright to the C standard library APIs. It's not old enough for copyright to have expired, and nobody has ever released the APIs to the public domain (because nobody ever seriously thought that such a thing would be necessary). Establishing API copyright as a real thing without broad fair use rights would throw into doubt the copyright ownership of a large portion of all software ever written.

People shouldn't have to write shit code cause judges are tech illiterate.

[0]: https://www.opengroup.org/openbrand/register/

https://en.wikipedia.org/wiki/Single_UNIX_Specification#Curr...

"In a closely watched 2014 decision in the dispute, the Federal Circuit said the APIs were entitled to copyright protection."

Apparently, header files (which were subject to much discussion in the case) are still a legal minefield.

Aicas, PTG, IBM, MicroEJ, ....

Big difference with Google?

They play by the rules.

Or they will be sued out of existence. Google? probably not. IBM tried Harmony play along with Apache but backed away after legal threats.

Try to sell a device that comunicates with a e.g. BTS station without buying their licenses, to see how it ends.

For the rest there is the 3GPP patent platform.

Most of the patents are the result of a lot of research and cleverness. Some of the patents are the equivalent of looking in another drawer if the first one did not contain what you are looking in.

It's a bit arbitrary that an API isn't protected when some bullshit patents are. There is clearly much thought in some of the java APIs.

I'd like to see shorter protection time for patents thought, especially in areas where there are very low investment costs, like software development.

OpenJDK is GPL. If you comply with GPL, no. This is the problem, Google copied and did not comply with the GPL. Their other option was to pay Oracle/Sun a licensing fee for a commercial license. This is exactly the business model many GPL users follow. Ruling otherwise makes this business model invalid, but it also creates a double standard.

Consider a programming language where you program in types, like Idris. The case is more obvious here. The API is a program. The same applies to Java too, but that seems less obvious. The API is the program that produces compiler output.

I thought the OpenJDK people needed certain concessions to release their VM under the GPL?

GPL users charge money for a license on the implementation, not on the API. Or do you know any charging a license for the API itself?

It was Google's misfortune that through a quirk of the system the case wound up in the Federal Circuit, which has a history of creatively ignoring precedent to fashion new precedent that increases its own importance. (Which is how we have patents on all sorts of crap that the Supreme Court has ruled that we shouldn't.) And it was good lawyering on Oracle's part to throw every possible argument at the case, including the copyright arguments that they knew they should have lost.

That's it. The VMs on the market at the time we're absolutely terrible for phones. John Carmack was commenting on how JavaME gave you worse performance than an original IBM PC, and HotSpot's strategies absolutely destroy battery life.

There are OEMs selling commercial JDKs for embedded use, with their own VM, JIT and AOT compiler variations, and library extensions.

Contrary to Google, they always played by the rules.

Java still exists today thanks Oracle, not Google.

They also offer customized versions fine tuned for their deployment scenarios, doing Java bytecode to either native (AOT) or their own proprietary bytecode format when generating the firmware image.

Or for example, IBM Java running on IBM i mainframe, where Java bytecodes used to be translated into the TIMI bytecodes, just like any other IBM i application.

Firmware does not change during runtime.

Nokia and Sony-Ericsson flagship phones were quite good.

So one either swims or joins the graveyard of companies that tried to fight it.

I'd argue that it's next to impossible. OSes are a commodity now. Even Microsoft is coming around to that idea.

> tech unlawfully taken from other companies.

All of the previous caselaw said that this was fine.

When you create your own USB cable, or electric plug, you aren't copying the API specs, you're implementing them.

I'm not worried about Google in the least, I am however concerned about the precedent this sets.

Licensing costs can scale according to the customers business size and revenue. What is more concerning is that this may create precedent that API specs are copyrightable -- to the degree they are worth billions in damages.

I think some people in this thread are minimizing the issue because they don't like Google but I think it's naive and short-sighted. It's not about Google or Oracle, it's about copyrighting APIs.

It's legal precedential value is limited, because it was a copyright decision in the Court of Appeals for the Federal Circuit (CAFC).

The general principle for a precedent is that precedent for court X is set by the appeals court that hears appeals from X, and the appeals court that hears appeals from that appeals court, and so on.

So, for example, the district courts in the 9th Circuit (which covers the west coast tech companies) gets precedent from the Court of Appeals for the 9th Circuit, and from the Supreme Court. In particular, this is the appeals path for copyright cases.

The appeals path changes for a few special subjects. Patent appeals from all of the Federal district courts, for example, go to CAFC. So, in matters of patents, a district court in the 9th district would look to CAFC for patent precedent, not the 9th circuit appeals court.

Oracle sued Google for both copyright infringement and patent infringement. The parties were OK enough with the outcome of the patent part of the case that no one appealed that, but the copyright decision was appealed.

You might expect that this means the appeal would go to the appeals court for the 9th Circuit, because only copyright issues were being appealed, but that's not how it works. Where the appeal goes is decided by what was at issue in the original case, not by what was at issue in the appeal.

The rule is that if a case has both a special subject, such as patents, that points to CAFC, and other subjects, such as copyright, that point to the appeals court for the circuit the district court is in, the appeal goes to CAFC. CAFC handles the whole thing.

When CAFC gets a subject that normally does not come to them, but got there because it was attached to a case that also had a subject that does go to them, the rule is that they are supposed to follow the precedent of the appeals court for the circuit the district court is in. They don't set precedent in that district.

For example, if two companies sued over copyright in the 9th Circuit, with no other issues involved that would deflect the normal appeals path away from the 9th circuit's appeals court, the district could would look to that appeals court and the Supreme Court for precedent. CAFC opinions on copyright would at most be interesting opinions it might look to for insight, just like it might look to courts of appeals for other circuits, but only it's own circuit's appeals court and the Supreme Court would be precedent it has to actually follow.

PS: I think we'd be better off if CAFC just got the patent appeals. If a case has both copyright and patent issues, send patent appeals issues to CAFC and copyright appeals issues to the circuit's appeals court. At the trial level we merge cases that would normally be in different courts into one (e.g., if a case has both state and federal issues, it goes to federal court and the federal court handles the state issues).

That makes sense at trial court level because they involve examining witnesses, examining experts, and similar. If different issues were heard in different courts, many of those witnesses would have to go to multiple courts. It could be a major hardship on them. You'd want to hold them all in the same area, at near the same time, to minimize travel. That could be hard to schedule.

Appeals courts, on the other hand, just work off the transcript from the trial. The only people needed there are the lawyers arguing the case. The lawyers for appeals are usually more specialized than trial lawyers, so there are quite possibly different lawyers handling the different issues in the appeal.

It would not be much of a hardship, if any, for different issues to go to different appeals courts, as long as a little care is taken with scheduling.

Heck, it might even be less of a hardship. Imagine you are a copyright appeals lawyer in the 9th Circuit. Normally all your appeals court appearances are in the 9th Circuit, and you have a few cases going on there. Then some stupid mixed patent/copyright case comes along, and no you've got a case on the other side of the country to deal with.

The original license for Java said you can create your own implementation just fine, so long as it was compatible with the others (or at least the benchmark one). By not doing that, Google violated the license.

"It's a bit odd to claim that somebody stole your API while at the same time complaining that they did not steal it well enough."

Not if what you want to avoid is people Embracing your API, Extending it with new special bits, and Extinguishing your version.

And specifically, use of a J2SE implementation in mobile devices may have been forbidden.

I'm not sure I follow - Google believed they didn't need a license, just like everyone who used Linux despite SCO offering to license Linux to them.

If Google needed a license, and Sun had not offered one, it would not make a difference; Google would still be liable for infringement. There's no abandonware or compulsory license provision in the laws for this. The question is whether Google needed a license, not whether Sun was willing to offer one and for what price.

Whether or not they knew that someone would come along and sue them doesn't matter if the lawsuit is unjust.

Even if Oracle is correct, and even if APIs can be copyrighted, Google's intent still doesn't matter. The only thing that matters is whether or not they infringed.

I consider this to be a form of victim blaming. You should argue the case on its own merits, not posit that Google was "asking for it."

Google had a responsibility to their shareholders and customers to do the right thing regardless of how stupid they thought the law was, and their attitude here was pretty arrogant. (To avoid beating up on Google, I should point out believing they could take on anything helped them do some work that changed the world for the better.)

Since the attitudes of parties involved in a case are often considered in judging the case, I think it's entirely fair to bring them up.

If you then turned around and argued that the hacker somehow wasn't in the wrong because of the victim's attitude, yes it would be.

Victim blaming has nothing to do with someone's responsibility to others, and everything to do with taking a conversation about whether an attack is justified, and shifting that conversation to instead suggest "well, dumb people like that deserve to be taken advantage of."

Oracle contested that Google infringed their IP. "They should have known we were gonna sue them as soon as we smelled the money" is not compelling evidence for that claim.

Much in the same way, saying "Johny should have turned off his attitude and just given us the money" is not compelling justification for a mob hit.

What's being stated here is that Google's infringement improved Oracle's market position - that fact doesn't bar Oracle from pursuing their remedy against infringement. If you steal my software for making phones chirp every time you get a tweet and widely distribute it to the point that it becomes the de-facto standard in the tweet notification market, it doesn't magically mean that I don't get to come after you for stealing my tweet tech.

Here's the decision itself. Estopple is mentioned 0 times. This isn't because Google's legal team is braindead. It's because the argument that the Google's use was authorized following them walking away mid-licensing negotiation is insane. Google's defense is based on fair use. http://www.cafc.uscourts.gov/sites/default/files/opinions-or...

Here's some old HN discussion on it: https://news.ycombinator.com/item?id=2806771

In real estate, you can own a plot of land and provide others with permissions associated with the land; maybe they're allowed to walk over a path that runs through your land. That permission is not equivalent to all possible permissions associated with the land - although maybe some ancillary ones are implied in. Maybe people are allowed to bike over the path too, but they certainly aren't allowed to dump broken washing machines there.

Similarly, in IP I can grant you a set of rights related to my product without giving you ALL rights related to my product.

https://arstechnica.com/tech-policy/2016/05/suns-jonathan-sc...

If I hand you a bag of balls and say you're allowed to play with the purple and green balls inside, I haven't given you permission to play with any of the other balls.

In this case, the different balls are the different dismemberments/rights related to Java.

[edit] Jonathan Schwartz: "The strategy was, we agree on these open APIs, then we compete on implementations."

Nothing was stolen (i.e. Oracle still has the software), it was an infringement of copyright (and perhaps patents).

So although you're correct that Google did this themselves, the alternative was fraught with problems also. Better to fight it and lose than implicitly accept the idea and pay.

This was all happening in the context of C#, which people seem to be forgetting about too. It's important to remember that the whole idea of copyrightable API was done under the argument that it was important to protect API integrity from forks. MS provided evidence of a desire to do this (as has Google to some extent since then) but then introduced C# instead.

Anyway, this is a mess because copyrightable API is ridiculous, but Google should have been more careful with cleanroom implementations.

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

Google probably had to use their implementation and J2ME was and still is a piece of shit.

Yes it was about cost, but the cost would have been far greater then the licensing price ;-)