Consider reinstating CLA
Closed this issue · 7 comments
It has now been a while since the requirement for signing the CLA was removed. Would you consider taking a look to see whether the change in contributions has been worth the change in IP status?
My personal stance is that I preferred the situation when signing the CLA was a requirement. It makes life more difficult with commits of unknown provenance.
I realise that this may provoke some negative responses. I'm not looking for a fight but would like the developers to realise that this is important for some people and to take stock of the situation.
@ralight -1 for CLA, it is just about spending tons of maintainer's time on checking if the user has signed it.
@indutny I was under the impression that you had this automated before, is that not the case?
I signed it and I was still asked 3 times to sign it.
No way this is coming back. How does this make your life more difficult @ralight? It does make the lifes of us maintainers and some contributors more complicated for no real benefit that I can see.
At the Eclipse Foundation any third party code used by projects as a hard requirement needs to be IP clean. This means that the origin of the code is clear and the person who committed it was allowed to do so. One of the reasons is to ensure that any project can be used with a known provenance for the entire codebase including third party requirements.
By third party requirement here I mean something that you cannot disable the use of at compile time. The Eclipse Foundation calls this a prerequisite. There are more details on the 3rd party policy here: http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf I believe that libuv falls under section 4b, which means a full IP review is required. The CLA used for libuv provided a similar level of assurance to the Eclipse CLA, which meant this would have been easy. As it stands, I am essentially being offered the choice of using the most recent version of libuv that was released before the CLA was removed, or to not use libuv at all. The former is a flawed choice and the latter would make me very sad because I think libuv is the best choice for an event library.
The final side to this is essentially around distribution of binaries. You can see section 4a of the policy talks about exempt prerequisites and describes third party dependencies that are expected to already be available on the end user's machine. This is a straightforward argument to make for Linux systems - libuv is available on the important Linux distros. As far as I can tell though, nobody distributes Windows binaries for libuv so I would have to do that myself and there is no way that it could be argued that libuv is pervasive or is expected to already be available.
IANAL.
The choice was made to remove the CLA as often it was a stumbling block for adding contributions (especially trivial ones) into the source base.
There is debate in the open source community if the need for a CLA, DCO or similar utility should be required for contributing to a project.
While I am not equipped to argue the finer points of these devices, know that there are many voices interested in not having a CLA, having a CLA, or having a replacement mechanism for the CLA. These discussions are ongoing and are a part of the newly formed Node.js Advisory Board https://www.joyent.com/blog/node-js-advisory-board (which is quite young).
As this conversation begins to take shape you can participate, there is a mailing list (governance@nodejs.org) and there will likely be a working group communicating on github issues to handle discussions. These things are just now starting to take shape, please feel free to email me or the governance list if you have further questions or concerns.
For now I'm going to close this particular issue.
Thanks for the details, that sounds like a positive step all round.