From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Mon, 25 Aug 2008 22:01:05 +0000 Message-ID: <20080825220105.GA13599@muc.de> References: <20080816213508.GA8530@muc.de> <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp> <20080817073124.GA1294@muc.de> <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818101802.GA2615@muc.de> <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818210927.GD2615@muc.de> <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> <20080819155221.GA11524@muc.de> <871w0dcg6j.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219701488 814 80.91.229.12 (25 Aug 2008 21:58:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Aug 2008 21:58:08 +0000 (UTC) Cc: hannes@saeurebad.de, rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 25 23:59:01 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KXk5M-0001C1-93 for ged-emacs-devel@m.gmane.org; Mon, 25 Aug 2008 23:58:52 +0200 Original-Received: from localhost ([127.0.0.1]:52355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXk4O-0002t7-EI for ged-emacs-devel@m.gmane.org; Mon, 25 Aug 2008 17:57:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXk4K-0002rY-6g for emacs-devel@gnu.org; Mon, 25 Aug 2008 17:57:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXk4J-0002qt-I9 for emacs-devel@gnu.org; Mon, 25 Aug 2008 17:57:47 -0400 Original-Received: from [199.232.76.173] (port=35820 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXk4J-0002qf-9W for emacs-devel@gnu.org; Mon, 25 Aug 2008 17:57:47 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:3299 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KXk4I-0007RG-SY for emacs-devel@gnu.org; Mon, 25 Aug 2008 17:57:47 -0400 Original-Received: (qmail 52365 invoked by uid 3782); 25 Aug 2008 21:57:39 -0000 Original-Received: from acm.muc.de (pD9E23E5A.dip.t-dialin.net [217.226.62.90]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 25 Aug 2008 23:57:38 +0200 Original-Received: (qmail 14326 invoked by uid 1000); 25 Aug 2008 22:01:05 -0000 Content-Disposition: inline In-Reply-To: <871w0dcg6j.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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: news.gmane.org gmane.emacs.devel:102968 Archived-At: Hi, Stephen! On Mon, Aug 25, 2008 at 11:39:16PM +0900, Stephen J. Turnbull wrote: > Alan Mackenzie writes: > > What, exactly, are we getting so worked up about, then? > Well, I've been perplexed by the "no dynamic loading" policy for about > a decade now. I know that Richard is not going to give an answer > except that he's fearful, uncertain, and doubtful about dynamic > loading, and so has decided to avoid it. I was hoping you might > provide some insight, but you're giving me the same line. I'm very > frustrated by that. Sorry. The thing is, we're at the place where free software principles become ironic, inconsistent and contradictory, even absurd. Every half-decent religion or philosopy, even science and maths, has suchlike, so why should we expect free software to be any different? Yes, we want software to be free, but no, we don't want people to use this freedom in certain ways, ways which would inhibit the progress of free software. Something's got to give. In a democracy, sometimes people get elected who want to dismantle the democracy. So you have a constitution to protect it, and this usually works. In maths, there is the Axiom of Choice (which is obviously true) and Zorn's Lemma (which is patently absurd), yet the two are logically equivalent. Mathematicians are fairly relaxed about absurdities and joke about them over an afternoon cup of tea. The "resolution" in free software is to soft-pedal, to hope that nobody does anything too unfree, and to avoid giving them too much help and encouragement. A bit like politics, really. So whilst making dynamic modules part of "official" Emacs might not change what is possible, it might well encourage what is legitimate, yet we don't want to happen; it's a kind of touchy-feely thing. That's my understanding, anyway - I could be totally wrong. On the particular issue of dynamic modules, I don't feel I have the experience to judge the conflicting issues, so I defer to Richard's. I'm not sure what would happen if we made dynamic loading a first-class feature, documented in the Elisp manual and NEWS, as opposed to being downloadable in some obscure patch, not supported by the main maintainers, assuming you've even heard of it. Eric Ludlam mentioned a product called Xrefactory a couple of days ago. It seems to be a refactoring tool based upon (X)Emacs. Yes, this is legitimate within the terms of the GPL, but isn't the sort of thing we really want to encourage; it's not free, neither in the speech nor beer sense. [ .... ] > > > No. I understand your point. "Introducing a module loader could > > > cause Emacs to become non-free." That's scary. > > Again, non-free "for whom?". If you'ld've made specific reference to > > people who couldn't or wouldn't take action against non-free add ons > > themselves, I'd accept you'd understood my point. > I don't think there are *any* people who *couldn't* take action[1], > and I don't understand why "wouldn't" is a problem in the context of > freedom. There are two kinds of people who wouldn't, those who have > considered the consequences and decided they don't care, and those who > just don't care. Either way, why isn't it their place to decide, and > our place to provide them with the information they need to make > informed judgments? I think our basic philosophies just differ here. I appreciate living in a "free" society, yet if Nuremberg were once again subject to a military invasion, would I accept a rifle and be willing to use it? Probably not. I gladly accept the freedom guaranteed by professional soldiers. Just as those soldiers protect those "who don't give a damn", I feel we should protect the (software) freedom of those who, for whatever reason, wouldn't protect their own. > And I still don't see how they "lose" freedom or Emacs becomes unfree. > In the first place, they *gain* capabilities that they did not have > before. True, those capabilities do not come with the four freedoms > attached, but what have they "lost"? In the second, Emacs itself is > still free, the users have the four freedoms with respect to it. Again, with Eric's example of Xrefactory, any hackers who buy that product and incorporate it into their development process thereby lose some of their freedom - their process has become tied to a product they can't control - to some extent. This is another one of these contradictions about software freedom - by exercising freedom you diminish it. -- Alan Mackenzie (Nuremberg, Germany).