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: Emacs contributions, C and Lisp Date: Mon, 03 Mar 2014 10:44:18 +0100 Message-ID: <877g8bmxal.fsf@fencepost.gnu.org> References: <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <83sirj9cyp.fsf@gnu.org> <20140217203145.71a849f7@forcix.jorgenschaefer.de> <837g8t8ouc.fsf@gnu.org> <20140219080524.25689b6b@forcix.jorgenschaefer.de> <83k3cr58o2.fsf@gnu.org> <530BAEE5.9040004@online.de> <87ppmatkpe.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgfsxsr.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgf37n4.fsf@fencepost.gnu.org> <87ha7gshu9.fsf@uwakimon.sk.tsukuba.ac.jp> <871tyko9l5.fsf@fencepost.gnu.org> <87eh2ks897.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvn0mk25.fsf@fencepost.gnu.org> <87bnxorlol.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393839882 5259 80.91.229.3 (3 Mar 2014 09:44:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Mar 2014 09:44:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 03 10:44:51 2014 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 1WKPQU-0002n3-Lg for ged-emacs-devel@m.gmane.org; Mon, 03 Mar 2014 10:44:46 +0100 Original-Received: from localhost ([::1]:38633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKPQT-0002Lt-OT for ged-emacs-devel@m.gmane.org; Mon, 03 Mar 2014 04:44:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKPQQ-0002Lo-Fg for emacs-devel@gnu.org; Mon, 03 Mar 2014 04:44:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKPQP-0001rC-1v for emacs-devel@gnu.org; Mon, 03 Mar 2014 04:44:42 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKPQO-0001r8-Ua for emacs-devel@gnu.org; Mon, 03 Mar 2014 04:44:40 -0500 Original-Received: from localhost ([127.0.0.1]:47418 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKPQN-0000ns-OH; Mon, 03 Mar 2014 04:44:40 -0500 Original-Received: by lola (Postfix, from userid 1000) id 1D86BE065B; Mon, 3 Mar 2014 10:44:18 +0100 (CET) In-Reply-To: <87bnxorlol.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Mon, 03 Mar 2014 12:43:54 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.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:170091 Archived-At: "Stephen J. Turnbull" writes: > David Kastrup writes: > > "Stephen J. Turnbull" writes: > > > David Kastrup writes: > > > > > It only weakens the GPL if you start creating situations where > > > > it cannot be taken seriously and/or enforced. > > > > > > I see. So the widespread use of GPL in projects that don't collect > > > assignments is another excuse to declare a piece of software an enemy > > > of the movement. > > > > > > Seriously, I disagree. > > > > Since I cannot even figure out what your strawman is supposed to > > refer to, I am not sure what you disagree with. > > The argument for the FSF assignment policy is that it makes the > license much easier to enforce. No, that it makes the license enforceable at all. Only the copyright holder can enforce the license for a piece of code. > Ie, it is the position of the FSF that failing to collect assignments > creates "situations where [the GPL] cannot be taken seriously and/or > enforced." Wrong. The GPL can _always_ be enforced by the copyright holder. Collecting the assignments makes sure that the FSF has the full ability to enforce any violation of the whole code base even when a non-trivial part of the code's history can be traceable to someone affiliated with the defendant. The problem is not that the GPL would or would not be taken seriously, but rather the ability of the FSF to act as copyright holder. Since the FSF is not directly responsible for the majority of the code it has copyrights on, acting as a warden without assignments would be difficult. > If the GPL can't be enforced, The GPL can be enforced. The problem would rather be that the choice whether to enforce it or not would not lie with the FSF. If you take a look at the enforcement situation with the Linux kernel, a large ratio of enforcement cases is done by Harald Welte over the Netfilter code. Throw out the network filtering (and isn't it currently being replaced anyway?), and you have a good chance to use the Linux kernel in proprietary settings without anybody bothering to sue. That's underwhelming. > the software can be proprietized -- and so such projects, like LLVM, > are "failing to defend software freedom". So Emacs shouldn't provide > modes to support their unique features according to RMS's logic AIUI. > But I don't see how it can weaken the GPL. It doesn't weaken the GPL. It weakens GCC, and with it, the GNU project. Part of the strength of the GNU project lies with GCC setting language and performance standards, and it's bad if the most thorough modes we make available with Emacs are not able to support the GCC dialects. The Linux ecosystem (for a lack of a better work) is tightly connected to GNU, not just because of the general GNU flavor of the user space (including glibc and the core utilities) but also because the kernel is compiled using GCC, both for feature and performance reasons. And I think that it may by now be possible to compile the Linux kernel with Clang (which got implementions of all of the extensions including assembler templates that the kernel used). So in this case GCC and the GNU project were in the situation of creating a de facto standard. Once Emacs supports what Clang provides rather than what GCC provides, not even Emacs will support any new features of GCC. There is a rather tenuous hold based on licenses, technical dependencies, public perception (including "coolness") and so on over where semi-open systems like "Android" go, choose to go, and are able to go. GCC plays a central role in where people place their focus, their loyalties, and their goals. It's one of the actually active ties to the GNU project that the Linux kernel has. So we want to have GCC stay technically competitive in order to retain a non-licensing based connection into those kind of projects and, not least of all, the Linux kernel. On the other hand, staying technically competitive is not self-serving but it serves to have a wider audience for our non-technical goals. Giving up the latter in order to have a stronger stand for the former is sort of pointless. Sort of what one calls a "dying throw" or "parting shot". When put to the choice, we'd rather give up on Android than GNU. And us having to take that choice at some point of time is what Clang/LLVM are working towards. Once Clang/LLVM become the compiler for Android, it is a matter of time and hipness before it becomes the default compiler for the Linux kernel. Once the kernel is bootstrapped using Clang/LLVM, it is a matter of time before the userland of big distributions is compiled using Clang/LLVM as well, with GCC becoming optional. At some point of time, it will become harder to compile the Linux kernel with GCC out of the box, and bootstrapping a full GNU system will mean that we need to revert to the HURD, mostly relying on using Linux drivers. At least until someone sues us for combining GPLv2 drivers with a GPLv3+ kernel. All of this has nothing to do with "the GPL being weakened". It's the weakening of GCC as a vital part of the GNU-derived software universe that's the issue. And if you are saying "that's too pessimistic. All of this _could_ happen, but that's by no means sure.": the whole point of being behind GCC is to do what is in our power to push against this happening. Our power may be small compared to those of the universe, but that has not kept us from making a difference by applying it aimedly and timely enough. "We can still patch up our roof if and when a storm comes" does not work. And "oh, it's on the horizon, but maybe it'll pass. Let's see if it does, then we don't need to patch the roof." is, well... -- David Kastrup