Free software needs free documentation

Let's discuss a not so hypothetical situation. You are a (free) developer trying to get your crypto library FIPS 140 certified. You want to do this because it is the US Federal standard for properly implemented crypto and it is hard to use in the Federal space without it. Ignoring the fact that you need a third party lab to validate your work, you quickly hit a documentation problem.

FIPS standards are publicly available on NIST. That's great. But they in turn reference lots of other documents and expect you to follow the latest version of those documents. That is fine as long as other NIST documents are referenced. However references to ISO and ANSI documents do slip in. Each of those documents is a few hundred dollars a piece. You must comply with the contents of those documents in order to be certified. As a free developer, you now have a non-free documentation problem.

But note that this is a distinct issue from what RMS's essay is talking about! (The confusion owing to the word "free" being overloaded in English.) "Free documentation," as defined in the essay, means documentation that can be copied and modified, and RMS gives this as justification for those 2 freedoms:

> Redistribution (including commercial redistribution) must be permitted, so that the manual can accompany every copy of the program, on line or on paper.

> But there is a particular reason why the freedom to modify is crucial for documentation for free software. When people exercise their right to modify the software, and add or change its features, if they are conscientious they will change the manual too—so they can provide accurate and usable documentation with the modified program. A manual which forbids programmers from being conscientious and finishing the job, or more precisely requires them to write a new manual from scratch if they change the program, does not fill our community's needs.

The ISO and ANSI standards that the software conforms to don't really meet either of those justifications:

Copy: A user of GCC doesn't need to read the ASNI standard, the GCC manual is plenty good for explaining how to write C that GCC understands. A user of your crypto library doesn't need to read the FIPS standards to learn how to use your library. The standards are useful to the developers of the software, not the users; so the standards needn't accompany every copy of the program.

Modify: A lone programmer working on GCC has no business editing the standards. Agreement between multiple parties is the entire point of the standard; it doesn't make sense to grant permission for just anyone to make edits. RMS is generally pretty clear there are many types of writing that he doesn't believe you are obliged to grant permission for others to edit.

That said, the situation with non-gratis standards is problematic, it means that there's a monetary moat around contribution. But this is an entirely orthogonal problem to what's discussed in "Why Free Software needs Free Documentation".

PS: I particularly enjoyed the unification/gravity analogy btw :-D >.<

That's a strange reading. I can see it interpreted as forbidding storing the document on a workstation that is locked-down to prevent exfiltration of sensitive data (and such a system would almost certainly also use an encrypted FS among other measures), but forbidding the use of an encrypted FS per-se seems extreme. All an encrypted FS is doing by itself is ensuring that if you don't have access to the content, then you don't have access to the content.

Nothing about the GFDL forces anyone to redistribute, it just ensures that recipients have the right to redistribute. By itself, an encrypted FS is no hindrance to redistribution.

(Though there may be other advantages such as print distribution, brand recognition, and iconic animal covers. Tim O'Reilly also seems like an interesting guy.)