Appeals Court Doesn't Understand The Difference Between Software And An API; Declares APIs Copyrightable

from the total-failure dept

We sort of expected this to happen after the appeals court for the Federal Circuit (CAFC) held its oral arguments back in December, but CAFC has now spit at basic common sense and has declared that you can copyright an API. As we noted, back when Judge William Alsup (who learned to code Java to better understand the issues in the case) ruled that APIs were not subject to copyright protection, his ruling was somewhat unique in that it was clearly directed as much at an appeals court panel who would be hearing the appeal as it was at the parties. Alsup rightly suspected that the judges on the appeal wouldn’t actually understand the issues as well as he did, and tried to break it down clearly for them. Unfortunately, the three judge CAFC panel did not pay attention. The ruling is so bad that legal scholars are suggesting that it may be as bad as the horrific ruling in the Garcia case.

It’s tragic that this case ended up before the CAFC. It shouldn’t be there. It should be before the 9th Circuit (who issued the Garcia ruling, so it’s not like they’re particularly good either…), but because this case started out as a patent lawsuit, even if the patent stuff went away early, the appeals went to CAFC. CAFC is already famous for its maximalist bent on patents, and so it’s perhaps not too surprising that it takes a similar view towards copyright. Or, as law professor James Grimmelmann astutely notes: “Is there any body of IP law that the Federal Circuit hasn’t done its best/worst to screw up?” The answer, James, may be publicity rights. But, give them a chance and we’ll see what it can do there too…

As for the ruling itself… well… it’s bad. The court seems to not understand what an API is, confusing it with software functionality. It also appears to misread Judge Alsup’s ruling, thinking that he’s mistakenly using a fair use analysis to determine whether or not something is copyrightable. But that was not the basis of Judge Alsup’s ruling. He very specifically noted that the “command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted.” The CAFC panel doesn’t seem to understand this at all. In case you’re not readily up on your Section 102 knowledge, it covers what is copyrightable subject matter, and (b) is pretty explicit:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

Got that? Well, CAFC doesn’t seem to get it. At all. They basically seem to think that because the API is “big” it must therefore be copyrightable as a “literary work” even though — as Alsup rightly pointed out — it’s nothing more than a “system or method of operation” which 102(b) clearly states is uncopyrightable. And yet, CAFC spends many pages arguing how an API is not unlike a “literary work”, ignoring its intent and purpose. CAFC argues that the various names that Sun/Oracle used for naming things in the API are subject to copyright because they’re “creative.” Yet, as Grimmelmann against notes, if that’s the case, Brian Kernighan should sue Oracle for its “copying” of his creative choices in “int,” “short,” “long”, “float”, “double”, and “char.”

The original ruling pointed to the ruling in Lotus v. Borland, which found that pull down menus in an app weren’t copyrightable. But here, the CAFC rejects this (in part) by saying that a big difference is that the “source code” wasn’t copied. But in that case, the menu structure and names were copied — which is basically the same thing that was copied from the Java API. But the CAFC judges don’t even seem to realize that.

It seems fairly clear that the CAFC judges don’t understand the difference between an API and software. And thus they make a decision that makes no sense. There is no distinction recognized when it comes to the functionality of an API and how it’s entirely different than the purpose of the software itself. This is especially clear towards the end, in which the CAFC ruling misrepresents some discussions on whether certain functionality is best protected by patents or copyright. But the problem is that they misinterpret statements people are making about APIs, thinking that those statements were made about software as a whole. This is just a flat-out fundamental misunderstanding of what an API is, assuming that it’s just software. Take the following example:

Many of Google’s arguments, and those of some amici, appear premised on the belief that copyright is not the correct legal ground upon which to protect intellectual property rights to software programs; they opine that patent protection for such programs, with its insistence on non-obviousness, and shorter terms of protection, might be more applicable, and sufficient.

But that’s not true. No one is arguing that patents are more suitable overall for software. In fact, many in the software field have long argued the exact opposite. What they’re saying is that copyright is inappropriate for APIs — but the CAFC judges don’t seem to be able to distinguish between APIs and software. In fact, they’re so confused that they throw a bogus parenthetical “software” before “interfaces” in quoting Google:

Google argues that “[a]fter Sega, developers could no longer hope to protect [software] interfaces by copyright . . . Sega signaled that the only reliable means for protecting the functional requirements for achieving interoperability was by patenting them.”

Note that “[software]” thrown in before interfaces? Google is talking about whether APIs — “application programming interfaces” — are copyrightable. Not whether or not software is copyrightable. And yet the CAFC doesn’t even seem to realize this. Ridiculously, CAFC then uses its own misunderstanding and misquote, and points to some of the (many) arguments where people argue that patents are inappropriate for software to dismiss Google’s argument about APIs. It honestly doesn’t realize that it’s comparing two totally different things. What lots of people agree on: software shouldn’t be patentable and APIs shouldn’t be copyrightable, but software can be copyrightable and API functionality may be patentable. But by confusing APIs and software, CAFC totally misreads both arguments.

This is a disaster all around. Of course, it’s not over yet. Google can (and likely will) seek a review of this ruling, either en banc or by petitioning the Supreme Court. And even if that doesn’t happen, the CAFC ruling tosses it back down to the district court for an entirely new battle about whether or not — if the API is covered by copyright — Google’s use was fair use. So, there are still a few more years (and many more millions) to be thrown at this before there’s any real conclusion. In the meantime, CAFC has mucked up another form of intellectual property law through a basic (and near total) misunderstanding of technology.

Filed Under: , , , , ,
Companies: google, oracle, sun

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Appeals Court Doesn't Understand The Difference Between Software And An API; Declares APIs Copyrightable”

Subscribe: RSS Leave a comment
262 Comments
Anonymous Coward says:

Re: Re: Three questions

So to explain the difference further in terms non-programmers can understand, the key is in the last word of the term – INTERFACE. An API is a mechanism for software written by other programmers to interface with a particular piece of software to take advantage of it’s functionality. To drive home the point made by Judge Alsup in comparing it to the Borland case, pull down menus are a mechanism for users to interface with a particular piece of software to take advantage of it’s functionality. Judge Alsup had it correct and it went right over the heads of the CAFC judges.

Zonker says:

Re: Re: Re: Three questions

An API is like the buttons on a VCR or the controls of a motor vehicle.

To operate a VCR, everyone expects buttons to Play, Stop, Pause, Fast Forward, Rewind, Eject, and Record. This is the VCR’s interface.

To operate a car, everyone expects a steering wheel, accelerator, brake, gear shift (and clutch for manual transmission), and speedometer at a minimum. This is the car’s interface.

Imagine if Sony could have copyrighted the VCR interface or Ford had copyrighted the car interface, how would you know how to operate a VHS player or a Honda vehicle if you are only familiar with a BetaMax or a Ford? To play a video tape, do you push “Play”, “Run”, “Start”, “Begin”, “Show” or “Hi-Yo Silver”?

An API is exactly the same for computer software to communicate effectively with its host application, middle-ware platform, or operating system.

Zonker says:

Re: Re: Re:3 Three questions

There are also many unique implementations of the same API. The VCR interface is also implemented for laser disk, DVD, HD-DVD, Blue-Ray, DVR, Hulu, Netflix, Amazon, etc. Some are hardware interfaces, others are software, but they all perform the same method when you push “Play” or “Stop”.

Even IBM has their own implementation of Java with the same functionality as Oracle’s. IBM’s Java, like Google’s Android, did not copy Oracle’s code in their implementation. They use the same API though as otherwise it would be a different computer language altogether.

Loki says:

Re: Re: Re: Three questions

Alsup would have been more successful in making them understand if he’d equated APIs to Lobbyists. Lobbyists aren’t the bills written by the legacy industries they represent. Lobbyists are just the middlemen to transfer those bills to Congressmen who can attach their names to the bills and pretend the bills were their ideas (and also to help Congressmen – and other Federal officials – secure lucrative legacy industry jobs when they tire of the government).

The judges would have had no problem understanding that.

John Fenderson (profile) says:

Re: Re: Re:

You’re right, but I think this degradation goes much deeper. I think what we’re seeing if the corruption and failure of the system of checks and balances. Each of the three branches are supposed to restrain each other. They’re supposed to have disagreements, argue, interfere, and generally be a thorn in each other’s side. That happens only rarely now.

When I talk about the US government being corrupt, this is one of the corruptions I’m talking about.

Anonymous Coward says:

Re: Re: Re:

The United states absolutely insists that everything that anyone does (that could make a profit) must somehow be covered by someones monopoly. No progress is possible without some patent or other obstacle in the way to hinder it. It’s the exact opposite of free market capitalism.

Pragmatic says:

Re: Re: Re:2 Re:

You’re both right, but free market capitalism is subject to restrictions of all kinds, all the time, mostly because we human beings are naturally selfish and prone to hoarding.

Therefore:

? the market cannot regulate itself
? it can’t decide diddly squat
? it will never be truly free

We can make it more open and fair by restricting monopolies, monopsonies, and anything else that interferes in the balance between suppliers and consumers. The idea is to prevent either side from having an unfair advantage over the other.

Anonymous Coward says:

Re: Re: Re:

First, your response coimpletely evades the basis for a distinction between “software” and an API. What does “software” mean in your response? Are you using it as a synonym for applications?

Second, what should and should not be is rarely the same as what is and is not. I think there are good reasons for developers to be able to freely use APIs, but that doesn’t mean APIs are not copyrightable under the law. Judge Alsup had to stretch the law to reach his conclusion (improperly treating interoperability as an issue relevant to copyright protection, as opposed to fair use), and the Fed Circuit I think properly set the record straight based on the body of law in existence.

Anonymous Coward says:

Re: Re: Re: Re:

