CLA and our policy?

[pepoluan]

A bit surprising to see we suddenly have "CLA signing" as one of the "tests".

I have no problem with CLAs, although the abrupt implementation was ... jarring. Was totally caught unaware. (Personally I had no problem with the contents of the CLA and I have signed.)

However, I noticed there had been some resistances/disagreement with the "CLA" concept as a whole. As can be seen here and here.

Furthermore, some previously ready-to-merge PRs now gets the yellow bullet instead of the green checkmark.

Seems to me we're entering a minefield...

So, what will be the policy here?

[asvetlov]

Thanks for raising the question.
I am the person who applied CLA to the whole aio-libs organization.
The CLA text is very close to the CLA used by CPython itself: https://www.python.org/psf/contrib/contrib-form/
If you want to contribute to Python you should sign it. Python also has a bot that checks the CLA.
I personally have signed this document don't remember when, probably in the past century, I did it in paper form.
The process was very tedious, but now it is highly automated.

As the library maintainer, you decide whether to merge a PR without the CLA signed.
Sometimes in Python we do skip the check, while the common agreement is that the CLA is required for any contribution.
I recall discussions about the CLA for Python in the past, but the current status quo is described above.
Honestly, I don't think that the signing is hard technically or not applicable by moral/legal reasons.
If it works for Python itself -- why it doesn't work for aio-libs?

[pepoluan]

I personally have signed this document don't remember when, probably in the past century

Ahahaha 😂

Thanks for the answer! I think we shouldn't adopt any "blanket policy" then, as aiosmtpd is a small project with (still) manageable Issues/PR list, so everything can still be done on a case-by-case basis.

Anyways, thank you for the explanation, @asvetlov !

[asvetlov]

Sorry for misleading you, I wrote the message late at night.
The CLA sign date was definitely not so old but about 15 years ago.

Anyway, I agree that the CLI harms the project.
I did not expect such a negative reaction and thought that people consider CLA as yet another thing like Code-of-Conduct etc.
To be honest, I have a neutral feeling about such things: I personally trying to be polite regardless of the Code-of-Conduct presence; I respect all people regardless of a declared diversity policy, etc.

Thanks to @warsaw comment #207 (comment) I'm convinced that dropping the CLA is a good idea for aio-libs.

I apologize for the unconvinience.

[waynew]

Just weighing (and wading) in on this, after reading all the latest discussion(s) and linked posts and some other related post:

I think DCO is plenty sufficient for our needs here. This is not a novel or super fancy project. We're literally implementing the SMTP spec -- that's it. It's not glamorous or full of fancy mathematics or algebra or anything. Heck, there are at least dozens of other software projects that do exactly the same things that aiostmpd does (delivers email).

We're not breaking new ground here, we're just making a sweet sweet project that lets people accept and deliver email using Python+asyncio, and no other deps. Which is /valuable/ and (evidently) some of us really like it. I just can't imagine anyone trying to go after aiosmtpd, especially. Once we've successfully implemented the entire SMTP(S) specs, I fully expect this project to just enter a level of maturity where it changes very little, and folks are able to depend on it to build their own projects and platforms.

So: 👍 for DCO, 👎 for CLA, and 💯 for aiosmtpd 😍

[pepoluan]

Since it seems the CLA matter has been settled (I see no CLAassistant piping up, and no more license/cla checking), I vote for closing this issue.

[asvetlov]

I've switched off the CLA after receiving several negative reactions.