emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of the CEDET merge


From: David Kastrup
Subject: Re: State of the CEDET merge
Date: Wed, 27 Jul 2011 09:39:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

David Engster <address@hidden> writes:

> David Kastrup writes:
>> Chong Yidong <address@hidden> writes:
>>
>>> David Engster <address@hidden> writes:
>>>
>>>> We are working on it in the mentioned CEDET file-rename branch. We
>>>> didn't make the Emacs24 freeze, but thanks for reminding us.
>>>
>>> I too regret that this could not be done for the 24.1 freeze, but we
>>> should definitely get plan to bring Emacs CEDET back in synch with
>>> upstream for Emacs 24.2.  (Since CEDET was originally merged in
>>> 23.2, there is at least some symmetry in this).
>>
>> We are, in essence, distributing binary blobs with Emacs, and I find it
>> surprising that this does not seem to disturb anybody much except
>> myself.
>
> The parser generators will be merged. Please take a look at the
> mentioned file-rename branch[1] before speculating further on what the
> merge might not include.

I am not speculating on what the merge might or might not include once
it happens: I have no reason to assume that it will be incomplete with
regard to fulfilling the source requirements.

Most of us have signed a copyright assignment contract to the FSF.  This
contract states, among other things:

    The Foundation promises that any program "based on the Work" offered
    to the public by the Foundation or its assignees shall be offered in
    the form of machine-readable source code, in addition to any other
    forms of the Foundation's choosing. However, the Foundation is free
    to choose at its convenience the media of distribution for
    machine-readable source code.

The definition of source code, according to the GPL, is

      1. Source Code.

      The "source code" for a work means the preferred form of the work
    for making modifications to it.  "Object code" means any non-source
    form of a work.

[...]

      The "Corresponding Source" for a work in object code form means all
    the source code needed to generate, install, and (for an executable
    work) run the object code and to modify the work, including scripts to
    control those activities.  However, it does not include the work's
    System Libraries, or general-purpose tools or generally available free
    programs which are used unmodified in performing those activities but
    which are not part of the work.  For example, Corresponding Source
    includes interface definition files associated with source files for
    the work, and the source code for shared libraries and dynamically
    linked subprograms that the work is specifically designed to require,
    such as by intimate data communication or control flow between those
    subprograms and other parts of the work.

      The Corresponding Source need not include anything that users
    can regenerate automatically from other parts of the Corresponding
    Source.

      The Corresponding Source for a work in source code form is that
    same work.


When we release an Emacs version with a tarball and a new major version
number, nobody will seriously claim that this does not constitute a
release into the public.

So the plan is to openly breach the contract that the FSF has made with
contributors.

Personally, I'd consider that a show-stopper.  And I don't understand
that nobody cares or considers this much of a priority.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]