From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel,gmane.emacs.xemacs.beta Subject: Re: Permission to use portions of the recent GNU Emacs Manual Date: Sun, 19 Dec 2004 13:54:47 +0000 (UTC) Message-ID: References: <014501c4e4eb$3af838d0$0300a8c0@neeeeeee2> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1103464740 29506 80.91.229.6 (19 Dec 2004 13:59:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Dec 2004 13:59:00 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 19 14:58:53 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 1Cg1aG-0007ut-00 for ; Sun, 19 Dec 2004 14:58:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cg1ke-0006CZ-Uu for ged-emacs-devel@m.gmane.org; Sun, 19 Dec 2004 09:09:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cg1ib-0005Wg-Rc for emacs-devel@gnu.org; Sun, 19 Dec 2004 09:07:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cg1iZ-0005VQ-MT for emacs-devel@gnu.org; Sun, 19 Dec 2004 09:07:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cg1iZ-0005VN-Hn for emacs-devel@gnu.org; Sun, 19 Dec 2004 09:07:27 -0500 Original-Received: from [69.168.110.189] (helo=rattlesnake.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cg1WW-0001fB-J4 for emacs-devel@gnu.org; Sun, 19 Dec 2004 08:55:00 -0500 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.115) Sun, 19 Dec 2004 13:54:47 +0000 (UTC) Original-To: emacs-devel@gnu.org, xemacs-beta@xemacs.org In-reply-to: <014501c4e4eb$3af838d0$0300a8c0@neeeeeee2> (ben@666.com) 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:31270 gmane.emacs.xemacs.beta:17501 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31270 This is COMPLETELY relevant to this list, because the bottom issue is [a] XEmacs ... However, on 12 Dec 2004, Andy Piper said XEmacs explicitly does not collect papers .... This means that XEmacs depends on charity. In this case, it did not receive charity. Of course, people in the XEmacs project can complain, but they have decided to do nothing about their license. So that part of the issue is not relevant to this list. [c] ... will you cross-license the manual for us? That is only relevant if you may not legally change the modifiable parts, and if the illegality of your modifying those parts, such as an introduction, is less important than the principle the licensors are trying to establish in the world. Is it really true that legally you may not modify variant parts as you wish? As I said on 15 Dec 2004, I have been focusing on invariant issues, the `freedoms from', rather than on the `freedoms to'. But the freedom to modify is strong. Fair use is strong. As I said, I am not a lawyer; I am not skilled in these sorts of issues and I cannot tell you legally one way or the other. If my current understanding is correct, then you have no worries about modifications and about creating short `how-to' manuals or whatever from the Emacs manual. I do think it is a bug that the GFDL is not undertandable by lay people with only a little legal knowledge. The XEmacs issue is straightforward, but the modification and fair use issues are not. In particular, if I understand correctly, `fair use' is another feature, like `derivative work', that is established by judges, not licenses. As for the second issue: do you think the purpose of the GFDL is wrong, that is bad to permit invariant sections? Of the various types of invariant section, are you against an invariant section ... that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. Are you against limitations on front and back cover texts? Or think the limitations should be different? As "Stephen J. Turnbull" said correctly In general, authors of derivatives of works licensed under strong copyleft have _no_ choice. When it started, the XEmacs project chose to depend on a license chosen by someone else. You are trying to switch discussion from the difficulties of dealing with someone else's license to the simplicity of choosing your own. But you (meaning the members of the XEmacs project) did not write Emacs initially. I know for sure. You joined. And then you decided to stop being helpful in a major purpose of the GNU Emacs project -- I am not talking about writing of code or documentation, of course; that is a means, not an end. And you decided, presuming Andy Piper is right, to depend on charity. Unless your (now I am speaking individually again) framing takes this into account, it is erroneous. You say, for example I am satisfied with the XEmacs strategy as I understand it because I believe that there is no security, period. and speaking of SCO, say, If the meanest patent shark in the ocean, IBM, doesn't know what "good papers" look like, who does? as if IBM is more important to SCO either than courts or than investors on Wall Street who might be confused by a non-GPL'd license conflict in which one side makes statements irrelevant to the case. Note that the pay of SCO leaders depends on the value of SCO stock. 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. But `technical trouble' is one way for the bad guys to fight. It is as if you believe that courts which are honest are the only way to fight, not just a tool, like other tools. ... our (implicit) strategy is to interpret copyright claims as damage, and to code around it. With patents, this is not always possible. As you say, correctly, The FSF's strategy is less risky, but not a sure thing. I agree. It is not a sure thing. That is why the FSF seeks help. That is why it introduced the GFDL; it is better than a `Creative Commons license with a commercial restriction' or similar license. Several hackers have pointed out the convergence between code and documentation .... Yes. The problem is, those who use rivalrous or non-recoverable resources are more likely in practice to be publishers on CDs or paper than those who provide code. This may well not last too much longer -- it all depends on the progress of technology, law, and business models. But in the meantime, it is simply the case that software tends to end up on computers without using rivalrous or non-recoverable resources and documentation ends up both on computers and on CDs and paper. (This is not always the case, but is frequent.) Hence, the reason for a license that deals with rivalrous or non-recoverable resources. (Printed books and CDs are rivalrous resources. Like a shirt, if you have a book, I do not have it. You can loan me the book and the shirt, but then you have neither. Your and my use rival each other's. On the other hand, you can manufacture a copy of a program and give it to me so cheaply that it is, in effect, non-rivalrous.) A company that prints a book is in the hard-copy publishing business. That is to say, in business terms, it tries to recover resources from a decreasing marginal cost product that requires use of rivalrous resources. A software project is not like that. Of course, software projects may also deal with rivalrous and non-recoverable resources. Marketing can be an example; but it looks much less significant to software than to selling books. After all, intrinsically, software does not use rivalrous resources, but books do. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc