Over time I’ve written lots of user guides, installation documents, governance papers, roadmaps for various companies…and I can’t use any of them ever again.
This is because the standard consulting or employment contract contains lots of legal text stating that the employer owns all the copyright to the employee’s work. This naturally includes software documentation. This seems like a good idea on the surface – the company pays for the time I take to write the document, so it’s their property.
However, there are hidden downsides.
To begin with, software project requirements tend to be fairly standard. Most projects require a project plan, a specification document of some kind, server topology diagrams, installation scripts, standards and best practices recommendations, help and support docs.
The details of these may vary a bit, but the definitions, explanations, and recommendations usually won’t. Even the details may be similar – one 3-server SharePoint farm will have to address the same issues any other 3-server farm will. This could be boilerplate text.
Reinventing the Wheel
If companies claim ownership of all software documentation IP – which is their default stance - they may not realize that they are paying their employees or consultants to reinvent the wheel. If they claim ownership of everything they generate, no one else can benefit. Conversely, no-one has an incentive to share.
It might be better for a company to leverage documentation created somewhere else, and modify it to suit their own needs – then they are saving time and money.
As a consultant, it’s been suggested to me that if I bill by the hour I shouldn’t mind writing the same stuff over again. But I find that boring – having figured out a way to describe something once, why would I want to come up with new words to say the same thing again and again?
Also – I would rather spend my budgeted documentation time improving existing content. If I’m spending my allotted time rewriting from scratch, that won’t happen.
Finally, we programmers are lazy - in a good way! We’d rather move on to new, interesting problems than rehash the old ones again and again. So, proprietary IP ownership goes against most programmers’ core mindset.
I’m not saying a company should never claim software documentation IP – there can be valid business reasons for this.
If the company wants to own the IP because it is a business differentiator, and they will maintain and improve the documentation, that is a compelling reason for them to want to own, and not share, their IP.
Also, if the documentation contains lots of very sensitive information, or is very unique, that could be another good reason to hold on to the IP tightly.
I just think they should examine the alternatives first.
Why Bother Picking a Sharing License?
Why bother picking a license in the first place – why not just post the information somewhere and not worry about it?
Often information shows up on people’s blogs, in user groups, or in online tutorials. In most cases the authors want people to be able to use the information, but they don’t explicitly specify a license. They probably assume that other people can take the code or text and use it as they like.
However, most organizations are (rightly) nervous about copyright issues. If they can’t tell what license the information is released under, then rather than spend time requesting the rights to the content, and tracking the request, they may avoid using it at all. So, specifying the license makes the information easy to adopt, and provides legal protection for companies using it.
A Business Case for Creative Commons
Wikipedia is probably the best example of the power of sharing information on the web. It currently uses the GNU Free Documentation License, but will use Creative Commons Attribution-ShareAlike in the near future. Jimmy Wales, Wikipedia’s creator, says he would have used Creative Commons if it had existed at the time he founded Wikipedia.
There are other license types that allow sharing. Public Domain seems to allow freedom to do anything you like, but my understanding is the concept of Public Domain doesn’t exist in all countries, so it may be a legal impediment for companies wanting to share work. Creative Commons makes an effort to “port” the license terms to different jurisdictions so it is more likely to be valid elsewhere.
I’m primarily using Creative Commons Attribution-ShareAlike licensing because it fits my business model:
1) It’s transparent. People can easily understand what it means, because it’s in plain English and also in Legalese. Even the name is self-explanatory: “Share Alike” and “Attribution” makes it clear what somebody using it can do, and how. Having spent the last three months examining various software and documentation licenses, I’ve come to the conclusion that clarity is one of the most important qualities of a license. Also, I want my three months back!
2) It encourages sharing, even for commercial use. Information Technology is so complicated because we combine many different systems and technologies together and expect them all to work. No wonder software breaks all the time. If we don’t share, there are a lot of things we’ll never figure out on our own. Any licensing that encourages the spread of knowledge is a net gain for everyone.
3) It requires attribution. Attribution is a tiny barrier to adoption, because people are used to adding copyright notices to text they reference. I like the idea that if I do good work, people will find out about it. I consider it viral advertising.
4) It’s low maintenance. I don’t have to get a law degree to figure out the licensing. I would rather copyright law stayed the heck out of my way while I focused on my work. CC-SA allows that.
5) Sharing is good karma :)
Free Online Content on our Extranet
So, is 100% of my content shared under this license? No, and it never will be, because licensing is a business decision that always depends on the specific context. However, my default stance is to share what I write.
The content on this blog is now licensed under CC-SA.
As part of my contracts now I usually negotiate to own the IP I generate, with the promise of licensing it under CC-SA so everybody can benefit. This is working well so far.
To put my money where my mouth is, I’ve started to publish some content on our extranet at https://extranet.griffonsolutions.com/clients/allclients. You can log in with the username “guestuser” and the password “guestus3r”. There is a shared document library with the documents grouped by license type.
I welcome feedback on the documents – what works or doesn’t work, what can be improved and how. I’ll keep the docs up-to-date. Please email feedback to me at nick@griffonsolutions.com.
Feel free to browse, mix, and share!
Those docs would definitely have helped me the last time I was configuring SharePoint. I'll definitely keep that site in mind for next time though.
ReplyDeleteAlso, I agree entirely with sharing more content like this. I've found myself spending a lot of time discovering and documenting features that were not documented by a product's maker, but have no doubt been solved by other users.
Thanks for commenting, Anonymous. Hope some of those documents help you in the future. It feels good to share!
ReplyDelete