Website - Debian GFDL Dissent
Website - Debian GFDL Dissent
This page explains why I take issue with the outcome of Debian Vote 2006-1.
Invariant sections in manuals are acceptable because they do not hinder a manual in its purpose. The purpose of a manual is to inform, while the purpose of software is to be executed to achieve some effect. Manuals are not functionally equivalent to programs, and so the same criterion for "Free" should not apply to them. The result of labeling both manuals and programs as "software", and using this as a basis to make arguments for why manuals should not have invariant sections, is fallacy.
As some have pointed out, supposedly the DFSG does not use the word "software" explicitly, but uses "components" instead. That's irrelevant: the DFSG stands for "Debian Free Software Guidelines", and hence the DFSG ought not to make claims about its non-program "components". Debian really ought to make a "Debian Free Content Guidelines" document that explicitly spells out its guidelines for non-program parts that it distributes, such as fonts, manuals, pictures, and sound samples.
This page on the GNU website explains why the GNU Project uses the GFDL for manuals rather than the GPL.
The last two paragraphs of that section in particular illustrate the context in which invariant sections are acceptable.
This page on the GNU website explains in more detail the kind of sections which may be invariant, and the reason for making for some parts invariant.
No. My opinions are my own, and are not necessarily those of the GNU Project as a whole.
The issue is not so simple as "can't change == not Free". (I could also answer the question with another question: what part of allowing a position statement to be defaced and passed off as the original statement is Free? But that doesn't get us anywhere.) Technical content in manuals indeed ought to be changeable always, but the issue is not so clear with position statements.
For position statements, we really need to define an acceptable context for "change". One such definition is to say that invariant section can be changed in an acceptable manner by including a reply before or after one, such as "this is the position of the X project, and does not necessarily reflect the views of the developers of <derivative manual work>." In the context of an invariant section which contains an opinion, this is a sensible way to modify one.
From an ideological perspective, we can view distributions that wish to change or remove opinion statements as no different than censors who wish to silence the opinions of the author and abridge his or her freedom of speech.
It feels deceptive to just say something like "Debian wants everything to be free".
What I am really arguing is that this word "free" should be taken in context with the intended use of the software. or manual, or image, or other sort of content that a computer can be used to store.
What is minimally necessary to make source code "free" does not have to be (and ought not to be, I assert) precisely equivalent to what is minimally necessary to make documentation "free", just as we would not expect the requirements of "free beer" (consumption without cost) to be the same as "free software" (not just consumption, but various policies regarding distribution as well). To say otherwise is a gross simplification in my opinion.
I suppose you could say that an everything-is-free-as-in-free-source-code operating system might be more morally desirable for some unfathomable (to me) reason than a all-source-code-is-free-source-code operating system. The former OS might be simpler to understand in terms of what goes in and what can't go in, but please, please, be aware of the cost of such simplification.
To use an analogy, it isn't usually considered desirable to lop off a
hand to cure repetitive stress injury (after it heals, the end result
is a simplification). It would, however, be considered desirable to
remove a hand that is infected with gangrene or a very fast-spreading
cancer, rather than trying to deal with smaller units. GFDL'd manuals
distributed with Debian are at worst only on the level of RSI, and not
on that of a cancer that could destroy the Debian project if left
unchecked. I challenge anyone to assert otherwise :^) .
"Freedom of information" is a very broad goal, and hence should have many, many fewer hard guidelines than the DFSG has, in order to be fair and effective. I would not trust myself (or even the FSF) to craft such a broad definition at this moment of time. And given that Debian has not shown itself to be capable (in the past, as far as I can recall) of reaching consensus on their own Debian Swirl logo/trademark license, I highly doubt that they are qualified to provide such a definition.
I really think Debian's vote on the GFDL was a "yuck" response due to some misguided and lacking-in-credibility piece-by-piece dissection of the GFDL by a few Debian developers, rather than some serious attempt to make a unified set of Free Information guidelines.
It might be very useful to have a consistent and globally agreed upon set of guidelines for use of the word "free" which make sense in all forms of information, in all cultures, and arouse the same sentiments in all countries. But I don't think that it is yet possible. Perhaps Debian is angling for such a definition, in hopes that it turns into another de facto standard (such as the DFSG becoming the Open Source Definition). At any rate, there's some free advice — make of it what you will.
The program would still be free, just undesirable. Just because invariant sections might invoke unpleasant feelings in some Debian developers, does not mean that documents with invariant sections are (or should be considered) non-free.
Freedom is not a feeling or a reaction or a sensibility; it is the absence of (or exemption from) a particular kind of tyranny. In the case of Free Software, it is essentially (rewording the four freedoms of the Free Software Definition):
Sensible has nothing to do with Free. Just because the GFDL can be used as a vehicle for adding (perhaps unpleasant) statements in manuals does not mean that it should be prohibited.
If there is a serious concern about this sort of content getting into Debian (and not just a hypothetical edge case that goes against the common sense of 99% of all software maintainers, and perhaps 99.9999% of those who maintain very popular programs), it makes much more sense for those who approve packages for inclusion into Debian to exercise discretion in what sort of content they allow in. If some written standard is desired, it is far better to make a Debian Acceptable Content Guidelines document rather than to throw out the baby with the bathwater. (Though I doubt that such a document could be made and voted into effect due to how closely that approximates censorship — "leave it to the discretion of the archive managers" seems more acceptable).
An additional consideration, particularly for Front-Cover and Back-Cover texts is fairness to the author and publisher. One example is the need to provide a written offer to provide source code via mail. Even if one might not think that this is a burden, some publishers do indeed seem to think it one. A burden is also placed on authors who try to get a book published, given that some publishers balk at providing source code on CD or via a written offer.
Dual-licensing an entire program or manual is, in my opinion, wishing a problem away, rather than dealing with it. There also remains the problem of finding a publisher, which is mentioned in the previous topic.
In short: it cripples Emacs, especially for newbies that I introduce
to Emacs, by removing the manuals. It also causes defacement of the
file THE-GNU-PROJECT and the invariant section "Manifesto" in the
Emacs manual, which were my very first exposure to the ideals of the
GNU Project and the Free Software movement. This provokes a very
strong emotional response in me, which I have tried to keep out of
this FAQ.
One of my hats is that of Emacs Advocate, and I feel bad advocating Emacs to someone if they can't get instant help via the manual and its tie-ins in the documentation strings for various Emacs functions (not to mention those of the Customize interface, which helps people discover functionality and options). So now I must advocate Ubuntu instead of Debian for people who are new to both Emacs and GNU/Linux operating systems, in order to act according to my conscience.
Another thing that annoyed me about the vote proceedings themselves is the issue of legal experience. The people behind the draft position statement did not have nearly as much experience as the GNU Project, which consulted lawyers while making the GFDL. So I have my doubts as to whether some of the criticism of the GFDL on that page is really merited.
Additionally, I think it is very important to consider the negative consequences of a decision before making it, and I don't feel that said consequences were taken into serious consideration by those who proposed the vote.
![[FSF Associate Member]](/static/logos/fsf-member.png)
