Oracle gets a chance to rewrite software law

Every now and again, a court case comes along that stands to rewrite the legal rules of the computing industry -- and we might just be at such a juncture right now.

Oracle's suit against Google over Java and Android could be one such case. It's putting to the test the notion that application programming interfaces -- APIs -- can be copyrighted.

In a partial verdict today, a jury gave Oracle a hard-fought "yes" when U.S. District Judge William Alsup asked it, "As to the compilable code for the 37 Java API packages in question, taken as a group: Has Oracle proven that Google has infringed the overall structure, sequence, and organization of copyrighted works?"

Oracle's lawyers can't crack the champagne yet, though: the jury didn't answer a key follow-up question about whether Google was actually permitted to copy the technology through a doctrine called fair use, leading Google's lawyer to call for a mistrial. The jury also took Google's side on a second question concerning whether it violated Oracle's copyright on Java documentation.

Last, and perhaps most significant, although Alsup had told the jury to assume the APIs were copyrightable for purposes of their deliberation, he also said he'd rule on the matter if the jury found Google to have infringed. Finally, regardless of how the judge sorts out the muddle, an appeal seems likely.

Thus, the door remains open for Oracle to make a case that could reorder the software business.

APIs are a defined mechanism by which one program can talk to another to get something done -- everything from telling Windows to open up a new window to telling Google Maps to show where the Canary Islands are. In the Oracle case, Java programs use those APIs to call upon the services of pre-written modules called class libraries. Oracle argues that its descriptions of these APIs are copyrighted and that Google's use of them to create Android therefore is infringement; Google of course disagrees.

The case isn't likely to affect most consumers directly one way or the other. But it's a different story for programmers, including those in the particularly fast-moving new area of cloud computing. Copyrighted APIs raise the possibility of new barriers to entry in a market, new ways businesses can stave off competition, new involvement of lawyers in product development.

Intellectual-property lawyers may be fine with that future, but plenty of others shudder at the prospect, especially given how software patents, a reality since the 1990s, have resulted in infringement suits from patent "trolls" who don't have any business beyond suing deep-pocketed companies for alleged infringement.

"What will the impact be should APIs prove copyrightable? It is likely to be extensive, cascading and a lesson in unintended consequences," said Redmonk analyst Stephen O'Grady. "A decision in favor of copyrightable APIs is likely to be at least as damaging as the patent system is today."

Ripple effects
Some APIs are very simple, but collections of them can form a mechanism that lets programmers tap into a foundation for general-purpose computing. Java is one example, but there are more -- operating systems such as Windows or cloud-computing technology such as Amazon Web Services (AWS).

Cloud computing is a particularly hot market right now. It lets companies use their own servers more efficiently, and it lets start-ups quickly ramp up operations without having to spend so much on hardware and software. AWS is the powerhouse, but there are competitors including Google App Engine, VMware vCloud, Eucalyptus, Open Nebula, Nebula, OpenStack, Nimbula, Zimory, CloudScaling, and more.

Eucalyptus is an interesting case because it aims to let customers build internal systems that mirror what Amazon offers on the Internet. In March, Eucalyptus announced a partnership with Amazon, but Chief Executive Marten Mickos said he wasn't worried about infringing on Amazon intellectual property.

"We are ourselves very comfortable in our decision in 2007 to implement AWS API semantics in our open-source product. We did the implementation entirely on our own and without trespassing on anyone else's intellectual property," said Mickos, who by the way worked for Java creator Sun Microsystems for a time after it acquired the MySQL database company he previously ran. "The reason for us to enter into the deal with AWS was to speed up our API compatibility work and to address customers jointly with AWS."

Not everyone is so sanguine.

APIs are "something that takes an input and gives an output," said Ossi Niiranen, a lawyer with Linclaw in Finland. "If that's protected, then the problem arises when you try to develop an API that takes same kind of input and gives similar type of output. Then you're potentially infringing."

Amazon didn't respond to a request for comment.

If APIs should become copyrightable, a new tool could arrive to protect a business through legal action. Application developers needn't worry, but those building platforms might have to.

"It's not an issue if you're using this API provider's own platform to develop your apps. It turns into a problem when you're trying to compete with a platform," Niiranen said. "This is really relevant for those bigger companies fighting for whose platform will be No. 1."

Another interesting case is Yahoo's Flickr, which offers a very widely used API that lets programmers build mobile applications that tap into the photo-sharing service, display its photos on external Web sites, and more.

Yahoo didn't comment on whether it considers the Flickr API copyrighted, but it raises the possibility in the Flickr API terms of service: "The Flickr APIs may be protected by copyrights, trademarks, service marks, international treaties, and/or other proprietary rights and laws of the U.S. and other countries."

And API design isn't necessarily a simple matter. Take the opinion of Murat Yener, who has constructed APIs for the Eclipse Libra project.

