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: Sat, 17 Jan 2015 21:40:48 -0600 Message-ID: <54BB2B40.4040508@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> <54B9BA40.2070104@gmail.com> <87d26ddi4z.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 1421552476 2786 80.91.229.3 (18 Jan 2015 03:41:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Jan 2015 03:41:16 +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 Sun Jan 18 04:41:16 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 1YCgjh-00032R-TF for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 04:41:14 +0100 Original-Received: from localhost ([::1]:60818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCgjg-0003vz-Ni for ged-emacs-devel@m.gmane.org; Sat, 17 Jan 2015 22:41:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCgjc-0003vu-5X for emacs-devel@gnu.org; Sat, 17 Jan 2015 22:41:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCgja-0007O4-Gk for emacs-devel@gnu.org; Sat, 17 Jan 2015 22:41:08 -0500 Original-Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]:45590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCgjS-0007LH-KY; Sat, 17 Jan 2015 22:40:58 -0500 Original-Received: by mail-oi0-f46.google.com with SMTP id z81so1151578oif.5; Sat, 17 Jan 2015 19:40:57 -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=PF+z/ev1BjSWztAmhNs9svliobzeZO3+JqDkPgZcRmY=; b=gDo+45A4RpngN76LKqnL0ajeBY2gaGNddYsaKBLoVebWKgiqy43BeNsE0y+ZLLwJ4L ndPfoiX48a+SaakN+DwM2ffMB3Lv2wLHOf+dmoM7jHhciqxrMI41trs5CampP8CWy5hb KfnCuWvnWFD6b1iPc1lTwPlvHCXa19y+kDtETX2TLGPZtPZomholS0vqo32NBexUp0ZA piZxodrFJrvFf9IA0x0QKZ/UANogK4OKugnIFjP1jTWvPG8xB/gNRMQqiX1cOaE6WpeX MAuDhtMKxdLhsRRr8uyAIo748sxrQ4atkd9pV7eBWK42B+nebHI1VyTxaGlTqkOG7ZK5 DB8w== X-Received: by 10.60.119.33 with SMTP id kr1mr14199242oeb.45.1421552457787; Sat, 17 Jan 2015 19:40:57 -0800 (PST) Original-Received: from [192.168.2.42] ([70.133.148.241]) by mx.google.com with ESMTPSA id l200sm4601254oig.26.2015.01.17.19.40.55 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 17 Jan 2015 19:40:56 -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: <87d26ddi4z.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:c06::22e 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:181394 Archived-At: David Kastrup wrote: > Jacob Bachmeyer writes >> 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. >> >> > So gdb has to be licensed identically with any program you debug using > it because it is accessing the respective program's memory? No, because GDB is not, itself, communicating with the target using complex data structures. A program that uses GDB to inspect some GPL target and interprets complex data structures from that target might bring the GPL into the picture, but GDB itself is merely a conduit in this picture. The OS kernel that implements ptrace does not have to be licensed identically to the program being debugged, either. > At any rate, does not sound like an interface one could keep steady > across different GCC versions. To make that the case, you need > something describing the internals' meaning, akin to how debug > information describes memory layout. Once you have that kind of "my raw > memory means $x" description, this constitutes an interface. Possibly > an awkward interface, but that's not legally significant. That's the point--the interface between the underlying processes is not stable across GCC versions and the "description" of the internals' meaning comes in the form of a C DSO that Emacs can load to get Emacs Lisp bindings to GCC's own API for accessing these structures. The "description" is a program component that must be combined with any program that uses it. Reverse engineering one version of the interface would allow non-free software to use that version of GCC, yes, but doing that repeatedly as GCC changes, without it ever becoming a derived work, would quickly become more expensive than simply writing a new parser. Especially since the two halves of the link plugin are only required to talk to each other, and are built together, so they can change easily. The link protocol could even be made polymorphic in some way, so that every pair of binaries built would have a subtly different link protocol. >>> 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. >> >> > It sounds to me like we are looking for a snakeoil bottle label text > that will placate Richard and/or ourselves for some while so that we > might carry on a bit. But I don't think we can terminally avoid dealing > with the fact that we cannot achieve interoperation between separate > free software applications without enabling interoperation with separate > nonfree software that does not trigger copyright. > > And our limited and distributed resources and skills as free software > developers mean that our success depends on interoperation within free > software. We can't afford this process every time we want something to > work together. > We are at a point where continued inaction will eventually make GNU irrelevant, the right action will put GNU far ahead of all the others for the foreseeable future, and the wrong action will... well, extending the metaphor about the defensive wall around our city that RMS has used, the wrong action could destroy our defensive wall entirely. It is very important that we find and carry out the right action.