From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Compiled files without sources???? Date: Sun, 31 Jul 2011 23:29:21 +1000 Message-ID: References: <87wrk54pzp.fsf@ginnungagap.bsc.es> <87tyf7aw9b.fsf@engster.org> <871uxgyu0u.fsf@fencepost.gnu.org> <87vcus3slm.fsf@engster.org> <87k4b4jv8p.fsf@stupidchicken.com> <877h7444uj.fsf@fencepost.gnu.org> <87tya82mv5.fsf@fencepost.gnu.org> <87ei1bzjwg.fsf@fencepost.gnu.org> <4E3133CE.7010101@cs.ucla.edu> <4E31F0B3.3030505@cs.ucla.edu> <87mxfw90oo.fsf@stupidchicken.com> <87r558ms8j.fsf@stupidchicken.com> <87zkjv33w3.fsf@stupidchicken.com> <87sjpn8if0.fsf@ambire.localdomain> <87sjpm7lvt.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1312118976 18798 80.91.229.12 (31 Jul 2011 13:29:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 13:29:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 15:29:32 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QnW5B-00009H-3B for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 15:29:29 +0200 Original-Received: from localhost ([::1]:50364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnW5A-0007vd-Jj for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 09:29:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnW57-0007vM-LN for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:29:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnW56-0000Sr-DO for emacs-devel@gnu.org; Sun, 31 Jul 2011 09:29:25 -0400 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:60867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnW54-0000SR-P5; Sun, 31 Jul 2011 09:29:22 -0400 Original-Received: by vwm42 with SMTP id 42so1975030vwm.0 for ; Sun, 31 Jul 2011 06:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PnnJFDR0Z2UkYwdIppLB+9FGn3caqTryuJrIhTO6y8Y=; b=WbQNfjRETzCre8HZD1v4potX7it/lLPZZKTILECHLBByRfLxBgcG+O171/bG19XD/F DLDZyvzWdgWSSbAOnX2xP7ITuNTgLhuLDvRQ9rMerNiroLyyfXjZxiJ1KLRZpEHbC8Vm GJ530eng+Uc4qldNkREOWPm9eMLOJslLuvE20= Original-Received: by 10.220.140.203 with SMTP id j11mr945297vcu.41.1312118961749; Sun, 31 Jul 2011 06:29:21 -0700 (PDT) Original-Received: by 10.220.142.82 with HTTP; Sun, 31 Jul 2011 06:29:21 -0700 (PDT) In-Reply-To: <87sjpm7lvt.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.41 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:142563 Archived-At: On Sun, Jul 31, 2011 at 9:03 PM, David Kastrup wrote: > Tim Cross writes: > >> On Sun, Jul 31, 2011 at 9:20 AM, Thien-Thi Nguyen wrot= e: >> >>> The problem is that the differences aren't accountable, not that >>> there are differences. =A0To be accountable, the path from original to >>> current must be transparent. =A0If that path involves manual editing, a >>> commit (+ ChangeLog) should be generated. =A0If that path is machine >>> manifested, the program that does the change must be distributed (+ >>> commit + ChangeLog, of course). =A0In the case of distribution, GPL >>> comes into play (recursively). >> >> FYI, for anyone who perhaps may not recognize how important this is, >> this issue has been reported in the latest issue of LWN. > > Both article and comments are quite off-color. =A0For one thing, they > assume that the parser generator has been Bison and the respective code > C. =A0That does not really make all that much of a difference with regard > to the implications except that it might have been easier to hand-edit > the files. > > Then they assume that the FSF is in violation of the GPL. =A0Since Emacs > is (c) FSF, the FSF can't be in violation of its own license. =A0The > issues are different, but still need fixing. > > Anyway, I find it bad taste to drag an internal discussion from the list > into the limelight like that. =A0Even if the original reporter would have > gotten his facts right, the conclusions of the average reader would have > likely been off-color. =A0The mud-slinging is detrimental to making a > solid and timely fix. > > The article in LWN is at . =A0The > front page at has the lead-in > > =A0 =A0Emacs distributions are not GPL-compliant > =A0 =A0[Development] Posted Jul 29, 2011 12:10 UTC (Fri) by corbet > > =A0 =A0It turns out that the Emacs 23.2 and 23.3 releases contain a numbe= r > =A0 =A0of parsers created with Bison, but the source for those parsers wa= s > =A0 =A0not included. That has led Richard Stallman to say: "We have made = a > =A0 =A0very bad mistake. Anyone redistributing those versions is violatin= g > =A0 =A0the GPL, through no fault of his own. We need to fix those release= s > =A0 =A0retroactively (or else delete them), and we need to do it right > =A0 =A0away." This state of affairs is clearly just a slip which will be > =A0 =A0fixed quickly, but it shows that anybody can make mistakes. > > I can't seem to find a good permanent link for the article that would > include this lead-in. > > Anyway, even though the publication seems to me to be in bad taste and > ill-advised, I would not want to have mailing list or archives limited > to a closed circle. =A0It's a risk we have to live with. > Personally, I was surprised when I read the lead-in. I also thought it was an 'internal' matter being dealt with, but thought it worth pointing out, regardless of its accuracy. I also suspect it is really only getting such attention because of emacs being a well known FSF package and Richard's direct involvement. I guess it is a positive that the issue was one identified within the emacs dev community and one being dealt with appropriately and quickly once identified. It does highlights the need for care. In some ways emacs' and other key FSF projects need to set the standards, which I think was one of Richard's main points. Tim