He's not So Fine

I wrote about how to mitigate the disaster that is the appeal courts's decision in Oracle v. Google. Today, I'm going to cover a few more topics.

Sometimes, copyright law can have really bad side effect. It's supposed to help content creators make money from their content and that's awesome. But in the George Harrison case, he lost a copyright suit because he "subconsciously copied" another song. If this is the standard that the court is going to apply to all API design, the computer industry is screwed... luckily starting with Oracle.

We build on the shoulders of giants

Most computer software is a derivative work of some other computer software. We take someone else's design, make some changes, and it becomes our design.

It is considered good practice to use the Gang of Four's Design Patterns to write software. There's even a book about it. More accurately, there's a cottage industry of books about the design patterns.

Sadly, after the court's decision, one cannot safely use the Structure, Sequence, and Organization of Design Patterns from a copyrighted work. Why not? Well, copyright is attached to the book (I know this because I recently signed over my copyright in the second edition of Beginning Scala to Apress). So copying the design pattern, the very essence of structure, sequence, and organization, is a copyright violation. We can't use the structure, sequence, and organization we read about in copyrighted works anymore unless the copyright holder in the book explicitly grants permission. Sigh.

In fact, there is very little in computing that isn't a derivative work at the design/API level from somebody else. Scala's Actors derive from Erlang's Actors derive from Scheme. Collections libraries... mostly derive from Smalltalk. Network libraries... mostly from BSD sockets. Layers on top of Posix (who has the copyright in the SSO of Posix?) The list goes on.

Oracle is the first to be screwed

Under the 9th Circuit, copyright attaches to the Structure, Sequence, and Organization of APIs. Structure, Sequence, and Organization is actually a test for non-literal copying in software copyright cases.

So, everything in Java and in MySQL's wire API and everything in most of Oracle's ERP systems are APIs that derive from other copyrighted works.

If I were an IP litigator, I'd be warming up my pitch deck with quotes from the JCP discussing how a particular Java API should be similar to a .Net API and going to pitch Microsoft on an API infringement suit.

If I were an IP litigator, I'd be warming up my pitch deck with quotes from Oracle's ERP marketing materials about how Oracle's APIs are similar to SAP's to make it easier to migrate from SAP to Oracle and going to pitch SAP on beating the mule snot out of Oracle.

And IBM... IBM and Google have a collectively huge brain trust of folks that were the originators of the structure, sequence, and organization of most computing libraries, APIs, and paradigms. If SSO of systems, not just software, are subject to copyright, then IBM and Google have about 75% of the brains that developed what we all use today.

Once we toss in the subconscious copying of the structure, sequence, and organization of the APIs we've seen and used over the years, there will be a bonanza for the lawyers and the software industry will be screwed... at least Oracle has the most to lose in this situation... My Sweet Lord.

Sun made a ton of money off Java

Only an idiot would try to monetize a language. It's clear from Eiffel and GemStone/Smalltalk and more recently Typesafe/Scala (note that Scala is now mostly absent from Typesafe's home page) that one cannot make money from selling a language.

What Java did for Sun was make it possible in the 90s and early 2000s for Sun to sell very expensive hardware. How?

Back in the 90s, Windows boxes were inexpensive and Sun servers were very expensive. Back in the 90s, you needed at least 10 developers to put together the simplest interactive web site.

In order for Sun to sell very expensive (and worth it) servers, they needed a way for developers to write software for those servers. But it would have been cost-prohibitive to put 10 $10K Sun workstations on 10 developers' desks.

But Java's "write once, run anywhere" promise allowed developers to write web sites and test web sites on their Windows machines and then deploy to Sun's servers and have nearly identical behavior.

Sun's product was expensive, high margin servers. Sun enabled the use of its servers with Java because developers could develop on inexpensive machines and deploy to expensive machines.

This is no different than Google making search "free" and selling advertising. Or broadcast networks making their content "free" and covering the cost with advertising.

Underlying Oracle's suit is the premise that because Sun/Oracle put a lot of money into Java, there should be some direct way to monetize that effort.

But, Oracle's perspective is a pure software perspective. And, as a matter of history, one cannot monetize a language. One can monetize things around the language... and Oracle has WebLogic and many other things around Java-the-language that monetize the language. Even IBM has a competing implementation (or at least used to) of Java that IBM subsidizes because IBM has a language that runs the same on a PC and a mainframe.

Sun survived and for a time thrived because of Java. Sun would have been Silicon Graphics but for Java. Instead, Oracle acquired Sun for $5B+. This may not have been the best deal for Oracle, but Java was certainly a key driver in Sun's outcome and the cost of Java development at Sun was certainly paid many times over in hardware sales and the exit to Oracle.

What Google should do

Google should petition for an en banc re-hearing of the case. Why?

• The court erred by going to the Structure, Sequence, and Organization analysis when they could have found that copyright attached to the source code of the Java APIs. Google copied the source code (this is in the record), and thus the Structure, Sequence, and Organization analysis was unnecessary.
• The SSO analysis conflicts with the outcome in Sony because a simple machine-based reverse engineering seems to magically remove copyright even though the SSO of the resulting APIs are identical.
• The court's use of the term "Original Work" is different than the accepted industry norm relating to APIs. As a matter of fact, Sun employees typed the names and developed the specific hierarchy of the Java APIs, but the vast majority of the APIs derived Structure, Sequence, and Organization from other works. Google did not dispute that Sun/Oracle typed the source code that resulted in the Java APIs. But if APIs are subject to SSO analysis, then Google's lawyers erred in failing to dispute that the Java APIs were original work because they are not an original work under an SSO analysis.

If the EFF or Google's lawyers want me to take a look at any briefs or otherwise help with the issue, I'll be happy to. There may be a conflict, but we can discuss the potential conflict privately.