From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: Permission to use portions of the recent GNU Emacs Manual Date: Fri, 17 Dec 2004 14:36:18 +0900 Organization: The XEmacs Project Message-ID: <87fz25bi5p.fsf@tleepslib.sk.tsukuba.ac.jp> References: <87llc49kn1.fsf@floss.red-bean.com> <6.2.0.14.2.20041212125027.024c6900@mail.comcast.net> <87d5xbd4it.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1103261849 8006 80.91.229.6 (17 Dec 2004 05:37:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Dec 2004 05:37:29 +0000 (UTC) Cc: xemacs-beta@xemacs.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 17 06:37:22 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CfAnq-0004Hy-00 for ; Fri, 17 Dec 2004 06:37:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CfAy7-0002PV-FT for ged-emacs-devel@m.gmane.org; Fri, 17 Dec 2004 00:47:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CfAxo-0002BQ-Qj for emacs-devel@gnu.org; Fri, 17 Dec 2004 00:47:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CfAxk-00028v-KN for emacs-devel@gnu.org; Fri, 17 Dec 2004 00:47:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CfAxk-000288-GU for emacs-devel@gnu.org; Fri, 17 Dec 2004 00:47:36 -0500 Original-Received: from [130.158.98.109] (helo=tleepslib.sk.tsukuba.ac.jp) by monty-python.gnu.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.34) id 1CfAmz-0000Rk-69 for emacs-devel@gnu.org; Fri, 17 Dec 2004 00:36:29 -0500 Original-Received: from steve by tleepslib.sk.tsukuba.ac.jp with local (Exim 4.34) id 1CfAmo-0008ST-Gn; Fri, 17 Dec 2004 14:36:19 +0900 Original-To: bob@rattlesnake.com In-Reply-To: (Robert J. Chassell's message of "Wed, 15 Dec 2004 23:32:58 +0000 (UTC)") User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (chayote, linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31226 gmane.emacs.xemacs.beta:17488 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31226 >>>>> "Robert" == Robert J Chassell writes: 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 . 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.