Choosing a license for sharing documentation content

I received this set of questions from Laura Ferrar after a Central Texas DITA User Group meeting this summer, and I have been thinking about these for a few months. These are good questions. I’ll try to answer them to the best of my knowledge, but I do think I should lead with the disclaimer “I am not a lawyer.”

Laura: Could you elaborate more on the legal and copyright issues of open source content, and collaborative content, beyond asking for permission?

Anne: First, a few definitions. Copyright was intended to protect the creator from publishers publishing the content, “to the Ruin of them and their Families.” That ruination quote is  pulled from the Statute of Anne, considered the origin of all copyright. Copyright was a concept written into the US constitution. Mark Twain thought it was a good idea to extend his copyright privileges in 1906.

Copyright law’s international standardization started in 1886. Copyright law gives the original creator exclusive rights to do with the content as they please. A writer might give someone one-time printing rights for an article or essay. A photographer might display a photo on Flickr but mark it with a certain license that indicates how you can use it.

Licensing the content is one of the things the copyright holder can do with the content to indicate how they, the creator, give permission for it to be used, sold, distributed, and so forth.

The phrase “open source content” isn’t precisely defined. The term open source typically describes software, but more and more people are using the term “open source” to talk about content that can be re-used as long as licensing requirements are met. Collaborative content could be created by a small set of trusted collaborators, and there are different production and sharing models you can follow for collaborative content such as wikis. My book, Conversation and Community: The Social Web for Documentation, goes into some ideas.

Laura: What issues and legalities do we as Technical Communicators or Wiki Administrators need to be aware of as we move towards collaborative authoring projects and so forth, especially when documenting open source software?

Anne: Projects that are open source give away the code artifacts to create the software. Open source software, as defined on Wikipedia, has many criteria it must meet in its licensing agreements.

Documentation specifically may lean towards an openess, but restrictions on use, requirements for attributions, and what happens with changes (or branches) from an original document source may vary widely. Legally, documentation writers should understand the license under which the content can be used, and follow the licensing instructions.

Creative Commons has four licenses that are explained in straightforward language on their website. The most accommodating requires only attribution. Then there are more restrictive mixes and matches that enable different commercial uses,  whether you must share any derivatives, whether you can make a derivative, and so on.

Licensing of content is something that we’ve talked about recently on the FLOSS Manuals discuss email list. Adam Hyde, the founder of FLOSS Manuals, also wrote an essay about free documentation and he is passionate in his thinking that even requiring attribution limits the “freedom” of content to go anywhere and be used by anyone. Collaborative content often requires that attribution of all collaborators be displayed somewhere.

Laura: How about content that is done collaboratively? How does that content get vetted, in terms of technical accuracy to avoid any legal liabilities?

Anne: I believe we create collaborative content quite often in a corporate environment, and your review process is how the content gets vetted. In larger collaborative environments, such as the ones that large wikis can scale to, there are more reviewers of the content. I believe the content is vetted if the company backs it up based on the language in the software contracts that happen at the sale of the software. In open source projects, the “contract” you enter with a provider may or may not exist. It may be “use at your own risk” or it may be “we are service providers for this open source software and here’s what you can expect from us.” The same general principles can be upheld for guaranteeing the accuracy of documentation. The legal liability lands in the contract that a person enters with the vendor of the software, I believe. Since I’m not a lawyer, I can’t guarantee avoidance of legal liabilities, though.

One model to follow is to offer two sets of collaborative content. One set of collaborative content has a disclaimer stating that the company or organization does not guarantee the accuracy of the content, such as “Content in this collection has not been verified by our company. Use all of the information here at your own risk.” Another set of collaborative content where the collaborators are only your company’s information developers, and their job is to provide content that is as accurate as possible. That collection of content would not need a disclaimer and could be displayed like an online help site. Lisa Dyer has an article on the WritersUA website that describes this model for company-generated content and community-generated content.

To learn more, you may want to watch these free training courses from this blog entry.

  1. Online Media Law: The Basics for Bloggers and Other Online Publishers: With this course, you’ll learn about copyright, privacy, defamation, and more for online publishing. [News University]
  2. Introduction to Copyright Law: Check out this course to get a lowdown on the basics of copyright law, specifically online. [MIT]
  3. A Fair(y) Use Tale: Here you’ll learn about fair use and copyright. [Novell]

Updated to add: Technical Communication student and Austinite Emmelyn Wang just recommended the book, A Legal Primer for for the Digital Age, which is in the Allyn and Bacon Technical Communication Series. Thanks Emmelyn!