From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Johannes Weiner Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Thu, 14 Aug 2008 13:07:35 +0200 Message-ID: <87y72z7t3c.fsf@skyscraper.fehenstaub.lan> References: <10697146.3630221218551689983.JavaMail.www@wwinf4615> <20080812171404.GB7999@muc.de> <20080813092057.GA3010@muc.de> <20080814083817.GA2593@muc.de> <877iak7xfp.fsf@skyscraper.fehenstaub.lan> <873al79akr.fsf@skyscraper.fehenstaub.lan> <20080814103040.GB2593@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218712105 5916 80.91.229.12 (14 Aug 2008 11:08:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Aug 2008 11:08:25 +0000 (UTC) Cc: ams@gnu.org, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 14 13:09:17 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 1KTahg-0003uy-1g for ged-emacs-devel@m.gmane.org; Thu, 14 Aug 2008 13:09:16 +0200 Original-Received: from localhost ([127.0.0.1]:33471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTagi-0003so-WA for ged-emacs-devel@m.gmane.org; Thu, 14 Aug 2008 07:08:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTagf-0003sa-9Q for emacs-devel@gnu.org; Thu, 14 Aug 2008 07:08:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTagc-0003sL-Ht for emacs-devel@gnu.org; Thu, 14 Aug 2008 07:08:11 -0400 Original-Received: from [199.232.76.173] (port=58460 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTagc-0003sI-Dp for emacs-devel@gnu.org; Thu, 14 Aug 2008 07:08:10 -0400 Original-Received: from saeurebad.de ([85.214.36.134]:41739) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTagS-0005TT-Kd; Thu, 14 Aug 2008 07:08:01 -0400 Original-Received: by saeurebad.de (Postfix, from userid 107) id 151A72F00CA; Thu, 14 Aug 2008 13:07:59 +0200 (CEST) Original-Received: from localhost (83-221-69-159.dynamic.primacom.net [83.221.69.159]) by saeurebad.de (Postfix) with ESMTP id 1C2CB2F00C4; Thu, 14 Aug 2008 13:07:58 +0200 (CEST) In-Reply-To: <20080814103040.GB2593@muc.de> (Alan Mackenzie's message of "Thu, 14 Aug 2008 10:30:40 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:102441 Archived-At: Hi Alan, Alan Mackenzie writes: > Hi, Johannes, > > On Thu, Aug 14, 2008 at 12:04:36PM +0200, Johannes Weiner wrote: >> Hi, > >> We can fix the former if our definition of freedom allows us to. This >> was the whole point of my previous email, in fact. > >> Emacs has still no support to load shared libraries during runtime and >> IIRC it was rejected back then due to political reasons. I call this >> crippling. > > Well, for a piece of software that is crippled, Emacs works remarkably > well. If only non-crippled software could run as fast. Uh, crap, that came over wrong. I was never to claim that Emacs works bad. I just know there are features that would further improve it. > I think the lack of provision of binary libraries is more of a legal > thing than a political one. It would allow people to extend Emacs with > non-free code, and it would be problematic to prevent them distributing > their enslaved versions of Emacs. > > I agree with Richard that this would > be undesirable in the extreme. Linux has taken the opposite attitude: > that extending Linux with non-free modules is OK. This has not been free > of problems. I am very sensitive when it comes to such decisions. Because when you try to prevent idiots from being idiots, you will also restrict people that could do great work with the potential features. The primary thing about Linux modules is, well, that you can load modules. This gives you power to do really clever stuff. Whether one loads proprietary modules into the kernel is a personal decision and I don't like deciding for other people. I argue with people loading these modules and tell them why I consider it stupid but the decision should be their own. Neither the Linux kernel, nor I as a free user who chooses not to load proprietary bullcrap into it, have been harmed by the kernel's mechanism to load said bullcrap. If it restricts people, than because of their own free decision to restrict themselves. That is not a reason to leave the mechanism out alltogether. You can also not blame car manufacturers for building devices that might help a person to kill itself by driving against a tree as a way of suicide. People will do that on occasion, this is not a reason to forbid cars for all others that get a good job done by utilizing it. And having a mechanims that would be very helpful but also makes it potentially a bit easier to do stupid things is better than not having this mechanism. I also refer to the recently discussed emacs package manager. > If there were a way of licensing Emacs so that only free libraries could > be attached to it, this would be done. Linux prevents certain APIs from being used by non-free modules. And modules have to explicitely identify themselves as GPL-licensed to be able to use GPL-only symbols. IANAL but perhaps a mechanism for Emacs that requires modules to announce themselves as GPL'd software would be enough? > What sort of libraries do you want to use from Emacs anyway? I would be interested in having OTR support for jabber.el. So my choice is between implementing the OTR protocol in elisp or linking the emacs binary against libotr. I consider both solutions bad by design. The optimal solution would be for jabber.el to issue (require 'libotr) and have Emacs doing the right thing. Hannes