http://www.techdirt.com/articles/20140509/10133727178/appeals-court-doesnt-understand-difference-between-software-api-declares-apis-copyrightable.shtml#c202

This is the difference. And to tie it directly to the law. An interface for software is clearly a method of operation that is explicitly not able to be copyrighted according to the law.

Anonymous Coward says:

Re: Re: Re:2 Re:

Ugh…using the defined term in your definition is not helpful.

I know what an API is. I know what an application is. I know what an operating system is. I know what a function library is.

I would refer to all of those as various forms of “software,” and I’m wondering why others would not.

Anonymous Coward says:

Re: Re: Re:5 Re:

Oh so you are saying that the reason the word software was inserted was to distinguish a software interface from a hardware interface? I highly doubt it as hardware is really relevant to what they are talking about, doesn’t appear to be even mentioned at all there, so there doesn’t appear to be any reason whatsoever to clarify that they are not talking about an interface with hardware in a discussion that solely revolves around a software interface.

Anonymous Coward says:

Re: Re: Re:5 Re:

It’s obviously a big deal because, as you pointed out, ‘software’ can refer to many various forms of things. So by replacing a specific word with a general word to make a specific argument the court can make nonsensical conclusions, which of course they did. You’re just trying to pretend it was Mike and not the court that was doing the conflating.

Anonymous Coward says:

Re: Re: Re:6 Re:

What is the nonsensical conclusion you think they reached by referring to a “software interface” instead of an “application programming interface.”? It is clear they are not talking about implementation code. They make that so clear in the opinion, that the only way someone could possibly think otherwise is if they don’t read the opinion and take someone else’s word for it.

There is absolutely nothing in the opinion that indicates the court did not understand the difference between an implementation and an API. If anyone wants to actually read the opinion and actually point out some flaw in their description, that would be interesting. But to argue that an API is not a software interface (it is an interface between software and software, right?) is just disingenuous nitpicking…smoke and mirrors.

Adrian Lopez says:

Re: Re: Re:3 Re:

“I would refer to all of those as various forms of ‘software,’ and I’m wondering why others would not.”

APIs aren’t software. Software can present and implement an API, but the API itself is just a set of available mechanisms and commands to which the software responds. Essentially, an API is the language by which an application programmer invokes and interacts with a particular software.

Anonymous Coward says:

Re: Re: Re:6 Re:

I just figured out what he is confused about. He is confusing an API with something like a DLL. Libraries are software that have function calls that can be used. But that is different than an API. APIs just describe what the function calls are, how they are used, and what can be expected to be returned by calling them.

Anonymous Coward says:

Re: Re: Re:7 Re:

This also could be the very thing that have the judges in th CAFC confused as well. Libraries with public methods that have public methods that are published so that others can call them do implement an API. But the API is not the same thing as the library. You can, for instance, have an API that is publicly released so that it can be remotely called (ie. the Google Maps API) where there is no library that is publicly released.

Anonymous Coward says:

Re: Re: Re:5 Re:

APIs are totally software. I mean, they have code. I write APIs in the form of web services to interface with some of our software systems. There’s lots of code in there.

That’s like saying HTTP is software because you implemented a web server.

An API is an abstract concept, not software itself. Software is concrete. I write web services on a daily basis. First thing I do is design the API (which is basically looking at properties of objects in the real world and model them). For example: a sales order may be updated, so the API specifies a PUT operation on the sales order resource (in case of representational state transfer). When a software developer uses this API he or she may notice it behaves like it isn’t there, i.e. I still need to build the actual software that implements this interface.

See it like this. An API is for software what words are for understanding. If words are copyrighted communication becomes a bitch.

Of course the crux of this is that a lot of words may be a story. And stories may be copyrighted. However, like words API elements are a unordered bunch of modifiers. Only when used in a specific order in the right context they may be useful or functional and therefore becomes a creative work, just like a story.

(My English may need some improvement, critique usually welcome.)

Greetings to y’all from The Netherlands. 🙂

SF says:

Re: Re: Re:5 Re:

There is 0 code in the API itself, the API is the endpoints your software exposes. i.e:

GET /documents/{id} should return a json object with [some properties]

The wording i used to describe the API is part of the API documentation (which is and should be covered by copyright) and the code that takes the /documents/… url and generates an appropriate response is part of the implementation (also covered by copyright).

Oracle tries to claim that having API endpoints with the same names, parameters and expected results is covered as well (Which would make writing software or services that are compatible with a competitors offerings impossible)

Anonymous Coward says:

Re: Re: Re: Re:

APIs allow programs written in different programming languages, to talk to each other.

So an API is basically a language translator. For example, an API takes the English work ‘hello’ and translates it to the Spanish word ‘hola’.

So without APIs (the translator), computer software written in different languages wouldn’t be able to communicate with each other. Breaking everything!

The translator (API) isn’t creating a whole new language while performing the translations. The translator (API) is simply converting words from one pre-existing language, into another pre-existing language.

In the case of software programming language, the API is simply translating a ‘write’ call in C language, into a ‘write’ call into Java language.

Both ‘write’ calls already pre-existed in each of their respective languages. Therefore, the API itself is not creating a new programming language, and software cannot be written, compiled, or run using APIs on their own.

APIs require pre-existing programming languages in order to do anything. They’re useless on their own without pre-existing programming languages, and software that’s already been written in those pre-existing programming languages.

Anonymous Coward says:

Re: Re: Re:2 Re:

i don’t agree with this. APIs are not only for programs written in different languages to talk to each other.

APIs come in many flavors, but what they are boils down to this.

Functionality is written by one entity and they want to make that functionality available to others without giving away the code or methodology or internal workings or to just have a standardized implementation of a complex idea (for example encryption).

The way to make that functionality available to others is to publish the Application Programming Interface (API) that details what a particular method will do, what parameters are required, and what it will return. There is no software involved in publishing the API.

It is generally good software engineering practice to create an API before any functionality is developed in code. So the idea that an API is creative software is false.

Another reason it makes no sense to allow copyright on an API is so that others can improve the implementation of the APIs without having everyone who used the APIs to rewrite their code.

So in the case of something simple like searching for a word in a large text (like a book). Lets say there is a standard API for doing this and its functionality is implemented by Oracle as a web service. After thousands of other sites have taken advantage of this functionality by Oracle, Google comes up with a better and faster way to do the search.

Normally, all those who want to switch from Oracle to Google, would just have to change the domain in their configuration from http://www.oracle.com to http://www.google.com, but if APIs by themselves are copyrightable, all those people that used Oracle to do the search would have to rewrite their code to use Google’s different API.

Judges who are not technical enough to understand this should either learn about it or recuse themselves from making hugely important decisions.

madasahatter (profile) says:

Re: Re: Re:3 Re:

APIs describe the input/output interface between different programs. It promises that specific inputs will give specific outputs. It allows some to leverage the work of others to solve problems.

For example, one might want to plot a list of customer addresses on a map. There APIs that allow one to convert addresses to latitude and longitude suitable. And there are APIs that allow one to enter the lat/long and obtain a map. If you had to write all the code yourself, you will be busy for a long time. But the APIs allow to concentrate on the parts you need to do, confident that you can actually map your addresses.

Larry, Curly, and Moe do not understand this.

Anonymous Coward says:

Re: Re: Re:3 Re:

Thank you! Your explanation of APIs has helped me greatly to understand what APIs are and what they do.

What an API does, is feed inputs (commands), into the actual processing software or libraries, and then the API passes along the returned outputs (responses), it receives from the processing software or library.

The software that’s responsible for processing these API inputs and coming up with the resulting outputs, is completely separate from the the APIs themselves.

An API is nothing more than words, numbers, or symbols. No software or libraries makeup an API. None at all!

So if you copyright APIs, you’re copyrighting basic words, basic numbers, and basic symbols. Which on their own, do not form a functional software program. It’s like trying to copyright a the structure of a sentence or the structure of a math formula!

Here’s a simple example of an API in action, that hopefully judges and lawyers should be able to understand. Remember, we got into this mess because nobody has been able to dumb down the explanation of APIs far enough for non-programmers to understand them.

Let’s take a car that accepts voice commands as an example of what an API is and does.

1. I say, “start engine”. – These two spoken words are in a format and structure the API input specifications call for.

2. Voice recognition software accepts the two word API input, processes the command, then outputs the results back as an API output.

3. The car’s engine starts. – The engine starts because the the API output is in a format and structure the car’s engine control system understands.

In the middle of these two events, is the car’s voice recognition software. The voice recognition software is what’s preforming the actual computational processing of the two words I spoke. Remember, these two words ARE the API input command! That’s what makes up the API, only those two words!

The voice recognition software processes my words, and then the voice recognition software outputs an API response. The API response is in a format the car’s engine control system can understand. The engine control system is separate from the voice recognition software, and also in a different programming language from the voice recognition software.

So the voice recognition software outputs an APT response to the software that controls the engine, causing the engine control system to close an electrical relay. This forms a closed electrical circuit, which supplies a electrical current to the car’s starter motor. Turning over and starting the car’s engine.

Now, let’s say APIs are copyrightable. I go out and buy a different car that has a voice recognition system installed in it, that’s made by a different manufacturer.

I can no longer use the voice command, “start engine”, because that API structure and format has already been copyrighted, by a different voice recognition system manufacturer.

Instead of using the voice command “start engine”. I must now use the voice command “turnover engine”. If I buy another car, made by yet another manufacturer, I would have to use something different yet again. Such as, “fire engine”.

Do you see what just happened? There is no longer any voice command standardization in the automotive industry, because voice command APIs have been copyrighted.

That’s what these judges just did to the software programming industry. They killed standardization, and fragmented the whole computer industry.

Anonymous Coward says:

Re: Re: Re:4 Re:

Close. You have the right idea but are slightly off. In your example, spoken words, “start engine” are the HUMAN INTERFACE not an application interface. Let’s say the car had an API though with a function called “startEngine()” and the developer of the voice recognition software designed it such that when it recognized the spoken words “start engine” it then made the call to that function of the programming in the car to perform the task. API’s are for other software to use, not users to use. Otherwise, your example of an interface in General is spot on.

Zonker says:

Re: Re:

APIs are defined methods to be performed given certain specified inputs and returning specified outputs. For example, the plus (+) sign in mathematics is used to add the numbers on each side together. The input of 1+1 gives the output of 2. This interface may be implemented in any number of ways: software, hardware, mechanical, etc. APIs are, as Judge Alsup recognized, a method of operation independent of implementation in software or otherwise.

In fact, the whole kernel of this case is that Oracle is claiming that because Google did not use Sun/Oracle’s own (free to use) implementation of Java unchanged and in whole rather than write their own implementation of a subset of Java (just the essentials useful for mobile devices without the bloat) that Google is therefore infringing their precious API.

In other words, Google is being sued for not copying Oracle/Sun’s Java and using their own independently created subset of Java instead.

pegr (profile) says:

This has always bothered me

Software copyright is a strange thing. Copyright covers creative expressions. Now can software source code be creative? Sure! But users of software rarely, if ever, get to see the creative expression in the source code. They see the creative expression in the execution of the software. There is no exposure nor appreciation of the creativeness of the software, only the creativity in its functionality.

But without being compiled, software’s creative expression is only “appreciated” by other developers, most often, only those devs that work on the very source code in question.

So here we have a creative expression that, when used as intended, expresses no creativity within the source code (generally not available to users), but has a functionality component that may or may not be creative enough for copyright protection only when compiled and executed (within a very narrow set of circumstances such as platform, OS, etc.).

While the bar for creativity is pretty low for copyright purposes, purely functional expressions are not copyrightable. A command line version of ZIP, for instance, is not expressive in its execution in any significant way, yet it’s source code may be copyrighted. But the source (assume a proprietary implementation) isn’t distributed, so the creativity of the source is never considered by the users.

To put it another way, the derivative work of a creative expression (compiled source) may very well be uncopyrightable, as its expression is purely functional!

‘Splain that, Lucy…

Anonymous Coward says:

Re: This has always bothered me

Okay, I am sure you are trolling, but people put time and effort into creating code, and should not have to have an asshat copy it and make money at the expense of the hard working creator for 1.5 seconds of bandwith for that copy.

Patent NO Copyright… hell yes! And a reasonable one too! Copyright for Software should not last longer than a decade!

nasch (profile) says:

Re: Re: This has always bothered me

Okay, I am sure you are trolling, but people put time and effort into creating code, and should not have to have an asshat copy it and make money at the expense of the hard working creator for 1.5 seconds of bandwith for that copy.

Whether it takes time or effort to create has no bearing on whether it’s copyrightable (in the US).

Anonymous Coward says:

Re: Re: This has always bothered me

You miss the point.

The interface is not the implementation. Whatever creativity is in the original source code is not in the object code or the binary code. The object code and binary code are the result of compiler/interpreter used (based on source code language used). The output is the result of a translation and transformation of the original source into a completely different form based itself on a set of rules and associated procedures (interface).

Hence for any interaction between the program written and any other system there is a requirement for the program to obey a specific set of interface specifications.

This is where ORACLE is going to hit a brick wall. If it wins it case, they will then be in the firing line to have JAVA completely useless as the JAVA JVM must itself obey specific sets of API’s to even run on any operating system. No program is an island it exists within a coordinated environment.

These judges, by their own choices, have deluded themselves in thinking that they understand what they are making a judgement about, if they do not have any understanding of operating systems, compilers/interpreters, programming interfaces, object code, binary code and each of the other ancillary areas of computer systems and science.

Heck, it seems at times a lot of “programmers” don’t seem to have a clue – this is after being in the field for over 35 years. I have met and worked with a lot of “programmers” who write lots of code and applications but have no clue about what happens to their programs after it hits the compiler and so forth.

Pegr (profile) says:

Re: Re: This has always bothered me

Not quite. Yes, writing a book is producing the creative expression. But copyright is meaningless without consideration of its intended purpose. If you write a book but do not publish it, copyright is meaningless.

As for what people deserve wrt effort and creativity, I’m not saying software has no value or should not be protected in some way. But the current state of copyright law does not make any sense for software. Software is not a book or a movie. It should not be treated as such. Truly, the way to fix this is to rewrite copyright law to address the particulars directly instead of trying to force fit current law.

Anonymous Coward says:

Re: This is truly astonishing.

If it’s so obvious, please explain the wrongness, then.

As someone who has spent a very large amount of time researching and analyzing this particular issue, I think the Fed. Cir. opinion is correctly applying the law (and doesn’t show any signs of misunderstanding the technology).

Rather, Judge Alsup misapplied the merger doctrine and improperly treated interoperability as a consideration in determining copyright protection (rather than a potential consideration in evaluating fair use).

John Fenderson (profile) says:

Re: Re: This is truly astonishing.

The article does a reasonable job of explaining it, but here’s my take. It boils down to what an API is and is not. An API is not code, or any other written expression. It is, essentially, a method. Methods are not copyrightable.

Your turn: why do you think the court ruled correctly?

Anonymous Coward says:

Re: Re: Re: This is truly astonishing.

First, let me deal with your basis. APIs are embodied in literal source code. Actual letters and numbers. There was not dispute in this case that actual letters and numbers were copied verbatim. I have no idea how you can say there is no written expression. That wasn’t even disputed in the case.

There is an always has been a distinction between a method of operation (or a purpose, function, idea) and the literal expression of that method/purpose/function/idea. The literal expression is protectable, the idea/method/function/etc. is not, and there is a gray area in between.

If there had only been one way to write the API to perform a certain task, that would be one thing. But it was (correctly) undisputed that the API could have been written (by its original author) in many different ways while achieving the same purpose and performing the same task.

Thus, there is no merger if idea and expression (although the Ninth Circuit tends to look at that as a defense to infringement rather than a copyrightability question).

Where a number of commentators veer off course is by citing interoperability concerns. However, the law is pretty clear that merger and scenes a faire only applies when the author could only write the work in a certain way or a limited number of ways to perform a task or express an idea. It is no defense (at least not under the merger or scenese a faire doctrine) when the copyist says they had to copy in order to acheive interoperability. If that were the case, then anyone could freely create sequels, claiming they needed to copy characters and plot lines to acheive interoperability with the original.

That said, I think interoperability could be a consideration in a fair use analysis.

Anonymous Coward says:

Re: Re: Re:3 This is truly astonishing.

As I wrote below, and had to explain to an expert witness nearly 10 years ago, that doesn’t make them “methods” or “functions” for purpose of copyright law.

For example, a standard dictionary definition for “function” is “an action or use for which something is suited or designed.” That is very different than the literal text written to perform that function.

JP Jones (profile) says:

Re: Re: Re:10 This is truly astonishing.

You think adding two plus two is the same as the literal text “2+2”? Because I can certainly add two plus two without writing “2+2”!

Right, and this is a perfect example, and why the two are the same.

Here’s the thing. Let’s say I write “2+2=4” to, well, add 2+2. That statement is not covered by copyright, even though it is an expression. Anyone else can write “2+2=4” and not be in violation of copyright.

You stated earlier, however, that APIs are different because you can write them differently and get the same result. So what? I can write “2+5+2-5+3-8+5=4” and, while silly, is still not covered by copyright, even if it’s unique. Maybe nobody else would use that method to add 2+2. Maybe I was trying to make a smiley face, or use it as an artistic expression on how the fundamental truths of the world can be obfuscated by complexity. It’s irrelevant…if someone else wanted to add 2+2 they could use my method, even in their own work, and there isn’t a darn thing I can do about it (nor should there be).

An API is closer to programming languages themselves than any sort of software. If I write the code “if then ” the computer isn’t actually seeing what I wrote, it’s seeing a bunch of zeros and ones that mathematically result in the output I expect, based on the compiler and operating system.

This argument is basically that, because a program is written in Windows, and pull from Microsoft’s methods to display information, Microsoft has a copyright claim on every Windows program.

Which is silly. Which is the whole point. You can try and prove your point by saying “2+5+2-5+3-8+5=5” all you want, but you’ll still be wrong.

JEDIDIAH says:

Re: Re: Re:2 This is truly astonishing.

First, let me deal with your basis. APIs are embodied in literal source code.

Nope.

Interfaces are defined independent of source code. That is rather the point of them. In an environment that has not been completely corrupted by intellectual property maximalists, two different entities can solve the same problem using their own unique expressiveness to do it.

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

In software APIs are used to interface (interact) with the software code that implements that API.

How you interact with the software is a factual matter, not one of creativity and as such is not copyrightable.

The written expression that implements the API is covered by copyright.

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

Simply saying something is not copyrightable does not make it so. In fact, the only appellate court to deal with the issue has just said the opposite.

If you are the person creating the API, and have a range of options in how you write it, I’m not sure why you would say that is simply “factual” matter.

Anonymous Coward says:

Re: Re: Re:6 This is truly astonishing.

I’m not sure why you would say that this is simply “factual” matter

A phone number is an human-level API to the phone system. Phone numbers are factual matter, not one of creativity and as such is not copyrightable.

A mailing address is a human-level API to postal delivery systems. Mailing addresses are factual matter, not one of creativity, and as such is not copyrightable.

Domain names are a human-level and programming-level API to the Internet, particularly the Web. Domain names, while subject to trademark, are not copyrightable.

And so on.

There are plenty of things in this world that are factual matter and have a range of options in how you write it (does the phone number spell something useful? who chooses street names?).

Shall we consider dialing a phone number to be copyright infringement?

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

Domain names are actually a great example, because there is certainly room for creativity in them, despite the fact that they also serve a utilitarian purpose.

