So you are starting on your new project and you decide (gasp) to write actual specifications for the network and API interfaces. Being a good ’open’ type you want to have a solid open license for the specifications. Below I look through what I think are the key terms the license needs and conclude that the Apache 2.0 License seems to have all bases covered.
Disclaimer
I’m not a lawyer and I don’t play one on T.V. So what the hell do I know? But I have to deal with these issues and here is my best (non-lawyer, almost certainly worthless) view.
Copyright of the specification’s text
Copyright is its own infinite pit of idiotic doom but the bottom line is that if anyone wants to reproduce the specification or (better yet) create a derivative work they must have copyright permission. So if a specification is going to be open it better have a copyright license that explicitly allows for copying (with no charge) and for the creation of derivative works of that text. Note that requiring copying with no charge makes my requirements apparently more strict than the OSI’s (see the availability requirement) which I find odd on the OSI’s part.
Copyright of the specification’s definition of the Application/Program Interface (API)
In theory one might need a license in order to produce the same API as defined in the specification. The last legal judgement in the U.S. that I know about in this area was Oracle’s attempt to copyright the Java APIs in the context of a lawsuit with Google. In that case the judge said that you can’t copyright APIs. But the funny thing about judicial opinions is that they can change. Furthermore I’m not completely clear if the term API encompasses both APIs for local code as well as on the wire formats. It’s all a bit of a mess. So it seems to me that an explicit grant to the API itself, separately from the copyright on the document, would be useful.
Now I suppose one could argue that if one has an open source implementation of the standard by the same person who owns the API definition then one has granted a de-facto license to implement the API since any such implementation can claim to be a derivation of the open source. Now we are getting into an area that my non-lawyer mind simply isn’t qualified to address. But I would point out a few things:
- Standards sometimes contain things the code has gotten to yet
- Code can contain bugs that result in the code being inconsistent with the standard and so not a full implementation of the standard specified API
- If an implementation of the standard is in a language/environment that is completely unrelated to the open source implementation would the open source license really still apply?
I just don’t know. But again, having an explicit grant of a right to implement the API and to create derivative works from the API would seem to be really useful.
No royalties or fees to get the specification
The specification has to be available at no cost with no royalties are other restrictions on its initial access or distribution and on any derivative works.
Patents
One of the many reasons I’d like to move to New Zealand is that they have wisely (so far, I’m sure some trade deal will force them to ignore their own democratic process) refused to allow for software patents. My personal belief is that software patents are a really bad idea. But they do exist and if a standard is going to claim to be open than it is a requirement that the folks who create it provide free access to any patents they own that are necessary to implement the standard. This is a higher standard than ’Reasonable and Non Discriminatory’ (RAND) licensing which allows the patent holder to charge money. Even RAND-Z is unacceptable as it still puts the patent holder in the position of getting to grant a license and therefore leaving them the ability to not grant one. So for a specification to be meaningfully open it must provide Royalty Free/Reciprocal (RFR) licensing. To quote myself:
RFR means that the technology is available royalty free but only if the user accepts that they can not sue the issuer for patent violations in relation to the technology.
In retrospect there is a clarification I wish I had made in the article - the retaliation clause needs to be universal. That is, if anyone sues anyone else in regards to a patent related to the specification then the person suing loses all rights to all patents granted in relation to the specification.
Unfortunately RFR is not a magic solution. Patents create real problems for open source/open standards that I don’t think are solvable by anything but banishing them. The reason is derivative works. If a license covered patents in derivative works then someone could fish for patent coverage by taking the specification in any direction that an interesting patent happened to be. So if there are patents then providing rights to derivative works is impossible.
Warranty (aka Liability)
In providing a open specification one certainly doesn’t want to end up on the hook for any liability regarding implementations of the specification. So some disclaimer of liability seems necessary.
Turning it into an open standard
Ideally if the specification proves really useful it would grow up into an actual open standard. I believe (again, not a lawyer) that if all the previous requirements are met then the specification would be suitable for submission to just about any credible standards organization I can think of.
Putting it all together
There is one license that seems to have everything and that is the Apache 2.0 license. It’s copyright language about ’source or object form’ would seem to cover the distinction between the copyright of the text and copyright of the APIs but I’m not a lawyer and I could be wrong. It mandates no royalties/fees. It has a RFR term on patents. And it disclaims all warranties. It doesn’t explicitly state that covered material can be taken to a standard organization but its terms seem consistent with every standards org I’ve ever seen so I wouldn’t imagine that would be a problem.