On the last day of its term, the Supreme Court refused to hear an appeal from the Court of Appeals for the Federal Circuit, and thus it let stand a controversial copyright decision by the appellate court on the copyrightability of application program interfaces or APIs.

The case, Oracle v. Google, dates back to 2010 when Oracle (then Sun Microsystems) sued Google over use of certain Java APIs belonging to Sun that were used in Google’s Android operating system. Both Oracle and Sun agreed that Google did NOT copy Oracle’s “implementing code,” but did copy verbatim Oracle’s “declaring code.” That is, Google copied the “method headers” from 37 Java packages with over 600 classes and over 6000 methods. Google then implemented each method with its own code.

The original trial court that reviewed the lawsuit held that APIs were not subject to copyright protection. The court reasoned “there is only one way to write” the header, and thus the “merger doctrine bars anyone from claiming exclusive copyright ownership of that expression.”

OK, so what is the “merger doctrine!?”

Basically, if there is only one way to express something, say “2+2=4”, then that expression “merges” with the idea itself. And, because ideas cannot be protected by copyright, the expression cannot be copyrighted. (Note, an idea might be protectable under patent law, but not copyright law). Google also argued that, of course the method headers must be the same in Android as they are in Java in order to maintain interoperability. The trial court agreed.

But wait, there’s more! Copyright in computer code covers the literal code itself, but can also the non-literal “sequence, structure and organization,” or SSO, so long as there is some modicum of creativity in the SSO. Here, Google argued that the SSO of the 37 Java packages, 600 classes, and 6000 methods was simply a “command structure” and excluded from copyright protection. Again, the trial court agreed.

Sounds reasonable? Well, the trial court got schooled by the appellate court.

The trial court made several key mistakes in applying the merger doctrine. The trial court focused its merger analysis on the options available to Google at the time of copying, rather than on Oracle’s options at the time of creating. Looked at from the time of creation, Oracle had almost unlimited ways to determine, create, name, and express the 6000 method headers. So, as long as there are several alternative expression choices at the time of creation, the merger doctrine does not apply.

The appellate court further found the sequence structure and organization of the Java packages, classes, and methods sufficiently creative to be copyrightable. And, the court noted, Google did not need to copy verbatim the SSO to make a functionally equivalent platform, albeit not interoperable with Java. See, for example, competitive mobile platforms of Apple iOS or Microsoft Windows Phone.

The case heads back to the trial court to determine if Google’s use of the APIs nevertheless falls under the “fair use” defense doctrine. The factors the trial court will use to determine fair use are: (1) “the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;” (2) “the nature of the copyrighted work;” (3) “the amount and substantiality of the portion used in relation to the copyrighted work as a whole;” and (4) “the effect of the use upon the potential market for or value of the copyrighted work.”

Typically courts consider the “commercial nature” of the use as almost dispositive. That is, if any direct or indirect commercial gain is obtained by the use, the fair use defense does not apply. So, IMHO, I think Google will have a hard time succeeding on a fair use defense.

So, what does this mean?

The high tech sector uses, and for that matter CableLabs develops, APIs, including Java APIs, in many projects, platforms, and systems. APIs are intrinsically necessary whenever you want two software systems, platforms, or layers to communicate with each other in an interoperable manner.

The court’s ruling holds that such APIs are likely copyrightable by the creator/owner of the APIs. This means the copyright owner can enforce a copyright license on users of the APIs, or choose not to license the APIs at all. We note that many projects employ an “open source” license with very few restrictions on use, and no royalty of fee. Other projects, like Oracle’s Commercial Use License for Java, may impose fees, and require strict adherence to the APIs and a Certification program in order to maintain interoperability — maybe a good thing.

Similar to APIs, “data models” are widely used by the high tech sector. For example, data models are widely used in the burgeoning Internet of Things to generically represent anything from a light bulb to a refrigerator. It is unclear if data models are so similar to APIs that they too are copyrightable.

CableLabs plays an important role in establishing ownership and managing the associated copyrights of specific APIs and data models. Through our well-tested project creation, project management, and legal agreements, CableLabs ensures that copyright ownership vests with CableLabs (or, at a minimum, a joint ownership interest with the creator), and CableLabs can enforce such copyrights if needed. This disciplined role is especially key in the world of open source that can often become fragmented or “tainted” with multiple ownership rights that are difficult to later enforce. CableLabs will continue to foster collaborative work with our members, and suppliers, while also ensuring copyright ownership is made clear.

Jud Cary is the Deputy General Counsel at CableLabs.