The GNU Emacs user's manual has changed its license to the GFDL. The XEmacs manual has a different license -- the GPL. Because of contributions from various parties, we cannot easily change our license, Too bad. I won't relicense such a large amount of material all together. If you show me specific parts you would like to use, I will consider relicensing them.

On Fri, Dec 10, 2004 at 06:59:50PM -0600, Ben Wing wrote: If the entire manual was made available under the GPL as well, it would sort of make using the GDFL a bit pointless, no? -Miles -- If you can't beat them, arrange to have them beaten. [George Carlin]

I think you are taking the ``free'' part too literally. Free Software or Free Documentation does not necessarily mean that you are ``free'' to do whatever you want with it. For example, the GPL says that your freedom is limited by the requirement to supply the sources together with the binary. So an argument that ``free'' means there are no limitations is an invalid argument, IMHO. A better argument would be whether the limitations of freedom imposed by the GFDL are justified by the goals of the Free Software movement.

I have no real opinion on the GFDL, tho just because of the turmoil it has caused and is still causing, I guess I'm rather annoyed by it. But I think that this "freedom" argument is flawed. "Freedom" means something different to everyone, so it's not a very good way to convince other people. Especially in the context of the Free Software movement, I understand "free" to apply to the program itself, not its user: the program (or the doc) itself is "free", can't be harnessed/hijacked by anyone. It quite directly implies that people aren't "free" to use it as they please. I don't see any benefit from using the GFDL over the GPL that would justify the downside of preventing the XEmacs people from using our documentation. [ Unless we consider that as an upside, but I really don't see any good reason why we should be so antagonizing. ] Similarly, the licensing problems it can cause when extracting docs and doc-skeletons out of code is worrisome. Stefan

Karl Fogel <kfogel(a)floss.red-bean.com&gt; writes: It's bad for the XEmacs developers and other Emacs forks, irrelevant for us, since only FSF copyright assigned contributions are accepted into Emacs and its manual, anyway, and the copyright holder is free to move stuff between licences within the scope of the assignment contracts. Again, this is not a problem for Emacs development itself (the copyright all being by the FSF), but for every fork of it. Which makes it appear to me as jibing with the idea of a Public Licence. As explained elsewhere, I do think the GFDL a good idea, but I don't like the implications of using it tightly coupled with GPLed software development. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Matthew Mundell <matt(a)mundell.ukfsn.org&gt; writes: Certainly. This protection is the whole point of copyleft licences as compared to licences like the MIT X11 licence or placing something in the public domain. This is not an issue: the various GNU licences never were aiming for the "most free in every sense of the word" award in the first place. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

"Robert J. Chassell" <bob(a)rattlesnake.com&gt; writes: If O'Reilly was worried about this at one point, they've loosened up considerably. They're now happily publishing books under considerably *less* restrictive [than the GFDL] Creative Commons licenses -- licenses that do not have, for example, front- and back-cover requirements, or invariant portion requirements. (Thanks for the summary of the GFDL's purposes -- very helpful!) An important question remains: Why is attractiveness to commercial publishers, or reducing benefits to free riders, important for the Emacs manual? If the Emacs manual were picked up by free riders, that would be fine with us, wouldn't it? (Is it that the FSF sells manuals? If so, how many copies do they sell anyway, and how much would that number be likely to be affected? Most people who contribute to the manual are not doing it to raise money for the FSF. They're doing it to contribute to Emacs. When I want to contribute to the FSF, I write a check. When I want to contribute to Emacs, I write code or docs.) So what exactly is the GFDL protecting, in the specific case of the Emacs manual? Are we really worried about some portion of the manual being used in a screed in support of software patents or something?

"Robert J. Chassell" <bob(a)rattlesnake.com&gt; writes: [Lots of other explanation deleted] This is all very fine and explains the reason for both the GFDL and the GPL pretty much equally. It does not explain, however: a) what precise purpose does the GFDL achieve for the GNU Emacs manual that is not achieved by it being under the GPL (your explanation is mostly about the contrast to Public Domain and/or BSD)? b) is the difference this makes worth the trouble it causes? c) in particular: is it a good idea to split a free project into two parts with incompatible licences in a manner that makes it only possible for the copyright holder to sensibly maintain the exchange of material across the rift? Do we really want to demonstrate how to do such a thing in large scale? d) is it a good idea to change a large body of free software (like the GNU Emacs manual) to a different licence when it is well-known that substantial forks exist for which no licence change is possible, not least of all because the fork does not have the permission of the FSF to change the licence for old derived material to the GFDL, even in the case (which is not the current case) that they'd wanted to do it? In short, in this manner we are creating an insurmountable border for anybody but the FSF to past versions of the manual, as well as to current versions of the Emacs code. I don't like it. This has nothing to do with liking or not liking the GFDL itself: as I already stated it would probably be my preferred manner of publishing a book that was intended mainly for publishing in the first place, and that was not as tightly coupled with software as most Texinfo manuals are. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Florian Weimer <fw(a)deneb.enyo.de&gt; writes: So what is the actual situation with the licence of the XEmacs manual? What kind of licensing are they _free_ to place on the XEmacs manual without the possibility of XEmacs contributors vetoing that decision? This would give us some sort of idea whether the requirements of the XEmacs team can be accommodated in a manner that is not equivalent to returning to the old licensing conditions completely. Well, ok, so we just substituted one idea I don't like with another one. So what terms in the old licence were GPL-incompatible? And, putting back the XEmacs manual problem for a moment, do we have a reasonable chance to place the GPL on the manual source code in a sensible way, without causing insurmountable problems for printed manuals? I'd think that the problems with printed manuals from GPLed source might be somewhat similar to the problems with embedded controllers based upon GPLed source: in both cases the usual end product is used without accessing the source. There is a difference, though: in the case of the manual, the usual customer will _benefit_ from a machine-readable source code copy since he can then use text search and indexing and similar. Since this problem does not seem restricted to GNU Emacs and its printed manual, is there a more appropriate list where we could try discussing how to cope with the general problem that gets exhibited here? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

