Licenses for Protocols

pieterhpieterh wrote on 17 Apr 2013 13:51


A few years back, when we set-up the Digital Standards Organization, one of our goals was to create a simpler framework for protocol development. At the time, licensing a protocol spec as open source was unheard of, and offensive to many people. Today it's just radical. In this article, I'll look at why and how to license a protocol spec.

Most of the open standards we use are not licensed for remixing. That is, if you take the HTTP spec and try to make a new document based off it, and publish that, you are violating the IETF's copyright, and your modified spec will (I assume) be asked to disappear.

In the old days, the thinking was that a standard has to be inviolate. There's a process for building it, and then we need a single standard. Forking a standard would be… bad.

Then around 2007 we realized that if a standard ever became important (in a good or bad way) to someone's business, it was relatively easy for powerful, wealthy firms to simply take over the standards-making body, and thus take over the standards. We saw this happen with OOXML, where Microsoft effectively took over parts of ISO so it could push this thing through as an "International Standard". Microsoft then did a similar move into OASIS so it could control the future of ODF, the competing standard.

Anyone involved in standards-setting committees has seen the cost of the traditional process. The key question we had in Digistan was how do we make standards development cheaper? I used the term "unprotocol" to describe this cheap, community-built standard.

Of course anyone can design and publish a protocol and say, "He guys, here's my vision, any comments?" How do you get real contributions from people willing to bet money on that?

I argued at the time that developing standards was the same as writing software. You want people to compete and collaborate in the same way. Open knowledge. Blah blah, you know the story. My main argument was that forking was not bad, but essential. The right to fork was essential. It's the only guarantee an implementor has that if some unkind people with more time and money capture the standard process, they don't destroy your business. Paranoia? Maybe, but it happened to us with AMQP, which became a captive enterprise jelly fish. We lost a huge investment in OpenAMQ. Well, it freed us to make ZeroMQ but still… that should have happened as a smooth evolution of AMQP, not a reboot.

Freedom to fork. This is the first, essential requirement of an unprotocol. Any open source license will give this freedom, BSD, MIT, X11, Apache, MPL, GPL. Also, a Creative Commons license like CC0.

But it's not sufficient. Imagine if AMQP had been BSD or CC0. Now imagine it's successful and businesses start rolling out products based on it. They're competitors so they look for ways to gain advantage. One classic way is to build proprietary extensions. This happens so often it's ridiculous.

If I'm a lawyer working for some evil corporation, say Microhat, or Redsoft, I'll tell my clients this: "You make an extension of the standard that passes the conformance tests, but you make your extensions proprietary and you license them on your own terms."

If I extend a CC0 or BSD protocol, my version of the protocol is by default proprietary. The license does not extend to forks. I can announce any licensing model I want on my extensions. For instance, "You may only use this protocol on Tuesdays". Now, if I'm big and rich enough, I can force this on my users.

Forks must be remixable. This is the second, essential requirement of an unprotocol. If you don't do this, your low-cost community is vulnerable to attack by well-funded competitors. Only the CC-SA and GPL provide this assurance.

Further, as that lawyer, I tell my clients, "Now please file a patent claim on these extensions and put a patent license into your support model. It doesn't matter if the patent gets granted. The claim will be enough to scare clients into paying."

Paranoia? Maybe, but RedHat did this with AMQP: patented a proprietary extension for XML routing. Patents aren't just toxic to competition, they can scare people away from the whole standard itself.

OK, it's true that anyone can file patents on protocols, but it's the firms that implement them who have the strongest incentive to patent around the edges. You do need to consider this threat.

So, the last requirement is protection from patents. The GPLv3 has language that scares off patent lawyers. It's effective. and arguably the main reason Apple has invested so much in removing all GPLv3 products from its stacks and tool chains.

Finally, how do you enforce interoperability when anyone can make forks? The answer is the same as in open source. You use a domain name and trademark and establish your processes under that brand. For instance, conformance tests, and contribution policy. People see the name, they know what they're getting.

So in conclusion, my advice is to treat protocol licensing like network security. You try to guard against known attacks, you don't trust good intentions. It comes down to CC-BY-SA if you're not concerned about patents, and GPLv3 if you are.


Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License