The problem is that the differences aren't accountable, not that
there are differences. To be accountable, the path from original to
current must be transparent. If that path involves manual editing, a
commit (+ ChangeLog) should be generated. If that path is machine
manifested, the program that does the change must be distributed (+
commit + ChangeLog, of course). In 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. For one thing, they
assume that the parser generator has been Bison and the respective code
C. That 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. Since Emacs
is (c) FSF, the FSF can't be in violation of its own license. The
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. Even if the original reporter would have
gotten his facts right, the conclusions of the average reader would have
likely been off-color. The mud-slinging is detrimental to making a
solid and timely fix.
The article in LWN is at<URL:http://lwn.net/Articles/453374/>. The
front page at<URL:http://lwn.net> has the lead-in
Emacs distributions are not GPL-compliant
[Development] Posted Jul 29, 2011 12:10 UTC (Fri) by corbet
It turns out that the Emacs 23.2 and 23.3 releases contain a number
of parsers created with Bison, but the source for those parsers was
not included. That has led Richard Stallman to say: "We have made a
very bad mistake. Anyone redistributing those versions is violating
the GPL, through no fault of his own. We need to fix those releases
retroactively (or else delete them), and we need to do it right
away." This state of affairs is clearly just a slip which will be
fixed 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. It'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

Hi,

IMHO exists a certain danger GPL might be used against contributors and
vendors of GPL'ed stuff.