"The API should be easy to understand and fun to code on to attract developers. The API should be consistent on naming, usage, and behaviour so the developers will feel like it's a platform," Yener said. "The API should be well designed to be able to [accommodate] future requests and changes in a friendly way -- which you usually realize after you start developing version 2."

At the heart of the API copyright matter is how much API design is an act of creativity -- whether an API is a mechanical byproduct of underlying technology on the one hand or a creative work on the other.

"What is copyrightable is creative expression," said Julie Samuels, an attorney with the Electronic Freedom Foundation "What is not [copyrightable] is functional information. The programming language is not. You can't copyright a language. It's what you make of that language."

Added Bruce Wieder of the firm Dow Lohnes, "Originality is important. If there's one way to do something, then you have a real problem whether it's copyrightable."

Intellectual property and software
You don't get too many chances to change how the courts see software. Lawsuits aren't uncommon, but every now and again, one of them changes the relationship between software and intellectual property concepts such as patents and copyrights.

One was a 1983 decision in a case in which Apple, then in its first glory years selling its Apple II computers, sued a company called Franklin whose ACE 100 computers used operating system software copied from Apple. That court concluded that software -- both the underlying source code programmers write and the resulting binaries the computer understands -- is protected by copyright.

Then in 1986, in a case between Whelan Associates and Jaslow Dental Labs, the court extended copyright protection beyond the code to to the program's' structure, sequence, and organization, or SSO. The court's analogy was that a program was like a book's words, but the SSO was like its plot, which is also protected by copyright. (Remember that term, SSO? It's what the first jury question concerned in the Oracle v. Google case.)

The Whelan decision gained clout when it was affirmed in a 1990 case pitting Lotus against Paperback Software; Paperback went out of business before it could appeal. That affirmation perhaps encouraged Lotus to sue Borland for spreadsheet software; Borland's product could run automated command sequences called macros that had originally been designed for Lotus's product. The case was once again about SSO.

Borland lost the first round but won on appeal in 1995, and Lotus' appeal of that decision failed to convince the Supreme Court. Thus was SSO hobbled.

Another big case involved Apple yet again, this time against Microsoft, which Apple accused of violating copyright by adopting in Windows elements of the Mac operating system's "look and feel." In 1992, the court rejected Apple's contention.

Even as courts defined some limits for software copyrights, though, another litigation option arrived in 1998 in the State Street Bank v. Signature Financial Group case: software patents. Where copyrights protect creative works, patents protect inventions that are new and useful. The lower court found that the software in question couldn't be patented because it was either a mathematical algorithm or a business method, but appeals court took a broader view of the federal law's title 35, section 101, which defines what is patentable as "any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof".

The appeals court rejected the lower-court ruling: "It is improper to read limitations into section 101 on the subject matter that may be patented where the legislative history indicates that Congress clearly did not intend such limitations," the court found.

Unsurprisingly, given the size and competitiveness of the software industry, many software patent lawsuits arrived afterward -- many of them brought by so-called patent trolls that own patents but that don't have a business beyond selling rights to them. Software patents also figure in the second phase of the Oracle-Google case that has just begun.

The most recent big case involving software patents came with Bilski v. Kappos, which went all the way to the Supreme Court. That court sidestepped an opportunity to reject software patents in general, with the majority opinion stating that the court "need not define further what constitutes a patentable 'process.'"

Four judges, though, added a concurring opinion that indicates that software patents don't enjoy broad support in the courts. "Patents on business methods are patents on business itself. Therefore, unlike virtually every other category of patents, they are by their very nature likely to depress the dynamism of the marketplace," the concurring opinion stated.

Copyrighted APIs
For a detailed look at the technology underlying this court case, check our FAQ about Java and Android in the Oracle-Google case. A brief version goes like this, though: Java, absorbed into Oracle with its Sun acquisition in 2010, lets a given program run on a multitude of devices.

To achieve that flexibility, Java comes with a "virtual machine" that adapts the Java program for the particular hardware it's running on, and it uses "class libraries" that provide a wide range of pre-built abilities so that programmers don't have to write everything from scratch. To use these libraries, Java programs rely on each library's API. A group of organizations called the Java Community Process defined these libraries and their APIs, but Sun kept copyright to the documentation that describes what the APIs do.

For Android, Google wanted a running start so programmers could write Android apps as soon as possible, so it had long discussions about licensing Java from Sun. The companies couldn't agree to terms, though, and Google decided on a programming approach that was closely akin to Java. Google didn't use Sun's Java source code (except for a nine-line tidbit that Google admitted shouldn't have made its way in), the Java brand, or the test kit that ensures Java foundations are compatible so that Java programs will run.

Google built its own virtual machine, called Dalvik, and for the necessary class libraries, it relied on "clean-room" work to reproduce the software and on an open-source project called Harmony attempting to reproduce the Java environment. In all, it used 37 of Java's APIs.

