Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Perception of Patent and Copyright Overlapping When It Comes to APIs

DZone's Guide to

A Perception of Patent and Copyright Overlapping When It Comes to APIs

Here the API Evangelist takes a quick look at copyright and patents and how they apply to the intellectual property of APIs.

· Integration Zone ·
Free Resource

The new Gartner Critical Capabilities report explains how APIs and microservices enable digital leaders to deliver better B2B, open banking and mobile projects.

I just read an interesting piece by Dennis Crouch over at on Patentlyo asking, “Are Copyright and Patent Overlapping or Mutually Exclusive in Protecting Software Innovations?” The article is challenging the most recent decision in the ongoing Oracle v. Google copyright case using a study called “The Patent-Copyright Laws Overlap Study,” prepared at the behest of the House Subcommittee on Intellectual Property and the Administration of Justice in May of 1991.

Among the most significant of the Study’s software findings is that there is “no overlap in subject matter: copyright protects the authorship in a set of statements that bring about a certain result in the operation of a computer, and patents cover novel and nonobvious computer processes,” according to a letter from Ralph Oman and Harry F. Manbeck to the Hon. William J. Hughes, July 17, 1991 (transmitting the Study to the then Chair of the House Subcommittee).

I’m interested in this level of discussion because it helps me see the many layers of how patent and copyright law applies, or does not apply in the digital world, and specifically to APIs. Personally, I do not feel that copyright or patents apply to the API definition layer of API operations. Maybe patents can apply to the software processes behind, and maybe copyright could be applied to some more complex, creative software orchestrations using APIs, but really this layer acts like a menu to what is possible, something akin to a restaurant menu, which I have argued in the past.

At a time in the growth of the API industry where we should be standardizing, sharing, and ensuring our API definitions are interoperable, we are going backward and further locking up these definitions, and keeping them in our proprietary safe. Instead of locking them up we need to be having more conversation like this about further defining the licensing layers of API operations, separating the backend code, data, schema, API definitions, front-end, and rules that surround them. I can get behind keeping some of the code, processes, and rules behind API operations secret, but the interface itself needs to remain open–I mean, you are asking other people to integrate this layer into their applications.

I am still understanding the patent implications in the world of APIs, and it is helpful to have lawyers out there to help me better understand all the moving parts. As we prepare for the next round of the Oracle v Google API copyright case, it helps me to pull back and understand the overlap of copyright with patents using earlier legal precedents like in the Patent-Copyright Laws Overlap Study from 1991.

The new Gartner Critical Capabilities for Full Lifecycle API Management report shows how CA Technologies helps digital leaders with their B2B, open banking, and mobile initiatives. Get your copy from CA Technologies.

Topics:
integration ,api

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}