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: Contributing LLVM.org patches to gud.el Date: Tue, 10 Feb 2015 17:11:57 +0100 Message-ID: <878ug5sq42.fsf@fencepost.gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <874mqvf4dj.fsf@panthera.terpri.org> <87sieeru2k.fsf@fencepost.gnu.org> <87oap2rq9o.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1423584738 5039 80.91.229.3 (10 Feb 2015 16:12:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2015 16:12:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Yann Hodique Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 10 17:12: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 1YLDQ8-0000GN-A3 for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 17:12:16 +0100 Original-Received: from localhost ([::1]:40476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDQ7-0006Ko-D0 for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 11:12:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDPu-0006Ki-7R for emacs-devel@gnu.org; Tue, 10 Feb 2015 11:12:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLDPq-0008PK-6k for emacs-devel@gnu.org; Tue, 10 Feb 2015 11:12:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDPp-0008Od-Ub for emacs-devel@gnu.org; Tue, 10 Feb 2015 11:11:58 -0500 Original-Received: from localhost ([127.0.0.1]:38352 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDPp-0000QZ-Gu; Tue, 10 Feb 2015 11:11:57 -0500 Original-Received: by lola (Postfix, from userid 1000) id 2276BE0514; Tue, 10 Feb 2015 17:11:57 +0100 (CET) In-Reply-To: (Yann Hodique's message of "Tue, 10 Feb 2015 07:42:50 -0800") 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:182817 Archived-At: Yann Hodique writes: >>>>>> "Helmut" =3D=3D Helmut Eller writes: > >>> Tell them to dissolve their own community and >>> commit ritual suicide? > >> Changing the license would hardly be suicide. Apple could still be the >> main contributor and they managed to survive even when they had to use >> GCC. It would piss off NVIDIA but it might attract some other >> individuals who don't like the idea that NVIDIA profits from their >> contributions. Either way, you don't make those decisions. > > I find that claim (that a license change would annoy the NVIDIAs of the > world) very odd. > > After all, the core of the entire issue, and this whole discussion, is > that the FSF did object to *technical possibilities* in order to counter > those same people, effectively deeming the GPL alone insufficient to > reach that goal. So now we cannot possibly be suggesting that slapping > a GPL sticker on LLVM could solve the "issue", can we? > > I mean, one (at least...) of the following has to be true: > - the modularity of LLVM (GPL or not) allows access to the internals of > a compilation phase in a textual form, making it easy for people to > pipe a non-free component where they fancy > - the GPL is enough to push non-free components away (or is the best we > can do anyway), and we've been wasting time and opportunities > protecting something that doesn't exist There can perfectly well be a truth in the middle. Closing GCC down regarding modularity may have provided _extra_ leverage over the coercive nature of the GPL, leverage that is _now_ eroded through LLVM's existence and licensing. So the exact details were a _temporary_ strategy (also known as tactics) catered to the current situation. We don't have the same leverage any more but that does not mean that there is none left over those who are still to some degree invested in using=A0GCC. If tactics are supposed to provide a net advantage, one needs to monitor the situation closely and adapt the tactics accordingly and swiftly. It turns out that our managerial structures are not really set up to facilitate swift and flexible response, so it's not clear to me that playing with tactics where the success depends on timely reaction to third parties is a good match for GNU. > Bottom line, we cannot say that a GPL compiler (GCC) made modular > would have been a problem, but that a modular compiler (LLVM) made GPL > would be a solution. In the end, they'd be both modular and GPL, > right? The state "in the end" does not mean that we should not try deriving best benefits from the situation where they are still non-equivalent. -1 -2 lim x =3D 0 and lim x =3D 0 x->oo x->oo But still inf / | -1 -2 | (x - x ) dx =3D> inf |=20 /=20=20 1=20=20 So there is nothing wrong to make the best of the difference while it is there. As long as one keeps an eye on it. --=20 David Kastrup