Why documentation and programs should not be treated alike
>The main difference between a program and documentation is that a
>program does something, while documentation is passive;
By this argument, source code to a program (of the sort which must be
compiled to run) is not a program.
That's a pedantic approach to the issue. I'd say a source program
does do something (after you compile it).
And can therefore, in your opinion be
encumbered by unlimited numbers of Invariant Sections (presumably in
'mandatory comments') while remaining free, as long as they can be removed
from the actual executable binary, I suppose.
I think that nontechnical invariant comments do not make a program
non-free, but not for those reasons. The reason is that this is a
packaging requirement that doesn't really restrict you from making the
program substantively behave as you want it to.
Furthermore, a manual in any markup format (LaTeX, HTML, info, texinfo) is
not passive: it does something, namely generating the actual manual in the
intended-to-read format (printed, visible on screen in 'info' or 'mozilla',
etc.) So manuals in any markup format -- including all the GNU manuals --
are thus akin to programs, and should be judged by those criteria.
That's focusing on form rather than substance. A manual typically has
source code which contains markup, and that is formally analogous to
the source code of a program. But in substance the two cases are
completely different.
In the compiled form of a program, you can't see anything important
about it. If even the comments are missing, you can't understand the
important aspects of the program. Thus, access to the real source is
essential for a program to be considered free.
In the "compiled" form of a manual, as long as there is no DRM to stop
you from reading it, everything that matters is plain to see. You see
the contents, and you even see the fonts and indentation that were
selected by the markup. The markup commands, which you don't see, and
any comments in the markup, are far less important than what you do
see. If you can read the published manual, what you see is everything
that really matters.
This is why the GFDL does not require "complete corresponding source
code" for a published manual. It's easier to change the manual if you
have this, but no disaster if you don't: you just have to write your
own mark-up, which is pretty straightforward. The requirement for a
transparent copy is so that you don't have to keyboard the whole text
again in order to publish a modified manual. Even that is not
impossible, but it's a bigger pain than writing mark-up afresh. (I
think the right thing to do is to distribute the complete
corresponding source code.)
> For manuals, there is a real danger that the
>"source" will be in a format that free software cannot read, and thus
>useless.
The same danger *does* exist for programs, and happens often: a 'free'
program written in an interpreted language with no free interpreter or
translator is effectively non-free in exactly the same way. Yet there is no
similar clause in the GPL.
These are two different kinds of problems, two different issues. A
program in a language with no free interpreter is nonetheless
transparent if the language is documented and the source is legible.
To be non-transparent, it would have to be obfuscated (and then it
would not be the real source code, so the GPL would reject it).
Conversely, the GFDL does not require the transparent copy to be
processable by a free text formatter.
To write a program in language A can be very different from writing it
in language B; it is not really the same program. But whatever text
you want to write, you can write it in any word processor or text
formatter, and it is the same text. And any word processor can
store the text in a transparent format.
Thus, it is too much to insist that everyone program (or write markup)
in languages with free implementations, but any manual can easily be
published in a transparent format.
>Another difference is that DRM systems to stop people from accessing
>documents are a real threat to our freedom, and we need to try to push
>against them in any way we can.
Not a difference. They're being applied to programs too.
Not in the same way, though. DRM is often used to stop you from
reading the contents of a document, and could be used to restrict even
a free document. When DRM is put in programs, typically those are
non-free programs, or else they restrict running modified binaries on
a certain machine. They are both important issues, and what to say
about DRM in GPL version 3 is a hard problem, but it wouldn't be
anything like the DRM clause of the GFDL.
Literate programming styles encourage
documentation to be extracted directly from program source code, and
documentation to be embedded directly in program source code.
I agree with you that it is a drawback to be unable to intermix the
program code and the documentation. But this drawback has nothing to
do with any of the specific features of the GFDL that have been
criticized here. The old simple documentation license that we used
for most GNU manuals years ago, which nobody here has claimed was
non-free, would give you the same consequence. The problem is simply
due to the fact that the software and the manual have incompatible
licenses.
You also cannot combine code from Apache and code from Emacs. They
are both free, but they have incompatible licenses.
Reply to: