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: Emacs Lisp's future Date: Fri, 19 Sep 2014 19:46:56 +0900 Message-ID: <87y4tfzy3j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <877g11c8wh.fsf@gmx.us> <87wq91uhe8.fsf@newcastle.ac.uk> <8738bpc6qv.fsf@gmx.us> <87oaucvrlp.fsf@newcastle.ac.uk> <87lhpg8ooc.fsf@gmx.us> <87fvfoxcoe.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1411123672 10543 80.91.229.3 (19 Sep 2014 10:47:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 10:47:52 +0000 (UTC) Cc: magnars@gmail.com, rms@gnu.org, Rasmus , emacs-devel@gnu.org To: Nic Ferrier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 19 12:47:45 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUvj6-000224-Kx for ged-emacs-devel@m.gmane.org; Fri, 19 Sep 2014 12:47:44 +0200 Original-Received: from localhost ([::1]:57405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUvj6-0004WM-9t for ged-emacs-devel@m.gmane.org; Fri, 19 Sep 2014 06:47:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUvim-0004V8-Jl for emacs-devel@gnu.org; Fri, 19 Sep 2014 06:47:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUvif-0007JA-38 for emacs-devel@gnu.org; Fri, 19 Sep 2014 06:47:24 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:36916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUvie-0007FF-PO for emacs-devel@gnu.org; Fri, 19 Sep 2014 06:47:17 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7DD561C3AF5; Fri, 19 Sep 2014 19:46:56 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6B9601A28C8; Fri, 19 Sep 2014 19:46:56 +0900 (JST) In-Reply-To: <87fvfoxcoe.fsf@ferrier.me.uk> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174542 Archived-At: Nic Ferrier writes: > I am torn between a much more open and distributed Emacs (which I > suspect rms won't like) What's not open or distributed about Emacs? Maintaining legal paperwork is a cost and an inconvenience, but the GPL itself legally guarantees openness and in practice Emacs development is highly distributed. ELPA is only going to provide more cases where people want to "sign papers", or to gather "papers" from their coauthors. I can't see this as a problem -- Emacs will acquire more copyrights than it would have otherwise. I suppose it's theoretically possible that the body of unassigned and perhaps unassignable Emacs Lisp will grow faster than the body of assigned Emacs Lisp, but I doubt it. Even if it does, most people do obey the rules, and the body of free software will increase. > and having Emacs stay guaranteed free There are no guarantees. It is certainly possible that an SCO-like attack could be made on Emacs, especially via submarine patent. The FSF legal policy merely makes it less likely to succeed, and provides the FSF the option of shifting costs onto contributors if it fails to defend the copyrights they claimed to assign. > But that's what we did when we introduced packages. How else did > people think it would end? Huh? Packages simply are a way of making long-standing practices (development and distribution by satellite projects) more convenient for end users, permitting multiple development cycles for "core" modules if desired by the core developers, and to some extent blurring the line between core-developer and end-user convenience. As long as GNU ELPA exists, there is no reason to believe that Emacs is at any more legal risk than ever. The only legal "danger" to Emacs created by third-party packages is that, because of the greater convenience, people who otherwise would not have used them at all may be exposed to "buccaneer" packages from folks who play fast and loose with the GPL. As long as everybody is aware that GNU ELPA protects them from that, it's their choice. You may not like knowing some will make the "wrong" choice, and I know RMS doesn't like it, but what do you propose as the alternative that is safer? The package system itself doesn't favor or enable GPL violations and other unfree practices, except possibly as a side effect of more free software being available to violate (unlike "permissive" licensing, which does enable unfree distribution and intentionally does so). The practical problem created by packages is (to some eyes) a blessing in disguise. By enabling convenient separate development and distribution of many more Lisp packages than would otherwise exist, separate from Emacs core, it "exports" many APIs that would otherwise be considered internal. Developers wishing to change these "exported" APIs will encounter a lot more resistance, especially from package maintainers whose development cycles differ from the core's. But many projects have found such discipline to be useful in encouraging development of a community of library modules and applications. Consider-the-source-ly y'rs, Steve