Updating the CLA to the Apache-style ICLA and CCLA

[brianwarner]

Folks,

At the request of a project and a few members, we've been discussing changing the CLAs from the custom text inherited from the JSF to the more-common Apache-style Individual CLA and Corporate CLA. In the words of an attorney during a OpenJS member counsel meeting, this proposed change would be "adhering to the Principle of Least Astonishment." In other words, contributors and counsel who review documents will have the easiest time approving things they've seen before.

The rationale for bringing this up now is that some projects have started to move to the OpenJS CLA, but many are still in progress. As migrating off the JSF CLA will require a new signature anyhow, this is an opportune time to make a change like this which will also require a new signature. (General reminder: under the OpenJS Foundation IP Policy, the CLAs are optional and the decision to use them is left to the project)

From a process perspective, this is first reviewed with member legal for any concerns (done). The board then deliberates it and votes (in progress). During the discussion, the board may request input from various sources. In this case, the board asked to collect feedback from the CPC.

I'm tagging this for the next meeting, but we can also have a breakout call if anybody wants to get into the details or logistics. Let's start with Tuesday, though.

• The proposed ICLA
• The proposed CCLA

[tobie]

Approve the CLA text change

The goal of a good IP policy should be to achieve a careful balance between providing IP protection for the project, its users, and contributors, and providing a frictionless a contribution process as possible.

Sometimes, some changes improve both. This is the case of moving to the Apache CLA, which offers more IP protection and, because it is a well-known CLA, makes it easier for legal departments to approve contributions, making the contribution process smoother as a result.

👉 I believe the CPC should +1 this change.

Allow an ICLA-only option

It is worth noting that the individual CLA (ICLA) covers both contributions done as an individual and on behalf of one's employer:

4. You represent that you are legally entitled to grant the above license. If your employer(s) has
   rights to intellectual property that you create that includes your Contributions, you represent that
   you have received permission to make Contributions on behalf of that employer, that your
   employer has waived such rights for your Contributions to the Project, or that your employer has
   executed a separate Corporate CLA with the Project.

As a result, the ICLA in and of itself is sufficient to accept both contributions from individuals and corporations. Large corporations, such as Microsoft, have adopted ICLA-only for their own open source projects (e.g. Visual Studio Code). This has allowed Microsoft to rely on the industry standard CLA bot, CLA-assistant, which provides one-click CLA approval using GitHub handles and makes the whole process of approving a CLA easily understood and extremely lightweight.

Corporate CLAs (CCLA), on the other hand, are notoriously hard to handle for various technical reasons. A common issue is that corporations provide lists of approved contributors using their corporate email addresses while those often aren't connected to contributor's GitHub accounts. This creates a lot of unnecessary overhead for maintainers which have to chase contributors to get them to update their GitHub profile settings, end-up having to escalate pull requests for manual approval, or even have to abandon otherwise good pull requests. No amount of tooling can fix this.

As @dylans mentioned on the call yesterday, the pain of dealing with CCLAs is why projects such as Dojo have decided to only accept ICLAs in the past.

👉 As part of the feedback we provide the Board, the CPC should recommend that projects that opt-in to use a CLA may opt-in to use just the ICLA.

[dylans]

I will also add that at one point in time the Dojo Foundation ICLA and CCLA were nearly identical to the Apache versions of the agreements. We switched away when the Dojo Foundation and jQuery Foundation merged to become the JS Foundation. We had always required individuals to sign an ICLA even if their employer provided a CCLA, as it wasn't always clear if a CCLA covered someone's personal time efforts and contributions.

I believe the argument at the time was that the desire was to have the tersest possible CLA, and the version that was used by the jQuery Foundation was terser than the Dojo Foundation version.

Today the OpenJS Foundation is about 50% terser than the Apache version (1 page vs. 2 pages), but given that we have tooling for clickthrough CLA approval, I don't think it's a significant obstacle for approval.

So I am fine with a switch to the language to match the Apache CLA versions.

One bit of gray area for me is that we definitely have portions of the Dojo codebase covered under several different versions of CLAs over the years (I think we had at least 3 versions of the Dojo CLA over the years as Apache made updates, then 2-3 versions under the JS Foundation, and now what will become the second version under the Open JSF). I seem to recall there being some effort during the early days of the JS Foundation to get people to all approve the new CLA (or maybe that was copyright, it's been too long and things are blurring together), but I've assumed Dojo is fine and never worried about it. The only situation where I potentially see a problem is if the new CLA has significantly different conditions than the old one. In practice, I simply don't think anyone cares on that level so I'm not losing sleep at night. :)

[eemeli]

I'm fine in general with the new CLA texts. The only detail that I'd like some clarification on is this bit in both of the preambles:

[...] the Project shall not use Your Contributions in a way that is contrary to the public benefit [...]

Under a maximally purist and strict understanding, would that make the software non-open-source, given that this license is implicitly placing a usage restriction on the codebase to which a contribution is made under this license?

Just to be clear, I don't personally object to this at all, but would be interested in the rationale for the inclusion of that phrase, esp. as "public benefit" is left undefined.

