One of the interesting conversations that came out of the APIStrat Un-Workshops at Gluecon this week, was the exploration of the analogy of applying copyright to restaurant menus, and applying copyright to APIs. This type of conversations is why 3Scale and API Evangelist support these types of events.
When you Google the topic of restaurant menu API copyright, you get a wealth of contradictory answers that show the difficulty of applying copyright to menus. In practice you can put a copyright on your menu, and you could probably spend a lot of energy enforcing this if someone copies your menu. In reality, it will probably be pretty hard to win, unless your menu is exactly copied, and a fair use claim couldn’t be enforced.
One interesting layer in this discussion, is the ubiquity of restaurant menus, and even the order, naming and organization of these menus. A phase I don’t think APIs have reached, but will at some point. It is pretty difficult to argue that menus are essential to interoperability, meaning you can sit down at any restaurant and the menu contributes to you on boarding with the restaurant experience. Imagine if you had to know to ask for food via a chalkboard, or pick up some phone to call in what you wanted, without knowing any orderly way of understanding what a restaurant provided? Each restaurant would be different, and screw up the whole thing.
I would argue that bookmarks, images, video and other common API designs are just like hamburgers, steaks, and salads, when I explore this analogy. I think a lot of the confusion in the API copyright discussion is around the separation between an API and the API definition. The order and layout of restaurant menu is not the restaurant, just like the API design is not the API.
Could you imagine enforcing copyright on a american restaurant or diner menu layout? Maybe with fast food, which is not about delivering value, but maximizing profit. I think things are just newer in the API space vs the restaurant industry, but the analogy holds up. As a restaurant, your menu is not your restaurant. If someone copies your menu exactly, and opens up across the street, you may have a copyright case where fair use may be hard to defend, but in the end is their steak dinner the same as your steak dinner? Ultimately it comes down to your service, ingredients, presentation, price, ambiance and the other building blocks of a restaurant.
This same thought process can be applied to APIs. If you offer an image API, and someone copies your image API design exactly, the APIs are not exact copies. What you have behind the API design is the value, and represents your company’s intellectual property, not the API design. Allowing your API definition to be copied will increase interoperability, and increase the chance developers will build clients, and other tooling that encourages interoperability—think about Amazon EC2 and S3. Does every copy of the API design deliver the exact same value as Amazon API? I think not.
In the end, if you don’t see the separation between an API and its design, the benefits that an open API design delivers to not just an individual API ecosystem, but the overall API sector, you probably don’t understand APIs well enough, and /or you are just concerned too much with monetization and control, and you really don’t belong in the API space.
I'm guessing that we will end up with the fast food of APIs who really don't offer much value, but actively enforce their brand, which is tightly coupled with their API design. Even with this shit in the market, the rest of us can work hard to offer high quality APIs, which employ open API designs.
Disclosure: 3Scale is an API Evangelist partner.