a) what precise purpose does the GFDL achieve for the GNU Emacs manual that is not achieved by it being under the GPL (your explanation is mostly about the contrast to Public Domain and/or BSD)? To be a `do what we do, not a do what we say' organization. b) is the difference this makes worth the trouble it causes? I think so. Certainly, over the past few years lawyers have become very important in the question of software and other freedoms. As the cost of manufacturing information, which is called `copying', comes down, the information's legal status becomes more and more important. A long time ago, I heard someone say that the issue was whether anyone could create a program using an interpreted language like Emacs Lisp, or whether the program would be too slow. That is not the issue now. Many programmers think of the trouble licenses cause to other programmers. That is to be expected, since programmers write code and document it. But the issue here is the interface between certain professionals in one industry and everyone else. Moreover, industry also develops hardware that combined with software have enabled copying to become less and less expensive. This means that when you show how the interface is supposed to work, you need to think about all the people who are not programmers and who do not know anything about computers or code. Nanotechnological assemblers -- rapidly reproducing Von Neumann machines that also copy other things -- would reduce the cost of manufacturing copies to zero. But we are never going to see a reduction to zero in the cost of attention getting, that is to say, of marketing and advertising. That is because getting attention is a zero-sum operation, like getting status. It is not like science-based manufacturing, which is positive sum. This means that an appropriate license will continue to be relevant. c) in particular: is it a good idea to split a free project into two parts with incompatible licences in a manner that makes it only possible for the copyright holder to sensibly maintain the exchange of material across the rift? Do we really want to demonstrate how to do such a thing in large scale? If people on one of the two projects insist on using a license that hurts people, especially the vast majority, who are non-programmers, then their project should suffer. So far, I have not seen any remarks that speak to the points. Among others, I would like to see an argument favoring a `Creative Commons' license that forbids any but gratis distribution, except for its controlling monopolist. Why would that be better for you and me and others? I think it is worse. I would like to see an argument that says that says that FSF need not be consistent; that it should become a `do not do what I do, do what I say' organization. I think the FSF should be consistent. Perhaps I am wrong. I would like to see, but do not expect to see, an argument that says that many programmers who work on GNU projects are really good at selling non-programing business patterns to people are not programmers and who know nothing about computers and software. d) is it a good idea to change a large body of free software (like the GNU Emacs manual) to a different licence when it is well-known that substantial forks exist for which no licence change is possible, ... Why is it not possible? Are you suggesting that the XEmacs people lack proper papers for contributions? If so, this means they cannot ever ensure that the lawyers of a hostile organization with plenty of money will tell the organization's leaders that the software is legal. That is what I think you are suggesting. This means that the XEmacs project is rhetorically ineffective. Since I doubt that many people on it are concerned about business patterns, politics and the like, I do not think this issue is salient to them. I think they are mainly concerned with programming and wish the wider world would go away. In any event, the Lucid people were warned about this years ago and continued on their way. As for FSF: why should a project favoring software freedom, the GNU project, change its licenses to hurt its goal? I think that a good reason to go back on the license would be that FSF need not be consistent. But I do not believe that reason and have never heard an argument that claims that. Certainly, licenses are irrelevant to people who live in small communities. In a small community, social pressure and personal knowledge works well. 25 years ago, Unix and Lisp programmers lived in such a community or many of them did. I think many programmers wish they still lived in such a community. But the wider world has intervened. Programming and its machines have become successful. Even my grand-neice uses a computer. We do not live in a small and isolated community any more. As for living in a bigger world: one could argue that laws and licenses are irrelevant since most of the world is `extra-legal'. Only regions like Western Europe and a few others are more or less `law abiding'. In much of the world, any organization with more than a billion US dollars or so per year to spend can corrupt enough officials for it to continue to do what it has done before. But again, I do not think that the rule of rich, greedy individuals is better than the rule of law. I have heard claims that rich, greedy individuals do make better rulers, and that their right to hinder me is good for others than me; but I have never welcomed that. Moreover, there are good arguments -- indeed I have made them -- that failure is an intrinsic problem of hierarchies that exclude change. (Failure may not occur in the short term, that is to say, in less than a couple of human generations.) Only when competitors are equally weak can such hierarchies last for thousands of years. So, to answer your questions again: a) the precise purpose of the GNU Free Documentation License is to offer a better alternative to greedy publishers, a better way to protect their investment in attention getting. The FSF puts its own documentation under the GFDL because its leaders believe that programmers, at least those involved in the GNU project, are poor at being `don't do what we do, do what we say' salesmen to people who are not programmers. b) the difference between a license that insists that commercial organizations fail in their purpose and a license that enables their purpose is vast. No one claims that companies that are unable recover costs will survive against companies that are able to revover costs. c) a project that hinders another in fulfilling its goal cannot expect to be supported by the second, except as charity. d) as an organization comes to realize that its primary business is politics in a deep sense -- that of changing business patterns -- and that the people in the organization are poor at politics with strangers who know nothing of computers and that competitors are out to destroy it, it makes more sense to offer licenses such as the GFDL as an alternative to licenses such as the `Creative Commons license with a commercial restriction'. -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

