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: Contributing LLVM.org patches to gud.el Date: Thu, 12 Feb 2015 23:45:21 +0900 Message-ID: <87wq3nmbni.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <20150208001527.GA30292@thyrsus.com> <20150209150411.1f0f4e4f@jabberwock.cb.piermont.com> <20150211111722.181a2201@jabberwock.cb.piermont.com> <20150211183700.04ec0613@jabberwock.cb.piermont.com> <87bnkzpe6b.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1423752372 15262 80.91.229.3 (12 Feb 2015 14:46:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2015 14:46:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 12 15:46:01 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 1YLv1i-0007sF-AA for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 15:45:58 +0100 Original-Received: from localhost ([::1]:50543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLv1h-00080D-HT for ged-emacs-devel@m.gmane.org; Thu, 12 Feb 2015 09:45:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLv1P-000802-M0 for emacs-devel@gnu.org; Thu, 12 Feb 2015 09:45:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLv1K-00081n-Lt for emacs-devel@gnu.org; Thu, 12 Feb 2015 09:45:39 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:33492) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLv1A-0007zF-8r; Thu, 12 Feb 2015 09:45:24 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id B8EE81C3896; Thu, 12 Feb 2015 23:45:21 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9E3D31A26E3; Thu, 12 Feb 2015 23:45:21 +0900 (JST) In-Reply-To: <87bnkzpe6b.fsf@fencepost.gnu.org> 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:182952 Archived-At: David Kastrup writes: > There is a principal basic problem that we cannot overcome with any > trickiness: Emacs and GCC are two separate, independent > applications. _Any_ way in which we are able to combine them will > have a point where Emacs as an application ends and/or a point > where GCC ends. No trickiness needed, because copyright doesn't work that way, at least not in the U.S. Emacs and GCC remain separate, true. However, linking them in a single process implies a process of (1) making copies of each and then (2) editing the combination to make communication possible via function calls (and possibly access to global data). This copying and editing legally creates a *new* work which *as a whole* may be *presumed to be a derivative of GCC (and Emacs as well), according to the generally accepted "exec boundary" doctrine. The internal data structure representing the AST is still covered by GCC's copyright, and by GCC's license which applies to *the whole* because of the copying and link-editing. The same will be true of IDE-X and GCC. As usual, an individual user can write code to access the necessary GCC modules, compile and link, and run the program in the privacy of their own home, but distributing that program must be done under the GPL. This application of the GPL is as solid as any. It will successfully prevent GCC code from being abused in a proprietary combination.