Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger <owinebar@gmail.com>]

On Mon, Aug 28, 2023 at 12:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Mon, 28 Aug 2023 11:22:21 -0400
> > Cc: Eli Zaretskii <eliz@gnu.org>, Philip Kaludercic <philipk@posteo.net>, dmitry@gutov.dev,
> >       luangruo@yahoo.com, danny@dfreeman.email,
> >       Stefan Kangas <stefankangas@gmail.com>, Emacs Devel <emacs-devel@gnu.org>,
> >       Manuel Uberti <manuel.uberti@inventati.org>
> >
> > On Sun, Aug 27, 2023 at 1:39 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> > > I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed.
> > >
> > If it wasn't for the copyright assignment requirement, there wouldn't
> > be a real issue blocking the incorporation of clojure-mode into core
> > emacs.
>
> That's a far cry from what the above actually says.  They also don't
> want to deal with the "quirks/oddities" of the Emacs development
> process.  They quite simply do NOT want clojure-mode to be part of
> Emacs.  The CA part is just one part of that, and I'm guessing not the
> main one.

Whether or not a derivative of clojure-mode is incorporated into core
emacs is not the same question as whether the external clojure-mode
project is subsumed into core emacs development.  Given RMS's request
to include a clojure mode as a core emacs feature, the required
development effort could be spent either maintaining a derivative of
the existing software/manuals/etc that complies with the emacs
development process or developing the tooling from scratch.   Assuming
such development resources can be identified, then, as I wrote, the
only real issue blocking the incorporation of (some derivative of)
that software is the copyright assignment question, assuming any
trademark-type issues on the names of the packages are resolved.

Whatever authority Bozhidar has is over the project he's a maintainer
of, not over emacs or clojure features incorporated in it, or even,
frankly, the software produced by his project.  It is licensed as free
software, after all. The only meaningful constraint on the creation of
a fork, major or minor, of free software is the pain involved in
maintaining such forks.

I'm not sure why you would assume the project that
created/maintains/develops an external package would necessarily want
to contribute the additional labor required to participate in the
emacs development process.  If the emacs project wants to incorporate
such a package in core, it's not unreasonable to expect it to provide
the resources required rather than expecting the additional labor be
done by the external project.

Lynn