[tobie]

@eemeli wrote:

Under a maximally purist and strict understanding, would that make the software non-open-source, given that this license is implicitly placing a usage restriction on the codebase to which a contribution is made under this license?

IANAL, but my understanding is this only puts a restriction on what the Foundation can do with the Project, not on other licensees (which are just constrained by the terms of the Apache License).

[nzakas]

No objections to changing the text.

My concern is around the transition. On ESLint, we’ve already had two CLA changes (from our custom one to the jQuery Foundation one, then from jQuery to JSF), and both times we changed it triggered emails to every contributor to sign the new CLA. I don’t want to put our contributors through that a third time.

My question: can we just apply the new CLA on new pull requests rather than requiring all past contributors to sign the new CLA upfront?

[mcollina]

+1 from me.

[adrianhopebailie]

+1

Also +1 to @tobie on a single CLA for individuals since this already includes a clause covering contribution of company IP. We have been discussing the CLA process in the Mojaloop Foundation of late too and opinion from the members (including large tech companies that make significant OSS contributions) is that a single individual CLA is preferred.

The process for signing CAN include the ability to provide an employer name and explicitly state that they agree to clause 4 and have permission to make contributions as an employee.

[eemeli]

@eemeli: Under a maximally purist and strict understanding, would that make the software non-open-source, given that this license is implicitly placing a usage restriction on the codebase to which a contribution is made under this license?

@tobie: IANAL, but my understanding is this only puts a restriction on what the Foundation can do with the Project, not on other licensees (which are just constrained by the terms of the Apache License).

My concern here is that if the project is bound to "not use Your Contributions in a way that is contrary to the public benefit", that really ought to mean that licensing said Contribution for unlimited use should not be allowed. And that would mean that it's not open source. This if from the OSI FAQ:

Can I stop "evil people" from using my program?
No. The Open Source Definition specifies that Open Source licenses may not discriminate against persons or groups. Giving everyone freedom means giving evil people freedom, too.

Now, clearly we're not all going to switch to non-open-source licenses, so this assertion in the CLA can't be valid. Or maybe there is some legalese here that I'm missing?

[tobie]

Or maybe there is some legalese here that I'm missing?

Yes. Section 2, your licensing grant is to the “Project and to recipients of software distributed by the Project” (emphasis mine). i.e. the copyright licensing grant is going straight from the contributor to the licensee, it is not relicensed by the foundation.

Also, the ASF CLA has been used and reviewed by pretty much every actor in the tech industry at this point. If this really was an issue, it would have been fixed at this point.

(And sorry for fat-fingering the close button.)

[eemeli]

Thank you @tobie, that does clarify the situation. I'd missed that detail.

[boneskull]

1. I also do not want to spam all contributors to sign the new CLA. This is important.
2. The new CLA infrastructure should make it clear the CLA is new and that it needs to be signed even if you already signed the old one.
3. When we say the CLA is optional, we mean "you must use the DCO instead," correct?

Speaking of the new CLA infrastructure: I assume this will be a new/different tool. Have tools been evaluated? Have we decided on what will be used?

[brianwarner]

I have an open question with legal on how to handle prior CLA signatures, I'll be back once I have an answer. That should help clarify the correct answer to your second question.

Also, yes - if you're not using a CLA, DCO is the other pre-approved option outlined in the IP policy. Basically, either "CLA in, FOSS license out" or "FOSS license in = FOSS license out".

Also, also, yes - CLA infrastructure would be using a different tool than the legacy JSF tool. Same idea - open a PR, it checks if you're on a list of approved contributors (either as an individual, or an employee of a company who signed), and it either passes or blocks the contribution. The advantage of using the tool supported by the foundation is that one signature covers any projects that require it.

If a project wants to use their own tool it would be on a self-support basis and would not get the benefit of sign-once-participate-everywhere.

[eemeli]

The advantage of using the tool supported by the foundation is that one signature covers any projects that require it.

This is good, but not at all clear from the CLA text. I at least had not realised that it refers to the OpenJS Foundation itself as the "Project", whereas that term in our common use refers to one of the 34 "projects" that are in the foundation. Could that at least be updated in the license text to be more clear?

[brianwarner]

The CLA text itself is reasonably standard and (per the legal committee) it's better not to modify it.

This is probably something that's better clarified wherever each project documents that they require the CLA. (Since it's on a project-by-project basis, this will have to be done anyhow).

Similar to the standard footer, I can draft up common text that projects can copy/paste.

[brianwarner]

@boneskull and @nzakas - I have an answer from legal.

Prior contributor would not need to sign the OpenJS CLA unless they make a new contribution. We do not need to go back and get signatures for everyone who previously contributed.

[tobie]

Thanks for all of the clarifications, @brianwarner, and proposal to draft a common text for projects to use. I think that's going to be super useful.

Overall, I feel like this is really shaping up nicely!

[nzakas]

@brianwarner awesome, thanks for the followup.

[tobie]

See also #632.

[mhdawson]

Feedback has gone back to the Board, closing