The goal of invariant sections, ever since the 80s when we first made
the GNU Manifesto an invariant section in the Emacs Manual, was to
make sure they could not be removed. Specifically, to make sure that
distributors of Emacs that also distribute non-free software could not
remove the statements
Several Debian developers have claimed that they are working with the
FSF to make the GFDL DFSG-free and GPL-compatible, specifically:
I think I see two misunderstandings here. Just who has misunderstood,
I cannot tell.
First, as far as I have heard, Debian has not yet voted on the
quest
> Nowadays we have to struggle constantly against the tendency to bury
> the free software movement and pretend that we advocate "open source".
"Let those who fight monsters take care lest they themselves become
monsters." - Friedrich Nietzsche
That danger always exists, but it ca
At a cost. While I understand the desire for the invariant sections, it
can be wondered what freedom is most desirable: the freedom to run,
study, redistribute and improve for everyone, or the freedom to run,
study, redistribute and improve for only those that agree with your
ph
Now, the World Wide Web exists. And the FSF has its own website.
Anyone who looks at the attribution of any FSF program or manual
can probably find the website. People who have never seen an FSF
program or manual can find the website, too. The website will
always contain the
>It's not just a continuation of the status quo that is taking place
>here. The FSF has adopted an expansionist policy with respect to
>Invariant Sections.
The choice of words in this text that you cited indicates a desire to
cast the FSF's actions in a harsh light. I think that the
> We need every method of informing them that we can get.
Then why not go the Reiser[3] way and require that an advertisement
for the Free Software movement be printed out at every interactive
invocation of a GNU derived GPLed program?
A long message at startup would be very incon
You are correct that Debian has not yet voted on whether or not to allow
GFDLd works into its distribution. The consensus of debian-legal is that
works under the GFDL does not meet the DFSG.
I hope that the Debian developers will vote to include GFDL-covered
manuals in Debian. Whateve
It's true that many have gladly taken GNU software while ignoring the
GNU philosophy (or actively working against it). But I doubt that
invariant sections alone can ensure that the message will be heard.
Such things are very hard to estimate. What is clear is that one does
not use a
> We are the ones who first started to say that documentation should be
> free, and we are the ones who first wrote criteria for free
> documentation.
I don't see how this is relevant.
It's relevant in the context where I stated it: as a response to an
accusation that implied we i
> I hope that the Debian developers will vote to include GFDL-covered
> manuals in Debian. Whatever Debian decides, some amount of cooperation
> ought to be possible between the GNU Project and Debian.
You are asking for one-way cooperation.
I'm not asking Debian to do anything f
As for GPL 3, do you intend to use clauses similar to invariant sections
or to the technical measures stuff in GFDL section 2? This is a matter
of concern on this list.
That surprises me, since I believe I sent a message to this list
answering that precise question, two or three months
I believe the FSF is not in a situation where they can talk about the
best for our users, when they prominently advocate the use of invariant
sections, and spread misinformation about non-free software we
distribute.
To accuse someone of dishonesty is a grave accusation. This
accu
I, and, to a large extent, other members of this list, are concerned
that, beyond the non-trivial freedom aspects, texts under the GFDL
will begin to suffer the same fate that code licensed under the
4-clause BSD license has.
This is an illuminating comparison, because the practica
> > And that seems OK to me. Although you can probably restrict yourself to
> > the "TERMS AND CONDITIONS" part.
This brief citation does not show what case he was talking about.
If we're talking about use of the GNU GPL as such, the preamble may
not be removed. It is, in effect, a sort
That begs the question, "are the practical problems of the GFDL
basically the same (though of lesser magnitude) than those of the
4-clause BSD license?" :)
It's pretty apparent that the majority of the people here disagree with
you about that, and have presented many, many, man
>This is an illuminating comparison, because the practical problems of
>the GFDL (and I won't claim there are none) are basically of the same
>kind (though of a lower magnitude) than those of the 4-clause BSD
^^^
Replace this with "greater m
Branden Robinson wrote:
I have seven questions for you based on this episode:
Branden is trying to make innocent things look bad; shame on him.
Given the interview itself and the note I added later, both my views
and the events involving GNU/LinEx are clear enough. So I won't
answer his ques
This clause has a direct effect on all users,
restricting the use of e.g. encrypted filesystems.
That's a new one on me. I don't think the GFDL restricts
the use of encrypted filesystems.
> The FSF has every right to publish non-free work, but Debian should not
> bend it's rules to include it.
It is just as much a bending of rules for FSF to publish such material.
We are not bending our rules, we are following them. I designed the
GFDL to follow our criteria for fre
Branden Robinson presumes that the GNU Project's decision to stop
endorsing Debian must be meant as a form of pressure. This is
complete confusion, because the GNU Project never stopped endorsing
Debian.
The GNU Project has never endorsed Debian, because ever since we first
considered the questio
Branden Robinson wonders why I do not address him in my messages. I
will not answer him, because I am not on speaking terms with him.
However, I will explain this for the sake of others. I am not on
speaking terms with him, and I don't think questions like his
deserve a response.
Typically they
You have consistently refused to engage in a serious and sustained
conversation on the subject.
About two months ago, I posted several long messages which addressed
broad classes that take in all or nearly all of the issues that have
been raised. I think an unbiased judge would recognize
IIRC, the specific section that most people are refering to is:
You may not use technical measures to obstruct or control the reading
or further copying of the copies you make or distribute.
This means that you cannot publish them under DRM systems to restrict
the possessors of
> A long message at startup would be very inconvenient, simply for being
> long, regardless of its meaning. A section of the same length in a
> manual would not cause any such inconvenience. Nobody is "heavily
> affected" by a few extra pages in a large manual.
This is not tr
> Another form of tangent is citing practical inconveniences, often
> shared with many other accepted free licenses, as if they were
> reasons to consider a license non-free.
This is incorrect. Practical inconveniences are precisely the point
in deciding whether a restriction
... the fact that either you've stopped endorsing Debian, or
you've become more vocal about it.
I have never endorsed Debian, because ever since it became mature
enough to be technically suitable, it had the problem of recommending
and including non-free packages. Of course, the other a
That's not a serious and sustained conversation. Such a
conversation would require that you seriously and carefully attend to
all the questions that other people ask, even the ones that make you
mad, even the ones that you think are attacks, even the ones that you
think are unf
> The term "heavily affected" is still an exaggeration. In any case,
> the effect is simply due to incompatibility. I posted a long message
> explaining that this sort of thing is a consequence of the existence
> of incompatible free licenses.
No, you've missed the point.
Saying "you can modify the documentation, just not the invariant
sections" isn't enough, incidentally, to answer this, because the
attachment of the invariant section to the documentation *is* a
property of the documentation. (Consider if there were such a thing
on a piece of s
Not having source is a mere inconvenience; you can always decompile the
program, read the assembly, translate it back into C, etc. Not being
able to distribute the program is only an inconvenience; you can always
rewrite it from scratch.
Those words are simply an indirect way of de
> I think you have demonstrated, better than I ever could,
> that your criticism is based on an unfair standard.
It isn't unfair, precisely because I think it's a two way street.
This is the standard that applies to both sides.
This "standard" is an indirect way of claiming you ar
Then, why don't you just create your own distribution based on
Debian? Take the official CD set, remove all references to
non-free, and distribute it from your server. Problem solved.
We thought about that, and we're still thinking about it.
In the past, this sort of thing was unusu
"Other users consider proprietary manuals acceptable for the same reason
so many people consider proprietary software acceptable: they judge in
purely practical terms, not using freedom as a criterion. These people
are entitled to their opinions, but since those opinions spring from
- Maybe GNU should consider the option to provide its manuals
in two versions, one without philosophical/political/historical
texts, one as the current manuals.
I considered this possibility in the 1980s, not as an option but
rather as a potential problem. So I
Then, a license allowing to freely distribute a software or a modified
version
of this software in binary form only is free, but with a practical
inconvenience.
If you interpret my statements by stretching the term "practical
inconvenience" to the point where it means nothing any mo
But there is a difference between the GPL-required text:
...
And the GFDL-required text:
They are different, but neither of them is really short, so I think
the practical consequences are more or less the same.
[ Page 12 is the "front cover" of the GFDL'd subwork, so has just the
You can include the GPL as a separate file. It doesn't have to be
included in the derived work itself.
I explained in a message here, a couple of months ago, that this
difference in wording does not really lead to a difference in
consequences.
You have missed the point here, so I'll repeat it.
I didn't miss the point--I had not even seen it. The point you say I
"missed" was in a message that had not even arrived on my machine when
I wrote those words. I was responding to various points that I recall
having seen others make.
It ta
I don't really believe it. In the 1980s, formalized free software was a
new concept for almost everybody. Today, there are too many free
software projects for the word _not_ to get out.
My experience is just the opposite: our views are mostly suppressed.
The open source movement is v
> I explained in a message here, a couple of months ago, that this
> difference in wording does not really lead to a difference in
> consequences.
Um, yes it does. Importantly, it allows for more flexible
distribution strategies.
They allow the same distribution strategies.
So your purpose is to spread GNU propaganda in invariant sections of GNU
documentation, adding practical inconvenience where there shouldn't be.
It adds some practical inconvenience, but practically speaking the
magnitude is not great, so there's no reason not to do it.
How would you
Not the same so far. As I read it, you can have the text of the FDGL as
(Did you mean "can't"? I think so.)
a separate file in /usr/share/doc/PACKAGE/copyright, it has to be
included in the derived work itself.
I'm not sure whether your talking about the files as installed
in a ma
> My experience is just the opposite: our views are mostly suppressed.
> The open source movement is very effective at substituting their word
> for ours. I find that most of the people who use our software have
> never even heard of our philosophy.
I find that to be a cheap,
> > I explained in a message here, a couple of months ago, that this
> > difference in wording does not really lead to a difference in
> > consequences.
>
> Um, yes it does. Importantly, it allows for more flexible
> distribution strategies.
>
Someone writing
the (GFDL) manual for the GF45 compiler might have invariant sections,
but won't be willing to copy my rant into his work; better to rewrite
the section then annoy half the users.
The fact that you're talking about a hypothetical example decades away
suggests that
> The issue at hand for Debian is whether to include GFDL-covered
> manuals in the Debian GNU/Linux system. I am sticking to that
> issue.
Under the current GFDL 1.2, with the anti-DRM clause, there is
essentially no chance of that.
With all due respect, you do not necessaril
Then what is a real lack of freedom? I could use the regex code under
an invariant license;
If the license for the code did not allow modification, you could not
make it implement different behavior. You would substantively lack
the ability to change the functionality. That is a lack of
You have mistaken the objection. There is no reason to think it would
be a small fractional increase, especially since little parts of
manuals--single paragraphs even--are useful reusable bits just in the
way that single functions of Lisp are.
Reusing a single paragraph is fair us
For example, I might use a manual by tearing it into pieces and using
the individual pages as confetti for a parade. But I cannot copy
GFDL'd manuals and then do this.
I congratulate you on your imagination--it never occurred to me to
think about this as a use of a manual.
As it ha
The principal argument in favor of the GFDL seems
to be "this is the only way we can get our message out".
The GNU Project's motive for using invariant sections is not the issue
here; that's a GNU Project decision, not a Debian decision.
The question at hand is whether Debian should acc
To use one page of the GFDL-licensed work required one paragraph in the
Copyright page, the page I wanted to use, and a copy of the GFDL (so far the
same), plus:
1. the required front-cover text (on a page by itself before the excerpt:
"bracket" in the terms of the GFDL),
2.
Would you accept a similar restriction in a software license, and
still call the license free? (Say, one which said "you must always
distribute this function as part of the system".)
Yes, and the case of TeX is an example. It requires more than just
one function that you must include
They may cause practical
> inconvenience for some kinds of uses, but no more than that. The
> issue is basically the same as the issue of the preamble of the GPL.
Yes, they do. They say "you may not use this technical material
unless you also do this unrelated non-technical
The only question I intend to discuss on this list is Debian's
decision about whether to use or not use GFDL-covered manuals.
> So I think there really is no difference.
I meant that the GFDL requires you to have the license content itself as
part of the document, whereas it can be a seaprate file for the GPL.
Part of the document can be a separate file,
because a document can be more than one file.
This de
> The GNU Project's motive for using invariant sections is not the issue
> here; that's a GNU Project decision, not a Debian decision.
You are arguing that you should have a voice in what Debian does.
I have said nothing of the kind. The Debian developers decide what
Debian does, and
> You have mistaken the objection. There is no reason to think it would
> be a small fractional increase, especially since little parts of
> manuals--single paragraphs even--are useful reusable bits just in the
> way that single functions of Lisp are.
>
> R
TeX allows us to make any changes we like provided we distribute the
changed source as a patch file, and provided we change the name if the
result doesn't pass the Trip test.
Yes, but my point is that the original TeX source code must be
included in the source distribution, and you can
> It has to be prohibitively impractical in real cases. The
> inconveniences that occur in some cases with the GFDL are not
> prohibitive.
I'm a little sure what is "prohibitive". Can you flesh it out?
If you are asking for a bright line as to what is or isn't
prohibitive, I don
The argument for that is that there are many
> such manuals and they would be useful to include, and the DFSG can
> be interpreted to accept it.
The arguments appear to be:
1) There are many GFDL manuals.
2) The many GFDL manuals would be useful to include.
That's two
Recently you said you'd contact a lawyer with respect to section 2 of
the GFDL. If you've had the chance, would you mind sharing the lawyer's
conclusion with debian-legal?
We decided to clarify the text there but it will take some time
to actually do so.
Well, since Debian will contain only 100% Free Software, and I think most
of us
(and you, if I interpret your previous emails correctly) agree that GFDL
manuals are not Free Software, it would seem to be a natural conclusion
that
Debian will not contain them.
Manuals are not f
As has been previously pointed out, fair use is far from a universal
concept. Within the United Kingdom, it doesn't exist, and copying a
single paragraph from a GFDLed work would require me to fulfil the
license conditions.
I am pretty sure something along the same lines as fair us
I couldn't believe that RMS actually wrote that when I read it.
You shouldn't have believed I actually wrote that, because he
misunderstood what I wrote. He omitted a crucial part of the
argument, so that what remained was absurd; then he went on at length
pointing out just how absurd it was.
Can you give us an indication as to what the clarified text will look
like, or what restrictions it will contain? [Just so we're all on the
same page with regards to the sections problems.]
I've decided not to do that. The development of GNU licenses is not a
Debian issue.
> Manuals are not free software, because they are not software.
> The DFSG very clearly treats "software" and "programs" as
> synonymous.
And we very clearly treat everything in Debian as software (see the
first clause of the Social Contract).
That clause appears to neglect t
> Manuals are not free software, because they are not software.
> The DFSG very clearly treats "software" and "programs" as
> synonymous.
Richard, once and for all, please read
http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00690.html
Thanks for mentioning th
> I've decided not to do that. The development of GNU licenses is not a
> Debian issue.
Neither is the inclusion of GNU manuals in Debian a FSF issue.
That's what I said--at least twice in the past week.
Richard, for the sake of my blood pressure, please read
http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00690.html
(bis repetita)
When you first told me about the page, you seemed to be criticizing me
for taking o long to read it. How I could have done what you asked
The Social contract uses the "that which is not hardware" definition of
software.
The words of the social contract clearly equate software to programs.
In that sense, there is nothing but software in Debian.
But Debian contains essays, logos, and licenses that cannot be
modified. T
> Manuals are not free software, because they are not software.
> The DFSG very clearly treats "software" and "programs" as
> synonymous.
In that case, the DFSG prohibits their distribution outright.
That's one way to interpret it, but I don't think it is the best way.
The DFSG is
The "document" consists of both packages. The fact that users are not
obligated to download both at the same time is irrelevant, just as it is
irrelevant to the GPL that users can choose to download binaries without
source; and just as it is irrelevant that users can choose to d
Remember the hypothetical "emacs reference card", which must be
accompanied by 12 pages of additional invariant material? Sounds like a
big deal to me.
If the GPL were used, it would have to be accompanied by 6 pages
of additional invariant material. That is still bigger than the
But you want to be part of the discussion, right?
Debian developers on this list explicitly asked me to be part of the
discussion. They have often asked me questions, suggesting that I
send the answer to the list, and I have often done that. I don't
insist on discussing the matter here. A
The DFSG explicitly
> codifies my specific decision about TeX,=20
It does nothing of the sort; there is no mention of the word 'TeX' in
the DFSG.
Section 4 does precisely that, though without mentioning TeX by name.
In other words: I can live with Donald Knuth issuing a lic
2. The GFDL prevents you from using the technical material in the manual
in nearly any program, because most programs don't have a lot of the
specific things the GFDL refers to ("section titles", etc.), so there's
no legally clear way to satisfy its requirements.
I don't think t
If you are willing to disregard the explanation of the meaning of
a text by its author in order to reinterpret it, you're on the
wrong way. It is absurd to argue rigidly that "the DFSG obviously
doesn't say that" when its author says it is.
To point out what the words of the DFSG a
It containts detailed
mathematicly research on how the improvements were made, details which
are not evident in the source and therefore reverse engineering of the
documentation from just the source is not possible. Included in his
update to the documentation is an Invariant
If you are aware of the existence of unmodifyable essays and logos in
debian main, please file an RC bug against the package in question.
You seem to be saying that if our political statements, which are
included as invariant sections, could be removed from our manuals, you
would make a po
> If the GPL were used, it would have to be accompanied by 6 pages
> of additional invariant material. That is still bigger than the
> reference card. Do you object to the GPL on these grounds?
There's a critical difference here. The GPL can accompany the
reference card. The
Manuals, essays, licenses, and logos *encoded as bits on a
computer* are software.
Defining all these thing as software is a peculiar way to use the
word. I don't think that is the best way to interpret the DFSG,
because it leads to unnecessary inflexibility.
I do not try to tell the
>> I'm curious: Considering the GPL prohibits binary-only distribution
>> under section 3, do you still hold that position?
>
> GPL 3b and 3c deal with that quite nicely. Debian, for example,
> distributes its GPL'd software by offering the source on the same
> medium.
> The words of the social contract clearly equate software to programs.
I encourage you to look closer. The only part of the social contract
which even contains the word programs is #5, a part both of us would
like removed.
Several parts of the DFSG contain the word "program".
Ok, so for this "distribution section", I agree, it should not be
invariant as it is almost "technical" (how do I get more
information...), and the point of view of RMS about that would be
interesting.
This section explains what free software means, mention the existence
of the FS
As far as the logo, the name "Mathieu Roy" isn't free in the
DFSG-sense. Neither is the Debian name. I don't see why the Debian logo
should be either.
I don't believe the logo needs to be free; I think the way it is being
handled is appropriate. However, others were arguing recently
> Someone else criticized the idea (though no one had proposed it) of
> giving the FSF special consideration; now you seem to be saying just
> the opposite, that you believe in giving the FSF less cooperation that
> you would give to anyone else. The consequences of such an approac
None of these differences correctly classifies Hello as both a program
and documentation, as far as I can tell.
Hello is an example program.
It is difficult
to deal with such grey areas and I assume that it requires a
case-by-case review.
I have never found it difficult.
But if they were only removable without being
modifiable, then yes, removing them would be the only way to include the
accompanying documentation while still ensuring that all bits in Debian
guarantee the freedoms that we require.
Not long ago, people were trying to reassure me t
If, OTOH, your only goal is to persuade Debian to accept the GFDL
with invariant sections as free enough for inclusion in our
distribution, I don't see that such a discussion could ever bear
fruit without a concrete proposal spelling out the alternative
guidelines that should ap
> A few weeks ago someone was trying to argue that nobody would do
> this, and that invariant sections were designed to solve a
> nonexistent problem. Now we know the problem is not just
> theoretical.
No, it's still a theoretical problem.[1] The above has nothing to do
wi
>I don't think that section titles are a problem--it would not be
>hard to put them in a program.
In a *binary executable* ?!?! That's what I'm talking about here.
I am not sure if you are right; this might be impossible or it might
be easy. I have never thought about what this requ
If the whole doc was DFSG free, I believe no Debian maintainer
would remove the political statements one could find in it.
Two people have just said they would remove any essay that cannot
be modified.
I am not sure that it is, but the FSF seem to be suspicious of the
free press movement.
I don't know what that message said, or who wrote it, but it does not
speak for the FSF. If the free press movement means indymedia, I am
sympathetic to it, but the FSF has no opinion about it.
If the whole docu would be DFSG-free, than there would be no cause to
remove polical statements.
According to Don Armstrong, a non-modifiable text cannot under any
circumstances be considered DFSG-free, so it would have to be removed
from the manual. Others have (it appears) said the same
>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
While you are free to state the terms by which the GFDL should be
interpreted for GNU documentation, this is not always the case. We have
in the past seen cases where copyright holders have interpreted
seemingly unambiguous statements in a pathological fashion (see Pine,
for ins
But what if an Invariant Section was the only part of the document that
fell foul of the law?
I guess nobody could distribute that version, so it might be
non-free.
However, all free software and free documentation licenses share this
problem. You could simply add code for a DeCSS progr
FYI, that's not going to convince anyone.
We could all speculate about what might or might not convince certain
other persons, but doing so is attempting to speak for them, so let's
not do it.
> But I think
> that would not be free, because this behavior is substantive, not mere
> packaging. It's not the same as just printing an informative message
> about something nontechnical.
You often refer to the inclus
1 - 100 of 279 matches
Mail list logo