For example, the domain name onefishtwofishredfishbluefish.com may in fact be subejct to copyright protection because, despite it’s short nature, there is a significant amount of creativity contained therein.

Anonymous Coward says:

Re: Re: Re:9 This is truly astonishing.

Perhaps so, but the bar for the amount of creativity needed for copyright protection is extremely low. I actually used that example because it was used in a court opinion to show how the individual letters and words (e.g., “red” and “fish”) may not be original, but putting them together in a new and original way demonstrates creative expression.

Tim F. says:

Re: Re: Re:7 This is truly astonishing.

You’ve correctly identified a couple of non-copyrightable systems; however, you’ve failed to address the clear line that taxonomies are definitively copyrightable.

The fact that there are so many APIs not copying the Java API accomplishing the same functions demonstrates that there is a separation of the expressive from the functional in the instance of APIs.

Zonker says:

Re: Re: Re:8 This is truly astonishing.

Sure, there are plenty of different APIs out there that aren’t Java. For example: Perl, Python, Basic, C++, C#, etc. If you write code for the Python API though, it will not run correctly on Java because the APIs are different. In order for an API to be useful, it has to be clearly defined and available for programs to use.

It does not matter if you write a program for IBM Java, Sun/Oracle Java, Microsoft Java, or any other implementation of Java on Windows, Linux, Unix, OS X, Android, or iOS. In order for a program written in Java to run correctly, it must use the same Java API. If you could copyright the API, no one could write any program using your API without infringing or requiring a license, nor could anyone implement your API on new operating systems like some “FutureOS”. This is what we mean by saying that this would kill Java as a programming language.

If your API says “add(var1 integer,var2 integer) returns integer” and my API says “plus(X float,Y float) return float” then yes the two are different APIs, but I would have to code for one or the other and everything about the method would be different. At the same time, your implementation of “add” could be different than mine (use different registers, bit conversions, etc.) yet return the same “integer” result. Yours may be faster than mine, and mine may work on a different processor than yours. The creative part is the code, not the API. The API is the defined method you intend to apply to get the result you expect.

william (profile) says:

Re: Re: Re:2 This is truly astonishing.

As soon as I saw you comment that “actual letter and numbers” are copied and that THAT is written expression, I am certain that you are not really a programmer.

Look, spending years researching doesn’t make you possess actual knowledge of things you research. That’s like saying I have spent my last 10 years researching extensively on how a house is built, and knows every in and out of building a house, but have never built one, makes me an expert and you should trust me to build your next house from scatch.

I don’t want to talk about “definitions” and “dictionaries” and “meanings” with you. That’s all just words and they can be twisted. I am just going to show you.

Why should basic names and “letters and numbers” not copyrightable.

Let say you are writing a library management software. To makes things clear, you use a variable called “book” which can be grouped in a variable called “books”.

In order to do some work on it, you define a function and call it SortBooks() and pass in the books to be sorted.

Another person some along to write a different library management software, he also decides to use variable named “book” and “books” and a function called SortBooks(). WHY? because it makes sense.

Now, we claim that is copyrightable, so 2nd person can no longer do that. What’s he going to do? Name it “fish”, “fishes”, and “SortFish()”?

Now let says a company decided to make this type of software easier to create, so it created a group of functions all related to sorting books in various ways for everyone to use. In their group of functions, they also have an function to do the sorting, so they list in their interface something call “SortBooks()”, which makes logical sense to call it that. If that’s copyrightable, what could a second company call that function that does the same thing, “SortBuffalo()”?

That list of definitions listing out functions which is provided in that group of functions is call “API”.

People get so caught up in “definitions” that actual meanings are all but lost.

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

You cannot hope to apply laws (i.e., words written by legislators) without focusing on definitions and meanings.

The alternative is just doing what you think is right. That’s great for the person who decides (i.e., the dictator), but the role of judges is not to be dictators.

Anonymous Coward says:

Re: Re: Re:3 This is truly astonishing.

You are right. I am not a programmer. I don’t claim to have an in-depth knowledge of programming.

I am, however, a copyright lawyer, and it is equally apparent to me that most of the people commenting here are not copyright lawyers. I do claim to have an in-depth knowledge of copyright law.

Moreover, I’m going to go out on a limb and say that I think I have a better understanding of programming as it applies to this issue of copyright law than the commenting programmers have of copyright law as it applies to this aspect of programming. It’s possible I’m wrong there.

Anyway…your response seems to suggest that understanding programming is of vital importance when dealing with this issue of copyright law, without giving much though to understanding copyright law.

If you are going to ignore words and definitions, then you are not even trying to understand the law.

At any rate, you seem to be saying that APIs should not be covered by copyright. You might be right. But doesn’t mean the are not covered by copyright.

madasahatter (profile) says:

Re: Re: Re:4 This is truly astonishing.

So you are a shyster who is telling programmers what an API does?

The crux of the problem is an API defines the interface of inputs and outputs. It does not actually do anything. The implementation is deliberately hidden by the API and that is most definitely copyrightable. The issue Oracle is pouting about is anyone can write an implementation of the Java (or any other) API without infringing on the copyright of the underlying source code.

One of the reasons the API hides the source code is to make various parts of the program only dependent on the API not how the API is implemented. The idea is the implementation can be completely rewritten if necessary without affected (hopefully) any dependent parts of the code.

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

I am an ethical lawyer. If you think that’s synonymous with “shyster”, that’s up to you. I wan’t call you a basement-dwelling neckbeard just because you are knowledgeable about software. I don’t think I’m telling any programmers what an API does (although I am having a conversation about what APIs do).

Everyone seems to be distinguishing between the API and the implementing code as if it matters. “Doing something” is not a prerequisite for copyright protection.

Anonymous Coward says:

Re: Re: Re:6 This is truly astonishing.

You also miss the point.

API’s specify how to interact with a particular piece of code. It is a method of communicating how and what is needed to use the code in question. It is, in fact, no different to any other form of interface, whether relating to physical machines, software or communication between lawyers. Let me put in context for you, is the specification of the law copyrightable? If it is, then the law becomes not the law.

As a lawyer, you have specific skills in a very specific area. However, in this matter, you are unable to see the forest for the hole of the tree you have your head stuck in. Likewise, these judges have got their head stuck in the same tree and cannot see anything further.

You are a lawyer, hence you should also know the old adage that the law is an ass.

API’s are a purely functional/technical description of interaction, without it the source of the code in question is completely useless. Remember, the API in question is for a virtual machine for which someone is able to write their own code to interact with. That is the sole purpose for an API – the definition of interaction. It is not about creativity, it is about factual interaction.

The virtual machine itself runs within an operating system and uses the available API’s to interact with the operating system.

What ORACLE doesn’t really take cognisance of, is that if they get their interpretation set as the rule, they open themselves up to having all of their own systems attacked in like manner. Additionally, they will find that people will move away from their systems in droves because they will be now open to be legally attacked by ORACLE. If you try to warp things your way, you will have to face the consequences thereof.

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

It amazes me how many people are continuing to say that it is a lack of technical understanding (by me, or by the court) that makes this legal decision wrong, without seriously considering the possibility that their lack of legal understanding is at all relevant to determining whether a legal opinion is correctly applying the law.

william (profile) says:

Re: Re: Re:4 This is truly astonishing.

I agree that I do not understand copyright law. I only do what I know how to do, which is to write applications for people.

However, fundamentally, what is law? Well, law, as I understand it of course, is created so people could agree to work together in a state of conflict, or to define a certain framework so everyone could work together for progress.

So in the very essence of law, as I understand it, is to promote progress.

What just happened with Oracle, Google and the court, from a non-lawyer, actual worker of the field’s eye is to hinder progress, GREATLY hindering progress.

It’s a scenario in which, for example, a farmer in the field busily harvesting crop just heard some manager/boss/government/court/lawyer decided that, in order to satisfy the law, now you have to harvest while wearing a 20kg shackle, while carrying a crying baby.

This is why people has such disdain for lawyers. Make no mistake, I believe lawyers does have its place in society (my brother is a lawyer working for one of the top 3 wall street firms) But every once in a while, some really wanky things gets decided that’s so out of tune with reality by a group of people who had zero “real life” experience on what they are deciding on.

And often that decision is final.

How could we not get pissed off by lawyers and governments and courts in those cases? How could not to lose respect for people like these? How could we not starting to lose trust in governing?

Looping around, it always come back to how “The law is not working and not based in reality” and “Judges unable to admit that perhaps they are not the know-it-all they think they are”

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

Judges are not (or at least should not) be in the business of saying whether a law is good or bad (i.e., whether Congress is doing a good job or not), or advising Congress as to what they thing a better law might be. Judges are (or should be) in the business of applying the law to factual disputes.

When judges saying “copyright law says X,” they are not claiming to know what copyright law should say.

Anonymous Coward says:

Re: Re: Re:6 This is truly astonishing.

Judges are in the business of applying the law and should be able to say whether or not a law is good or bad. They are the appliers and should be seeing the consequences. To not provide feedback to the lawmakers is a failure of their duty as a judge. To twist the law should also not be their duty and that means that it behooves them to understand the consequences of their decisions for all of society not just for a special interest group that pays sufficient money to get the judgements that the SIG wants.

It is quite observable that the legal profession on the whole (including the courts) have developed an inability to see the spirit of the law and focus purely on the letter of the law (something developed over many thousands of years). I know lawyers tend to say that they only have the letter to go on, but that just says they are really only capable of manipulation not wisdom.

william (profile) says:

Re: Re: Re:6 This is truly astonishing.

I really, really, REALLY hate to bring this in the discussion.

But if judges are only in the role of applying the law, how are they different than the nazi soldiers who says they are just following orders?

See? I told you I really don’t want to bring that argument in.

I am not complaining about the roles or naccesity of law, judges or government. I am just saying that you really shouldn’t be making a decision, or “judge”, when you do not understand what you are judging about.

And in this case, it’s obviouse that the judges have no clear understanding on the issue at hand because everyone who understands how this works just had a collective facepalm so loud that you can hear it on Neptune.

Now about a judge’s impartiality… That’s a whole different can of worms…

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

People seem to be assuming that, because they don’t like the result, the people making the decision must not understand the technology.

But if you understand the role of judges, you would see that there is not much of a basis for that assumption. Their role is limited. They can’t say “I think this is a bad idea, therefore I will change the law.”

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

So in the very essence of law, as I understand it, is to promote progress.

What just happened with Oracle, Google and the court, from a non-lawyer, actual worker of the field’s eye is to hinder progress, GREATLY hindering progress.

This is an interesting argument. I’ve long argued that any copyright law that does not “promote the progress of science and the useful arts” in unconstitutional because that is the constitutionally-specified purpose of copyright. If making APIs copyrightable hinders the progress in the realm of software, I would argue that the copyright law in question in unconstitutional.

Tim F. says:

Re: Re: Re:5 This is truly astonishing.

If a judge made a decision based on what YOU think is right rather than what the law and legal precedent dictates to them they must decide, I would be far more offended… downright horrified.

i.e., I’m shocked that there’s little commentary on how bad both Alsup’s and Posner’s decisions were and how it is that they were readily overruled because they relied more on their personal views than the law to reach their decisions.

william (profile) says:

Re: Re: Re:6 This is truly astonishing.

And you are naively enough to believe that what judges decides are purely on what law and legal precedent is.

In fact, your own statement just proved that because you said “…because they relied more on their personal views than the law to reach their decisions”

So, how is the overrule not a reflection of the personal view of the higher court judge “relied more on the personal views than law”?
======================

Oh, and please don’t try to suggest that I am trying to be “above the law”

I am so sick of you people who doesn’t do the work trying to tell me how “that’s the rule of law and precedent”.

I am telling you, and open your freakin’ ears, that WHAT THEY DECIDED MAKES PEOPLE WHO DO THEIR WORK MUCH HARDER, FOR REASONS THAT DOESN’T HAVE GOOD RETURN ON THE ADDITIONAL WORK. And it’s not just me, a bunch of people who actually do this work agrees.

If this decision actually have benefits, I don’t think people would be this outraged. BUT IT DOESN’T. It just requires more effort for no return. How hard is that to understand?

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

You are incorrect even on your own terms, Mr. Copyright Lawyer – and you are embarrassing the rest of us copyright lawyers. Judge Alsup made the point crystal clear:

…the names are more than just names ? they are symbols in a command structure wherein the commands take the form

java.package.Class.method()

Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure ? a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability.

In other words, an API would be copyrightable as text, except that Section 102(b) explicitly says it’s not protectable because it is undeniably a “system [or] method of operation,” and thus categorically ineligible for copyright protection:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

17 USC 102(b) (emphasis added).

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

Three judges of the federal circuit court of appeals just denied what you claim to be undeniable, and gave a very convincing rationale.

Section 102(b) is a codification of the idea/expression dichotomy. It is not a provision that says expression cannot be protectable.

I would say it is undeniable that text = method, but yet you have denied it.

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

Not sure if you’re the same person as above, but do you ahve any response to the Federal Circuit’s reasoning for why Judge Alsup’s quote rationalie is wrong? There are really two bits. The first is that 102(b) is a codification of the idea/expression dichotomy, and literal text is not a “method” or “system” under 102(b). The second is that interoperability is irrelevant to copyrightability.

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

I’m talking about a rationale for interpretation of copyright law. Frankly, the people who work with APIs have not given me any reason to believe they care about legal interpretation. Thus far, it seems like they care about a particular result and don’t care how the court gets there.

Anonymous Coward says:

Re: Re: Re:9 This is truly astonishing.

In that case, your beef is with Congress. Assuming the judges applying the law that Congress wrote must not understand the technology if they reach a suboptimal (or “unfair” result) shows your ignorance, rather than theirs.

I don’t mean to be overly antagonistic with that comment, but the overwhelming tone of the commentary here simply ignores the distinction between correctly applying the law and reaching the best result as a matter of public policy. Many seem to think that if the result is bad as a matter of public policy, then the judges must be stupid, without even considering the possibility that the judges perfectly understand the law and the technology, but that the law written by Congress is not ideal.

Tim F. says:

Re: Re: Re:7 This is truly astonishing.

Why? I don’t find anyone arguing that there could be no other way to achieve the function of TimeZone, for example, without copying Java.

In fact, I find it completely confused and irrational to claim that the Java API is purely functional without expressiveness when there are so many APIs achieving the same functionality by independent means.

Jo?o Sousa says:

Re: Re: Re:5 This is truly astonishing.

“In other words, an API would be copyrightable as text, except that Section 102(b) explicitly says it’s not protectable because it is undeniably a “system [or] method of operation,” and thus categorically ineligible for copyright protection”

You forgot to add “by itself”, since 102(b) says that copyright protection of a work doesn’t automatically extend to components embodied in it, if they are X, Y and Z.

But Google didn’t copy an element, they copied almost the entire work.

Jo?o Sousa says:

Re: Re: Re:7 This is truly astonishing.

“They did not copy the implementation, and so did not copy the whole work.”

The Java API is separated a entity (or work), and that is supported by the fact that there are several Oracle approved implementations of the same API.

Oracle never asserted that Google had copied the JVM implementation of the Java API or any other implementation for that matter.

Anonymous Coward says:

Re: Re: Re:8 This is truly astonishing.

“Oracle never asserted that Google had copied the JVM implementation of the Java API or any other implementation for that matter.”

Yes they did. And the court found that they copied all of 9 lines of code from it, gave the the judgement for it and awarded them 0 dollars in damages.

“On May 7, 2012, the jury returned a verdict finding
that Google infringed Oracle?s copyright in the 37 Java
API packages and in the nine lines of rangeCheck code,
but returned a noninfringement verdict as to eight decompiled security files. The jury hung on Google?s fair use
defense.”

“On June 20, 2012, the district court entered final
judgment in favor of Google and against Oracle on its
claim for copyright infringement, except with respect to
the rangeCheck function and the eight decompiled files.
As to rangeCheck and the decompiled files, the court
entered judgment for Oracle and against Google in the
amount of zero dollars, per the parties? stipulation. Final
Judgment, Oracle Am., Inc. v. Google Inc., No. 3:10-cv3561 (N.D. Cal. June 20, 2012), ECF No. 1211. Oracle
timely appealed from the portion of the district court?s
final judgment entered against it and Google timely crossappealed with respect to rangeCheck and the eight decompiled files.
Because this action included patent
claims, we have jurisdiction pursuant to 28 U.S.C.”

Tim F. says:

Re: Re: Re:3 This is truly astonishing.

The decision clearly explains your concern. Obviousness or merger may explain away one example. Throw in 37 APIs with hundreds of methods and classes, all copied wholesale, when most other programmers duplicating similar functionality usually produce unique taxonomies and hierarchies of structures reveals expressive elements to the overall SSO. Attempting to deal with it at an atomic structure and then claiming that all of it cannot be copyrightable does not hold.

John Fenderson (profile) says:

Re: Re: Re:2 This is truly astonishing.

“APIs are embodied in literal source code.”

They are implemented using code, but are a distinct concept form the code itself. The code implementing an API can certainly be copyrighted — but that’s not what Oracle is claiming is being infringed. It’s claiming that the names used in the interface itself are subject to copyright. That’s pretty insane, and also devastates all modern APIs.

Anonymous Coward says:

Re: Re: Re:3 This is truly astonishing.

I think my use of “code” above was misleading (or at least is being interpreted to mean something than what I intended).

The API is embodied in literal text and in header material. So, there is certainly a literal expression aspect to it. You can argue about sufficient originality (which was not argued on appeal) or about other copyright doctrines, but saying there is no written expression or that the only copied material was a “method” or “system” is not viable when there is literal copied text.

Zonker says:

Re: Re: Re:8 This is truly astonishing.

And an API would be useless if you could not implement it without infringing it. If APIs were copyrightable (and they are not) then implementing the APIs method of operation would make that original and creative code you wrote somehow infringing. Implement another API and you’re infringing that one now. You could only ever implement your own API and no one else could ever use it without your permission, defeating its purpose entirely.

Only Sun (now Oracle) could implement Java and it would only exist on Sun (Oracle) Solaris OS.

Only AT&T (USL) could implement Unix and it would not exist on PCs (Intel i386) as BSD would have infringed.

This ruling overturns the Lotus vs. Borland ruling that developers have relied on for twenty years and well established practice in the industry and that is why developers are pissed.

Anonymous Coward says:

Re: Re: Re:9 This is truly astonishing.

Only AT&T (USL) could implement Unix and it would not exist on PCs (Intel i386) as BSD would have infringed.

United States District Judge Debevoise’s March 3, 1993 opinion (amended by March 30, 1993 opinion)

1. Copyright Infringement

Plaintiff claims that BSDI has violated Plaintiff’s copyright in the UNIX source code and, unless I enjoin further violations, BSDI’s continuing violations will irreparably harm Plaintiff. The first factor to be considered is whether Plaintiff has a reasonable probability of prevailing on the merits of this claim.

In order to prevail, Plaintiff must prove that it has a valid copyright in the UNIX code. Plaintiff’s chief difficulty here is the “publication doctrine.” The publication doctrine denies copyright protection to works which the copyright owner “publishes,” unless the owner has properly affixed a notice of copyright to the published work. This doctrine has suffered steady erosion over the years, and it now applies in full force only for works published prior to January 1, 1978. For works such as 32V (published in 1978), which were published after that date but before March 1, 1989, the doctrine is subject to the escape provisions of 17 U.S.C. ? 405(a) and the common-law “limited publication rule.” For works published after March 1, 1989, the publication doctrine has been eliminated by the Berne Convention Implementation Act, 102 Stat. 2857 (1988).?.?.?.

?

2. Trade Secret Misappropriation

?.?.?.?One fact does seem clear: the header files, filenames, and function names used by Defendants are not trade secrets.?.?.?.

(Emphasis added.)

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

Says who? Functionality is treated differently w/r/t literary works than w/r/t graphic and sculptural works.

IF you’re talking about the selection/coordination/arrangement being dictated by functional concerns, that is a relevant consideration. But the Court’s opinion has a good explanation of why that is not the case. If you disagree with the Court’s analysis, please say why.

John Fenderson (profile) says:

Re: Re: Re:4 This is truly astonishing.

Thank you, I think I’m understanding the legal argument better.

Legalities aside, this situation is potentially disastrous for the industry. This is even worse than software patents. To say that APIs are copyrightable means that it becomes impossible to write software that is interoperable. If this had been the rule before, the software industry would never have been able to accomplish what it has accomplished so far.

The entire purpose of APIs is to allow other entities to use and implement them so that software written by unrelated people can work together. Perhaps it’s been a matter of custom rather than law, but — Oracle aside, as they’ve been well-known scumbags for years — developers would never have dreamed of trying to do something like this, because it eliminates the entire purpose for having an API.

Hopefully, this will be confined to Java and not spread to anything else of importance. That’s the best outcome I can think of (and the death of Java wouldn’t be the worst thing in the world.)

Damn, do I hate copyright law today. It seems that it does nothing but harm.

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

I think most firms will want their APIs to be widely used, and won’t try to restrict people form using them unless there is some other reason to do so.

Also, there’s the potential that interoperability considerations will still win the day in the lower court on the fair use angle (and back up on appeal).

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

Usually I would agree with you, but I could see a lot of people in the industry relying on a fair use ruling on this issue. It’s taken this long to get to a ruling on this issue, I don’t think others will file a bunch of suits if it ultimately goes against Oracle. Would probably depend on the whether the opinion cites interoperability as a strong general concern, or factual issues specific to this case.

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

? saying ? that the only copied material was a “method” or “system” is not viable when there is literal copied text.

The contention that merger only applies to non-literal elements profoundly misconstrues merger.

Whether merger should have been analyzed at the point where the district court looked at it is a different point. However, there seems to be some confusion between ?copyrightability? of a work, and protectability (?copyrightability?) of elements with that work. This confusion is actually most clearly evident in Microsoft’s amicus brief. But the appellate court’s remand seems to get something very, very wrong along these lines too?if the district court is only to consider fair use and nothing else on remand.

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

Merger certainly can apply to literal elements. I mean, that’s the basic principle, right? When there are only a few ways to express an idea, the expression (whether literal or non-literal expression) is “merged” with the idea and is similarly unprotectable.

But there are two questions here. First, is the copied expression (both literal and nonliteral) merely a “method” or “system” that is unprotectable. Second, whether the copied expression is merged with an unprotectable method/system/etc.

With regard to the first, it is my contention (and that of the Federal Circuit) that literal expression cannot be considered an idea/method/function/etc under Section 102(b), because Section 102(b) simply codifies the idea/expression dichotomy. There is always a distinction between the idea and the expression in which that idea is embodied.

With regard to merger, it has long been my opinion (now confirmed by the Fed Cir) that merger must be evaluated at the time of the original author’s expression. IN other words, if the original author only had a few ways he could express the idea, then the expression is merged with the idea. Here, that was not the case (at least that’s what the Fed. Cir said and it sounds like that wasn’t seriously questioned by the lower court either). Thus, no merger.

Anonymous Coward says:

Re: Re: Re:8 This is truly astonishing.

[I]t is my contention (and that of the Federal Circuit) that literal expression cannot be considered an idea/method/function/etc under Section 102(b), because Section 102(b) simply codifies the idea/expression dichotomy.

If that truly is the Federal Circuit’s contention, then the CAFC panel fucked-up bigtime, and the Supreme Court needs to fix it. ASAP.

Note, though, that I’ve only read the CAFC opinion twice now, and only have had a chance to fully re-read Judge Alsup’s opinion below again just once. I’m going through the appellate briefs carefully, too, now.

I wasn’t paying as much attention to this case as it went along as I perhaps ought to have. Unfortunately, that means I probably won’t really get up to speed until this conversation under this article is long over.

So, all told, I’m not quite sure that the CAFC made the same obvious mistake that you appear to be making.

OldMugwump (profile) says:

Re: Re: Re:4 This is truly astonishing.

It does not matter if there is literal copied text.

17 USC 102(b):

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

Read the emphasized words.

Anonymous Coward says:

Re: Re: Re:5 This is truly astonishing.

Have you read the Fed Cir opinion? I would suggest doing so. It explains why this provision bars protection for the abstract idea or tasks performed by the written expression, but not the expression itself.

The emphasized words simply say that the idea is not protectable, regardless of the form in which the idea is embodied. They do not say that the literal expression of the idea is unprotectable.

Anonymous Coward says:

Re: Re: Re:6 This is truly astonishing.

Have you read the Fed Cir opinion?

Have you read Oracle’s reply brief at 49? The appellant, Oracle, quotes the CONTU report at 20:

The ?idea-expression identity? exception provides that copyrighted language may be copied without infringing when there is but a limited number of ways to express a given idea.

Immediately after the sentence quoted by Oracle, the CONTU report continues:

This rule is the logical extension of the fundamental principle that copyright cannot protect ideas.

The CAFC panel, while not using the phrase ?idea-expression identity? does quote Sega v Accolade (9th Cir. 1993):

In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for purposes of copyright.

That case then goes on to quote the CONTU report again at 20:

[W]hen specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.

As the CONTU report explains, section 102(b) codifies Baker v Selden (1879).

In short, no one else ?not appellant, not appellee, none of the amici, and certainly not the Federal Circuit, nor even the Ninth Circuit? no one else propounds the bullcrap that you’ve been putting out here in this subthread.

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

When expression and idea are merged, then the expression is not protectable. When expression is dictated by functional concerns, it is not protectable. HOWEVER, that is determined at the time the original author writes the later copied work.

I haven’t read Sega recently, but that quote seems to simply re-state the merger doctrine, which is irrelevant to whether something is a method/function/idea or expression in the first place.

Anonymous Coward says:

Re: Re: Re:8 This is truly astonishing.

? at the time the original author writes?

Baker v Selden (1879)

The very object of publishing a book on science or the useful arts is to communicate to the world the useful knowledge which it contains. But this object would be frustrated if the knowledge could not be used without incurring the guilt of piracy of the book. And where the art it teaches cannot be used without employing the methods and diagrams used to illustrate the book, or such as are similar to them, such methods and diagrams are to be considered as necessary incidents to the art, and given therewith to the public — not given for the purpose of publication in other works explanatory of the art, but for the purpose of practical application.?.?.?.

Recurring to the case before us, we observe that Charles Selden, by his books, explained and described a peculiar system of bookkeeping, and illustrated his method by means of ruled lines and blank columns, with proper headings on a page or on successive pages.?.?.?. The copyright of a book on bookkeeping cannot secure the exclusive right to make, sell, and use account books prepared upon the plan set forth in such book.?.?.?.

The conclusion to which we have come is that blank account books are not the subject of copyright, and that the mere copyright of Selden’s book did not confer upon him the exclusive right to make and use account books, ruled and arranged as designated by him and described and illustrated in said book.

?? necessary incidents to the art, and given therewith to the public? ?

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

That is not what he meant and you know it. I devastates all modern APIs because it sets a precedent that opens every one who attempts to use an API to build on the original software (which is the whole point of publishing an API in the first place) to being sued for doing so.

Rich Kulawiec (profile) says:

Re: Re: Re:2 This is truly astonishing.

“APIs are embodied in literal source code.”

No. They are not. They are implemented by object code which has (probably) been assembled from low-level code which has (probably) been compiled from high-level code, but they are not code.

They are specifications.

Let me give you a prominent example: Unix and Linux.

The kernels of both operating systems implement certain basic primitive functions, which are usually referred to as system calls. Some of these are open(2), write(2) and read(2) — where the “2” is a longstanding naming convention that refers to which part of the manual documents them.

As you might guess, open(2) opens files for reading or writing, write(2) writes bits and read(2) reads bits. All of these have various options and nuances, covered in detail in the manual.

But the code which implements open(2) in FreeBSD (Unix) is just about completely different than the code which implements open(2) in CentOS (Linux). Same for the others. However, since both versions of open(2) comply — or at least try to comply — with standards like POSIX, programmers can presume that their calls to open(2) will work equally well on both systems. The same is true about nearly all other system calls. It’s also largely true about the rest of the Unix and Linux API as emboddied in the main C library, the math library, and so on.

The API is not the code in Unix. It’s not the code in Linux. And it’s not the code that I could sit down tomorrow and write which would precisely replicate their functionality. The API is the specification which says things like “write(2) takes 3 arguments, and here is what they mean”.

Now the names of the functions which implement the API are the same, but surely nobody is going to be disingenuous enough to claim that naming an API that reads bytes “read” is a stunning act of intellectual creativity worthy of any kind of IP protection. (Doubly so when all kinds of prior art exists.) Moreover, the names are the same because that’s how programming is done: we don’t name functions cosine_unix_freebsd_2014_version1() in order to show their provenance, we name them cos() because that way code has a fighting chance of working across OS types and versions.

Code is merely one implementation of an API — as we so often see when APIs are written long before any code exists. And perhaps that code is covered by copyright (as the AT&T code implementing the Unix API is) but the API is not code and cannot be covered by copyright.

JarHead (profile) says:

Re: Re: Re:2 This is truly astonishing.

Maybe I’me wrong about what this, but my understanding of the case is a battle over using a particular language.

Let me illustrate. Let’s say “walking/ to walk“. According to webster it means “to move with your legs at a speed that is slower than running“. The involved procedures are (extremely simplified here):

1. Raise one leg
2. Shift balance of the body to one side (forward/backward/to the side)
3. lower the raised leg
4. Repeat 1-3 for the other leg

So the difference between API and libraries within the software dev world goes like this:

Libraries:
Walking = (from the above) Step 1, step 2, …

API:
Walking = to move with your legs at a speed that is slower than running

Now, you’ve said “The literal expression is protectable, the idea/method/function/etc. is not, and there is a gray area in between.“. And you also said “But it was (correctly) undisputed that the API could have been written (by its original author) in many different ways while achieving the same purpose and performing the same task.“.

What you’ve said applies to what “Library” is, cos it is (in terms of software dev)
1. literal expression of an operation
2. could have written/arranged another way

but it is not apply to API once it is set, cos it is
1. a definition/description
2. couldn’t have written another way as to avoid confusion.

Point 2 above is where Alsup’s interoperability kicks in. Imagine someone have a copyright/patent on the word/verb and meaning of “walk”, and can deny anyone else from using it or setup a toll on it. Everyone else who want to stay within the law then have to come up with something new every time they want to convey “walk”. This will lead to comprehension nightmare.

Hence it boils down to whether someone can copyright/patent the english language (for example, any other language apply) and preclude everyone else from using it. I dunno if someone could “legally” do it, but if it is, it’s utterly ridiculous and dangerous, not to mention defeating the purpose of having a language in the 1st place.

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

Because they created an implementation of Java.

C# (Microsofts equivalent) uses a lot of identical APIs to standard C/C++. As does Objective C (Apples equivalent).

What you’re saying is that both M$ and Apple should have avoided using standard APIs because of copyright.

Copyright has less and less relevance every day.

Anonymous Coward says:

Re: Re: Re:3 This is truly astonishing.

In terms of of the idea/expression dichotomy of copyright law they pretty much are. Determining whether something is expression or idea is only one part of determining whether something is protectable (or infringed), though.

Note that I’m not saying that anything that is expressed in letters/numbers/symbols is expression, because an idea can be expressed through such expression. But the letters/numbers/symbols are considered the “expression” in terms of copyright law.

Anonymous Coward says:

Re: Re: Re:2 This is truly astonishing.

But the term “method” and “function” can be confusing in this context. For example, many programmers might refer to a literal string of letters and symbols as a “function”, but copyright law would not consider those literal elements as a “function” for purposes of 17. U.S.C. 102(b). Rather, the term “function” used in that provision refers to a purpose, role, or task performed.

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

Something that performs a task is not the same as the task itself.

So, if a “function” performs the task of calculating the square root of a given number, copyright law will not protect that task. Someone else can write their own “function” that performs the same task. However, copyright law may protect the literal letters, symbols, and numbers that constitute that “function.”

Anonymous Coward says:

Re: Re: Re:6 This is truly astonishing.

The infringement was not based just on the organizational structure, but also the copying of literal elements.

Anyway, that’s neither here nor there with regard to the argument that APIs are just unprotectable “functions” or “methods.”

Anonymous Coward says:

Re: Re: Re:8 This is truly astonishing.

I disagree.

I mean, if you look at a table of contents, for example, it may consist of literal chapter titles and may also embody the overall structure of the work.

So, it’s possible that copying the literal chapter titles is infringement, and that copying the overal structure is infringement (or one or other other, or neither).

Anonymous Coward says:

Re: Re: Re:12 This is truly astonishing.

Potentially. You would have to show originality. In other words, you would have to show that you didn’t copy the name (so no copyright on Jacob or Diana), and that you put some modicum of creative thought into the name. Typically, the shorter the work, the more originality you will need to show.

Of course, even if the copyright is valid, that doesn’t mean you can stop copying of the name for all purposes.

Anonymous Coward says:

Re: Re: Re:7 This is truly astonishing.

Also, they didn’t copy the literal elements. The created new literal elements based on the API that behave in the same manner as the elements that the API implemented in the first place. Basically, they reverse engineered JAVA based on the API that was published for it. This is similar to the reverse engineering of CPM by the person contracted by Microsoft to create MS-DOS using the manual for CPM except THAT was a patent issue not a copyright issue, hence the reason many experts suggest that the API would be more appropriately covered by patents than copyright. However, this is a copyright claim not a patent claim. Had it been a patent claim Judge Alsup’s ruling would likely had been very different.

Togashi (profile) says:

Re: Re: Re:5 This is truly astonishing.

So, if a “function” performs the task of calculating the square root of a given number, copyright law will not protect that task. Someone else can write their own “function” that performs the same task. However, copyright law may protect the literal letters, symbols, and numbers that constitute that “function.”

This is you explicitly stating that an API is not protected.

An API is a listing of method calls that can be made, their inputs and their outputs. Using your words, the API is a list of the “tasks” you can ask the software to perform. The API may state that sqrt(x) returns the square root of x. Anyone who implements the API is saying they will take a request from you for “sqrt(x)” and return you the square root. The API says nothing of how that is done. They could use any number of languages, any number of algorithms. For all you know, when you call my implementation of the sqrt(x) function, my code could text me x and wait for me to text back the answer.

In the wording you’re using, the “function” is the implementation. Anyone can write their own code to perform that task, which can definitely be copyrightable. However, the description of the task being performed should not be.

Anonymous Coward says:

Re: Re: Re:6 This is truly astonishing.

To use your wording, the description of the task is not the same as the task. So, the task is not protected by copyright, but the description of the tasks might be, as might be the selection/coordination/arrangement of the tasks (and task descriptions).

JEDIDIAH says:

Re: Re: Re:3 This is truly astonishing.

They don’t do anything. They only define an interface. There is nothing expressive about them. You don’t even have to use the same variable names.

It’s “expressivity” on the level of a phone book.

Fred Idiot: 867-5309

You could express the arguments required for a function call the same way if you wanted to.

Someone should make a Java API to phonebook translator.

Anonymous Coward says:

Re: Re: Re:4 This is truly astonishing.

Whether something “does something” or is “expressive” is not really relevant, unless you are using “expressive” as a synonym for the level of “originality” needed to merit copyright protection.

The bar is so low for originality sufficient to merit copyright protection, though, and it wasn’t disputed on appeal.

Anonymous Coward says:

Re: Re: Re:8 This is truly astonishing.

Have you read the opinion from the Fed. Cir.? They refer to literal “declaring code” (also referred to as “declaration” or “header”) as being copied, and this was undisputed by Google.

Now, whether or not that would typically be called “code” is irrelevant. It is literal expression (as opposed to abstract idea).

While I know that many people think of headers as unprotectable by copyright law, there is not really any sound basis in the law for that.

So, if my prior use of “source code” or “code” was confusing, I apologize, but I’m basically referring to literal letters, symbols, and numbers.

Anonymous Coward says:

Re: Re: Re:9 This is truly astonishing.

While I know that many people think of headers as unprotectable by copyright law, there is not really any sound basis in the law for that.

To the best of my knowledge, the BSD litigation is the first district court decision finding headers unprotectible. Of course, that’s not binding precedent anywhere. But it was considered settled by the industry.

John Fenderson (profile) says:

This is the worst possible thing for Oracle

This is a bad thing for Oracle for two reasons. First, Oracle’s already besmirched reputation will take the biggest hit yet with this. Second, if this ruling is upheld then it will mean the death of Java as a commonly used language.

Languages covered by copyright are languages that are very nearly useless for serious development. Java brings nothing so unique to the table that it could overcome that downside.

JEDIDIAH says:

Re: This is the worst possible thing for Oracle

This problem isn’t just limited to Java. That’s the problem with a bad precedent. Oracle opened up Pandora’s box with this nonsense and the consequences could be far more damaging than they ever thought possible. Of course in their arrogance, they likely thought that they would never be on the receiving end of this kind of ruling.

John Fenderson (profile) says:

Re: Re: Re:2 This is the worst possible thing for Oracle

Yes, I understand. But Oracle’s opinion on this subject is much like asking a thief’s opinion on what counts as thievery.

In any case, if this is upheld, then Java will not remain a dominant language. Everyone will switch to one of the many alternatives that don’t come with that kind of nonsense.

Zonker says:

Re: Re: Re:4 This is the worst possible thing for Oracle

Those are licenses for Google’s implementation of Google Maps using the Google Maps API (specifically embedding the Google Maps application, hosted on Google’s servers, on your own web page).

There is nothing stopping, for example, Microsoft from coding their own maps program using Google Maps API as long as they don’t copy Google’s code (implementation).

Anonymous Coward says:

Re: Re: Re:2 This is the worst possible thing for Oracle

I have complete confidence in my sources. SCO based its allegations of infringement on a number of different things. This included copying of header material, as well as copying system calls in a manner that copied the overall selection/coordination/arrangement of the Unix operating system. Pretty analogous to this Oracle case.

Anonymous Coward says:

Re: Re: Re:3 This is the worst possible thing for Oracle

SCO based its allegations of infringement on a number of different things

I’ll be the first to admit that was extremely to difficult to pin down exactly what SCO’s claims were.

But their SSO claims had a big hole in the middle where the BSD settlement stood. And everyone knew that. Even SCO knew that.

Anonymous Coward says:

Re: Re: Re: This is the worst possible thing for Oracle

A lot of information about this case is on Grocklaw, but the claim was that Linux programmers copied text directly from various files that SCO claimed copyright over. Note, this was not a claim that they copied the API alone, but that Linux programmers actually copied text from Unix source files.

