While waiting for an apparently hung jury to reach unanimity or render a partial verdict if that's what Judge Alsup decides, I'd like to address the misinformation that some people -- mostly because they're uninformed and misguided -- are spreading these days about "industry practice" in connection with the copyrightability of APIs.
It's not impossible, but it isn't trivial, to analyze "industry practice" in connection with the concept of copyrightability. It's easier to look at industry practice in connection with what an industry actually does (such as how willing it is to indemnify customers in a given scenario) than with what an industry thinks about a question like copyrightability.
Those commentators who most vocally claim to know what "industry practice" is don't even have a commercial software industry background (by contrast, I have negotiated numerous software license deals since the late 1980s and advised one of the most successful open source startups, MySQL AB, which was later acquired by Sun). At any rate, those commentators get things wrong. There are overwhelming signs that the commercial software industry and even many key contributors to open source projects like Linux have for a long time had an "all rights reserved" approach to API copyrightability. If it's hard to find examples of enforcement, that doesn't mean that there's no basis for it. Most IP issues are resolved before anyone files suit, and no one disregarded other people's IP in APIs to the extent Google does, so previously there wasn't even a comparable need for enforcement.
I will address this issue in a structure way, but before I do, let me just show you one slide -- page 77 of Oracle's opening presentation -- showing that Android chief Andy Rubin himself knew all along that Sun claimed copyright on the Java APIs:
Let's define "copyrightability" the right way
One mistake commonly found in some of the comments on API copyrightability is that the term itself is, purposely or for lack of better knowledge, misinterpreted.
If something is "copyrightable", it means that it can be copyrighted (meaning that it's not categorically excluded from copyright protection), not that it must be copyrighted in 100% of all cases. The word "copyrightability" is the noun for "the state of being copyrightable", not for "the state of being definitively copyrighted", which would be "copyrightedness" (a word that I never heard, so I just coined it).
No one doubts that paintings are "copyrightable". But what about this one?
This is simply a blue square. I created it in a matter of seconds and can't claim copright in this because it's too trivial, chances are many other people drew a square in this shade of blue before me, and it would be insane to let anyone monopolize a square. Still paintings are copyrightable, and this includes paintings consisting of colored squares. For example, this link points to the official Guggenheim website, and you can see a picture consisting of squares, from the Josef Albers collection named "Homage to the Square". You can find another picture from that collection on Wikipedia. No one will seriously doubt that those pieces of art are unprotected only because my simple blue square isn't copyrightable.
On Tuesday I explained that the structure, sequence and organization (SS&O) of computer programs, including APIs, have been copyrightable in the Ninth Circuit (which includes California) for more than 22 years under the legal principle stated in the Johnson Control v. Phoenix Control Systems ruling. That's absolutely correct. It's 100% correct, even if not 100% of all people want to admit it or have the ability to understand that it's correct. Nothing is changed about that by the fact that the appeals court evaluated a motion for a preliminary injunction: the appeals court took a definitive position on a legal principle that applies to all cases, and the principle is that not only the literal elements of a computer program but also its SS&O are copyrightable. Nothing is changed about that by the later Supreme Court decision known as Feist v. Rural. Much to the contrary, the Feist decision upheld the concept that non-literal elements of a computer program are copyrightable and pointed out that the non-literal elements must meet the originality criterion, but a minimum level (or "spark") of creativity is sufficient for that purpose. That's a ringing endorsement of the Johnson Controls logic. So there are some incompetent and/or dishonest people out there you shouldn't trust. They can accuse me of bias, but if I had to be afraid of that accusation, why would I be as transparent as I am? Because I'm comfortable being judged by the substance of what I actually say.
Getting back to the paintings consisting of squares, the Java APIs are far more creative than most paintings -- they're huge and would fill an entire museum if printed out. Obviously that's a different field: creativity in software design is different from creativity in the fine arts. But the principle for copyrightability applies: there must be a "spark" of creativity, which is lacking from my blue square but undoubtedly found in Josef Albers' "Homage to the Square" series.
For a recap in a nutshell, copyrightability means that something can be copyrighted if it meets other criteria (especially originality): neither are APIs guaranteed to be copyrighted just by virtue of being APIs nor are they categorically excluded from copyright protection just because they're APIs. It depends on those other criteria.
Judge Alsup has in recent days asked the parties' counsel some additional questions with a view to SS&O copyrightability, and those questions show that he tries hard to understand what kind of originality and creativity went into the creation of the Java APIs (as opposed to non-creative elements dictated by technical requirements).
In the whole debate, it often happens that people raise issues that are separate from the question of API copyrightability, such as fair use considerations or other theories, and have to be addressed subsequently, not simultaneously. But let's not get into that now because this here was just meant to lay a necessary foundation for the discussion of "industry practice" in connection with API copyrightability. Using the proper definition I just discussed, the question for "industry practice" must be whether the actions and statements of industry players suggested that the SS&O of APIs are categorically excluded from copyright protection or whether the SS&O of APIs are at least potentially subject to copyright protection, depending on the specifics of each case.
All rights reserved: copyright notices on APIs
API specifications, such as source code files consisting exclusively of API definitions, typically come with copyright notices. By attaching a copyright notice to something, an author can't lower the bar for copyright protection: all requirements, such as originality, are still the same. But here we're talking about what the industry at large thinks. And in the software industry, it's hard to find code files without a copyright notice.
The screenshot I showed further above proves that even Andy Rubin was full well aware of the copyright Sun claimed in its APIs. In addition, Rubin had to admit in one of his depositions that his previous company, DANGER, which also did a mobile platform, took a license from Sun that included a license to the Java APIs. I'll talk about license agreements in the next section.
Here's another slide from an Oracle presentation to the jury (slide 63 of Oracle's closing presentation on copyright), and you can see that Bob Lee, Google's former lead developer for the Android libraries, affirmatively said that he saw the copyright notices on the Java APIs:
Last year I looked in detail at the Linux API, and quite interestingly, there are copyright notices in a number of Linux API files, even though the maintainers of the Linux project, including Linus Torvalds himself, have a rather liberal attitude toward how those files may ultimately be used by third parties.
But in all those 25+ years in the industry, I've never ever seen an API code file that contained an author's non-copyrightability notice.
The first time I ever saw a denial of copyrightability in connection with APIs was -- which is not a coincidence -- when I looked at Google's highly questionable use of Linux API material in Android. Countless API files in Android contain the following notice:
"This header was automatically generated from a Linux kernel header of the same name, to make information necessary for userspace to call into the kernel available to libc. It contains only constants, structures, and macros generated from the original header, and thus, contains no copyrightable information."
Again, nobody else did this before Google. Google departed from the established industry practice of attaching copyright notices to API files by doing the very opposite and replacing even existing copyright notices with a (legally erroneous) non-copyrightability claim.
Oracle's lawsuit against Google is perfectly consistent with the industry's (including Sun's) practice of claiming copyright in APIs. What Google and some of its supporters in the public debate claim is a total departure -- in fact, a 180-degree turnaround -- from that practice. Oddly, those who want a fundamental change claim that the court's confirmation of established practice would constitute major change.
License agreements: comprehensive licenses and API licenses
Like I said before, I've negotiated numerous software license agreements over the last 20+ years. In general, both parties to a license agreement -- the licensor and the licensee -- are interested in a comprehensive definition of the rights involved. As a result, software license agreements typically list all sorts of intellectual property rights. For example, I negotiated many software license agreements that listed "patents" even in cases in which the licensor didn't hold any since he might have filed or acquired some later on or could have been acquired by a company that previously held such patents.
In most cases, software license agreements cover all components of a complete product. In that case, there's simply no need to address the scenario of someone using only the APIs: they're part of the package, which can be used subject to the terms of the agreement, and if someone used them without a license, it would be an infringement because the license covers only the product as a whole. Most commercial software license agreements don't allow any modifications and "clean-room implementations" anyway.
Open source licenses are more liberal, but in Google's case, they don't apply (for the reasons I explained in this recent post). But even if someone puts an API under an open source license, that is a clear expression of the belief that the API is coprightable: something that isn't copyrightable can't be put under any license, no matter how restrictive or liberal the license may be, any more than one can nail together water.
The only way that any license agreement could declare something non-copyrightable is by saying so, not by putting something under a permissive, liberal license. And I've never seen any author do that.
Now let's talk about licenses that don't cover entire software products but instead relate to APIs. It's hard to find examples in which APIs can be licensed separately from a complete product, but Java is such an example. And in Java's case the situation is crystal clear: even Andy Rubin had to admit that he once took (at DANGER, not at Google) a license that included a license to the APIs, and he was always aware of the fact that Sun believed even "clean-room implementations" needed a license.
Not surprisingly, industry practice relating to copyright notices is perfectly consistent with industry practice relating to license agreements.
Actual use of APIs
Even if (contrary to what is actually the case) everyone used APIs as if they weren't protected by any intellectual property rights, that still wouldn't mean that everyone believes they aren't copyrightable: it could simply be attributable in all (or almost all) of those cases to other assumptions, such as the belief that license agreements allow a particular form of use or that it's "fair use", which is a separate question from copyrightability.
There is a way in which every programmer uses APIs without usually thinking about legal implications: if you write a program (an application) for an operating system like Windows or Linux, you will most likely compile some of the operating system's API material into your own application. Still the maker of the operating system won't go after you for a copyright violation just because of this way to use APIs. In this case, you simply do what the APIs are supposed to enable you to do.
Google's use of the Linux and Java APIs in Android is, however, fundamentally different. Google doesn't just create applications. Instead, it creates -- and distributes -- alternative platforms that aren't fully compatible. You can't take an Android app and run it on non-Android Linux. You can't take an Android app and run it on non-Android Java.
If you build a Linux or Windows application, the result is something can be used in conjunction with Linux or Windows, but you don't create an alternative system and you don't redistribute modified versions of those third-party APIs as part of what you make available. You just use what you need to use in order to make your application work.
In the Java community, it was accepted for a long time that a "clean-room implementation" of Java still required a license -- and that license agreement also related to the APIs and came with a requirement to stay 100% compatible.
Considering the enormous success of Android, no company has ever "hijacked" APIs on the scope and scale that Google has done it to Linux and Java. But I'm not even aware of any smaller-scale attempts to use API material in order to redistribute incompatible APIs.
To the extent that Google points to such initiatives as GNU Classpath, the fact that Sun didn't sue the GNU Foundation (or Apache for the non-licensed Harmony project) doesn't mean much either. By not suing, a company doesn't give up its copyrights. So far, no one has really sued open source projects. Sometimes those projects don't even correspond to legal entities you can sue but consist of individual developers. Now imagine the negative publicity a company would get for suing individual programmers (a patent troll named Lodsys did that last year, and is still doing so). Even a lawsuit against a non-profit foundation like GNU, Apache or Mozilla (though some of those foundations have greater financial resources than many companies) wouldn't look good. Commercial software companies typically let those open source foundations and projects do a lot of things that they don't accept if another commercial entity does them, especially if it does them on a large scale.
For example, here's a letter that Yahoo! sent to Facebook a couple of weeks ago. It claims that 16 Yahoo! patents may be infringed by Facebook's server infrastructure. Facebook's server software mostly consists of open source components, and if those patents read on anything runing on Facebook's server, that's most likely the open source stuff running there. Yahoo! targets Facebook, a commercial entity -- not the open source foundations or the individual open source programmers involved with the creation of those technologies.
I challenge all those who claim that treating APIs as unprotectable material is "industry practice" to provide actual examples of Google-style disregard for intellectual property in APIs. Show me the non-copyright notices that authors attach to their own code, or show me other companies than Google explicitly denying copyright through the kinds of notices Google attached to the Linux kernel headers. Show me the license agreements that state they don't relate to APIs because those aren't protected. Show me other commercial players who redistribute API material without a license. If you can come up with credible, verifiable examples, we can talk about "industry practice". But the fact that there wasn't another high-profile lawsuit over a hijacked API doesn't mean anything: there simply wasn't a need for anyone to bring such a lawsuit because no hijacked API ever reached a level of commercial significance even remotely comparable to that of Android. New types of conduct require new types of lawsuits.
If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.
Share with other professionals via LinkedIn:
