Re: Emacs CLA requirement

[Adam Tack]

I'm not interested in "strong-arming" the Emacs community or hijacking
anything, but since you've opened the discussion, I would argue in
favour of reconsidering the CLA requirement.

>From a global point of view, I think that it's absurd that, say,
use-package still isn't in Emacs, more than 5 years after the idea was
brought up.  If it were not for the CLA, we could have done this long
ago, and John Wiegley would not have the annoyance of having to chase
people up.

If it were not for the CLA, we could probably also include amazing
packages like Magit, and mention them in the manuals, which would
immensely enrich Emacs's out-of-the-box experience with git.  (That is
not to disparage vc-mode, but if we can have multiple e-mail packages,
we can also have multiple VC front-ends.)

>From a personal, anecdotal PoV, the CLA hindered my Emacs
contributions.  My completed CLA form seemed to have been ignored
which caused me to temporarily stop working on/finishing off my mostly
complete patches (in #13399) and after a month of not getting a reply
regarding the CLA I lost track of the topic due to external major life
issues.  (Fortunately, the issue that I had been working on was
eventually solved in a more general way, by Yuan Fu.  By the way, if
you're reading this, thanks!)

I do not wish to blame anybody -- you could argue that if I had been a
more dedicated contributor then I'd have followed up on the CLA (which
I have now very belatedly done).  My point is that the CLA is an
additional burden and friction, of a different type -- I personally
find bureaucracy off-putting in a way that I didn't find the e-mail
workflow, updating the Texinfo manual, adding News entries or writing
informative git commit messages.

> It helps less that RMS recently has been deposed from the GCC
> steering committee by a bunch of professional consent-manufacturers
> who should not have been given computers at an early age

I was also dismayed by the smear campaign against RMS, but could we
please avoid name-calling?

> Furthermore, a contributor license agreement allows the FSF to
> migrate Emacs' grant of license at any time -- whilst the regular
> "or later" clause only allows Emacs to also be available under a
> later version of the GPL; If a malicious actor relying on
> hypothetical system X, which is resolved in a hypothetical GPLv4 in
> the future, decides to redistribute a future Emacs under system X,
> then he would be able to do so after removing the small portion of
> contributions made under the "GPLv4 or later" clause.  That seems
> like a rather big problem.

In both cases -- with or without the CLA -- previous versions of Emacs
will continue to be available under the previous set of licenses and
will still be exploitable by the malicious actor.  What having the CLA
allows is re-licensing Emacs under a copyleft license[0] that's not
compatible with GPLv3+[1], which is rather unlikely to be needed.

> If so then I imagine it's every bit as necessary as it's ever been
> -- an annoying (but generally minor) hurdle to contribution which is
> nevertheless necessary for the FSF to have the ability to defend the
> code legally (which I presume remains important).

I am not a lawyer, so I do not know whether there have been any court
cases which change the view regarding having a single copyright owner.
It does seem to be the case that companies have been forced to release
their modifications of the Linux kernel despite there not being a
single copyright holder.

One other issue we'd have if the CLA requirement were removed would be
the license incompatibility between the GPL and the GFDL, which might
complicate the luckily rare copying of larger segments of code and
documentation between the manuals and the codebase.  However, it might
be possible to find a solution to this.

Adam


[0] It has to be a copyleft license since that's approximately what
the CLA declares.

[1] Without the CLA, Emacs could still be re-licensed under AGPLv3, a
hypothetical GPLv4+ and any licenses a hypothetical GPLv4+ declared
compatible with it (cf. Section 13 of GPLv3).