The US Appellate Court ruled that APIs are copyrightable

Sounds like Maidsafe just became an even more attractive option for developers - interesting read.from “programmable web” site:

With the exception of Oracle and its stockholders, the technology industry’s collective head exploded today when the US Appellate Court ruled that APIs are copyrightable. As a part of its findings, the court wrote “…the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection.”

That conclusion does not mince words. Those of us here at ProgrammableWeb, where APIs are our life, are quite stunned by the decision. Me personally because prior to joining ProgrammableWeb, I spent a significant number of years covering the ins and outs of copyrights and patents as they pertain to technology and some of the gargantuan legal battles that have taken place in our industry.

This ruling certainly looks to be both dangerous and stifling. For decades, the efficient interoperation of pretty much everything digital (and some things analog) has involved APIs. In concluding that APIs are copyrightable, the Appellate Court sent pretty much every technology lawyer on the planet scrambling to figure out next steps. It’s almost a footrace at this point. Why? The Appellate Court went on to say that “because the jury deadlocked on fair use, we remand for further consideration of Google’s fair use defense in light of this decision” and in so doing, posed a rhetorical question to every lawyer: Would you rather be the plaintiff or defendant in an API fair use case?

In remanding the question of fair use back to the Circuit Court, the Appellate Court left the definition of fair use (when it comes to APIs) completely open. A broad conclusion on fair use by the Circuit Court could, for all intents and purposes, nullify the extent to which API copyright holders should waste their time attempting to enforce their rights. Conversely, a narrow conclusion could load the Courts’ dockets.

In answering the aforementioned rhetorical question, if for no other reason than defensive purposes (where having intellectual property rights helps to fend-off other infringement suits), those lawyers have little choice but to be working with their technology organizations to catalog all that’s copyrightable given the new ruling. In situations such as these, having the option of a lethal offense is the best defense.

Unfortunately, there’s a snowball’s chance in hell that all such lawyers will be fully-satisfied with just defensive maneuvers. Some will no doubt go on offense and seek to enforce their “copyrights” through the extraction of royalties or infringement suits big enough to shut most startups down. For some plaintiffs, “shutdown” could be the objective. As I recently learned, it’s nearly impossible for startups currently involved in litigation to get venture funding. If the suit has to do with IP infringement, the startup becomes the hottest of hot potatoes. Even companies that are off the runway could be in big trouble. Given the number of APIs found across its portfolio of offerings, even Oracle could find itself a victim of its own doing.

While APIs have been around for decades, the ruling is particularly troubling in the case of the sort of APIs that ProgrammableWeb has covered and catalogued since 2005; Web APIs. The reason Web APIs are particularly vulnerable is because their designs, methods, and resources are so easily discoverable. The very nature of a Web API means that it’s exposed to the Web where pretty much everybody can see it. Lawyers could easily go to work with technologists to organize machines that crawl the Web, looking for API patterns that could constitute infringement (we can only hope that no one uses the API to ProgrammableWeb’s API directory to assist in such an endeavor).

And therein lies one of the most troubling aspects of the Appellate Court’s ruling and the halo of fair use uncertainty it created. APIs of all sorts tend to gravitate towards patterns that mimic the best practices of API provisioning while addressing the sensitivities of developers. The notion that the re-use of time tested patterns could result in a copyright infringement suit offends the sensibilities and camaraderie of those of us in the API economy. We’ve evolved those patterns together, as a community. If one, or three, or five years from now, the tens of thousands or millions of APIs on the Web must defy the expectations of developers in order to create a legal shield, innovation will have been thoroughly stifled.

This battle is long from over. In the mean time, we at ProgramambleWeb can only hope that all players big and small in the API economy refrain from staking an offensive position that would hasten progress and growth in one of technology’s hottest and most promising sectors.

