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 15:15:00 +0200 Message-ID: <87iqu37n6z.fsf@skyscraper.fehenstaub.lan> References: <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> <87y72z7t3c.fsf@skyscraper.fehenstaub.lan> <20080814123917.GC2593@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218719750 6149 80.91.229.12 (14 Aug 2008 13:15:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Aug 2008 13:15:50 +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 15:16:41 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 1KTcgx-0000lI-8z for ged-emacs-devel@m.gmane.org; Thu, 14 Aug 2008 15:16:39 +0200 Original-Received: from localhost ([127.0.0.1]:46738 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTcg0-0000XM-OL for ged-emacs-devel@m.gmane.org; Thu, 14 Aug 2008 09:15:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KTcfv-0000X8-O4 for emacs-devel@gnu.org; Thu, 14 Aug 2008 09:15:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KTcfu-0000Wv-0D for emacs-devel@gnu.org; Thu, 14 Aug 2008 09:15:34 -0400 Original-Received: from [199.232.76.173] (port=53246 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KTcft-0000Ws-QM for emacs-devel@gnu.org; Thu, 14 Aug 2008 09:15:33 -0400 Original-Received: from saeurebad.de ([85.214.36.134]:42658) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KTcfk-0002Bc-PZ; Thu, 14 Aug 2008 09:15:25 -0400 Original-Received: by saeurebad.de (Postfix, from userid 107) id CC3932F00CA; Thu, 14 Aug 2008 15:15:23 +0200 (CEST) Original-Received: from localhost (83-221-69-159.dynamic.primacom.net [83.221.69.159]) by saeurebad.de (Postfix) with ESMTP id 77CE02F00C4; Thu, 14 Aug 2008 15:15:22 +0200 (CEST) In-Reply-To: <20080814123917.GC2593@muc.de> (Alan Mackenzie's message of "Thu, 14 Aug 2008 12:39:17 +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:102447 Archived-At: Hi, again again! Alan Mackenzie writes: > Hi, again! > > On Thu, Aug 14, 2008 at 01:07:35PM +0200, Johannes Weiner wrote: >> Hi Alan, > >> Alan Mackenzie writes: > >> > 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. > > Just to clarify my previous post, I do see that there are strong points > on both sides of this argument. My personal view is that the coming into > effective existence of "enslaved" versions of Emacs through the loading > of binary libraries would outweigh the benefits. Okay. >> 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. > > The loadability of modules into the kernel has effects on the whole free > software community. Somebody MUST decide this issue for other people, > possibly by default. In these two cases, the decisions were taken by > Linus Torvalds and Richard Stallman. It is entirely possible that both > were right. Now I agree with you about it being a political thing. > ;-) I see the main difference is that Torvalds choose to leave that decision to the user by giving him the needed mechanisms to do crazy stuff. Richard restricted the user from doing crazy stuff. >> I argue with people loading these modules and tell them why I consider >> it stupid but the decision should be their own. > > The facility you want would allow people, in effect, to make proprietary > extensions to Emacs. We could end up with a firm like Linspire saying > "our version of Emacs is superior because it can access files over the > protocol, so why don't you buy a license for our superior > version of Linux instead of your lame Ubuntu or RedHat?". Yeah, this module license restriction comes to mind again. But really, this possibility has been there since XEmacs included the module loader and noone cared to sell proprietary modules. BUT! If a proprietary module would be written for Emacs that solves a problem no free alternative does so far and the functionality could be of benefit to the users, this could be motivation to create a free alternative. At least that is what I think. But that's just me, I really love evolving technology :-) > I think that this possibility outweighs the benefit from being able to > load in something like the OTR libraries. At the same time, I respect > your view to the contrary. > >> > 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 explicitly identify themselves as GPL-licensed to be >> able to use GPL-only symbols. > > I didn't know that. Thanks! > >> IANAL but perhaps a mechanism for Emacs that requires modules to >> announce themselves as GPL'd software would be enough? > > More specifically, as GPL3 software. Yeah, of course. The thing that you implement a cooperative loader, more or less. If the module doesn't say `hey, I am free software' on load time, the loader could refuse to continue. This works for Linux. I mean, I don't know of situations where a module claimed falsely to be under a free license while it was not, in order to access GPL symbols or prevent the kernel from tainting itself. But as said, it would be good to have some lawyer sort this out. >> > 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. > > There are other choices. You could, for example, write a module-loading > facility yourself, and thus distribute your own Emacs fork. You'ld not > make yourself popular though, any more than the Lucid Emacs crowd did a > long time ago. Yes, it's the difference between theoretical freedom and reality. Also, forking would mean leaving GNU Emacs behind, which I would prefer not to :) > Or, you could simply adapt the OTR sources and build them into Emacs. > Well, you could if either the OTR author was prepared to release his > sources under GPL3, or RMS was prepared to accept GPL2 stuff into Emacs. > Hell will freeze over before the second of these happens. ;-) In my opinion the OTR sources don't have anything to do with the Emacs core. The idea of the el packages is that you lazy load code and have it apart from the core. The same is not possible for C code but it would be great to have that! By the way, what prevents you from loading proprietary .elc files? > By the way, do you really live in an acid bath? ;-) Jawohl! It's actually a reference to a reeeeaaally bad piece of german electronic dance music... `Join me in my bath of acid. Witness your own decay. Boom Boom Boom Boom...' Hannes