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

[Lynn Winebarger]

On Mon, Aug 28, 2023 at 6:14 PM Danny Freeman <danny@dfreeman.email> wrote:
> João Távora <joaotavora@gmail.com> writes:
> > On Mon, Aug 28, 2023 at 10:15 PM Danny Freeman <danny@dfreeman.email> wrote:
> >
> >> I would once again like to ask, who is asking for this?
> >
> > Noone.  Noone asked that clojure stuff be forked or anything like that.

You both are reading far more into the term "fork" than there is.
"Fork" does not imply "schism", at least in modern usage.  A fork is
just a downstream repo that independently maintains a set of changes
relative to an upstream project.  AFAIK, every linux distribution
maintains its own fork of GNU emacs in the form of a patchset, and
maintains those forks of older versions with bug and security fixes
long after GNU emacs has stopped supporting them.  Go to any git-based
forge and there's probably a "fork" button for any given repo.
Personally, I would prefer "fork" not be considered to refer to
projects that have diverged to the point of being unmanageable.

> People are literally suggesting exactly this in the comments above.

In the sense that core emacs could distribute a downstream version of
clojure-mode (or whatever) in the same way linux distributions provide
forks of major software packages modified to suit their preferred
tooling, processes, principles, etc, yes.  I don't see a GNU emacs
developer integrating an upstream package into the Emacs project as
particularly different from a linux distribution customizing the free
software it bundles, as long as there is no misrepresentation as to
its provenance or trademark-type concerns.  I really do not get how
people publish software under a free license while retaining a
proprietary view of people publishing variations of their work.

But don't take my views as representative in any way of the emacs
project.  I just wrote what I thought were the implications of RMS's
email, versus Eli's conclusion.  If the issue is only the effort
involved in obtaining CA's and dealing with the emacs development
process, that does not intrinsically rule out the emacs project as a
downstream publisher of clojure-mode.  I only wrote that I think it's
fair for clojure-mode developers to expect the emacs project to
provide that labor, where Eli's position seemed to me to be that the
upstream project would be required to be swallowed into the emacs
project.

> it would be good if the flagship FSF project Emacs had some clojure
> > support under its umbrella, and invited your project to come on board.
>
> I'm not taking any issue with this. I was more than happy to answer
> questions about it at the start of this thread. If I were developing
> this on my own I would probably accept that invitation, but I'm not.
>
> > Many third-party projects that benefit from the incalculable amount
> > of work put in by FSF's developers and volunteers who have signed CAs
> > throughout almost 4 decades would find this invitation a privilege,
> > maybe in recognition that united we stand, divided we fall.  But noone,
> > absolutely noone, can force you or coerce you to accept the invitation
> > or even stand in the way if you or Bozidhar want to pursue other
> > paths.  And noone has done that.  So no need for persecutory delusions
> > that the FSF secret police is going to extort CAs from your developers
> > to fork and undermine your project.

Unless you read something different than I did, RMS's emails
explicitly requested a built-in clojure mode, whether that was derived
from the existing external package or not.  I agree there is no
attempt to "extort" CAs from the developers of the existing external
package.

>
> The reason I wrote that is because in the message directly before mine
> from Lynn:
>
> >> 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.
>
> is suggesting that someone could take on the task of obtaining CAs and
> forking. All I am asking is that NOT be done, not having "delusions".

I just said "derivative of", which might only mean an older version
with minor modifications required to conform to GNU coding standards,
like not referencing non-free software, etc.  If that would entail a
schism-level "fork" (in your terms), then it would probably not be
worth the effort.  Also, presumably if Bozidhar and other major
contributors were not willing to sign a CA, it (the incorporation of
the existing clojure-mode package in core emacs) would probably be a
moot issue anyway.

That being said, any contributor who has retained their copyright
doesn't need permission from anyone to sign a CA with the FSF or
anyone else for that matter.  I'm not sure why anyone would have an
objection to that.

>
> > Remember that NonGNU Elpa was
> > created by Emacs devs just to service projects like yours.  And your
> > original request has been serviced already, free of charge.
> >
> > João
>
> And I am very grateful my project was accepted into NonGNU Elpa. But now
> I am trying to act in what I believe are the best interests of
> clojure-mode by avoiding a fork.

Back to the original point, then, RMS requested emacs incorporate a
built-in clojure mode.  The members of the emacs project have every
bit as much right to provide a built-in clojure mode as the
contributors to the clojure-emacs project have to develop that project
as they see fit.  If anything, Bozhidar's standing to object to the
course of development of the GNU Emacs project has been severely
diminished by his explicit rejection of the invitation to participate
in it.  There is neither conflict nor coercion in either of these
positions.  I think the emacs developers have been pretty gracious
about it, really.

Lynn