Sun objected to Google's Java approach, but it didn't sue. But Oracle did, in August 2010.

Oracle argues that the APIs, not just its versions of the software itself, are copyrighted.

"The APIs are a detailed, intricate blueprint that is the product of over a decade of development work," Oracle argued in one brief. "The APIs at issue are far more creative than the pieces of source code Google hired contractors to write over a period of months, when Google re-implemented the Java APIs according to the design it copied."

Oracle also argued that in order to read the API documentation, Google needed to agree to particular conditions -- for example, that it maintain compatibility with Java (Android does not) and that it use the Java Technology Compatibility Kit (TCK) to prove it (Google did not).

Google disagrees, as it wrote in one brief:

The APIs are merely the medium through which Java language developers express themselves. Here, with all due respect to Marshall McLuhan, the medium is not the message. It is a system that can be used to express. And a system, by definition, is outside the realm of copyright protection.

Google also argued that its use of the Java APIs was "transformative," meaning that it created something new and not merely derivative out of Java. Transformation is one way that a work can be protected from copyright infringement claim under the fair use provisions. Android's Java-like foundation includes APIs that Java does not, and Java includes APIs that Android does not. In addition, Android includes lower-level software such as a Linux kernel to interface with smartphone hardware and higher-level software such as utilities to keep track of contacts and synchronize calendars.

The APIs come up in two ways in the trial. First are the libraries themselves to which Oracle holds copyright, which the judge calls "compilable code." Second is the documentation describing the APIs, including comments in Java library source code and specification details.

The trial puts the API copyright question to the test through a two-step process. Alsup effectively told jurors to assume Oracle's view of the situation is correct. The finding that Google infringed copyright with regard to the APIs means that the judge -- assuming he doesn't grant Google's motion for a mistrial and that he chooses to go ahead even though the jurors didn't decide whether Google's copying was permitted -- will himself decide whether the APIs are copyrightable. A jury decision that there wasn't infringement would have meant that Alsup could have left the question open.

"Copyright never protects any procedure, process, system, method of operation, concept, principle, or discovery," Alsop explained to jurors. "For purposes of your deliberations, however, I instruct you that the copyrights in question do cover the structure, sequence, and organization [SSO] of the compilable code."

"It's a smart way to do it on the judge's part," said Ed Walsh, an intellectual property attorney with Wolf Greenfield. "If the jury says there was no copying, he gets to punt on the whole thing. If they say there was, he gets to decide on that."

Leaving the matter to the judge is preferable, Niiranen said: "It's very much a legal issue and and not really an issue of fact. It will most likely it will be appealed."

The irony
The case poses some ironies for students of the computing industry. Sun, often playing the role of feisty underdog to Microsoft, espoused software with open interfaces that let customers swap out one company's products for another's -- a virtue co-founder Scott McNealy and former CEO extolled as a "low barrier to exit."

Although Sun advocated standards that could ease interoperability, though, it didn't exactly apply them to Java. In the 1990s, it backed out of a plan to standardize Java through a standards group called ECMA, a route that Microsoft eventually did take with its Java rival .Net.

McNealy came to Oracle's defense, but his successor, Jonathan Schwartz, who was in charge during the Google discussions, ultimately chose not to fight Google. That doesn't mean he was happy with Google's choice. After Java father James Gosling opined that "Google totally slimed Sun," Schwartz tweeted, "Goog slimed Sun w/Harmony. Like Orcl slimed Sun w/ #Linux, then slimed #RedHat w/OEL [Oracle Enterprise Linux]. Capitalism's so inconvenient."

Changing his position now would hardly reflect well on his decisions while Sun was negotiating with Google, though. At the same time that Google and Oracle were wrestling over Java licensing, Sun's business was struggling after the financial crisis blasted its prime customer base, financial services firms. Sun didn't have much time and money to fight Google, but yielding meant Google didn't have to send any checks to Sun.

A further irony: Android was founded to counter Microsoft, but if Google were to take the extreme step of scrapping Java -- something it threatened in discussions with Sun -- .Net and accompanying C# language could be a viable replacement. That's because Apple actually emerged as the dominant mobile technology company. There's even a conveniently available open-source implementation of .Net called Mono, with more permissive licensing than Java.

Embracing .Net would require a top-to-bottom overhaul of Android and its developer community, though, so don't expect it.

At the request of Google co-founders Larry Page and Sergey Brin, Google's Tim Lindholm looked for "technical alternatives to Java," but in a 2010 memo, he concluded, "We've been over a bunch of these, and think they all suck."

Now, with Microsoft a mobile underdog and Oracle a potentially very expensive thorn in Google's side, maybe .Net doesn't look so unpleasant.

Here's the jury's verdict in Oracle v. Google (copyright phase):