On Sun, Sep 3, 2023, 11:15 AM Bozhidar Batsov <bozhidar@batsov.dev> wrote:

> That's a pretty disappointing remark, which implies that the Emacs team
> doesn't really care about having a good collaboration with the authors and
> maintainers of 3rd party Emacs packages.
>

I'm an outsider, so you should not regard my view as representative of the
GNU emacs "team", whatever that encompasses.  My interest is primarily in
the extent to which dealing with the employer waiver involved in the
copyright assignment caused your lack of interest in allowing a (presumably
minor) fork to be maintained for use in the core, if no further constraints
were required of the upstream package.  My interest is not in persuading
the GNU project to change its policy, but to see if there is any evidence
of harm to non-profit endeavors like the FSF/GNU project caused by the
ambiguity around the enforceability of assignment clauses in employment
contracts that are not for works created in the course of employment.  Such
evidence might be useful in lobbying law-makers for reform, or
attorneys-general for a broader reading and enforcement of existing laws.


> I know that for whatever reason we're now discussing clojure-mode, but
> there are many other major modes for which one can make exactly the same
> case (erlang-mode, elixir-mode, haskell-mode, etc). Let's just rush forward
> and include some stripped down/forked versions of them upstream as well,
> ignoring the people behind them and their end users (who are bound to face
> some degree of confusion short term). Adopting such a combative stance
> across the board would be very harmful for our small community IMO.
>

I'm not sure what the GNU emacs team will decide is appropriate, but I
think they have been pretty accommodating.  In any case, I don't believe
the GNU project would publish a derivative work of an extant 3rd party
package without the author's consent.  The project's requirement of a clear
copyright assignment, and the assignment's clear assurances regarding the
intent of the author to make the contribution (at the time of the
contribution at least), would make that difficult.

On the other side, I don't believe your labor gives you, or anyone,
proprietary rights to dictate how the GNU emacs team should name libraries
in their project.  Rejecting participation in their development process
*decreases* your influence in the decisions they make.  It would be
perverse to reward someone for rejecting participation by granting them
greater influence.  That's just a generic observation on social
organizations and processes.  Your view on the obligations of etiquette and
goodwill seems asymmetric to me.

What I don't understand is why you (or anyone) publishes software under a
free license and then act aggrieved that someone would make use of the
freedoms the license accords them.  Such developers would seem to prefer a
non-free license that requires contribution back to and acceptance by the
original project.  At least, that's how it seems to me.

Lynn