emacs-devel
[Top][All Lists]
Advanced

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

Re: Drop the Copyright Assignment requirement for Emacs


From: João Távora
Subject: Re: Drop the Copyright Assignment requirement for Emacs
Date: Sat, 9 May 2020 12:35:42 +0100

On Sat, May 9, 2020 at 11:19 AM Eli Zaretskii <address@hidden> wrote:

> So I guess there's no such process at this time.  We just have some
> packages that are already in core, and are _also_ available from ELPA.
> IOW, it's a static situation that is not designed to change.

Not 100% sure what you mean by that. But yes, there's no pre-planned
route for :core packages.  We decide if it's convenient to do it on a case
by case.

Notice it does have drawbacks.  Once you do this for a lisp/foo.el file,
you need to add this:

;; Package-Requires: ((emacs "xx.y"))
;; This is an Elpa :core package. Don't use functionality that is not
;; compatible with Emacs xx.y.

Most of the times, I think the trade-off is more than acceptable.

> Is that really important?  Why cannot the authors experiment with that
> while outside ELPA?

They can, of course, but you're denying that "official" GNU stamp.
There's the legitimate ambition of recognition, very common among
younger developers, because these kinds of things can matter in job
interviews, for example.

> > 2. We envisioned (I recall) that Emacs might one day be distributed
> > with some of the packages in ELPA, presumably the well behaved
> > ones.
> This would require the same requirements as we ask for inclusion in
> core.

Not quite the same.  The bar for inclusion in the core is higher.
The candidate code has to have technical merit because it's
going to be used by other code already in the core, creating a
dependency. This is theoretically why including s.el in GNU Elpa
would be less bad than including it in Emacs.  However some
people think, and I agree with them, that this would encourage
other packages in GNU Elpa to adopt s.el's prepotent prefix
and thus create a larger problem.

This is, by the way, why I think this is a technical problem at heart:
  if s.el's default prefix wasn't so harmful there would be no reason
not to include it in GNU Elpa AFAICT.

> [Those requirements] doesn't seem to be happening, and AFAIU
> it isn't by omission.

It's happening de facto for some (or most?), packages in
ELPA, AFAIU.  I don't remember people requesting it from me
explicitly, but my memory is hazy here.

João



reply via email to

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