I don't know if off-shore translation will actually solve the dilemma though. I've already discussed how simply translating the names solves nothing because whatever the heck the SSO actually is, one of the few things we know is that it is not in the names. If you change all the names you haven't changed the SSO. Therefore, if you use a simple translator, Google's new APIs will still infringe. Regardless of where the translation happens you still need to create APIs that have the same functionality as Oracle's APIs but don't have the same SSO. As long as Oracle can keep the meaning of SSO shrouded in mystery, I don't think it will be possible to build an API that has the same functionality but a different SSO.

If we try to solve the API copyright dilemma this way then we are someday (perhaps someday very soon) going to force the courts to actually compare and contrast the SSO of two different APIs that have similar functionality. It is one thing to admire the beauty of the new clothes worn by one emperor, it is a whole new kettle of fish to compare the new clothes on one emperor with the new clothes on another emperor.

One could make an argument that any API that can be machine translated from Oracle's APIs must perforce have the same SSO. This is a simple black-box approach. Although this does mark a line in the sand, it is a totally ridiculous idea and makes API copyright protection over-broad. For example if I write a translator to convert Java code to C++ code and that translator groks the core Java APIs then something in the translator or over on the C++ side would infringe on Oracle's precious API copyrights.

As I said right after Judge Alsup ruled that the SSO of APIs might be protectable by copyright, if Oracle prevails then judges and juries are going to be forced to adjudicate the SSO of APIs. This will be a Herculean task (which BS&F seem to often leave in their wake) because unlike a book where the order of the words on each page matter and the order of the pages matter, the order of the signatures (method or function declarations) don't matter in an API. Getting copyright protection on the SSO of an API would be like getting copyright protection over a phone-book such that anyone who reprints those names and phone numbers in any order will infringe your copyright.

As I've said before, it is a real shame that adults are wasting so much time and energy on such nonsense. An API has no protectable SSO. It is just a list of unprotectable declarations combined with a list of unprotectable meanings for those declarations. The order of the list is irrelevant. The organization of the list is irrelevant. The selection of what items to include in the list is important but if this is protectable then you will have API copyright violations coming out of your ears because all computer languages need to implement the same core functionality.

Here is a very simple solution for Judge Alsup. If you have a list of unprotectable things and the order of the things in that last does not matter then the list itself is unprotectable even if people use the same or similar order.

---
Our job is to remind ourselves that there are more contexts
than the one we’re in now — the one that we think is reality.
-- Alan Kay

[ Reply to This | Parent | # ]