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: Mon, 19 Jan 2015 16:45:46 -0600 Message-ID: <54BD891A.1070904@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> <54BB2B40.4040508@gmail.com> <87r3usbe7w.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 1421707574 18928 80.91.229.3 (19 Jan 2015 22:46:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2015 22:46:14 +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 Mon Jan 19 23:46:10 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 1YDL5F-00071D-UP for ged-emacs-devel@m.gmane.org; Mon, 19 Jan 2015 23:46:10 +0100 Original-Received: from localhost ([::1]:40134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDL5F-00059Z-9B for ged-emacs-devel@m.gmane.org; Mon, 19 Jan 2015 17:46:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDL52-00059H-1o for emacs-devel@gnu.org; Mon, 19 Jan 2015 17:45:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDL50-0000dm-TX for emacs-devel@gnu.org; Mon, 19 Jan 2015 17:45:55 -0500 Original-Received: from mail-ob0-x230.google.com ([2607:f8b0:4003:c01::230]:60587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDL4v-0000WN-46; Mon, 19 Jan 2015 17:45:49 -0500 Original-Received: by mail-ob0-f176.google.com with SMTP id va2so7205913obc.7; Mon, 19 Jan 2015 14:45:48 -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=/7wo7BU8FPeI5wDKelrtvkDO9PtheBsNRt8uWBgBShk=; b=dtTxHYk75H273iQn1BOeEMbRiSU7cP7/TmzYeOFQq7gcpsF7foMZ7tzMDmsiLFxRMZ s31ZeRhgT1KWI6SYUQc3HexZB9j3Hb7BaeEoSUdZiqmieD6c9UZ5OY2A9ZOd/fe+QfqE ht40Zd4YKP4eoxqQoem4bypqkQ3fVKjeH/mM/Alcpq5wtn8XaEhf4hG+5v1oQHSknAFG llQrfYTf8PE7Dz6xQSKxojy6FH9PYjBfFld5SnHCMdGdXecaFmWSZI1uqfIVsEkY243B dUW+es29jmkRxv8oZtVtMBgQS41Zh7i02/w/LKo0TXAlSLr0wYwER21ObHUvbCaYDMuR tuAQ== X-Received: by 10.60.78.137 with SMTP id b9mr19835318oex.36.1421707548511; Mon, 19 Jan 2015 14:45:48 -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 dd17sm6553611obb.18.2015.01.19.14.45.47 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Jan 2015 14:45:48 -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: <87r3usbe7w.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::230 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:181452 Archived-At: David Kastrup wrote: > Jacob Bachmeyer writes: > >> David Kastrup wrote: >> >>> Jacob Bachmeyer writes >>> >>>> 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. >>>> >>> 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. >> > > So what? You do that with a minimal program you license under the GPL > and then dump the AST in a generically useful form. Then you get a > sanely usable dump of generally useful information you and other > proprietary programs can use conveniently while any program from the GNU > project has to go through a binary mess by decree. > This comes back to writing Emacs Lisp code to dump the AST. I argue that no reputable proprietary vendor would choose jumping through those particular flaming hoops over writing their own frontend, especially when jumping through flaming hoops to abuse GCC would make their own license terms reek of hypocrisy, which could look bad in court if they ever needed to sue. Less-than-reputable vendors (likely in foreign countries where enforcing copyright is difficult) would simply violate the GPL outright (probably by copy-paste-edit from GCC) and ignore demands for compliance, just like they violate proprietary licenses. This is probably happening now and we just don't know about it yet due to language barriers. >> 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. >> > > So any version of Emacs will work only with a particular version of GCC? > Remind me: whose life were we trying to make harder? > No. GCC would provide the link plugin, and it would be updated with GCC. That is why this proposal requires that Emacs be able to dynamically load C plugins.