How does this hand-waving address the difference between GPL and GFDL? The GFDL is designed to enable commercial publishers who print on paper or other material entity to survive. The GPL is not. The idea is that software development will be paid for by hardware companies, by trade associations, by governments, by universities, and by programmers whose material income does come from the project at hand. In other words, cost recovery for someone writing code is, or should be, different than cost recovery for someone getting attention for and printing a book written by another. At the moment, proprietary software companies and many documentation publishers depend on the same method of cost recovery, which is to say monopoly pricing enforced (ultimately, not most of the time) by police. Proprietary restrictions hinder both software creation and documentation writing. That is why I have said so often that the purpose of the GFDL is to provide an alternative to a `Creative Commons license with a commercial restriction' or similar license. As for a single license: I personally would like to see one rather than two or many, but I am not sure that is possible. Laws are written mostly by lawyers. Businesses that use software are often run by people who know nothing about software (and the business may have nothing to do with software except to use it as a tool -- it may train horses or something like that). Perhaps one license is possible. Then again, perhaps not. Incidentally, a great advantages of both the GPL and the GFDL is that they can be read, perhaps with difficulty, by non-lawyers, and mean more or less the same thing to them as to lawyers. (I am told that the main legality a non-lawyer like me needs to learn is that `derivative works' are defined by judges, most of whom know nothing about software. The meaning of `derivative work' cannot be specified in a license.) Readability means that programmers who do not wish to learn much law can grok the major interfaces between them and the wider world. Imagine if a programmer could not understand these interfaces without becoming a different person -- imagine if a programmer were in the same position as a typical politician, the one being unable to understand the interface, the other being unable to understand the software. It is hard enough right now to deal with these issues: doubtless you have noticed that almost all discussion by programmers is addressed to programmers' issues rather than to non-programmers' issues. Imagine it were worse. -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

At 11:43 AM 12/12/2004, Robert J. Chassell wrote: That's either amusing or insulting. XEmacs explicitly does not collect papers because we believe that hinders development of the product. ... To me you sound as if your primary concern is in the `development of the product' rather than its use by strangers who care nothing about software. As a technique, you have made yourself hostage to anyone who is hostile to you and has lots of money. That is what is meant by `does not collect papers'. You can hope to be perceived as irrelevant, in which case no one will attack you. That is fine. But that also means you are doing no good for society as a whole. Please do not make assumptions about we are or are not concerned with. If anything the XEmacs project is much more concerned with these things than the FSF appears to be. Well, please undertake actions that show you being effective as salesmen. I am not persuaded of that. The FSF strategy is not very powerful, but I cannot think of anything more effective, considering the nature of the people who are part of GNU. Please show me how you have been better at affecting poltical and business change in Washington, Paris, and Berlin. I dislike this whole need for `papers', police support of legal monopolies, and developers' hinderances; I want to see this harm ended. I want to see more software freedom. ... So you can protect the code from big, bad companies - I highly doubt that anyone in the real world actually cares anymore. They do care. That is why some companies lobbied for laws like the DMCA. That is why SCO got funding which they have used, among other actions, to make statements that confused decision-makers who know nothing about software. Only the irrelevant are untouched. I personally believe that the FSF's approach has contributed to making Emacs (and XEmacs) largely irrelevant today. .... Perhaps GNU/Linux is irrelevant, but neither Microsoft nor IBM think so. I do not think so. As for Emacs, it may be a failed project; or it may be an integrated user environment that is less interesting than a graphic user interface; or it may be doing as well as a programmers' tool can be expected. In any case, Emacs is not the GNU project. To focus on Emacs when we are talking about licenses suggests to me that you are more concerned with the development of that product than with changing the political and business patterns of societies. -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

From: "Robert J. Chassell" <bob(a)rattlesnake.com&gt; Date: Mon, 13 Dec 2004 01:59:20 +0000 (UTC) To focus on Emacs when we are talking about licenses suggests to me that you are more concerned with the development of that product than with changing the political and business patterns of societies. you are falling victim to a false dichotomy. the xemacs programmers are certainly a society, one of the many involved in this thread. to what extent any society has desire for self- and not-self-change is a concept too vague to be useful, primarily because what is externally visible may not be what is internally held (and if you are external enough, even understanding what is visible is very difficult). by not recognizing this, you also demonstrate the lack of salesmanship you have been talking about, which is at least consistent. thi

