It’s been two weeks since we hosted our live, online debate around the impact that the ongoing Oracle v. Google case will have on the software industry – specifically in the of API and mobile world. Along with having a lot of fun, we had two main goals in hosting this event:
We wanted to impress upon our audience the importance of this case. While it may seem like a legal battle of tech giants, the results of this case will eventually have a major impact on individual developers, start-ups and mid-sized software companies.
We wanted to utilize the expertise of our guests, Mitch Stoltz and Joel Rothman, to educate our audience on the real legal issues at stake in order to help them make up their mind about which side they subscribe to.
While it’s difficult to prove whether or not we were successful in the first goal, our pre- and post-debate polls showed us that we were overwhelmingly successful in helping people decide whether they were for or against API copyrightability.
While two-thirds of registrants said they were undecided before the debate, 80% of attendees left the event having made up their mind one way or the other. Personally, I attribute those numbers to our participants in the debate, who both did an excellent job of citing existing legislation and previous court rulings in their prepared arguments.
Let’s take a look at some of the main points that were made by Joel and Mitch during the live debate. If these paraphrased recaps aren’t detailed enough, feel free to click the link at the bottom of the page to view the entire hour-long recording.
For API Copyrightability (Joel Rothman)
Copyright protection for code can and should co-exist with an open use of that code in the right circumstances. Generally, the purposes of copyright are to:
- Secure fair return for the author/creator
- Stimulate creativity and empower new works for the general good
It seems that many people have gotten caught up in the issue of whether code in an API, which is intended to be inter-operable, entitles to copyright protection at all? I think this is the wrong area to focus on.
If there is work that is entitled to copyright protection — minimally creative in this case, yes, but still creative work — it is code, because in many ways code is like poetry. It ought to be entitled to copyright protection, but the decision of whether or not it should be used without infringement should be based on whether it has been used in a fair way. This is the issue that we should all actually be discussing here.
If the District Court or a jury, on remand, properly applies the four factors of Fair Use (below) to the software that’s at issue, the conclusion will likely be that it’s entitled to copyright protection but that the use that Google put it to was a fair use that is not an infringement.
This would be a result that would serve not only the purposes of those who object to copyright protection for code, but also the objectives of those who wish to control the use of their code and choose to license it for the general good. It’s really a win-win compromise for both sides.
Against API Copyrightability (Mitch Stoltz)
Software developers who want to code to an existing API and have good, valid, and legal reasons to do so should not have to rely on Fair Use, which was the conclusion that the Federal Circuit Appeals Court reached in this case.
Three reasons the Federal Court got it wrong:
- Wording of the copyright act
- Previous decisions of courts
- The fundemental purposes of copyright law
It’s important to understand that it won’t just be the final verdict of this case that will affect the industry. How we get to that verdict is also going to have a big impact on those of us who don’t have the resources of Oracle or Google.
Fair use is flexible legislation that is laid out in those four nebulous factors that Joel mentioned. The purpose of Fair Use is to act as a safety valve in copyright law. It allows judges to use their own judgment about circumstances that congress never considered, that courts haven’t had an opportunity to consider yet, where using someone else’s creative work without permission leaves us all better off and shouldn’t be prohibited.
The problem is that Fair Use gets overloaded. It was intended for new and unanticipated uses, but it’s now forced to bear the brunt of a lot of common things that really have been going on for a long time that aren’t new — one of those being the re-use of interfaces or coding to existing class and method specifications. It’s a very case-by-case analysis that really has to deal with the economic impact of these particular circumstances. The outcome becomes too unpredictable.
Pinning all of a new software developer’s freedom to write code to an existing API (without paying for the privilege) on the Fair Use doctorine is going to, frankly, scare them off. It’s going to lead to a lot of re-writing from scratch. It will lead to a lot of wasted efforts. It’s going to depress investments in new software and in keeping popular APIs alive.
Take a look at 17 U.S. Code section 102b:
This is the key language here. Class and method declaration very much falls under this idea. Saying “copyright must apply to code” is speaking too broadly. An API is not a program. Whether or not it is code doesn’t really matter because all code is not created equal.
Check out the recording of the full debate, or just a section or two, and let us know which side of the argument you’re on by commenting below.