Read more: http://programmableweb.com/news/oracle-vs.-google-judgement-will-send-api-lawyers-scrambling/analysis/2014/05/09#ixzz31XTq3NDG
Follow us: @ProgrammableWeb on Twitter | ProgrammableWeb on Facebook

1 Like

Holy (Bleep)! This is almost certain to drive A LOT of talent towards the SAFE network. Let’s get it off the ground!

I know maidsafe has patented the maidsafe project, but I think they should seriously consider copyright ING the api before the big release to prevent fork → other copyright → attempt for someone to try and charge license to them. They’d have prior art, but it would still end up as a legal battle that could easily be avoided. Maidsafe holds copyright, they can allow people to use it for free. If someone else holds it, maidsafe may be liable for a license fee.

Yes, that was my concern, or rather that even any component of api reliant/based on anything copyrightable - is that even a word btw? My main concern is that any kind of legal battle could probably not even be defended by Maidsafe due to prohibitive legal costs; this is a tactic now commonly used, such as in fracking industry where legitimate legal claims are stifled either by costs or as is often the case, claim libel/slander against fracking companies which can’t be afforded to be defended against.
Ok team, any nice, soothing reassurances would be welcome…lol

Hope it stays bound to US territory… I really have no soothing answers. I’ll just ignore it for now :slight_smile:

Even if it stays just bound to us territory, if someone copyrights it here, maidsafe may be liable for license fees for any product distributed here. :confused:

Maybe technically speaking MaidSafe isn’t distributing the the SAFE network. Rather it’s putting it out there for grabs. I am no lawyer and I know too few details about these things.

Could we just re-visit this thread a bit and maybe get some dev input, as I think there may be a number of attack vectors from a patent point of view, or new ones that sprout from previous comments? I think a brief overview of how all- encompassing (or not) acquired patents are and maybe add to FAQ. I think this would be helpful/informative for potential builders who may fear future litigation from other more established internet apps etc. For example do we have a patent that covers all de-centralised apps or does it have limitations? Could a currently patented app on the normal internet operate on the safe network, then sue any competitors based on what it does (a windows/Lindows scenario -actually probably not the best analogy, but a windows/something that does same thing scenario - I don’t want to confuse with copyright). Which would take precedence and would it even matter - as the big player would litigate the arse off the smaller one which would not financially be able to defend itself? There just seems to be maybe other things worth thinking about/exploring in this whole area here, as its not just about the network/Maidsfe but also the builders - they are symbiotic really…
Can you patent the whole eco-system and is this what has been done…kind of?
Actually, Can you patent a whole eco-system wherein patents do not apply? Now there’s a novel idea, something patents were invented to protect…the irony would be good.
Anyway, this leads on to adding to terms and conditions of Safe network user agreement - I think a lot of potential lawsuits could be pre-empted there too.

Who is going to obey the copyright?

The patent coverage we currently have is focussed on the components of the network and does not currently expressly mention decentralised applications, we are currently taking steps to sure this up. I would say that you can’t patent a whole ecosystem, but you can patent across many aspects of it (infrastructure, functionality) and offer some robust protection.

MaidSafe’s patents are in largely unchartered territory and, as a result, we have been able to get some pretty broad claims (such as the ability to login to a fully decentralised/serverless network) granted. MaidSafe grants an open source license (GPL3) for use of the technology and the patents to developers on the network.

However, I believe (bear in mind I’m a long way from being an IP attorney) that if a SAFE app copied a patented design, like Twitter’s scrolling (User interface mechanics) functionallity then it would be infringing Twitter’s IP, regardless of it being on a decentralised network.

So, I would say there is some decent protection now and we are looking to enhance this, but I believe that app builders will still need to be mindful of how they design their apps. Not sure if this puts you at ease any @AlKafir but hopefully gives you some more information.

It doesn’t affect me, I’m a decorator, not clever enough to be a builder, but I think it will help app developers to cover all bases and get their ducks in a row…too many metaphors…lol

1 Like