Re: CVS is the `released version'

[David Kastrup]

Trent Buck <address@hidden> writes:

> Richard Stallman <address@hidden> writes:
>
>> In that case, I think the real proposal is not "add a package system
>> to Emacs" but rather "set up a standard site for Emacs add-ons".
>
> Agreed.
>
>> If the add-ons are put in such a web site, finding and installing them
>> would be much easier.  Maybe it is worth doing that, though calling it
>> a "package system" seems like hype.
>>
>> But there are two important non-technical problems with this approach.
>>
>> 1. It could reduce the incentive for people to assign copyright on
>> their code.
>>
>> 2. It would mean that Emacs refers people very strongly to a site
>> that isn't run by the GNU Project.  I don't know what their policies
>> are.  But even if they are good, now, we have no way to assure that
>> remains so.
>>
>> These problems would be eliminated if we put the package repository on
>> gnu.org and limit it to packages that are copyright FSF.
>
> Would it be acceptable to have two repositories "main" and
> "non-fsf", both hosted on gnu.org, and only have the former enabled
> by default?  That is, packages in "non-fsf" would not be listed or
> installable unless the user explicitly added something like this to
> their .emacs:
>
>     (add-to-list 'package-repositories "http://elpa.gnu.org/non-fsf";)
>
> That way Free software packages that are NOT assigned to the FSF
> (such as paredit, which is declares itself to be in the Public
> Domain), can still be installed easily by users via the package.el
> framework, but only after the user explicitly says "please enable
> installation of Free, but non-FSF packages".  It would also make it
> easy to move a package into "main" once the paperwork was done by
> simply changing a few headers -- the rest of the package.el
> integration would already have been done and tested in the "non-fsf"
> repository.

I don't think that "non-fsf" is a good label: it focuses on a legal
aspect, not on the motivation behind it.  And it is irrelevant for the
end user whether or not a GPLed piece of software is copyrighted by
the FSF or someone else (unless she wants to negotiate a different
license, but that's quite unlikely with Emacs packages).

If one wanted to make such a distinction, it would likely be better to
use something like

http://elpa.gnu.org/core or http://elpa.gnu.org/gnu-packages

and

http://elpa.nongnu.org/contrib

and make clear that the core packages require formal approval that
will imply a copyright assignment as a rule.

-- 
David Kastrup