From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jacob Bachmeyer Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Fri, 16 Jan 2015 19:26:24 -0600 Message-ID: <54B9BA40.2070104@gmail.com> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> <54B456C8.6010506@gmail.com> <8761cbhvhb.fsf@fencepost.gnu.org> <54B5AA10.7080606@gmail.com> <54B6F8EF.7020401@gmail.com> <54B8326B.90804@gmail.com> <54B889CC.9030401@gmail.com> <878uh3dquk.fsf@fencepost.gnu.org> Reply-To: jcb62281@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421458001 15509 80.91.229.3 (17 Jan 2015 01:26:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2015 01:26:41 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 17 02:26:41 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 1YCI9t-0002Mc-Lz for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 02:26:37 +0100 Original-Received: from localhost ([::1]:58007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCI9t-0006hJ-4u for ged-emacs-devel@m.gmane.org; Fri, 16 Jan 2015 20:26:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCI9p-0006hD-6J for emacs-devel@gnu.org; Fri, 16 Jan 2015 20:26:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCI9n-0007gb-UQ for emacs-devel@gnu.org; Fri, 16 Jan 2015 20:26:33 -0500 Original-Received: from mail-ob0-x233.google.com ([2607:f8b0:4003:c01::233]:39236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCI9i-0007f8-N1; Fri, 16 Jan 2015 20:26:26 -0500 Original-Received: by mail-ob0-f179.google.com with SMTP id nt9so21863770obb.10; Fri, 16 Jan 2015 17:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=o3eFM9kf3bv53yq4U+oKCpX4WNwITZw/tMclTdVTEK4=; b=yFMpz8VogXBZAQw8W40+4PMIX8bJ7TzazAGqcJUgNInajSXHapA/mBqY4RlGWUtl3L GYzo46MBA/hDx1bmDjSmeJwkT2aY1vziEXzzfuvf9wq/7Dg9uhTmoStzjE8fvrGMSgjp fsi8bo4xT/GXq7yfW7i4ikG5viVMaXSogs74v4ZPGKAbOy2TPhb9YgsGTpRhq4OS3Uol YHO3rBFadUbGilSUbjKlBhMU/rey0NrOMAhfAZss78DZ4SYwZ93LfO/SZgmYY18aD5xX MW1edTaHIF2gutoZ5fXia9KfLpok6nqDkgbquOCaF9mmxxOkG23Y6BhNA9RBfdfsRnLi 2X7Q== X-Received: by 10.60.229.163 with SMTP id sr3mr11296644oec.29.1421457985887; Fri, 16 Jan 2015 17:26:25 -0800 (PST) Original-Received: from [192.168.2.42] (adsl-70-133-148-241.dsl.ablntx.sbcglobal.net. [70.133.148.241]) by mx.google.com with ESMTPSA id w81sm3091159oiw.10.2015.01.16.17.26.24 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Jan 2015 17:26:25 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 In-Reply-To: <878uh3dquk.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::233 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:181362 Archived-At: David Kastrup wrote: > Jacob Bachmeyer writes: > >> Richard Stallman wrote: >> >>> [[[ To any NSA and FBI agents reading my email: please consider ]]] >>> [[[ whether defending the US Constitution against all enemies, ]]] >>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]] >>> >>> The situation with Emacs will be the same as it is with GCC now: >>> plug-ins have to be GPL. >>> >>> >> This illuminates the central question at hand: if an Emacs plugin is >> GPL, and provides access to internals of GCC, which is also GPL, can >> nonfree software use that Emacs plugin? >> > > That's not the central question at hand. The central question is: if an > Emacs plugin can provide access to internals of GCC, what keeps nonfree > software from using the same mechanism as the Emacs plugin to get access > to internals of GCC? What stops nonfree software from doing that is that the mechanism used to get access to internals of GCC is very low-level (using ptrace(2) to directly access GCC's memory would not be out of the question) and transfers GCC internal structures over the link, which are interpreted within the Emacs process. According to the GPL FAQ: "Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."() I expect that GCC's internal trees qualify as "complex data structures". There is certainly not a nice, readable, text AST dump involved at any point. > If you combine Emacs and GCC, there will be one point where Emacs ends > and GCC begins. And that is the point where you can swap out either for > a nonfree application without getting copyright involved, since GCC and > Emacs are clearly independent applications. The point where Emacs ends and GCC begins in my interim proposal is the function calls into the Emacs plugin I propose that GCC would provide. Emacs would be, in effect, dynamically loading GCC as a library. That that library is implemented using RPC to another process is an implementation detail. > The price for interoperation is interoperation. And since it is rather > more than less important for free as opposed to proprietary software > that independent teams can create cooperating applications, I don't see > that it makes sense for us not to pay that price. And the latest point > to which we can delay this is when a concrete application is imminent. > > We can't guarantee that such an application will be successful if we > allow it. But it will definitely fail if we don't. You are right, which is why I am seeking a workable solution that all can be happy with.