From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Sat, 16 Aug 2008 02:54:37 +0900 Message-ID: <87vdy2go4i.fsf@uwakimon.sk.tsukuba.ac.jp> References: <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> <87r68rh3xj.fsf@uwakimon.sk.tsukuba.ac.jp> <20080815141819.GB4781@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218822905 8896 80.91.229.12 (15 Aug 2008 17:55:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2008 17:55:05 +0000 (UTC) Cc: ams@gnu.org, Johannes Weiner , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 15 19:55:56 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 1KU3Wj-0007ht-O1 for ged-emacs-devel@m.gmane.org; Fri, 15 Aug 2008 19:55:54 +0200 Original-Received: from localhost ([127.0.0.1]:48592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KU3Vn-0004Vd-2b for ged-emacs-devel@m.gmane.org; Fri, 15 Aug 2008 13:54:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KU3Vd-0004RF-Uf for emacs-devel@gnu.org; Fri, 15 Aug 2008 13:54:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KU3Va-0004ON-O6 for emacs-devel@gnu.org; Fri, 15 Aug 2008 13:54:45 -0400 Original-Received: from [199.232.76.173] (port=58524 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KU3Va-0004O6-HJ for emacs-devel@gnu.org; Fri, 15 Aug 2008 13:54:42 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:35209) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KU3VP-0003uj-PO; Fri, 15 Aug 2008 13:54:32 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 915101535A8; Sat, 16 Aug 2008 02:54:29 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 99CD61A25C3; Sat, 16 Aug 2008 02:54:37 +0900 (JST) In-Reply-To: <20080815141819.GB4781@muc.de> X-Mailer: VM ?bug? under XEmacs 21.5.21 (x86_64-unknown-linux) 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:102503 Archived-At: Alan Mackenzie writes: > Hello, Stephen! > > On Fri, Aug 15, 2008 at 03:00:56AM +0900, Stephen J. Turnbull wrote: > > Alan Mackenzie writes: > > > > The loadability of modules into the kernel has effects on the whole > > > free software community. > > > Yeah, it forces free people to make free choices. This is a good > > thing. > > A bit like the availability of guns in a community does. A bit, yes, but the prevalance of that kind of exaggeration in this community is precisely why I no longer think of myself as a "free software advocate", though I do advocate software freedom. > > > The facility you want would allow people, in effect, to make > > > proprietary extensions to Emacs. > > > That's FUD. According to the FSF legal staff, it is illegal to > > distribute non-GPLv3 modules intended for linking to Emacs. > > Are you sure? OK, yes you are. Actually, no. I misspoke. It is a violation of the GPL to distribute something, like a Makefile, that is intended to cause a non-GPLvX- compatible module to be to be linked to a GPLvX module. I strongly believe that would include a module being loaded by an Emacs-specific dynamic loader, such as one that won't load if you don't call hey_emacs_i_am_gpl_v(X). I do believe that the FSF would maintain the original position above (where "intended" is the key word and "-compatible needs to be inserted appropriately), but I am not terribly sure of that. In any case, the restatement is what I need here. > Any chance of a reference? For the restatement: FSF vs. XEmacs. We sought and received guidance from Richard on the question of whether a Qt XEmacs could be distributed. His answer was yes on X11 platforms, no on Windows platforms, and provided that we made it impossible to link Qt in the Cygwin and native NT builds. (Unless the user patched our code, of course.) It's in the XEmacs archives, but you'd have to ask me as they're currently offline due to a severe space crunch on our host. FSF vs. Aladdin (Ghostscript). It's in the ghostscript mailing list archives, from several years back. Searching for readline and ghostscript probably will bring it up. The FSF intimidated Aladdin into removing two lines from its Makefile, on the grounds that they showed the intention to link Aladdin Ghostscript to GNU readline, thus making Aladdin Ghostscript a derivative of GNU readline. Aladdin did remove the code, under protest that there was no license violation since they did not distribute GNU readline. > Are you also sure this applies to external libraries interacting > over a clean thin narrow openly specified interface, as contrasted > to Elisp libraries which burrow into the heart of Emacs? First, that's not an "extension" in the usual sense of the word; to really extend Emacs you need DEFUN. But that's wordplay. Show me the interface, and I'll tell you whether I think it applies. If you mean something like the interface of libpng, sure, you could do that and it wouldn't apply. But any platform that provides a proprietary version of libpng (for example) can already link it statically. This is not a distinction between dynamic and static linking; if one prohibition can be enforced, so can the other. Cost will differ, that's all. I don't think Emacs itself has any such "specified interfaces", and all the modules I know of either call Emacs buffer functions or use the DEFUN macro. > Hey, just because I'm mistaken (if I am) doesn't make me a fudder. No offense intended; I say if it is a mistake it is FUD, but I'm talking about the statement, not the speaker. Just because a mistake is FUD doesn't make one a fudder. But fudders can pick it up and cite it as the authority, so one should avoid it. > Sincere topologies. Offense wasn't intended, it was just an ill > considered throw away comparison. Your open sets are accepted, and in private mail David Kastrup contributed somthing like "It's all parallel anyway; that's the point of hyperbole." (Which I failed to get until he explained it.) And I would not believe without strong evidence that you ever intended offense. > > The module-loading facility has long been available for both Emacs (as > > 3rd party patches, sorry, no URL offhand; maybe from the same source as > > XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4). > > I didn't know that either. I looked in the two canonical places on my > XEmacs 21.4.17, but didn't find it. Any chance of a hint to type at C-h > f? It's probably not quite that standard; I believe you need to configure --with-modules. Look in M-x describe-installation for module capability, and if it's there, C-h f load-module. If not, you can see the few that we've got in the modules/ directory of the source.