Re: A possible GFDL compromise
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 of our philosophy, which they might think of doing because those statements criticize their actions. Changing the GFDL to permit removal of these sections would defeat the purpose. Nowadays we have to struggle constantly against the tendency to bury the free software movement and pretend that we advocate "open source". So I don't think we can conclude that such precautions are no longer necessary.
Re: A possible GFDL compromise
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 question of which GFDL-covered documents to accept. I have therefore been trying to convince Debian developers that the GFDL is a free license and should be accepted. Has Debian actually made this decision? Second, the FSF is not working on changing the GFDL now. We intend to continue to use invariant sections that cannot be removed, as we have always done. The only issue being considered (if it is still being considered) is what decision Debian will make about use of the GFDL. To make the GFDL somehow compatible with the GPL would be desirable, but it is not simple. It would require making a sort of combined-license with terms like the GPL for software and terms like the GFDL for documentation. That raises lots of difficult issues. At this point all we have done is begin to think about it in very general terms. We won't try to go beyond that until after GPL 3 is ready--and we're not making much progress on GPL 3 due to lack of manpower.
Re: A possible GFDL compromise
> 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 can't be happening here in regard to invariant sections, because they are not a change. We've been using invariant sections in our manuals since at least 15 years ago. What the GFDL changed in regard to invariant sections was to formalize the criteria, stating explicitly that sections that cover part of the manual's topic cannot be invariant, and to increase compatibility by providing a way to merge manuals with different invariant sections.
Re: A possible GFDL compromise
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 philosophy, and will not remove it from any accompanying documentation. The GFDL's permissions apply to everyone, regardless of whether they agree with philosophy expressed in the invariant sections. Those who disagree might choose not to exercise the freedom, but the GFDL does not deny it to them. If people disagree with what you say, you should not prohibit them from doing so. I agree completely. The GFDL does not prohibit people from expressing their own views. It only says that those who redistribute our manuals must include our statements of our views. If they wish, they can also say they disagree with our views. > Nowadays we have to struggle constantly against the tendency to bury > the free software movement and pretend that we advocate "open source". Is a manual the right place for advocacy? Isn't the purpose of a manual to document a piece of software? We try to make everything do multiple duty if possible.
Re: A possible GFDL compromise
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 GNU Manifesto, unmodified, regardless of the actions of distributors. In other words, what happens to the local copies simply isn't as important as it used to be. These facts have not prevented the open source movement from quite effectively covering up what we stand for, and our movement's very existence. They cannot make any specific person forget, but they have led most US journalists to deny our existence, so that most people never find out about us. We need every method of informing them that we can get.
Re: A possible GFDL compromise
>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 only such statements deserve is to point out that fact. This is a very important point. I have stated before that I would not have serious objections to the FSF issuing a small number of non-free manuals for a good reason, as it has been doing for 15 years. The FSF manuals are all free documentation by our criteria. 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 hope that Debian developers will vote to follow our criteria for free documentation, but they have the right to choose differently. However, you cannot expect us to follow your choice if it differs from ours. Ultimately we and Debian may simply have to disagree.
Re: A possible GFDL compromise
> 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 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.
Re: A possible GFDL compromise
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. Whatever Debian decides, some amount of cooperation ought to be possible between the GNU Project and Debian.
Re: A possible GFDL compromise
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 viewer program to read a manual published on paper.
Re: A possible GFDL compromise
> 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 intentionally distribute non-free documentation because we don't care about the issue. It's relevant that we're the ones that have led the community in caring about this issue, often against strong resistance. Taking a point out of context, and criticizing it for not proving something it wasn't meant to prove, is not useful discussion--it creates tangents that distract the discussion from the issue at hand. Those arguing here against the GFDL frequently create tangents, and have done so several times in the latest thread. When I said that the use invariant sections was not a change, someone cited various changes in *how and where we use them* and presented them as a contradiction. But it's just a tangent--not relevant to the context in which it was mentioned, nor to the larger issue. That message used the term "expansionist policy" to describe these tangents--a term that carries a very harsh attitude. When I pointed that out, another message defended the use of the term "expansion". That's another tangent, because "expansion" and "expansionist policy" carry very different attitudes. 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. Other recent tangents include the question of who was first to write a free software license (it wasn't BSD, but I don't know who it was), and how the GNU Project makes these decisions. For the sake of a more focused and intelligent discussion, I ask the other people on this list to make more effort to avoid tangents, and to criticize tangents as tangents when they are raised by others. Just because the FSF is the first to release a free documentation *license*, doesn't mean it was the first to come up with free documentation *criteria*. The GNU Project has been working on (and applying) criteria for free documentation since the 80s. However, that is a tangent, so let's not go further down it.
Re: A possible GFDL compromise
> 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 for the GNU Project in regard to the GFDL. I have been presenting reasons why it is proper, and better, for Debian to accept GFDL-covered documents. Although you perceived my words as a sort of demand, they were actually meant as just the opposite. I was saying that we will try to continue cooperating with Debian in other areas, even if Debian decides not to use our manuals. We have stated many times why we don't want GFDL'ed documents in Debian, You and some other Debian developers have said this, but you do not speak for all Debian developers any more than I do. You are trying to persuade them, and I am too. I expect that eventually they will vote on a decision. You are free not to change your license, and we are free to drop your documents if we feel your license is not suitable. I have acknowledged this several times on this list. It is precisely because the Debian developers can make their own decisions that I have posted messages with arguments I hope will convince them.
Re: A possible GFDL compromise
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 ago. I cannot find that message easily--the only way I can search my large volume of mail is with grep. If a substantial number of people are concerned, can one of them look up my previous message and repost it?
Re: A possible GFDL compromise
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 accusation is harsh and unjustified. I am the one in the FSF who has made statements about Debian and non-free software, and the statements I have made are true as far as I know. If you think anything I said is not true, please show me the statement and the relevant facts. If something I said is incorrect, I will change it. Even if Debian decides not to use GNU manuals, some kinds of cooperation should still be possible, as long as we are civil to each other.
Re: A possible GFDL compromise
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 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 license. (I explained a couple of months ago why they are smaller.) None of us have ever considered saying that the 4-clause BSD license is non-free, or suggesting that programs under such licenses should be removed from Debian main.
Re: GPL preamble removal
> > 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 of invariant section for inclusion in all GPL-covered software. By contrast, you can make a modified license (which is not the GPL) using the terms and conditions of the GPL. In that case, you would need to ask the FSF's permission if you do want to use our preamble or a modified version thereof. But such a modified license is not the GPL; you cannot use it as the license in a GPL-covered program. These questions are both answered in the GPL FAQ, but apparently the answers are not entirely clear. If someone can show me specific text and explain how it can be misunderstood, I can try to clarify it.
Re: A possible GFDL compromise
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, many points to support their position. People are of course entitled to their opinions. However, a couple of months ago, I addressed these issues and explained why the real problems were limited to practical ones of the sort I've referred to above. Meanwhile, people continue to state opposition to the GFDL here, citing practical problems of precisely that sort. So I think misunderstanding remains on the issue.
Re: A possible GFDL compromise
>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 magnitude", and you'll have my opinion on the practical problems (as opposed to the freeness problems). This is because the 4-clause BSD license only directly imposed a burden on people who chose to advertise, while the GFDL imposes corresponding burdens on all users. There is no burden at all for most users, who install and copy the system. The practical problems occur only in special cases. The 4-clause BSD license creates a large problem in that the various required notices are cumulative at the level of the entire system. True, this requirement only applies to advertising, but the size of what it requires can be very large. The GFDL does accumulate in that way, because all the notices it requires only need to appear in a given document. It does not create such a large problem, not ever.
Re: GNU/LinEx, Debian, and the GNU FDL
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 questions here. I will, however, add some information to the note, giving additional information I think is useful. The FSF would like to continue cooperating with Debian in such areas where Debian's and the FSF's policies agree. However, we will not cooperate with people that treat us harshly, no matter what their policies might be.
Re: A possible GFDL compromise
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.
Re: stepping in between Debian and FSF
> 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 free documentation. Debian is of course free to adopt or interpret rules in a way that yields different criteria. The DFSG are written very differently from the Free Software Movement's criteria for free software and free documentation, and is being interpreted by different people, so that it would be surprising if the results were the same. The differences may yet get bigger. I previously said that no one here had considered claiming that the 4-clause BSD license was non-free, because I had not seen anyone say that. Now I stand corrected--apparently there are people who want to reject that too. I looked at this for the GNU Project years ago, and concluded that it is a free software license. It looks like, practically speaking, the criteria of Debian and GNU are different.
Re: GNU/LinEx, Debian, and the GNU FDL
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 question, the Debian servers have been distributing and recommending non-free packages. I think this practice is entirely wrong, but I did not try to change it with vilification and pressure. Instead, for several years I talked with some friendly Debian developers to promote a Debian decision to change the practice. But the proposals were voted down, and eventually I stopped trying. When asked, I say that Debian is better in regard to freedom than the other distributions, but still not good enough. The GNU Project is still looking for a GNU/Linux distribution to recommend. I thought we had found one in GNU/LinEx; it contained non-free packages but its developers said they would remove them. When they told me that change was made, I thought we had finally found a distribution to endorse. However, Jose Marchesi of GNU Spain informed me that it contains other non-free packages, which means we can't recommend it. We are still looking for a distribution we can recommend to the public. If at some point Debian distributes main from a server that doesn't include or refer people to non-free software and documentation, the GNU Project could point to that server as a place to get an entirely free version of the GNU system. We could say this even if the system on that server did not include our manuals--but in that case, we would not find that system entirely satisfactory. We could not endorse it in glowing terms, and we would continue looking for a better alternative.
Re: GNU/LinEx, Debian, and the GNU FDL
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 take a belligerent tone. Often they start with fabrications, and speculate at length about what it would mean if those fabrications were true. (This is classic smear campaign tactics.) Often they assert that unless I disprove the fabrications to his satisfaction, he is entitled to presume them valid. To answer the questions would be to accept the ground rules they presuppose, so I do not answer. When it seems useful, I criticize the questions themselves. For instance, his latest message speculates at length about the meaning of a supposed conflict between my personal statements (about Debian, one must presume) and the FSF's position. It implies that I made personal statements endorsing Debian, and that I was at fault for not distinguishing them from the FSF's position. Nothing like that occurred. What I personally say about Debian is that it pays more respect to the user's freedom than other distributions, but that I cannot endorse it because of the distribution of non-free packages. Robinson actually cited this in his message, but that didn't stop him from fabricating something contrary. If Debian is seriously interested in discussing how to produce a distribution that the FSF could recommend, or at least consider ethically acceptable, I would very much like to discuss that with Debian developers that approach the discussion in a spirit of good will. I won't discuss the issue with Branden Robinson, though.
Re: A possible GFDL compromise
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 that as serious discussion.
Re: A possible GFDL compromise
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 the copies. It isn't supposed to refer to use of encryption or file access control on your own copy. I will talk with our lawyer and see if that sentence needs to be clarified.
Re: A possible GFDL compromise
> 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 true. Such an addition to the manual prevents taking small snippets of the manual and using them in isolation. 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. The situation is the same with the simple license we used in the past for manuals with no invariant sections. Yet nobody is saying that that license is non-free. It looks like a double standard is being applied.
Re: A possible GFDL compromise
> 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 is insignificant or not. It takes more than just inconvenience to make a license non-free. In effect, you are chosing to ignore the distinction. If so, it is natural your conclusions will disagree greatly with the GNU Project's conclusions.
Re: GNU/LinEx, Debian, and the GNU FDL
... 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 alternatives
have generally been worse. So I have not endorsed any GNU/Linux
distribution in recent years, except, briefly, GNU/LinEx.
I've said this many times over the years in responses to questions at
speeches. ("What GNU/Linux distribution do you recommend" is a common
question.) The reason I mentioned the issue in that interview is that
I thought I had found a distribution I really could recommend. That
was good news and I wanted to talk about it.
The FSF has not endorsed any GNU/Linux distribution in recent years,
and perhaps never, but my memory is not certain.
I believe Debian is seriously interested in all that. As far as I
can tell, though, Debian already produces a distribution that the FSF
should recommend, it's called Debian GNU/Linux and contains no
non-free software.
While nominally Debian GNU/Linux does not include the non-free
software, the non-free software is distributed from the same server.
We cannot recommend one without effectively recommending the other.
Further, the distribution itself surely contains references to that
server, so putting a copy on a different server would not solve the
problem.
The change that I asked Debian developers to make, some years ago, was
to separate the two, such that we could refer people to Debian
GNU/Linux without in the same act referring them also to the non-free
software. This would make it possible for us to refer the public to
Debian GNU/Linux. If in the future Debian GNU/Linux does not include
the GNU manuals, this reference could not be wholeheartedly positive,
but we could still make the reference.
Re: A possible GFDL compromise
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 unfair. I think you have demonstrated, better than I ever could, that your criticism is based on an unfair standard.
Re: A possible GFDL compromise
> 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. There is *no* license which is free-for-software which would allow the use of such a manual section in isolation. None. Because, of course, the FSF's definition of free, as applied to software, doesn't allow invariant sections. That's both inaccurate (since it does, in some ways, allow them) and irrelevant (because we don't apply our definition of free software to manuals, and Debian may not apply it to anything), but in addition, this problem doesn't really depend on invariant sections at all. The same would be true for a GPL-covered manual, because you can't use snippets without a copy of the GPL (unless they are fair use). However, the point is that the simple license, was always compatible with at least one free software license. For example, one could easily distribute software under the simple license itself. I don't think anyone ever did so. In practice, the issue is not significant, since you can distribute the manual along with the software, and make the software access the manual in whichever way you want.
Re: A possible GFDL compromise
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 software: you can modify all these functions, but not that one. The result is that the whole thing is nonfree.) This would be like having a technical section which can't be changed. That would be non-free, but it's not what our actual invariant sections do. For them, the preamble of the GPL is a better analogy. That too is text that can't be changed or removed from the program, but does not restrict its practical functionality.
Re: A possible GFDL compromise
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 declining to recognize the difference between loss of freedom and practical inconvenience. Where we draw the line, when judging licenses as free or not, is whether you can practically speaking make the code or the manual do the substantive job you want. If license restrictions make it impossible to make the technical changes you want, then the license is non-free. If they make it possible, but with conditions you might not necessarily like, it is free but with a practical inconvenience. Invariant text that isn't part of the technical job that the program or the manual does is just a practical inconvenience. That's why I decided that the unchangable text required by Reiser's license is just a practical inconvenience (though it is getting close to the limit). A number of free software licenses also themselves contain text that is more or less equivalent to an invariant nontechnical section in the source code and executable versions of the program. So what divides "egregious practical inconveniences" and "non-free"? The practical inconveniences of the GFDL are similar to those Debian accepts from other licenses that we agree are free. They are not egregious.
Re: A possible GFDL compromise
> 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 are entitled to demand answers from me. (If I don't give you the answers you want, then my discussion is "not serious".) I think that if we want to have a serious discussion, rather than a volly of attacks, we should not approach it with a belligerent attitude. Are there questions you think Debian hasn't answered? The question is moot, because I am not demanding answers from Debian, only presenting arguments for Debian developers to consider. None of us is entitled to demand answers from the others. But if we imagine that we were all entitled to demand answers from each other, the fact is that those arguing against me here outnunmber me. They appear to have, each of them, more time available for this than I do. A "standard" which requires me to match them point for point would be unfair in the circumstances. Has Debian announced that it will ignore whatever you say because you have been cruel and dismissive towards us? I have not been cruel to anyone in this discussion, so the question is moot. But if I were cruel to someone, no one could blame him for deciding not to speak with me further. Even if a person felt I merely dismissed him, I don't see how he could be faulted for not speaking with me further. I will drop this thread here. That way I may be able to turn some attention to other messages in which other people have raised more substantive issues.
Re: GNU/LinEx, Debian, and the GNU FDL
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 unusual, and we thought that people in and out of Debian might look at it as an affront to Debian developers. That isn't what we wanted. Also, to do the job right would call for more effort than just that, and we wanted to save that effort for when we could do it based on the Hurd. Nowadays, making a modified version of an existing distro is not unusual and would not be considered an affront to anyone. So we've been looking at hooking up with some existing project to release a modified version of Debian. In effect, that's what GNU/LinEx is. If only it had been entirely free, as its developers said, it would have solved the problem. Instead, we're still looking.
Re: A possible GFDL compromise
"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 values which do not include freedom, they are no guide for those of us who do value freedom. >From the above, I won't judge Invariant Sections on practical terms, but using freedom as a criterion. We agree on that point. They are the very opposite of free. So I reject them (_both_ in terms of our principles, and in terms of multiple practical inconveniences). The invariant sections don't restrict your freedom to use the technical material, verbatim or modified. 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. Incompatibility of licenses does cause real obstacles to certain uses, and it might be worth changing the GFDL to solve that problem, if it can be done without big drawbacks. I'm going to think about this question. But the same issue arises for free documentation licenses that don't have invariant sections, and Debian is not considering rejecting them. It's not valid to use this argument against the GFDL alone. Perhaps then you will understand us better and decide whether you wish for us to distribute free FSF software manuals. I would like Debian to distribute free GNU manuals, but I recognize that Debian can decide either to use them or not.
Re: A possible GFDL compromise: a proposal
- 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 developed a method to make sure this would not happen: invariant sections. The danger has not gone away, so we still need invariant sections.
Re: A possible GFDL compromise
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 more, then you could reach this misinterpretation. Any criterion can be distorted if you stretch the terms.
Re: A possible GFDL compromise
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 words "A GNU Manual"] (Page 13 is the same as page 12 above) I don't undertand this. Why have page 13 duplicating page 12? Anyway, this is not required for on-line use, only for printed copies, which have covers anyway. Likewise page 19.
Re: A possible GFDL compromise
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.
Re: A possible GFDL compromise
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 takes up to 48 hours for me to respond to a message, even if I write the response as soon as I see it. But sometimes I am even further behind and don't answer all of one day's messages until the next day. And if I want to put some thought into the response, it may be delayed more. To berate and lecture me because you have not received a response in two days is a cheap shot that illustrates your general attitude. I do plan to respond to that message, but I will not hurry because you badger me.
Re: A possible GFDL compromise: a proposal
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 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.
Re: A possible GFDL compromise
> 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. In a previous message, I explained why there is no practical difference.
Re: A possible GFDL compromise: a proposal
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 expect Debian to consider such manipulation free ? It's free because you can change the technical substance of the manual to say whatever you want it to say. That is the standard we have always used in judging licenses. I suggest it would be useful for Debian to follow the same standard. Where do you place the limit above which a practical inconvenience makes a license non-free ? A free documentation license must give the freedom to modify the technical text of the manual to say what you want it to say. It can have packaging requirements about how you can publish that changed technical text. If the packaging requirements are prohibitive, so that it is impractical to publish the modified manual with the changed documentation, then it's not really permitted. In that case, the license is not a free license. However, if the packaging requirements are feasible, so that it is practical to publish the modified manual, then you really do have the freedom to change the manual text. Then the license is a free license. It is easier to apply a criterion when there is a bright line, but there cannot be one here. There is no bright line to draw between feasible requirements and prohibitive requirements. None of the possible bright lines goes in the right place. It would be simple to make a policy rejecting all packaging requirements, but there's no valid reason to reject them. Many of the free software licenses we agree are valid have packaging requirements. Modifying a software in its binary form is possible, and allowed by my hypothetical license. This issue relate to software, rather than documentation, so we're talking about free software licenses. Changing a program by studying and patching the binary is so different as to be prohibitive. In effect, this restriction would say you cannot distributed a modified version (or determine what the program does). By contrast, a requirement that the program must print a copyright notice and permission notice does not stop you from changing the program to do, substantially, what you want it to do. Some people might dislike that requirement, they might say it stops them from doing what they want to do with the program (such as, "I'm not allowed to make it not print a message). Nonetheless, this requirement doesn't stop you from making the program do substantially whatever you want.
Re: A possible GFDL compromise
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 machine, or a distributable package. If you mean the distributable package, both the GFDL and the GPL require a copy of the license to be in the package itself. If you mean the files as installed, neither license prevents it from being a symlink or hard link to a file present elsewhere in the file system. So I think there really is no difference.
Re: A possible GFDL compromise: a proposal
> 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, and unworthy shot by you against the Open Source movement. It lowers my opinion of you, and by your strong association with it, the FSF. To cry conspiracy because a like-minded group "is more effective" at spreading the word casts you in a lunatic, fanatical light. You're shining a lunatic, fanatical spotlight on my words--it doesn't come from them. The widespread nature of the practice of writing about the GNU system, using only the terminology and the ideas of "open source", is a fact. Some do this having no knowledge that the free software movement exists, but many do know and do it anyway. If they do this simply because they want to boost the open source movement, that is not conspiracy, and not malicious, but it is still substituting their word for ours. I would appreciate if in future you would restrict you comments to the need for the Invariant sections within the GFDL. 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.
Re: A possible GFDL compromise
> > 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. In a previous message, I > explained why there is no practical difference. There *is* a practical difference. For example, when I distribute a set of GPL'd works, it suffices to send one copy of the GPL. When I distribute a set of GFDL'd manuals, I must distribute many copies of many invariant sections. I was responding to a specific point. Someone claimed that the fact that the GFDL says that the license must be "included in" the work, not just distributed "along with" it. My response addressed that issue. You're raising a different issue. It is not logical to misinterpreted my response as responding to that issue. All I want to say about the new issue is that a small fractional increase in size for a large collection of manuals is not a big deal. That's not enough to make a license non-free. I think Debian folks understand what you are trying to accomplish with the GFDL, and are sympathetic with the goal, but we find the methods used to be disturbing and worrisome. Do you understand why Debian objects? Debian doesn't have a view on this; various Debian developers have variou views. I have been trying to convince Debian developers that the GFDL's methods are proper, but you're all entitled to form your own opinions and make your own decisions.
Unidentified subject!
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 this is not a major issue. But we can consider the issue anyway. The scenario shows directly that this is an inconvenience, not a real lack of freedom. The author of the GF45 compiler might prefer not to use your regexp documentation, but he is free to use it, and using it is feasible. Any free software or free documentation license that has nontrivial requirements can have results like this. For instance, there are cases where people choose not to use a GPL-covered program because the GPL has requirements that they don't want to follow. If you adopt the stance that any license condition that someone might be reluctant to follow is unacceptable, you'd have to reject most free software licenses.
Re: A possible GFDL compromise: a proposal
> 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 necessarily know the answers to such questions. For example, you wrote: It is similarly the case that Debian is vanishingly unlikely to distribute invariant political text, excepting only metadata such as the terms and conditions of licenses for Debian's software. This is more than just likely, it is a certainty. Debian distributes the preamble of the GPL, which is invariant and required political text that is not part of the terms and conditions of a license. Debian can decide to use GNU manuals or not to use them. Whether there are still many Debian developers reading this discussion who have yet to make up their mind on the question, I don't know. I would like to know. If there are, then my participation in these discussions may achieve something and I will continue. But if you are right that it is too late to change the decision, then my effort is fruitless, and I ought to stop this and do something else. Debian can go its own way while the GNU Project continues on its way. To the readers of this message: if you are a Debian developer and you do, or perhaps might, support including manuals covered by the GFDL (without expecting it to change) in Debian, please write to me and tell me. (I am not subscribed to debian-legal and could not handle the volume of mail.) But before you send it, please see if I have sent a further message to debian-legal saying "enough!" And that disconnection between purpose and methods really is what this is about: the FSF is concerned about getting to a state where all computer programs are free, and is willing to restrict freedoms in the interim to get there. There is no disconnect between our purpose and our methods. Our licenses grant the freedoms that we are fighting for. We are following the purposes and criteria we developed in the 80s. Lately Debian has interpreted the DFSG in a way that is substantially more strict than our criteria of free software, rejecting software licenses that we consider free, totally aside from documentation licenses such as the GFDL. If there is a disconnect, it is between our methods (and purposes) and Debian's.
Re: A possible GFDL compromise
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 real freedom. However, we do accept the license of TeX. This license says that you cannot modify the source file at all, but you can use a change file when you build it. Use of a change file give you the ability to change the functionality as you wish, so you have freedom to change the substantive behavior of TeX. The fact that the original TeX source is invariant is a considerable inconvenience, but only an inconvenience. And given a big, sometimes nasty, world, he might very well not be free to use it. He may be in a country, or working for someone, that will not tolerate him espousing the message in that invariant section in any way. That is possible. In the same way, he could be in a country that prohibits the functionality of the program, or issued a patent on it, or have an employer who dislikes the license conditions or the license preamble, and will not tolerate its use. Those things can happen, and they are real problems; but if the possibility were a reasons to say that the program is not free, then no program would be free. There's a difference. The GPL is full of technical requirements. But when Amnesty International releases its freedom fighting robot code under the GPL, I'm free to reuse it for my baby mulcher. You would likewise be free the GFDL-covered manual for the robot to document your baby mulcher. Inclusion of invariant sections, if any, would not stop you from making it a useful and accurate manual for the mulcher.
Re: A possible GFDL compromise
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 use--you don't need to follow the license conditions. > Debian doesn't have a view on this; various Debian developers have > variou views. I have been trying to convince Debian developers that > the GFDL's methods are proper, but you're all entitled to form your > own opinions and make your own decisions. Um, Debian *does* have a view on this. My understanding is that there is no final decision. If and when the issue is decided, I will cease discussing it here.
Re: Unidentified subject!
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 happens, you are free to do that, because copyright does not cover tearing up a manual. You don't need a license to give you permission to do that. And then, in between the silly ones and the reasonable ones, there are a whole lot more, with some pretty darn ambiguous cases. Yes, there are gray areas where it is hard to decide. I had to think for months about whether the TeX license qualified as free, since it makes the whole of the original TeX source code invariant. And I had to think for weeks about a LaTeX license, that required changing the name of any file that you modify. I eventually concluded that LaTeX was free despite this requirement, but only because it has a remapping feature that lets you say "Use file myfoo.sty when the document asks for foo.sty". My previous question is still the right one, I think. How would you go about explaining why "send $1 to the author for permission to make changes to this program" is not a mere "requirement", but actually kills freedom? That question is straightforward: if you have to pay for permission to do something, you do not have permission to do it. Debian has a way of answering that question: but our way, which involves the DFSG, would say that "send $1 to the author for permission to make changes" is wrong for the same reasons that "send $1 to the author for permission to make copies", and is wrong for the same reason that we think that invariant sections are wrong. The DFSG doesn't say anything about invariant sections; you're assuming a very strict interpretation. You're also assuming that the DFSG should be applied to manuals as well as software, and that the interpretation should be the same. I'm arguing for a less strict interpretation of the DFSG.
Re: Unidentified subject!
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 accept or reject GFDL-covered manuals. 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.
Re: A possible GFDL compromise
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. the required invariant sections (several pages), and 3. the required back-cover text (on a page by itself after the excerpt and the invariant sections). In both cases, the other required material is much larger than the text you want to use. Meanwhile, I think that you can in most cases avoid separate pages for the cover texts. Do you believe there is some limiting size of license, beyond which the license automatically becomes non-free regardless of its text? If not, this argument seems to be a double standard. Do data CDs "commonly have printed covers" (jewel case inserts)? Would pressing a CD (rather than burning a CDR) be considered "printing"? Yes, it definitely is. If you press a CD whose contents are only or mainly a single GFDL-covered manual, then you need to put the cover texts on the CD itself or on the jewel box insert. However, if the CD contains a large aggregation such as a GNU/Linux distribution, section 7 says that the cover texts can go on the electronic equivalent of covers, in the manual itself. So in this case there is no requirement to print anything on the CD or the jewel box insert.
Re: A possible GFDL compromise: a proposal
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. I think Debian regards this license as free. Ah! So I think we have made progress. This is just what people have said about why a practical inconvenience, sometimes, makes a thing nonfree. Now the question is: how impractical does it have to be? It has to be prohibitively impractical in real cases. The inconveniences that occur in some cases with the GFDL are not prohibitive. Debian especially is concerned with the fact that we can't imagine all the future ways of publishing. How can we tell that it isn't a prohibitive requirement? We have to try. If we accept this, or any, reason to say that any requirement might perhaps be prohibitive, and reject any and all requirements, that leaves rather few acceptable licenses. Maybe none.
Re: A possible GFDL compromise
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 thing". They say that if you redistribute modified versions the technical material, you must do so in certain ways. That is a packaging requirement. The GPL also contains packaging requirements: inclusion of the preamble, inclusion of copyright notices, etc. The TeX license has a much more annoying packaging requirement. Those are both licenses that Debian accepts, I believe.
Re: A possible GFDL compromise: a proposal
The only question I intend to discuss on this list is Debian's decision about whether to use or not use GFDL-covered manuals.
Re: A possible GFDL compromise
> 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 detail of wording doesn't make a difference that I can see.
Re: Unidentified subject!
> 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 I recognize that. I am only offering arguments to convince them. That is why I recently asked to hear from Debian developers whether they are still making up their minds about the matter and whether they are interested in what I have to say about it. If this is generally not the case, I will stop discussing the issue here. I am not interested in beating a dead horse.
Re: Unidentified subject!
> 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 use--you don't need to follow the > license conditions. This is not true if we are reusing all the paragraphs, by extensive reworking and reassembly. (Say, to manufacture doc strings.) You raised one scenario and I responded to that. Now you're saying my statement doesn't apply to a different scenario. It wasn't meant to. Let's not mix up different issues--that makes a discussion which doesn't treat any issue thoughtfully.
Re: A possible GFDL compromise: a proposal
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 cannot change it. This is not allowed for a GFDL manual, is it? The GFDL allows you to make any changes you like in the technical substance of the manual, just as the TeX license allows you to make any changes you like in the technical substance of TeX.
Re: A possible GFDL compromise: a proposal
> 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't think that is possible. When you let other people write detailed rules, but insist these rules substantively permit certain things, you invariably face the question of whether the requirements are tantamount to a prohibition in disguise. When I judge this question for a packaging requirement, I try to be tolerant. Any packaging requirement that doesn't generally prevent users from publishing versions with the technical behavior they like is ok. Importantly, what must the impracticality prohibit to count? The question is whether you the user are free to publish a modified version with the technical behavior you like. If the requirements for publishing a modified version cannot be met, then you really can't publish a modified version with the technical behavior you like. The DFSG says that we must have the right to modify everything, at least by the use of patch files. I cannot find that in the DFSG. If you are talking about this part, The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. then I don't think it says that. This text is specifically about source code for programs, and specifically about licenses that entirely forbid modified versions of the source code. It is extremely specific and narrow. I think Debian developers have come to feel that the literal interpretation of these words is too weak a criterion. I too think it is too weak: a software license that passes this criterion but allows only some kinds of modification can be non-free. And documentation should also be free in its appropriate way, though it is not software and not a program. It looks like Debian developers, rather than changing the criterion, have decided to reinterpret it by discarding some aspects of the actual words. I'm not sure that is the best way to solve the problem, but never mind that. My point is that once you decide to do that, there is more than one way to do it. To take the most strict possible interpretation of what the words don't say is not necessarily right.
Re: Unidentified subject!
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 parts out of the three I mentioned, and the third part is crucial. The DFSG doesn't directly say anything against the requirements of the GFDL. I sent another longer message explaining why.
Re: A possible GFDL compromise
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.
Re: A possible GFDL compromise: a proposal
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 free software, because they are not software. The DFSG very clearly treats "software" and "programs" as synonymous.
Re: A possible GFDL compromise
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 use does exist in the UK. The use of short quotations is standard practice all around the world. Anyway, the GPL makes requirements of the same sort. They differ only in that the GFDL might require a couple of extra pages (in some cases), and an invariant section might require a few more (if there is one). I don't think the difference between 6 pages and (say) 12 makes the difference between feasible and infeasible, and this case is basically artificial anyway.
Re: Unidentified subject!
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.
Re: A possible GFDL compromise
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.
Re: A possible GFDL compromise: a proposal
> 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 the fact that there are things other than software in the system. It seems to say that all the software must be free software.
Re: A possible GFDL compromise: a proposal
> 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 that message to me; nobody had mentioned to me before (at least since the start of 2003). It is a message from Bruce Perens, suggesting that the DFSG should be taken to mean something quite contrary to what it actually says. If you are willing to disregard the meaning of some of the words in the DFSG in order to reinterpret it, there is more than one way to do so. It is absurd to argue rigidly that "the DFSG obviously says exactly this" when what it actually says is something else. There is more than one way to generalize the concept of free software to deal with documentation. I think the right way is to go back to the basic four freedoms, and then consider what they should mean for documentation. But this issue is not just about documentation. I think you're drawing the line too strictly for software, too, and the DFSG doesn't explicitly say to put the line there. [EMAIL PROTECTED] wrote: > The arguments appear to be: > >1) There are many GFDL manuals. >2) The many GFDL manuals would be useful to include. > That's two parts out of the three I mentioned, and the third part is > crucial. But they are an irrelevant two parts. They are relevant if you would like to use the many manuals that are released under the GFDL. If Joe Blow writes a license for his program or documentation, it should get the same consideration under the DFSG as when the FSF does. It's not an issue of giving special consideration to the FSF, or to anyone else. It's an issue of what could be useful for Debian. At the start of the GNU Project, I was in a similar situation. When I wrestled with the question of whether TeX was free software, I did not owe Donald Knuth any special consideration, but I did want to use TeX in the GNU system. The most obvious place to draw the line would have rejected TeX's license, but that was not the only place to draw the line. I asked myself if it was really unacceptable to draw it in a place that would allow that license. I concluded that was acceptable, that TeX does provide the necessary freedom though in a somewhat inconvenient way, and that it would have been counterproductive to reject the license on account of that inconvenience. Subsequently I generalized this to the idea that any sort of packaging requirement for publishing modified versions was acceptable in a free software license, as long as it was feasible to meet and did not substantially limit the substance of the changes. The DFSG explicitly codifies my specific decision about TeX, but doesn't explicitly say anything about the rest of the issue. I recommend interpreting it in a way that follows this principle. Section 3 says "The license must allow modifications and derived works[...]"; if that's ambiguous in any way about everything being modifiable, a note on section 4, talking about patch files, says "The Debian group encourages all authors not to restrict any files, source or binary, from being modified.". Section 3 is rather general, and doesn't directly address this issue. The statement in section 4, because it only "encourages", clearly shows this is not a requirement. I take it to mean that people are urged not to use licenses like TeX's license.
Re: A possible GFDL compromise
> 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.
Re: A possible GFDL compromise: a proposal
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 before you asked, without a time machine, is beyond me. Just one day later, you rebuked me for being slow to respond. At that point there had barely been time to get a copy of the page onto my machine. Would you please give me a break? I'll try to take care of your blood pressure if you do the same for mine. By now you should have seen the comment on this page that I sent out in the previous mail transfer.
Re: A possible GFDL compromise: a proposal
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. These are not programs; are they software?
Re: A possible GFDL compromise: a proposal
> 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 written as if the system consists entirely of programs and contains nothing else. But there surely was never an intention to develop a system that didn't have manuals and essays and licenses in it. I think that this was an error of thinking at the time. Why should we listen to your arguments to convince us if you will not listen to our arguments trying to convince you? I started discussing this issue here because I thought that Debian developers were still making up their minds on the issue. I am not presenting a demand, just a proposal. I don't want to nag, and if Debian developers are not interested in what I have to say, I will let the issue drop. By contrast, you are trying to change a policy that was decided almost two decades ago, so I would need to find your reasons rather convincing. But they are based on a completely different view of the issue, so I don't find them convincing. Also, you often present your arguments as a demand rather than a proposal. It comes across as a pressure campaign--just the opposite of the way I am approaching Debian. That doesn't make me inclined to listen. I'm inclined to let the issue drop pretty soon, but I think the current discussion about the DFSG is getting to the heart of the matter, so I think I will continue until this point is fully explored and then let it drop.
Re: A solution ?!?
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 download single source files from CVS without downloading even the license. You can split a document into multiple files, but you cannot distribute them as separate packages encouraging people to get just part.
Re: A possible GFDL compromise
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 reference card. Do you object to the GPL on these grounds? The DFSG lists three specific licenses that are meant to satisfy its criteria. Nowadays some Debian developers tend to say that these three licenses are listed as exceptions to the rules of the DFSG, but I think that is a misinterpretation. I think they are meant as examples to help people understand what the DFSG criteria mean. An interpretation of the rules which would lead to rejecting any of thee licenses is the wrong interpretation.
Re: A possible GFDL compromise
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. As I have said a couple of times, I will stop doing so unless Debian developers seem to be interested in what I have to say.
Re: A possible GFDL compromise: a proposal
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 license in the gray areay between free and non-free. I cannot live with the same thing coming from the FSF. The GFDL is free according to our standards. If you wish to view the matter otherwise, you're entitled to your opinion. 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 approach should be obvious: there will be no cooperation. is that the Debian Project could end up being better friends with the Open Source Initiative than with the FSF; while most Debian Developers and users nowadays think the FSF is a "good" organization[1], this might change if the FSF insists on having those Invariant Sections.\ The FSF has lived with contant criticism for many years. Say what you wish; we will make no concession to threats like this.
Re: A possible GFDL compromise: a proposal
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 that section titles are a problem--it would not be
hard to put them in a program. But it is true that you cannot take
text from a GFDL-covered manual and put it into most free programs.
This is because the GFDL is incompatible with the normal free
software license.
This is equally true of other free documentation licenses, including
the Open Publication License version 1, and the simple license we used
in the past for GNU manuals without invariant sections.
(It is trivial to fix this, if you are not obsessed with unremovable
"Invariant Sections" to the exclusion of all other goals. Add a clause
to the GFDL allowing GPL-conversion, exactly like the clause in the
LGPL.
This is simple, but it might effectively nullify all the other special
features of the GFDL. That is something we want to avoid.
3. Consider the following. (For future reference, this is called the
"ls --hangman" example.) I am designing a license (the "hangman
license") for a new version of "ls" which requires that any derivative
work (if executable) provide a documented way, preferably a command line
option, to invoke a particular piece of unmodifiable machine code,
designed to play a game of "hangman".
I think I have never considered whether such a license is non-free,
and since the question has not arisen in reality, I don't need to
answer it. (Where there is a gray area, it is often possible to
construct artificial questions of any desired degree of difficulty,
and often the best response is not to worry about them.) 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.
So even if you feel that you really, really, need these Invariant
Sections for a few special cases to promote the FSF's work, why is the
FSF *promoting* the broad and general use of Invariant Sections by all
and sundry? It should be actively *discouraging* them.
I don't agree that we ought particularly to discourage them, but we
are not actively urging others to use them. I wrote the GFDL to allow
anyone to add invariant sections so that it would be possible to merge
manuals with different invariant sections.
Re: A possible GFDL compromise: a proposal
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 actually say is surely appropriate for understanding it. I don't think that a message from Bruce Perens, proposing an interpretation that is contrary to the words, settles the issue. It is up to the Debian developers to decide Debian's interpretation of the DFSG, but if they choose an interpretation which is not what the words say, I hope they will recognize that they could choose a different one.
Re: A possible GFDL compromise: a proposal
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 Section in which he advocates the "Open Source" model as given better freedom to the community than the FSF model. A position I am sure you disagree with even though you support his freedom to make such a claim. I would not much like distributing that, but I would be free to distribute that.
There was never a chance of a "GFDL compromise"
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 point of removing them. 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.
What does GFDL do?
> 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 invariant material must be in the reference card. I explained months ago, and again last week, why this is not so. A similar issue has come up recently on -devel[2] regarding single files downloaded out of a tarball or a cvs repository. Hopefully it's clear that making the license available by reference is sufficient to allow people to download single files from a cvs repository. "Making the license available by reference" does not satisfy the GPL. The GPL must accompany the GPL-covered materials. Access to the program as a collection of files, in such a way that the user might copy just part, is acceptable as long as you do not encourage people to copy less than the whole that includes the GPL.
Re: Unidentified subject!
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 Debian developers how to make this decision about interpreting the DFSG. My point is that it is a decision, and that it goes contrary to the words of article 4 of the DFSG, which seems to treat "software" as equivalent to "programs". For the sake of avoiding confusion, please note that I use "software" in the meaning I believe is standard, referring to computer programs only. A software package, to be useful, needs to come with other things--manuals, licenses, and sometimes essays and scientific papers--but they are not the software. Likewise, in the term "Free Software Movement" and "Free Software Foundation", "software" refers specifically to computer programs. Our criteria for free software licenses concern licenses for computer programs. You've asked me to explain why the criteria for free documentation licenses should be different from free software licenses (or, as you would perhaps put it, free computer program licenses). I would rather ask why they should be the same, since they deal with different situations. If you reinterpret the DFSG's words by defining software to include manuals, you are forced to treat them alike. In the GNU Project we don't define manuals as software, so we have no a priori reason to treat them alike. The main difference between a program and documentation is that a program does something, while documentation is passive; you look at it. Another difference is that distribution of programs on paper is rare, and not an important case to consider, whereas distribution of documentation on paper is a very important case. Another difference is that the you can see the words of the text in the manual, whereas you cannot see the source code in the executable of a program. For software, the danger is that the source won't be available at all. For manuals, there is a real danger that the "source" will be in a format that free software cannot read, and thus useless. This is why we designed the requirement for "transparent" copies. 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. Another difference is that DRM
Re: Unidentified subject!
>> 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. "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy," could indeed be read differently than the GPL. I think the FSF was thinking "book in a book store" here, not "FTP site" or "table at a Linux convention." I hope the FSF (RMS cc'd) is willing to make a minor change to this wording to make it clear that if you offer a machine-readable Transparent copy, but your offer is declined, then that's fine. I'm not sure what the scenario is, or what the perceived problem is.
Re: A possible GFDL compromise: a proposal
> 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". For instance, Source Code The program must include source code, and must allow distribution in source code as well as compiled form. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. Distribution of License The rights attached to the program Each of these assumes that the software in question is a program. To make that even clearer, one of them also assumes that the availability of source code for it is an important issue. That is most unfortunate, but Social Contract 1 says we have to apply those guidelines to everything in Debian. If you interpret item 1 of the social contract as meaning that everything in Debian is considered software, then you run smack into the fact that the DFSG equates software with programs. So you have to ignore what those words say, too. Thomas Bushnell proposed another interpretation, in which certain things that are included in the Debian package files are not "part of Debian" for this purpose. That way, you don't have to apply the DFSG to them.
Re: A possible GFDL compromise: a proposal
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 FSF's distribution service, and asks for donations. It says nothing about how to use Emacs. However, the acknowledgements ought to be in a separate Acknowledgements section. I will move them.
Re: A possible GFDL compromise: a proposal
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 that everything in Debian is software and that the DFSG applies to it.
GFDL
> 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 approach > should be obvious: there will be no cooperation. He didn't say cooperation. He said consideration. I stand corrected, but this doesn't change the point. We are disappointed that you don't value freedom in documentation as much as you do for programs. I value freedom in documentation just as much as I do for programs. I value it so much that I designed the GFDL specifically to induce commercial publishers to publish free documentation. However, I don't follow the DFSG, nor an interpretation of the DFSG that labels documentation as software; so I don't have an artificial reason to insist on identical criteria for freedom for manuals and for programs. This reminded me of another relevant difference between manuals and software. It is harder to find good technical writers as volunteers than good programmers as volunteers. So I decided it was worth while going quite close to the line, in the GFDL, to try to induce commercial publishers to use it. I would not think of going so close to the line in a software license, since I know there's no need.
Re: Unidentified subject!
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. When it's hard to decide, neither choice is really wrong, so pick whichever seems better.
Re: There was never a chance of a "GFDL compromise"
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 that if invariant sections were removable, nobody would remove them. I guess not. This reinforces my conclusion that it is essential for these sections to be unremovable as well as unmodifiable.
Re: A possible GFDL compromise: a proposal
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 apply to documentation. I don't plan to discuss even small GFDL changes here. I think people will present a proposal for guidelines for free documentation for Debian. The definition of software that includes documentation is simply the only one that permits Debian to include documentation at all, and only if it complies with the DFSG. I've mentioned the other possible choices, so there's no need for repetition now.
Re: There was never a chance of a "GFDL compromise"
> 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 with the content of the statements themselves, merely the fact that they are not free under the DFSG. The problem is that our non-modifiable political essays might be removed from our manuals, if the manuals' licenses permitted that. You have just said you would remove them.
Re: A possible GFDL compromise: a proposal
>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 requirement means for a binary executable, because the question is not important. I don't think it needs to be possible to use text from manuals in a program. A manual is free if you can publish modified versions as manuals. Many free documentation licenses won't permit use of the text in GPL-covered free programs, and practically speaking, this means I can't use them in any of the programs I might want to use them in. Whether the manual's text could be used in a free software package with a license that qualifies as free software, but is not one I'd want to use, is just academic.
Re: There was never a chance of a "GFDL compromise"
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.
Re: GFDL
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.
GFDL
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 thing. Having seen a lot of rigid dogmatism here recently, I can hardly expect Debian not to be rigidly dogmatic on this issue too.
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 t
Re: What does GFDL do?
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 instance) - in the GFDL case, the wording does not make it clear that it is the intention that the license may be bound as a separate volume. If this is how you wish the license to be interpreted, clarification of the license would be helpful. I think it is clear that a printed work can consist of multiple volumes, but clarification might not hurt. I will think about it.
Re: A possible GFDL compromise: a proposal
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 program, and that would make the modified version illegal in the US. So the existence of such a possibility cannot be a criterion for criticizing a license. I have read statements =66rom you saying that while you cannot indorse Debian because it including "non-free" on its FTP servers, you have stated that Debian gives better considerations to users' rights by separating non-free software from the Debian System. As the GFDL allows for text that is legally, morally or ethically objectionable shouldn't we, Debian, not mark a GFDL work as different also (given that such material can not be modified)? A distinctive marking of some other kind might be reasonable.
GFDL
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.
GFDL
> 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 inclusion of Invariant Sections as a mere packaging issue. To us, a packaging issue is how software gets packed to distribution and installation on someone's system and has little to do with the content that gets installed (e.g. Invariant Section are content, not packaging). We are talking about two different kinds of packaging. When I speak of a "packaging requirement" I'm talking about a requirement that applies to the form of a program or other work, but not the substance. This a different kind of packaging from the making of Debian packages containing the programs and other works. I'm sorry if this matter of terminology caused any confusion.
