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: Mon, 09 Feb 2015 12:21:13 +0100 Message-ID: <87d25juy8m.fsf@fencepost.gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423480889 1972 80.91.229.3 (9 Feb 2015 11:21:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Feb 2015 11:21:29 +0000 (UTC) Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 09 12:21:29 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 1YKmPA-0008IS-Jz for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 12:21:28 +0100 Original-Received: from localhost ([::1]:60302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKmPA-0002jQ-0R for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 06:21:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKmP4-0002dF-JC for emacs-devel@gnu.org; Mon, 09 Feb 2015 06:21:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKmP3-0001xs-2N for emacs-devel@gnu.org; Mon, 09 Feb 2015 06:21:22 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKmP2-0001xo-VY for emacs-devel@gnu.org; Mon, 09 Feb 2015 06:21:21 -0500 Original-Received: from localhost ([127.0.0.1]:57856 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKmOw-0007hE-8Z; Mon, 09 Feb 2015 06:21:14 -0500 Original-Received: by lola (Postfix, from userid 1000) id D3E1BDF676; Mon, 9 Feb 2015 12:21:13 +0100 (CET) In-Reply-To: (Richard Stallman's message of "Sun, 08 Feb 2015 19:06:40 -0500") 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:182674 Archived-At: Richard Stallman writes: > [[[ 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. ]]] > > > If we try to close down every cooperation with non-GNU free software, we > > are sacrificing our goals for the sake of our temples. > > I agree. But is anyone proposing that? GCC's approach to plugins took years to do exactly in order not to interface with software not under the GPL. A generic dynamic library loading facility to Emacs has been in discussion and vetoed for decades. Somewhat amusingly, the only working run-time dynamic library loading that I know of in Emacs is the loading of image libraries (free ones, of course) under Windows. At the current point of time we are seeing about a year of roadblocks on trying to get Emacs and GCC to communicate about various issues. While the more recent batch of blocking LLVM cooperation (which is non-GNU free software) has started with blocking LLVM on the grounds that GCC should go first, the subsequent attempts to integrate GCC first have been blocked on grounds that this would open too many paths to interoperating with LLVM or proprietary compilers. So yes: you _are_ very much sacrificing the interoperation of GNU software on the grounds that it would also enable the interoperation with software that is either unfree or "too free". Whether or not this is "proposed", it is being done. As long as our only weapon is copyright, we cannot block interoperation except by blocking all interfacing. If we want to block interoperation selectively, the only meaningful way to do that is to start hacking patent law in a similar manner to how the GPL hacked copyright law: collecting patents and providing public licenses. Patents reach beyond interoperation. Which is part of what makes software patents a bad idea in the first place. At any rate: crippling GNU until we reduce open-ended interoperation to the degree where it becomes infeasible without touching copyright-propagating parts is a strategy for obsolescence. As long as our sole weapon is copyright, we need to focus on using it in a manner where it hurts us less than our opponents. Part of doing that is to have feasible strategies, and easy and effective rules that can be applied by project managers with confidence. The GNU project is far too large, and interoperation far too important that it is even feasible to route all the decision-making through the "Richard oracle" with unknown outcome. Top-level decisions are a scarce resource, so the project cannot afford this process frequently. Partly one gets the impression that you think if you wait long enough, the problem will go away. But what rather tends to go away is the window of opportunity. We did our part in making the creation of LLVM attractive to a diverse set of people because we decided that catering to their causes would have been disruptive to our own goals. The rise of LLVM or other compiler technologies was an _expected_ consequence of our actions: compiler technology is not an inaccessible art, so it was clear that alternatives to GCC would get developed and maintained eventually. What happens now is burning down the barn after the mule has bolted. And it's not like we didn't open the door, beat it and yell for it to go away. More by accident than anything else I have been in some "IT planning for startups" talk on a conference. The speaker did a lot to explain how import contingency plans were when things went wrong. But what he also said: "the worst mistake a manager can commit is to be unprepared catering for the eventuality of success". If you are not prepared for dealing with success, where is the point in even starting? So we worked on making GCC a bad choice for proprietary vendors. What do they do? They manage to unite an industry-spanning coalition of different parties including academia into creating a free software compiler framework. Free to the degree that we could just take it, slap the GPL on it and distribute our own version of it (assuming we were prepared to dealing with pissing everybody off in the process). So what's our reaction to our and GCC's role in causing a large-scale industry cooperation creating a free compiler framework? Panic. We are not prepared to deal with people doing on their own terms what we have fought to happen for decades. So now we try to fight those in our midst who want to make use of what we have fought for. And since LLVM is relicensable as GPL if anybody bothered to, the only effective means to "fight" LLVM is by necessity effective in fighting GPLed software in just the same manner. It seems sort of pointless to be fighting our spoils because they were given to us in the wrong kind of ceremony. -- David Kastrup