Emacs CLA requirement

[Christopher Dimech]

> Sent: Thursday, June 17, 2021 at 2:34 AM
> From: "Adam Tack" <adam.tack.513@gmail.com>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs CLA requirement
>
> 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 can be off-putting, but if you want to function in this world, you cannot
simply disregard that aspect of work.

> > 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.

The strive and hope is that there will not be any owners in future, making
licensing complications irrelevant.  We use copyright law to subvert it, and
would be a shame that you are not encouraged or motivated to get that part
completed satisfactorily.

> 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.

Who owns the copyright is not really important.  The actual problem
emanates from the reality of having so many different licenses, and the
incompatibilities they generate.  The relevant one today is definitely the
Gnu Affero GPL.

> 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.

Have been talking with Stallman about this.  We recognised it as a problem to be
solved.

>
> [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).

CLAs can still problematic without disclaiming agreements.