The Grumpy Editor's guide to free documentation licenses
This article is part of the LWN Grumpy Editor series. |
This is not the case for licenses covering documentation. There seems to be little consensus on which rights authors need to retain, and which should be relinquished. Indeed, there is little agreement on why documentation should be free. Many of the reasons for keeping software free (ability to look at the source to see how it works, ability to correct misfeatures) do not apply to documentation. Obtaining a manual in "original source" form may be helpful for cranking out more copies, but that source will reveal little which is not already evident in the text. Software, when distributed in binary form, is a black box which hides its internal nature. Documentation, on the other hand, expresses its ideas on its face; it is transparent.
Or, at least, it should be. Certainly your editor has produced writings which fail on that front at times.
So why should documentation be free? Your editor has a renewed interest in free documentation licenses for a couple of different contexts. One is a longstanding item on LWN's "good intentions" list: putting our original content under a free license. The other is the almost-imminent publication of a book, which will certainly be released under free terms. In both cases, the motivations are similar:
- Free software changes rapidly; its documentation has, in rare cases,
been known to lag a little behind. If the original author is unable
or unwilling to update a document to match current reality, somebody
else should be able to do so.
- Some readers never got the memo saying that English is The Language;
they can have funny ideas about having manuals in their own tongue.
It is rare that the original author can produce a translation in even
one alternative language, but there are often people with the interest
and skill who can do such translations. A free license should certainly
enable that work to happen.
- Collections of documents can be good things. Consider the massive "All
About Linux" books which were published in the mid-1990's, which were
generally made of the Linux Documentation Project's output, combined
with duct tape. Taking excerpts from free documentation can also be
useful; a book on Python database programming could benefit from, say,
Python and PostgreSQL introductions taken from other books.
- A printed book is unlikely to be available everywhere there might be an interested reader, but a free, downloadable book is available anywhere a net connection can be found.
For the purposes of updating and creating other sorts of derived works, having the "original" source of a free document is important - though not absolutely necessary. If nothing else is available, a free license, a scanner, and some sort of character recognition software can fill in. Translations and distribution do not necessarily require source; PDF files may be all that is required. Since not all free licenses are driven by the same goals, they do not all require the distribution of a machine-editable version of the text.
Documentation licenses address one other area which is typically not an issue with licenses applying to code: that of artistic integrity. Some authors feel that their words should be distributed intact, or not at all; others insist that certain types of material not be removed from their works. A survey of documentation licenses will find a number of "thou shalt not modify the text" terms. Such licenses will, for the purposes of this article, be considered non-free. A document which cannot be modified resembles a program which cannot be recompiled; it may have its uses, but it is also a dead end.
Creative Commons
The Creative Commons project is trying to address the current impoverishment of the public domain by encouraging the release of artistic works under any of a set of licenses. Many of the creative commons licenses forbid the creation of derived works or any sort of commercial use; they are thus, by this survey's standards, non-free. There are two licenses which lack those terms, however, being the Attribution 2.0 and Attribution-ShareAlike 2.0 licenses.
The Creative Commons licenses are explicitly written as contracts; they read:
The Attribution license allows the creation and distribution of derived works. Distributed copies must include a copy of the license - or at least a URL pointing to it; additional restrictions may not be imposed on the original work. Any distributed copy must include attribution giving credit to the original author, along with the author's URL pointing to the original version. The "ShareAlike" version of the license is GPL-like in that it requires derived works to carry the same license.
Interestingly, the Creative Commons 2.0 licenses explicitly disclaim any warranty or indemnification. Earlier versions of the license offered a warranty by the author that he or she was entitled to offer the work under those terms.
The Creative Commons licenses say nothing about the format in which works are distributed. By your editor's reading of the licenses, distribution of a derived work in PDF format, with no availability of the work in its original format, is allowed.
The GNU Free Documentation License
The GNU Project's recommended license for documentation is the Free Documentation License; it is complicated and, by some accounts, not truly free. In places, the FDL has clearly been written with the idea of furthering the Free Software Foundation's particular goals.The FDL is GPL-like, in that it allows the creation and distribution of modified versions, but any derived versions must carry the same license. The FDL places limits on modifications, however. Any derived versions must carry the original's "History," "Acknowledgments," and "Dedications" sections, along with a full copy of the FDL. Beyond that, however, the FDL creates the concepts of "invariant sections" and "cover texts"; these features of the FDL are at the heart of the disagreement over its status as a free license.
An invariant section is not allowed to address the primary topic of the text. Instead, it deals with the "relationship" between the author(s) and publisher and the subject:
The FDL requires that all invariant sections be included in any derived work, and that, as indicated by their name, these sections not be modified. The purpose of invariant sections is clear: it enables the GNU project to include the GNU Manifesto (and related texts) in manuals and to forbid its removal. Thus, documents can be made to serve two roles: describing the subject matter of interest, and promoting the agenda of the group which created the document.
"Cover texts" are short passages which must, in some conditions, appear on the front and back cover of any distributed copy of the work. Use of cover texts is only required when over 100 copies are being distributed. Distributing large numbers of copies also obligates the distributor to make a "transparent" version of the document - one which is machine editable - available. The "transparent" copy need not be the original source; a plain text file stripped of markup will do. People who distribute a small number of copies can, if they wish, distribute them in an "opaque" format which does not allow editing.
An FDL-licensed work with no invariant sections and no cover texts is, by most peoples' reckoning, free. The inclusion of text which cannot be modified or deleted obviously changes the picture, and many people consider documents with those features to be non-free. Certainly the FDL makes certain types of derived products, such as those using an excerpt from an FDL-licensed work, difficult. An author wishing to take a few sections from the GNU emacs manual must drag along the entire FDL, the entire GPL, the GNU manifesto, the "Distribution" section, and the cover texts as well. In practice, these requirements will make that sort of use almost impossible.
The FDL makes no statement with regard to warranties or indemnification, other than to note that the document may carry warranty disclaimers outside of the license. It is also careful to note that warranty disclaimers cannot modify any other aspect of the license.
Open Publication License
The Open Publication License (OPL) dates back to 1999. Among other things, it is used for the Perens Open Source Series of books. The OPL is a relatively simple license; it allows redistribution of works, with or without modifications, in any format. The distributed copies must be licensed under the terms of the OPL, but nothing in the license requires that an editable version be made available. Modified versions must include a pointer back to the original, along with the usual notifications that changes have been made. The OPL includes a warranty disclaimer.
In its plain form, the OPL is a free license. It includes two "options," however, which can change the situation. "Option A" is a prohibition on the distribution of "substantive" modifications - essentially anything beyond reformatting or typo fixes. "Option B" is a restriction on commercial redistribution. If either of these options is exercised, the license becomes non-free. There does not appear to be anything prohibiting a person who distributes a derived work from adding options to the license, even if the original author chose not to use them.
The Creative Commons licenses and the FDL both include prohibitions on the use of "technical measures" to deprive recipients of the works of their rights under the license. The OPL, like many older licenses, has no such requirement. An OPL-licensed document could, conceivably, be distributed in some sort of DRM-infested electronic book format that, in practice, deprived the reader of the right to copy or modify the document.
Common Documentation License
The Common Documentation License was published by Apple Computer in 2001. It is a GPL-like license, requiring that all derived works carry the same license. It makes no requirement regarding credit to the original author beyond stating that copyright notices must be preserved. Derived works need not carry a pointer back to the original. Distribution in any format is allowed, with no requirement to make an editable format available. There is no restriction on the application of DRM schemes to CDL-licensed works. This license does carry a strong warranty disclaimer.
Design Science License
The Design Science License is, perhaps, the most direct attempt to translate the GPL into the world of text. It allows the usual freedoms, but requires that all derived works carry the same license.
The DSL takes a strong approach with regard to editable formats; it requires that any person distributing the document make it available in "the preferred form for editing." This requirement is rather firmer than the FDL's terms; a plain text file will not suffice unless that is how the work was created in the first place.
There is a warranty disclaimer in the DSL, though it does not explicitly disclaim warranties of noninfringement.
Conclusion
A significant amount of documentation has been released under the BSD license or the GPL. Putting a BSD-like license on a document makes some sense; it allows any sort of use as long as the copyright notices are preserved. Putting the GPL onto a document makes the author's intent clear in an informal sort of way, but the GPL was not written for this sort of application. The GPL refers explicitly to "programs" and acts like compiling and running programs; how such language applies to documents is unclear at best.
So which license would a grumpy editor use? Your editor co-authored a book which was released under the FDL. But the next edition is unlikely to go out under that license; the restrictions imposed by the FDL are simply too heavy. Any of the remaining licenses described above would probably be usable, though one of the licenses with a copyleft term looks preferable. No decision has been made on that subject; stay tuned.
Posted Oct 27, 2004 0:57 UTC (Wed)
by piman (guest, #8957)
[Link] (3 responses)
"Most peoples'" is, I think, an overstatement. I don't know anyone (except possibly the editor) who thinks this, and doesn't also think that a document with invariant sections and cover texts is still free. The remaining problems are not fundamental to the FDL (I think), but they do exist in its current version, and present real issues. The definitions of "transparent" and "opaque" copies leave much to be desired (and prevent "transcoding" to a new preferred format, which the GPL allows), and the anti-DRM restriction prevents even simple things like transferring the document over an SSL-encrypted channel.
http://people.debian.org/~srivasta/Position_Statement.xhtml outlines these problems. It mostly focuses on the aforementioned invariant sections because those are usually the biggest point of contention, and the most complicated issue (and also more philosophically fundamental, while the rest are technical in nature). But there are other real problems with the FDL which make it impractical and non-free, that are all-too-often ignored.
Posted Oct 27, 2004 23:50 UTC (Wed)
by hmh (subscriber, #3838)
[Link]
The GFDL has its place, even as it is now. But that place is well away from any free software project.
Posted Oct 28, 2004 14:45 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (1 responses)
He wrote explicitly about that topic. So, why do you raise that straw man? Just to post the Debian link? You might have just done so, with a subject line "Debian viewpoint" or similar, that would have been better and more honest, IMNSHO.
Joachim
Disclaimer: As a member of the LaTeX team, I'm biased when it comes to the Debian Legal folks or on any Debian viewpoint on "free licenses". I would have never had the patience of Frank or David to discuss license issues with people who insult developers with every email they write. They're more hilarious than rms, and that's sometimes hard to do.
Posted Oct 28, 2004 22:36 UTC (Thu)
by piman (guest, #8957)
[Link]
Why are you so confrontational? Of course I read the original article -- I quoted it, and responded to it.
> It said "a work without invariant sections and without cover texts" is considered free. The context gives a reasoning - because then all the work can be changed and that is considered "free by most persons".
And I'm asking Jon why he thinks that. Most people I know who have looked at the FDL either come to the conclusion it's all free, or even documents without invariant sections are still non-free because of the issues I cited.
> Then you jump to a related, but different topic and write about "work with invariant sections and with cover texts" and you use "is still free" as an implication that the editor meant that.
I what? I thought my point was clear, but let me try again: In my experience dealing with the FDL, I find people who either consider it free, with or without invariant sections, and people who consider it non-free, with or without invariant sections. I do not find people who fit the editor's assertion of "most people", that think it's free without invariant sections but non-free with them. On the rare instances I do talk to such people, they are usually totally unaware of the DRM clause, and change their mind after learning about it.
> I would have never had the patience of Frank or David to discuss license issues with people who insult developers with every email they write.
I'm sorry you feel that way about some Debian developers. I have nothing but respect for the achievements of the LaTeX team, and apologize if you feel I insulted your efforts in any way. Not all Debian developers, even those on debian-legal, are Andrew Suffield.
Posted Oct 27, 2004 1:47 UTC (Wed)
by dlang (guest, #313)
[Link] (4 responses)
given the variety of tools and formats available what is easily editable to one person may be completely useless to another person.
I've been known to create postscript files directly from vi for example, many people would not consider .ps files editable, but the content may not exist in any other format.
I agree that the idea of making a document unable to be modified makes it less useful, but at the same time I don't believe that all documents should need to be modified (exerpts pulled from them possibly, but not the same document modified) an example of documents in this class are the internet RFC's. there are all sorts of reasons to use parts of them in other documents, but absolutly no reason for anyone to modify a document and call it RFC3501 for example.
Posted Oct 27, 2004 10:53 UTC (Wed)
by jamesh (guest, #1159)
[Link] (3 responses)
The "the preferred form for editing" language in the DSL license seems to cover that. PostScript might be the preferred form for editing certain documents, but if I generate the postscript with tex/dvips it certainly isn't. This mirrors the case of software, where assembly might be the preferred form for editing for some programs while not being acceptable for other programs.
Posted Oct 27, 2004 18:02 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
if yu had a programming toolchain that had you write your program in language A, run a tool that converted it into fully commented source code for language B, run a second tool that converted it into fully commented source code for language C, and then converted the result into machine code you could concievably prefer to modify the program in language B or C instead of A that the origional author used and it would be a far closer match to the documentation situation
Posted Oct 27, 2004 19:02 UTC (Wed)
by bfields (subscriber, #19510)
[Link] (1 responses)
There are cases where it may not be clear which the preferred form is. There are also very common cases where it is quite clear (you probably don't hand-edit the postscript produced by latex/dvips or the average wordprocessor).
I'm having a hard time seeing how ambituity in the choice of preferred format is likely to cause a real problem in any case--the case we really want to prevent is someone modifying documentation and then claiming they only need provide you with some obfuscated version (nothing but the output of xfig->latex->dvips->ps2pdf for you!), in which case there's not really any ambiguity.
Posted Oct 29, 2004 20:37 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
Yeah, I've always hated the "preferred form" standard.
What we really want is just to stop someone from withholding the source code that he has as a means of stopping others from building on his work.
The requirement should be that you have to make available what you worked with to make the file you distributed. If you typed in a .o file with a hex editor, the .o is all you have to provide. If you used a special in-house markup language that you machine-translated to latex and then to dvi and then to Postscript that you distribute, you should have to provide the in-house markup on request.
Posted Oct 27, 2004 4:10 UTC (Wed)
by hisdad (subscriber, #5375)
[Link]
I'm sure it will bring a smile in these dark and depressing times of
Ever Yours,
*** PS remember to disconnect the AC adapter on your laptop
Posted Oct 27, 2004 7:36 UTC (Wed)
by atai (subscriber, #10977)
[Link] (2 responses)
Posted Oct 27, 2004 16:31 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
I've known, worked with, and argued with RMS for many years, and I wish I could agree, but I'm not hopeful. The Debian objections to the GFDL have been out for at least a year; moves to fix the problems have not made any progress.
There are two classes of problems with the GFDL: one class are technical difficulties, and the other class are fundamental differences of opinion. The DRM-related problems, one could argue, are just mistakes that could be corrected without anyone losing face. It appears that the goal was to prevent people from using DRM to make an allegedly-free document uncopyable; it would suffice to say that if you provide a DRM copy, you have to tell people how to get an unencumbered copy. Some of the other issues Debian has complained about can also be solved without too much
difficulty.
The invariant sections issue, though, is one that I can't imagine RMS giving any ground on. I'm afraid that the best we'll be able to do is get a fixed GFDL in which a document that lacks invariant sections and cover texts could be agreed by everyone to be free. Then everyone could agree that, for example, the Gnome documentation is free.
RMS has also suggested that the problem of GPL-GFDL incompatibility could be remedied by a combined license, good for both software and documentation. It would be a complete disaster if the combined license were considered by any influential group (such as Debian) to be non-free. I don't think that this would happen in the end, as the FSF would lose most of its volunteers, and RMS is more pragmatic than he is sometimes given credit for. But just the fear that this would happen is good reason to try to fix the GFDL first.
I think that the "open source movement" has made RMS more determined than ever to stick with the "invariant sections" doctrine, since he sees open source as free software without the free software principles, and he is determined to spread the word about what he sees as the principles.
Posted Oct 28, 2004 22:16 UTC (Thu)
by atai (subscriber, #10977)
[Link]
Posted Oct 27, 2004 10:59 UTC (Wed)
by cantsin (guest, #4420)
[Link] (10 responses)
At the
institution where I currently work, Piet Zwart Institute for Media Desig nin
Rotterdam/Netherlands, we are in the final stages of putting out a 100-pages
Open Content Licensing Guide which compares all existing open content
licenses and describes their particular aims, advantages and drawbacks. The
text was principally authored by Lawrence Liang, a lawyer and member of the
Alternative Law Forum in Bangalore. At the moment, I can only provide a provisional
link to Lawrence's project page, but the guide will be published both in
print and be downloadble under the Creative Commons
Attribution-NonCommercial-ShareAlike License.
Posted Oct 27, 2004 14:22 UTC (Wed)
by zlynx (guest, #2285)
[Link] (6 responses)
Why would that be otherwise?
Posted Oct 27, 2004 16:37 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link] (5 responses)
It is a problem. Short code examples can be included based on "fair use" even when the licenses conflict, but anything more substantial cannot be moved from a GPL'd file collection to a GFDL'd file collection or vice versa without all the copyright holders agreeing to a license change.
For example, you might like the example calculator program in the Bison manual; you might want to take it, enhance it a bit, and distribute it.
But you can't mix it with any GPL'd code, and you might need a lawyer to help you figure out what you have to do to distribute the executable.
Posted Oct 27, 2004 16:44 UTC (Wed)
by kimoto (subscriber, #5244)
[Link] (4 responses)
Posted Oct 28, 2004 5:07 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted Oct 28, 2004 6:54 UTC (Thu)
by dmantione (guest, #4640)
[Link]
Posted Nov 4, 2004 8:56 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
In practice we get away with it under common law (and bringing lawsuits is expensive - the doctrine of "loser pays" and "plaintiff pays for nuisance suits" means prosecution is unlikely).
As an example - I make a "fair use" quote. The copyright owner sues me. I offer to pay the value of the work. The owner is now in a dilemma. If he accepts my offer, he's paid hundreds of pounds of court fees and got tens of pounds in copyright fees back (I don't have to pay his costs). If he *doesn't* accept my offer, and then the judge/jury accept my offer as reasonable, he not only has to pay *his* legal costs, but *mine* *as* *well*.
Lawsuits just don't happen under those sorts of rules ...
Cheers,
Posted Nov 4, 2004 8:58 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Oct 27, 2004 18:07 UTC (Wed)
by dlang (guest, #313)
[Link]
Posted Oct 28, 2004 9:09 UTC (Thu)
by dvrabel (subscriber, #9500)
[Link] (1 responses)
Posted Oct 28, 2004 22:39 UTC (Thu)
by piman (guest, #8957)
[Link]
Posted Oct 27, 2004 12:56 UTC (Wed)
by mwh (guest, #582)
[Link]
I *like* the Grumpy editor articles :-)
> An FDL-licensed work with no invariant sections and no cover texts is, by most peoples' reckoning, free.The Grumpy Editor's guide to free documentation licenses
Indeed. Whatever the GFDL at its current form is, it is NOT a Good Thing when applied to free software documentation, unless we are talking about "external" documentation, such as books.GFDL not good for free-software documentation
I don't understand your post, or maybe I do... Did you read the OP? It said "a work without invariant sections and without cover texts" is considered free. The context gives a reasoning - because then all the work can be changed and that is considered "free by most persons". Your reply starts with a personal account of people you know, but without any context and any arguments. Then you jump to a related, but different topic and write about "work with invariant sections and with cover texts" and you use "is still free" as an implication that the editor meant that.The Grumpy Editor's guide to free documentation licenses
> Did you read the OP?The Grumpy Editor's guide to free documentation licenses
one term that you used frequently that I see as an issue is the refernce to an 'editable format'The Grumpy Editor's guide to free documentation licenses
The Grumpy Editor's guide to free documentation licenses
given the variety of tools and formats available what is easily editable to one person may be completely useless to another person.
my point is that the prefered form for editing is going to be different for different people on the same document. it's a very nebulous term, far more so then for programs where there's a very obvious difference between source code and the binary result.The Grumpy Editor's guide to free documentation licenses
The Grumpy Editor's guide to free documentation licenses
my point is that the prefered form for editing is going to be different for different people on the same document. it's a very nebulous term, far more so then for programs where there's a very obvious difference between source code and the binary result.
preferred form
Dear son,Subversion
I suggest you examine the subversion project.
Not just great software, but a great _book_ as well!
Just the sort of thing to read while relaxing dreamily in a hot bath ***.
universal brough-hahah.
dad
or I'll never have grandkids.
The FSF listens to people. The FSF may address your criticisms in the future versions of the FDL.Do not count out the FDL for your next book
Do not count out the FDL for your next book
Never say never :-)Do not count out the FDL for your next book
Thanks for this excellent article which sums up the current issues of open
content licenses nicely. There is, however, yet another troublesome issue
for Free Software documentation released under free documentation/open
content licenses, namely the incompatibility of those licenses with the GPL
and BSD licenses. They become a problem in two cases:The Grumpy Editor's guide to free documentation licenses
I don't see a solution for this problem except a more
generic GPL revision 3.0 that speaks more generally of "works" than of
"programs" and thus is applicable to digital data as well.
#2 is not a problem. Code samples in documentation are obviously quotes and covered under the same rules as quoting from a text document.The Grumpy Editor's guide to free documentation licenses
The Grumpy Editor's guide to free documentation licenses
On debian-legal, it is often asserted that there are jurisdictions where there is no such thing as "fair use". (IANAL so can't pass judgment on that.)The Grumpy Editor's guide to free documentation licenses
Such assertions are demonstrably wrong. Without fair use, you couldn't quote even the tiniest portion of a copyrighted work, or even read aloud (what? you are performing the work without the explicit permission of the copyright holder!) and I know of no country where people fear prosecution for quoting one line of a book. That shows that everyone has some concept of fair use, even if they don't call it that.
The Grumpy Editor's guide to free documentation licenses
They do not exist in the EU, which is a larger market than the US. Instead the US has quotation rights, which allow you to quote from a document. It is a lot more restrictive than fair use.The Grumpy Editor's guide to free documentation licenses
I'll give you an example of a jurisdiction where there is no *statutory* concept of "fair use".The Grumpy Editor's guide to free documentation licenses
Wol
Whoops - I didn't say what exactly that jurisdiction was. It's pretty clearly mine, the UK.The Grumpy Editor's guide to free documentation licenses
Wol
GPL version 3 is going to have some problems in solving the problem. while the 'default' GPL license is 'GPLv2 or newer' there are a number of projects (including the linux kernel) that are 'GPL v2' instead and it's going to be practicly impossilbe to get hold of all the authors to get them to agree to re-license these projects under a new license, even if that license is GPLv3The Grumpy Editor's guide to free documentation licenses
Code examples in documentation should surely be public domain? They're supposed to be copied and incorperated in other programs. Perhaps the documentation license needs a clause making this explicit.The Grumpy Editor's guide to free documentation licenses
More problematic is the case where the program itself contains significant portions of its documentation, like LaTeX or Emacs. In these cases, you need to move arbitrary text between the documentation and the program, not just code samples.The Grumpy Editor's guide to free documentation licenses
> Free software changes rapidly; its documentation has, in rare cases, been The Grumpy Editor's guide to free documentation licenses
> known to lag a little behind.