Tom Petrocelli's take on technology. Tom is the author of the book "Data Protection and Information Lifecycle Management" and a natural technology curmudgeon. This blog represents only my own views and not those of my employer, Enterprise Strategy Group. Frankly, mine are more amusing.

Friday, April 16, 2010

Tom's Plain Language License for Mere Mortals

For the past few months I've been working sporadically on a piece of software. It's not a great looking bit of code but interesting none-the-less. It's a simple document management system called Document Locker that allows you store files in a repository (so you know where they are) and wrap some metadata around them. That's not the interesting part. What's neat is that you can define relationships between documents and see which is connected to which. This approach will be most helpful when organizing multi-part documents, scientific papers, and a software project.

Finally, the day is near that I am to release it into the wild, including source code. Roughly two weeks hence, Document Locker 0.5 (the first iteration) will be made available through Part of preparing for the release is developing a license. All software needs a license to keep it from being misused and to protect the creator. This includes open source software. It never ceases to amaze me how little people realize that open source has a license.

I looked over all the major licenses such as Apache and GPLv3. All of the open source licenses I examined had the same problem – they are a mass of legal gobbly gook. I'm used to reading contracts and license agreements (which are a kind of contract) and they were still a tough slog for me. And long? As Sarah Palin would say “You betcha!” No sane person would subject themselves to reading these documents unless driven by necessity. It's like eating bugs. You would do it if you had to but not if there was an alternative.

The reason that even open source licenses are like this is because they are written by lawyers. Lawyers, like engineers, have their own technical language. They have their own concerns and worries and they think in a certain manner. The documents reflect this. I'm not saying it's a bad thing but for a great many uses this type of language obscures more than it illuminates.

When you get down to it, a license exists to create an agreement between people about rights. As the creator, I hold all the rights. You can do certain things with my creation but only those things that I allow. If you can't understand what I'm allowing you to do, how can you be expected to uphold your end of the agreement? You can't.

So, I set out to develop my own license. I'm pretty sure that a large number of lawyers would think I'm nuts just I would if lawyers wanted to write software. My goals were:

  1. To make obvious what I was allowing a recipient to do.

  2. To make obvious what they can't do.

  3. To say so in plain language that anyone could understand.

  4. Keep it short. Life's too short for long licenses.

  5. I wanted to make a point about licenses.

The result was Tom's Plain Language License for Mere Mortals. It is as plain language as I could get. Unfortunately there is no getting away from referencing other, big, heavy, legalese licenses. Since I have to reference the Java and Neo licenses the reader is still struck with reviewing those licenses. Too bad. Otherwise, it's pretty straightforward and just a bit irreverent. Irreverent? That helps me to achieve goal number five and make the point that software licenses, even benign ones, are so complicated, so full of legal jargon, that they are useless as the basis for a relationship.

With Tom's Plain Language License for Mere Mortals you know where you stand. If you can't understand what you are agreeing to then you shouldn't be mucking about with software. Really.

If you are interested in a preview, you can check it out at Twitter comments (direct message please) or email them to me if you know my email.

No comments: