Re: Compiled files without sources????

[Tim Cross]

On Sun, Jul 31, 2011 at 9:03 PM, David Kastrup <address@hidden> wrote:
> Tim Cross <address@hidden> writes:
>
>> On Sun, Jul 31, 2011 at 9:20 AM, Thien-Thi Nguyen <address@hidden> wrote:
>>
>>> 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