Anonymous Coward says:

Re: Re: Re:2 This is the worst possible thing for Oracle

? not a claim that they copied the API alone?

Awfully easy to forget the difference between API and ABI, especially when there’s an APA in the mix.

But, from Ryan Tibbets’ 2003 letter:

? While some application programming interfaces (?API Code?) have been made available over the years through POSIX and other open standards, the UNIX ABI Code has only been made available under copyright restrictions.?

Anonymous Coward says:

State Monopoly "Justice" For Ya...

I will not have any faith in a fair and just judicial system so long as the State holds a monopoly on the “service”.

We will continue to see illogical bullshit rulings like this so long as there is no consensual competing market in dispute resolution.

I prefer consensual relationships and voluntary exchange.

Pragmatic says:

Re: Re: Re: State Monopoly "Justice" For Ya...

Damn straight! Find me an arbitration service where there’s not an unfair advantage baked in. The fact is, if you use them a lot, and there’s competition, the one you use will be more favorable to you to stop you going to the other guy.

In any case, the state does not own a monopoly on arbitration services. It does, however, have the monopoly on enforcing the law, which it is obliged to do impartially. Arbitration services are not.

Get the profit motive out of the justice system, then we’ll see what justice looks like.

Kogi says:

I disagree

The reasoning in this article makes no sense in my opinion (also a programmer).

If you really want to use section 102 against API – then there would be no reason to not use it also against copyrighting a software which is also a system, procedure, etc..

Whether API SHOULD be copyrightable or not – the difference between API and software shouldn’t matter.

The only real difference between API and software is that API cannot be used standalone – end of story.

The API IS CODE. REALLY IT IS. It doesn’t matter that Unix API is old and was implemented by various programmers. What does it have to do with a question whether API is code? They didn’t implement the specification but just copied the CODE.

API is not just SPECIFICATION – specifications you can have in RFC, W3C etc. and guess what? Those specifications ARE protected by copyright, even though they are voluntarily allowed to be used by public. There are even some specifications that you have to pay to actually even read them!
But API is a CODE – there are some APIs that are implemented in various systems differently, but then they are different code with (almost) same specifications – that is all there is to it.
API cannot exist without a code – without a code it is called “a specification”, while with a code it is called API – that is the difference between those words. You CANNOT use specification in your code without writing a code for it, while you can use API.

Now from the theoretical point of view (not taking under consideration current IP laws):

What does it have to do with copyrights actually?
Why would a piece of hard work not be copyrightable while other piece of hard work should be? because an end-user can use it, while for the other only a programmer can use it?
A programmer is the end-user if you talk about APIs.

The reason of existence of copyrights is to provide financial compensation to people that write some valuable, easily copy-able work.

In the end – the question whether API SHOULD be copyrightable is a question whether authors of APIs should have any compensation for their work or should they work for free.

From the practical point of view – taking under consideration IP laws.
I am not an expert on USA copyright laws, but this section 102 could just as well be used against copyright of all software which is in the end a procedure in processor language, there is no way that one can find in this section a distinction between API and software. That is for sure.

Anonymous Coward says:

Re: I disagree

Well Kogi (“also a programmer”), I’m glad I don’t work with you because you don’t know your own area that well. The API should absolutely NOT be copyrightable.
The code in the software should can be (it is a specific implementation to solve a problem, it could be done many ways, in many different styles, in one of many different languages).
The API is just the interface NOT the code behind it.
The code for a function to sum integers might be:
function int Sum(int X, int Y){
return X+Y;
}

The API for this would be:
function int Sum(int X, int Y); //And hopefully a comment

Notice how there is no code in the interface (the API) just a declaration, that’s all an API is declarations showing how one can interoperate with the library/application. That’s why It shouldn’t be copyrightable. People do not really write API’s the merely expose them. A WSDL is also an API, and this might be what you should think about, as there is no code in a WSDL, just an interface description, the code that actually does ~something~ with it is all on the server and (generally) inaccessible.

Do you understand now?
This is not about the code (the software) it is about the interface to that code. (in C -as you say your a programmer- terms the “.c” file is copyrightable, the “.h” is not)

Anonymous Coward says:

An Analogy

An API is essentially a protocol. Are protocols copiable? If I wrote a paper describing the functions of a time machine for coffee lovers (assuming the document is original), could I sue someone who implements my protocol? For instance, I think there should be a coffee button. I label it “get coffee”. When you press the button, a cup of coffee comes out. Should I be able to sue someone who develops a time machine that has a button labeled “get coffee”? It sounds a lot like a “system, method of operation, [or] concept” to me, and is not protected by copyright law. On the other hand, the literal text “get coffee” does show some remarkable ingenuity…

Anonymous Coward says:

Re: An Analogy

In this analogy, I would say the actual steps taken to get the coffee are the method, and the words “get coffee” are literal expression.

Whether that literal expression (and whether the selection, coordination, and arrangement of all the other button labels) is subject to copyright protection depends on a number of things, but I don’t think being a method is one of them.

Zonker says:

Re: Re: Re: Re:

That they think that APIs are software code and not methods of operation. That you can infringe a method of operation (not copyrightable under 102(b)) with your own independently developed (and copyright protected) software implementation of that method.

How can your independently created software you have copyright on infringe someone else’s copyright when nothing was copied but the names and definition of a collection of methods?

Can you copyright the term “square root” combined with a number gives you a specific numerical result that is defined as the mathematical square root of the number provided? What if you made a collection of such defined methods grouped in a category called “Math” and listed them in alphabetical order? If your method works on decimal numbers do I have to use whole numbers instead in mine?

But that concept is “creative” according to the CAFC’s emotionally charged and bereft of any legal foundation ruling here and therefore, according to the CAFC, copyrightable. It is a emotionally charged ruling in that they explicitly state that if you put any thought into building an API it must be creative and if it’s creative it must be copyrightable. That is not the plain reading of the law, that is wishful thinking on Oracle and the pro-IP biased CAFC part.

Jo?o Sousa says:

Section 102 (b)

You are miss interpreting section 102 (b) which is exactly what the Federal Circuit said Alsup and Google had done.

“In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”

This means that even if a work is copyrighted that copyright doesn’t extend to it’s components. It’s actually quite clear since starts with “extend” and the paragraph ends with “embodied in such work” which references the copyrighted work.

Which makes sense because while the JAVA API can be copyrightable, but shouldn’t mean a specfic method in it is copyrightable.

It’s curious that noone mentions that the Federal Court ruling also cites Congress, who explains that the spirit of 102 (b) wasn’t to restrict copyrightability.

If the Supreme Court disagrees, then this ruling will be changed, it’s that simple.

Jo?o Sousa says:

Re: Re: Section 102 (b)

“But, yes, the misinterpretation of 102(b) is fundamental to the arguments here.”

It’s the whole point. In my opinion, the one that misinterpreted 102(b) is Mike Masnick, not the Federal Circuit.

When 102(b) says that “copyright protection for an original work” doesn’t EXTEND to ideas that are “explained, illustrated, or embodied” in it, it is implying that the work itself is copyrightable.

This is exactly what the Federal Circuit says, that 102(b) doesn’t restrict copyright of a work just because it is composed by X, Y, Z. It’s the other way around, it just makes it clear that although the work is copyrightable, it’s individual components aren’t.

Google could have taken the sort function, or the max, or the copy, since 102 (b) ensures that the copyright of the work doesn’t extend to it’s individual components. But Google copied the work as a whole (at least a large part of it).

Jo?o Sousa says:

Re: Re: Re: Section 102 (b)

Congress says (cited by Federal Circuit and available in http://en.wikisource.org/wiki/Copyright_Law_Revision_(House_Report_No._94-1476)/Annotated )

“Section 102(b) is intended, among other things, to make clear that the expression adopted by the programmer is the copyrightable element in a computer program, and that the actual processes or methods embodied in the program are not within the scope of the copyright law.
Section 102(b) in no way enlarges or contracts the scope of copyright protection under the present law. Its purpose is to restate, in the context of the new single Federal system of copyright, that the basic dichotomy between expression and idea remains unchanged.”

According to Congress it is clear that “Section 102(b) in no way enlarges or contracts the scope of copyright protection under the present law”.

Charlton A. Butler Jr says:

Simple API explanation

What no one could come up with this simple explanation for them?
An API is an interface. It’s like the specification of the telephone system or the electrical wiring in your house. Anything* can use it as long as it knows how to interface. You can even buy off-the-shelf software to use a particular API, just as you can buy off the shelf telephone equipment or devices that plug into the AC wiring in your house.

An SDK is implementation tooling. It’s like a kit that allows** you to build something custom to hook up to the telephone system or electrical wiring.

*Anything can use an API. Some APIs have security provisions to require license keys, authentication, etc. which may prohibit complete use of the API in particular instances, but that’s only because particular authentication/authorization steps fail. Any software that presents the right credentials (if required) can use the API.

**Technically, if an API is well-documented, you don’t need an SDK to build your own software to use the API. But having an SDK generally makes the process much easier.

Anonymous Coward says:

Re: Re:

You’re shitting me… you’re using fosspatents? And, no doubt, you think you’re a credible expert on copyrights?

Take a course in programming.

You think there’s a misinterpretation of s102(b). The problem stems from a misinterpretation of APIs. If you don’t understand what something is how can you apply the law to it?

Anonymous Coward says:

I have to wonder though...

What if in creating Android Google had named all of their functions differently then simply created links to those functions with similar names to create the Java API compatibility? For instance, lets take one of the examples from the decision. What if instead of java.lang.Math.max they HAD actually named it java.lang.Math.maximum and then simply created a link that pointed java.lang.Math.max to java.lang.Math.maximum such that the compatibility for programmers familiar with programming in java would have been preserved? That would not be literally copying it.

Add Your Comment

Your email address will not be published.

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...