From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Tue, 15 Sep 2015 10:45:49 +0200 Message-ID: <87k2rsul36.fsf@fencepost.gnu.org> References: <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> <55F6E43E.9030502@dancol.org> <8737ygz8z3.fsf@uwakimon.sk.tsukuba.ac.jp> <55F789D5.3080005@dancol.org> <87zj0oxflr.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442308184 3325 80.91.229.3 (15 Sep 2015 09:09:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 09:09:44 +0000 (UTC) Cc: Paul Eggert , Tom Tromey , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?iso-8859-1?Q?Aur=E9lien?= Aptel , Daniel Colascione , Stephen Leake To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 15 11:09:43 2015 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 1ZbmFB-0000bU-Pn for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 11:09:41 +0200 Original-Received: from localhost ([::1]:46131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbmFB-0003kT-B1 for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 05:09:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbmF7-0003kF-Lc for emacs-devel@gnu.org; Tue, 15 Sep 2015 05:09:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbmF6-0007NE-J7 for emacs-devel@gnu.org; Tue, 15 Sep 2015 05:09:37 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbmEr-0007GG-6K; Tue, 15 Sep 2015 05:09:21 -0400 Original-Received: from localhost ([127.0.0.1]:59846 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZbmEp-0008Gt-TZ; Tue, 15 Sep 2015 05:09:20 -0400 Original-Received: by lola (Postfix, from userid 1000) id EB463DF43D; Tue, 15 Sep 2015 10:45:49 +0200 (CEST) In-Reply-To: <87zj0oxflr.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 15 Sep 2015 17:16:00 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:189969 Archived-At: "Stephen J. Turnbull" writes: > Daniel Colascione writes: > > On 09/14/2015 07:56 PM, Stephen J. Turnbull wrote: > > > The rest of the discussion aside: Python's current license is > > GPLv3-compatible, isn't it? gnu.org and Python's documentation both > > claim it is. > > AFAIK IANAL TINLA. That's not the issue I have in mind. > > Pragmatically speaking, even if it's not possible to legally prohibit > you from distributing such a module, I think Richard would veto > incorporation of such a module in Emacs, because it would make it > possible to silently link Emacs to proprietary code via a Python > plugin. Well, regarding the "proprietary plugin" issue it would seem most expedient to have the plugins run in the Emacs GC and exception model and, where third-party independently developed libraries are to be integrated, to have to compile/byte-compile/assemble some library-specific wrapper encapsulating/mapping the exceptions/callbacks to the Emacs model. I have no idea regarding the technical feasibility of various different approaches. But regarding the "circumvent GPLv3" angle, having a default model of completely separate exception/memory handling and FFI that allows a drop-in direct binary use of libraries not specifically developed for use with Emacs, while certainly offering the maximum of convenience in one regard, forms a reasonably clearly defined license barrier for "application as a whole" forming a clear stop for the reach of the GPLv3. So having our binary interfaces and calling conventions and memory/exception handling default to "like Emacs does" is not just Lisp-friendly but is also keeping our license enforcement options more conservative. While my personal opinion is that licensing considerations should not justify complications amounting to uselessness, I see nothing wrong with letting them serve as tie-breaker. -- David Kastrup