Robert> To focus on Emacs when we are talking about licenses Robert> suggests to me that you are more concerned with the Robert> development of that product than with changing the Robert> political and business patterns of societies. Not exactly. Emacs is only part of my life, free software advocacy is only part of my life. In fact, living in a rather unfree (though very comfortable) society, software freedom is only a small part of the libertarian advocacy I should engage in. I prefer the simplicity of advocating the _quality_ of free software by producing it and giving it away, and of advocating the _extension_ of software freedom by _talking_ about it and engaging in other political behavior, separately from development. To me, the Emacs or XEmacs license is an instrument to enable sharing, no more, no less. It's not part of advocacy for me; I'm equally happy with whatever free upstream license, permissive or copyleft. It distresses me that licensing issues (and related legal flummery), however necessary, get in the way of sharing. You can mix advocacy with development if you like; I'm happy that you are free to do so. Nor do I speak for Andy, or need to. I don't know what he thinks he's doing, and it doesn't matter to me as long as we can share the code. Different people doing things different ways: that's freedom. That's good. Robert> An organization has at least three options, none vague: I am sorry, but although some of what you write about the business and socioeconomic environment in this passage is accurate, much is quite inadequate. Especially beware of false trichotomies, the CC-with- commercial-restriction does not fit any of the options as written. Robert> The goal of the GNU project is to change the wider Robert> society's default ground rules and default assumptions. Which is why using the label "free" for a license that permits self- serving restrictions was a strategic mistake IMHO. I really don't see a correspondingly large gain to offset the very real reputational damage, eg among Debian community members. It doesn't make any difference for XEmacs; the existing doc license will forever be incompatible with any strong copyleft but itself. But personally I wish the FSF would amend the GFDL to remove the additional encumbering restrictions, or simply rename it the GNU Documentation License: "The GDL is a not-too-unfree documentation license that reserves certain non-economic rights to authors, while perpetually protecting the freedoms it does provide for users. We use it ourselves to ensure that our advocacy of freedom always accompanies our documentation, while users will always be able to adapt the documentation to the needs of their derivatives of our free software." Still unfree, but very hard to get upset about when you put it that way.:-) "Do I contradict myself? Very well then; I contradict myself. I am large, I contain multitudes." -- W. Whitman, Song of Myself --

