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.