"Robert J. Chassell" <bob(a)rattlesnake.com&gt; writes: Well, but that's no reason to cheer the good guys when they are shooting themselves and their friends in the foot. Anyway, could we keep off the picturesque rhetoric? If there is nothing new to say about the topic, nothing is gained by repeating the already said things in an obfuscated way. I guess we more or less got our differing points of view presented. We have two different problems: A) Emacs changed its manual licence from the old licence to the GFDL, and XEmacs can't or does not want to easily follow suit without contacting _their_ contributors. B) Both the old as well as the new Emacs manual licence are GPL-incompatible and thus present problems for integrating work on the manual and the code for derived works that are not copyrighted all by the same legal entity. It would appear to me that "A" is not something that we can reasonably deal with in isolation: if we accompany every change of the licence of the Emacs manual with an exception for old times' sakes, there is no point in changing the licence in the first place. However, A is in some manner an outgrowth of problem B, and if we got B solved in a satisfactory way, it might mean that XEmacs developers (like everybody else) would need to adapt at most _one_ more time. One proposal of mine was dual GFDL/GPL licencing which still has the disadvantage that third party code can be pulled into the manual by others only while sacrificing the GFDL licence, so we probably will still have the FSF as the primary responsible (non-public) source for GFDL manuals. It has the advantage that it can be accomplished rather fast, and the disadvantage that it does not seem to solve any of the more _urgent_ problems right now (certainly not the problem of the XEmacs developers, except that they might be less uncomfortable with the necessary relicensing then). On the long run, I'd hope that the next version of the GPL would become suitable to cover the generated of printed manuals in a satisfactory way without the need for a separate licence. However, this will take quite long, and it does not appear to me that Richard thinks it feasible at all. Other choices are to let things stay as they are right now. All of those choices don't look very appealing. And there is little sense in dressing them up with rhetoric about how free software and its licences are either great or completely irrelevant. Whether they are great or irrelevant, we still have to pick them, and the cases have more or less been made. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Robert> It is not merely picturesque rhetoric, it is true: you do Robert> not have to spend all your time supporting freedom to be a Robert> fellow who helps others. In the case of software, you can Robert> do this by choosing a license. Excuse me? Richard just denied exactly that possibility to us, in <E1CctyU-0007l0-D7(a)fencepost.gnu.org&gt;. In general, authors of derivatives of works licensed under strong copyleft have _no_ choice. I can choose not to distribute my work on XEmacs, but _the FSF_ chose XEmacs's licenses many years ago, leaving _me_ with _no_ choice[1] of license. That's what strong copyleft is all about, removing certain freedoms in order to protect certain other freedoms, deemed to be of overriding importance. IIRC, the FSF openly acknowledges this on the GNU web site among other places. It's a reasonable compromise, but it is compromise. XEmacs's documentation problem is simply "collateral damage" in the FSF's war against proprietary abuses. Richard says "too bad." It's a clear inconvenience for us, and he could have been more gracious, but he's exactly right. It is both undesirable and unavoidable. Robert> and suggested, although he did not say so, that choosing a Robert> good license, and dealing with legal paperwork, takes a Robert> great deal of time. You are correct that I did not say so. However, I did not suggest that choosing a license takes time. I suggested that dealing with a license chosen by someone else does. That's what this thread is about, at least for everyone who has posted except you. Robert> But that is not true. He framed the issue erroneously. Wrong. You are trying to switch discussion from the difficulties of dealing with someone else's license to the simplicity of choosing your own. That doesn't make my framing of _my_ issue erroneous. [...] Robert> which means that XEmacs depends on `security by Robert> obscurity'. This means that if XEmacs becomes widely No "if", at least not if GNU Emacs is the standard of "widely used." ;-) Robert> used, this policy may cause unanticipated trouble. Wrong again. I am satisfied with the XEmacs strategy as I understand it because I believe that there is no security, period. The SCO case proves that. SCO did not attack "code of dubious provenance"; they went after IBM's well-documented contribution. If the meanest patent shark in the ocean, IBM, doesn't know what "good papers" look like, who does? Therefore I do not worry about "unanticipated" technical trouble when the bad guys simply resort to brute force---lies, FUD and expensive lawyers---rather than anything resembling legal reasoning. "The Internet interprets censorship as damage, and routes around it." Similarly, our (implicit) strategy is to interpret copyright claims as damage, and to code around it. (We already have to do that, with the Emacs documentation. With friends like these ... well, I'll take such friends any day---and ask them to stop plinking BBs at my foot.) Risky strategy? Of course. The FSF's strategy is less risky, but not a sure thing. (For example, it is always vulnerable to attack via a completely independent patent on any technology it implements.) In return for risk reduction in the long run, it does, however, involve known and certain damage to the interests of some free software users and developers in the short run. A reasonable compromise---as is ours. Any ecologist will tell you that monoculture itself is risky. Vive la difference! Let Freedom ring![2] In the next paragraphs, A = practical difficulty of changing license of community-owned software B = incompatibility of GPL and GFDL dak> However, A is in some manner an outgrowth of problem B, dak> and if we got B solved in a satisfactory way, it might mean dak> that XEmacs developers (like everybody else) would need to dak> adapt at most _one_ more time. Robert> Maybe. But more likely more than one more time. Doesn't worry me. The big Problem A XEmacs faces with the FSF's old Emacs documentation license (aka the current XEmacs documentation license) is that it is unnamed and unversioned. Satisfactory resolution of B will involve a named versioned license so that a permission statement of the form "may be redistributed under the GNU Perfected License, version 1.0 or later, at your option" can be used. Robert> There is reason to separate the GFDL from the GPL. IMO, this is very short-sighted. Several hackers have pointed out the convergence between code and documentation as exemplified by uh, well, GNU Emacs itself. Don't forget "literate programming". The library association's brief in the Eldridge case points out the importance of cut and paste in compilations of existing documents. I have musician and film acquaintances who wish to have the same freedom to borrow the recordings of others that I have to borrow the code of GNU Emacs. I'm sure there are classes of information that you and I would intuitively agree are "not software" that I have not yet considered. I don't see why they shouldn't all benefit from the same definition of freedom as software. There simply is no reason not to use the GPL, perhaps in a slightly modified version to avoid referring to documentation as "the Program", etc, except for reasons of encouraging commerce.[3][4] Those reasons apply with equal force to software, yet in the case of software are rejected most vehemently by exactly the folks who insist that the GFDL is a free license. A rather unappealing combination. dak> All of those choices don't look very appealing. Robert> I agree. It is not an appealing world. And it is getting Robert> worse. It's always darkest before the dawn. When Milton Friedman and Kenneth Arrow can sign the same amicus brief for Eldridge, there is hope. Footnotes: [1] Yes, I have the option of delegating that choice to the FSF, and in fact I have done so. This eliminates the problem of incompatibility between GNU Emacs and XEmacs licenses for my own contributions, but still leaves me with _no choice of license_. [2] Sorry, David, but I do so love my own picturesque rhetoric. [3] Albeit on better terms than the "sorry for the legalese, but the net effect is that copying without explicit permission is forbidden" that graces O'Reilly's _X Window System_ series. [4] Of course there are clauses of the GFDL that deal with issues like "technical means to prevent copying". But it has long been recognized that the GPL needs to be amended to deal with those issues, and the GFDL's terms are arguably problematic. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Richard Stallman <rms(a)gnu.org&gt; writes: If you want to produce a help sheet from the contents of the manual, having to include the complete invariant sections might prove prohibitive even where the scope and content of additional invariant sections has not been chosen explicitly for encumbering further distribution by a party in the middle. But of course, this has been trodded out with the Debian people already, and IIRC the GFDL does not meet their Debian Free Software Guideline, which was quite closely modeled after the FSF's idea of Software Freedom as expressed in various publications. But it leads nowhere to discuss the _name_ of the licence. The only thing that is interesting is how it is applied, and to what. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

David Kastrup <dak(a)gnu.org&gt; writes: I haven't studied the GFDL, but IIUC, the issue raised here with the GFDL is this: It is not legal (execpt for the copyright owner) to take sections from a GFDL'ed text and incorporating that text into a GPL program or other GPL or GFDL (or similarly) licensed documentation without breaking the GFDL of the original text. Compare this to taking a section of one GPL program and including it in another GPL program -- that's fully legal (IIUC). -- Kim F. Storm <storm(a)cua.dk&gt; http://www.cua.dk

This is COMPLETELY relevant to this list, because the bottom issue is [a] XEmacs forked and kept the identical license [b] 3 or 4 years ago -- i.e. 9-10 years after the XEmacs fork -- you changed the license in a way that it cross-incompatible. [c] I made a simple request -- will you cross-license the manual for us? [d] you said no. This is totally relevant to GNU Emacs. Richard, please reconsider. You have a reputation of antipathy towards XEmacs. If you're at all interested in mending fences a little, this would be a very easy step -- simply declare that we are allowed to use the code under our license (which was your license up through 2000 or so). Otherwise you give the impression of actively hindering the XEmacs project. ben

Richard, under what circumstances would you accept or refuse such a request?

"Ben Wing" <ben(a)666.com&gt; writes: Uh, no. It is relevant to XEmacs. Since you more or less stated that XEmacs developers are not to be bothered with issues like licences, it is somewhat unclear what factual problem you would have with changing the XEmacs manual licence to the GFDL. That you don't feel like it is not really sufficient. To the extent that your problems are related to actual practical considerations instead of "we liked the older licence better and did not bother asking contributors whether they'd go with changes, since they better be fine anyhow", they might also be relevant to Emacs. It is my personal opinion that by far the most prominent distribution channel for the Emacs manual is as part of Emacs, and so it should also be available under the GPL (which would probably not help your case, incidentally). I'd be somewhat less inclined to state the same thing for the Elisp tutorial: that is more like being a separate piece of software, not as tightly integrated as either the Elisp manual and the Emacs manual are with Emacs. The question to solve for the licences of Emacs are what benefits Emacs first, and free software in general second. Licences like the GPL and the GFDL retain their force by having relevant software with suitable copyright owners willing to defend them. The FSF maintains a large and significant body of free software as the sole copyright holder, and it is paying a high price for it: the price is that the FSF itself is unable to reap the benefits of the GPL. It can't reincorporate third party contributions without explicit assignment. The GPL implies the freedom to fork. XEmacs developers have decided to make use of that freedom, and have by the same token decided that they would make use of that freedom also by relaxing their contribution criteria and maintaining diversified copyrights, partly not even tracking them. Which you were free to do. A different significant fork from FSF-maintained software was egcs. The egcs project, in contrast, decided that they would not simplify matters in a similar way: copyright assignments to the FSF were diligently maintained. As a result, this fork was able to get merged with the FSF's own variant of GCC again. Of course, egcs developers already had seen the consequences of the Emacs/XEmacs fork, so it was easier for them to decide differently. Now with regard to the discussion on this list, it has not made apparent by you a) why the GFDL is a bad choice for Emacs manuals (I myself have offered some opinions about that, but those mostly hold equally for the previous licence). b) why it would be technically impossible for you to change the XEmacs manual licence to the GFDL: it does not seem like you have handed out any written assurances that the licence is never going to change. My personal guess would be "we don't like the licence". Neither do I for this purpose and have explained why. But my dislike would be for the old version of the licence, too. It is pointless to say "well, everybody else but us should be affected by the GFDL, so please give us an exception". If there are arguments good enough for you, they should also be good enough for everybody else. So please explain in detail what concrete problems you would have with a licence change that other users and developers of free software could reasonably also be expected to have. As long as this is not particularly connected with Emacs itself, but rather a general dislike of the GFDL, I have to agree with Richard that this group does not seem the right place for it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Richard Stallman <rms(a)gnu.org&gt; writes: Definitely. It strikes me as a disadvantage, though not because of XEmacs in particular, but because it will be a disadvantage for _any_ derived project, and the whole point of a public licence like the GPL is not to put the copyright holder into a special position with regard to software development. You are speaking here for Ben Wing, presumably. But Ben Wing is not the only developer of XEmacs. I know pretty well, for example, that Stephen Turnbull, the current maintainer, considers the inability to broadly contribute back code with the stringency required by the Emacs project a disadvantage and has invested substantial amounts of work to remedy this in the past. But he as well as others are stuck with a history they can't change at their will. And that history is one of taking the "GPL" at its letter and spirit, developing in the manner that the "Public" in "General Public Licence" is suggesting, a manner that we as Emacs developers are not free to enjoy because our laws make it important that there remain substantial pieces of software which may be defended in court by a substantial copyright holder without conflict of interests from other contributors. Correct. We don't owe them anything. But the freedoms they enjoy are the freedoms we are fighting for in the first place. And where we find that our fight does not lead to the desired freedoms for the recipients of our software, we need to double-check. To meet our own goals, not those of the others. Let me put on the record here that I'd not consider you to be a pushover just because you are willing to judge requests for relicensing on their merit piece by piece, as you agreed to before, without letting yourself be swayed by some cheap rhetoric of Ben Wing. Even if Ben Wing was the only beneficiary of that process, we have the unfortunate situation that a free project with a free community is encountering problems with our choice of free licences in the intended manner. We need to look into this. Maybe after considering their case in detail we'll find that the situation is such that a licence change to GFDL is something that their processes should have made possible in the first place, and that there is nothing to be done on our side. But it would be a mistake not to look into this possible problem merely because the superficial beneficiary is XEmacs, and there are some XEmacs developers some of us don't like. It still is a case of downstream maintenance of free software, and if we don't care about the effects downstream from a copyright assigned pool, we might as well forget about public licensing altogether. In the long run, we should strive for a solution that does not necessitate any exceptions. But in the mean time, we should try to hold up the spirit of our free licences, if necessary, manually and learn about the problems with their application downstream. I'd offer to go here as a go-between if necessary where individual more detailed requests are concerned. I agree with you that there does not seem to be a persuasive case for blanket permissions and agreements currently, and so I'll be happy to take this discussion into private. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

I do not understand why the GFDL exists at all. It seems to me that the GPL is as adequate for manuals as it is for code. The GPL was designed for software, not for books. The GPL's requirements would be quite inconvenient for anyone who wanted to publish a printed book from the material. I think the GFDL says more or less what it ought to say.

??? The FSF sells printed copies of the ELisp manual. I actually saw them.

Well, but it would not seem that there is much interest from independent publishers, and that was supposed to be the driving factor for choosing the GFDL instead of the GPL, if I understood the argument correctly. Evidentally, I have not been clear. Nothing in this thread that I said should have suggested that interest from independent publishers drives the use of the GFDL with regard to the elisp reference manual. Instead, I have tried to say that the goal is to persuade others to choose the GFDL over a `Creative Commons license with a commercial restriction' or similar license. The GFDL is better. Being a `do as we do' organization is necessary on account of the characters of the people in the organization. They are lousy at doing one thing and saying something at odds with that action. The GFDL ends up both moral and practical. These are the driving factors. (Incidentally, as far as I can see, the timescale for measuring success or failure is another generation or so. My hope is that by that time, societies will have decided that it is a good idea to permit strangers to modify changeable works like technical documentation, to permit strangers to manufacture copies of them that use resources, and at the same time to permit the initiating organizations to recover costs they have expended. My fear is that the strategy will have failed and that societies will have decided to restrict your freedom to protect yourself from those who would hinder development to their benefit.) -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

Brian Palmer <bpalmer(a)gmail.com&gt; writes: Because it still is impossible to move GPLed material into a manual that is supposed to be dual-licenced under the GPL and the GFDL, for anyone except the copyright holder on the GPLed software? It would solve some problems with Debian et al, in that their guidelines would then permit them to distribute Emacs including its manuals under the GPL: so those usages where the manual is not actually intended to go into print are covered. It would also mean that a publisher wanting to print the Emacs manual under the GFDL might have to get it from the FSF even though he might have a Debian CD flying around (if patches to the manual are done GPL-only). And it might cause derived versions of the Emacs manual around that are not publishable under the GFDL. Really, we need a version of the GPL that applies tolerably well to manuals... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

Bruce> As far as I can tell the XEmacs people aren't asking for Bruce> GNU GPL; the XEmacs manual is distributed under conditions Bruce> which look incompatible with the GNU GPL. That is correct. We are not asking for the GPL. We are asking for the GNU Emacs (v19, I think) documentation license, which was, unfortunately for the current situation, anonymous and unversioned. I think of this license as approximately a special case of the GFDL. Because both require that any redistribution take place under terms _identical_ to the original, they are, however, mutually incompatible. Whatever the FSF might decide to do with its policy on documentation licenses, it shouldn't revert to a license that can only be specified by quoting the whole thing; it would be asking for this situation all over again. So no matter how you slice it, XEmacs would require an specific sublicense from the FSF to incorporate portions of GNU Emacs documents in the XEmacs documentation. Bruce> So presumably in 2000 the FSF chose to change the license, Bruce> and the XEmacs people didn't follow, either because they Bruce> didn't like the GFDL or because they felt they couldn't Bruce> (changing licences is obviously easier if one entity owns Bruce> the copyright). As far as I know, it didn't occur to us to change the license. There was no discussion that I can recall until perhaps two years later, which came to the obvious conclusion that changing the license was impractical, and the discussion was immediately dropped. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

There's been much contrasting of the GFDL w/ the GPL, or the GFDL with a "Creative Commons license with commercial restriction". I've never meant to suggest either of those, but rather licenses similar to the Creative Commons Plain Attribution or ShareAlike. Yes, I understand. Unfortunately, you are not the one choosing the license to apply. I have seen items that ought to be free put under a "Creative Commons license with commercial restriction". We do not need to convince anyone who is already using a free license. They are not harming us or others. (Note: I'm not advocating using an actual Creative Commons license, I agree. Neither am I. Indeed, I think it was wrong to give free and non-free licenses the same initial name, that of `Creative Commons'. The language is confusing. Rhetoric becomes very important in persuading people who mostly are not listening, who do not care much, and who are not professionals in the subject matter, such as music creation or software. For Emacs, what advantages does the GFDL have over (say) Creative Commons Plain Attribution or Creative Commons Attribution-ShareAlike? The two reasons I said before: first, that when FSF is dealing with the actual licenses of others, those two do not count. The license that counts is restricted. Please remember, neither you nor I are defining this issue. Second, as I said above, when dealing with strangers, language counts. Again, this is only about the application of the GFDL to Emacs, *not* about the GFDL in general. Right. This is what I am talking about: the application of the GFDL to Emacs. Note that my elisions are telling: I am not talking about the application of the GFDL to Emacs in a small community of like-minded programmers, as some thought the Emacs community was 20 years ago. Nor I am talking about the application of the GFDL to Emacs in a larger community that is harmless to Emacs. Unhappily, I am talking about the application of the GFDL to Emacs in the current world, its default circumstances. -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

OK, for books it makes sense. But it doesn't for material such as the elisp manual (which is not published). We published it in the past, and I hope that we or others will publish it in the future.

... with the electronic forms of the manuals, the GPL appears more appropriate to me. What specifically of the current form of the GFDL, as it applies electronically, do you not like? For example, I do not like the language in the license that talks of publishing printed copies. This suggests that `publisher' means only `printed copy publisher'. I would prefer to see the term `publisher' be more general. However, I do not know whether the term is necessary for legal purposes. My sense is that commercial restrictions should apply to those who publish using `non-recoverable or rivalrous resources',like spending resources to get attention, using printed paper, or stamped CDs. But I am not sure my language is right, either. (Note that technological change may decrease the cost of vehicles -- something may replace printed paper or CDs -- but nothing can reduce the cost of attention getting.) -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

... My issue is not with the GFDL per se. My issue is that it is not GPL-compatible, yet we use it for something that forms an integrated and tightly coupled part of Emacs and evolves with it. And that defeats the "Public" in GPL since it requires the copyright holder for normal maintenance work of derived versions. I do not understand you. First, the GFDL is not for code. Second, anyone can change the body of a GFDL's work. This means that you can modify code under the GNU GPL and then document your modification. And you may distribute the result, attempting to charge if you wish for both code and documentation. Or, of course, you may give away both. You have the freedom. The copyright holder is irrelevant. The only parts you may not legally change are parts that do not deal with the subject. This kind of invariance makes sense. The invariance means either that an author wrote something about the document, like why he wrote the first draft, or that an initial publisher used `non-recoverable or rivalrous resources'. The latter is the key new feature: it is designed to restrict other publishers free riding, but not to stop them from manufacturing and distributing copies of the work. Previously, invariant sections were an ad hoc part of documentation licenses. True, they usually were not aimed at encouraging a publisher (using non-recoverable or rivalrous resources) a little bit, but without legally excluding all other publishers as the "Creative Commons license with commercial restriction" does. That is the main new feature; and it could have been implemented in previous documentation licenses. Generally, people and organizations charge if they lose resources for each item distributed and do not treat the used resources as a `lost leader'. Thus, book publishers give away some books as lost leaders in order to gather attention and charge for the rest. But if they give away resources and never recover them, they will go broke if a book is successful. For the past half millenium, in Europe and in derived countries like the US, the method for recovering resources involved in books has been to prevent others from legally charging for copies that they produce. If necessary, police enforce this ban. The GFDL is different. It does not create a ban, but puts up a barrier (that is what the front and back cover text requirement is about). The goal is that the barrier be somewhat high, but not too high. In contrast, the "Creative Commons license with commercial restriction" and similar licenses put up a ban. Please explain further how GFDL actions defeat the "Public" in GPL, especially since invariant sections have existed in the licenses for past documentation. -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc

DOC strings and manual entries are material that are frequently copied between those differently licenced items. Now I see what you are saying. The legal question is, when you are basing additions to a Texinfo manual on a large number of doc strings from functions, are the changes you are likely to make big enough so that the manual does not become a derivative work? (Presumably, fair use means the issue is not relevant to a small number of doc strings. And the issue not relevant to additions that are quite different.) I don't know the legal answer. Presuming that neither RMS nor anyone else has thought of this, it becomes necessary to ask some people who understand the laws in all the major countries of concern. That is a major undertaking. My hunch is that a legally valid expectation is that any one's write up will be sufficiently different, simply because he or she is trying to write a document, not a doc string. Put another way, only poorly written documentation would be illegal.... But maybe not. As for ... code snippets ... [which include doc strings] at the end of the node, (emacs)GNU Free Documentation License says If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. which handles this issue unless you are moving others' code into a Texinfo manual without rewriting it more appropriately for a manual. If my hunch is right, that would be no problem since it would be reasonable to expect you to rewrite it suitably. Otherwise, as far as I can see, you have a reasonable point. -- Robert J. Chassell bob(a)rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc