Adding OpenSSL CLA requirement

[planetf1]

One of the potential projects consuming code from liboqs, and pq-code-package is OpenSSL.

In order for any code to be considered by OpenSSL, all contributors (current, future, and historical) are required to have signed the OpenSSL CCA. This is very similar to the Apache CLA. This will apply both at the individual contributor and organization contributor level.

Note that this in no way means it's certain OpenSSL will actually use our code. They are still evaluating the approach they wish to make. This is merely a prereq for consideration.

This discussion has been ongoing at the PQCA level both in terms of general approach ,as well as tooling to support.

As a TSC we need to consider if we are ok with this approach, whether we have any particular concerns, and provide feedback to the PQCA.

Suggest discussion at the 20241106 TSC meeting

[planetf1]

OpenSSL CLA

[mkannwischer]

It would be great to have mlkem-native in OpenSSL.

Two points:

1. @potsrevennil and me are happy to sign the CLA for mlkem-native and I don't see any issues with our employer signing as well. @hanno-becker and @rod-chapman, how do you think about this?

2. Is see that openssl recently merged ML-KEM-768 from Boringssl in ML-KEM768 openssl/openssl#25848 into a feature branch. It would be good to understand how much they are looking for more parameter sets, more optimized code, or more assurance. Maybe @baentsch or @dstebila do have some more information on this that they could share with us, please?

[baentsch]

Thanks for tagging me @mkannwischer . Sure I can give some background: These discussions started before the establishment of PQCA (see openssl/project#431 for "history" and rationale). When they then didn't really progress, as a long-time OpenSSL contributor, I more recently chose to re-prioritize my non research-community-targeting FOSS contributions to that project where we currently proceed implementing all standards in a way completely separate from PQCA for various reasons, (missing) CLAs being one. fwiw, SLH-DSA is the most mature, but work is proceeding on the other algs as well, incl. ML-KEM, see e.g., openssl/openssl#26006.

That said, as I am an independent contributor myself, I personally love to work with any other independent contributor on the same terms of any given FOSS project. So if indeed in this case all authors (and where applicable, their employers) of an ML-KEM implementation are also willing to contribute under the same terms, let's discuss concrete ways forward, ideally in an open forum like openssl GH. While I by now also appreciate the boringSSL APIs, there's (as always) room for improvement, so you may consider responding to openssl/openssl#25879 for example as and when you'd be willing/able/permitted to contribute and make OpenSSL better. Another approach may be for you to open further issues at OpenSSL explicitly targeting functional and non-functional benefits of alternative code bases. That way, the whole OpenSSL community can chime in as to merit and priority of such features. In this case, please be sure to use the tag "ML-KEM" in the issue header so they're easier to find in the "sea of issues" :-) Tagging me also would help. Or even more simply, just open a PR -- in the case of ML-KEM, be sure to target the feature branch of that name for now. Thanks in advance!

[hanno-becker]

The CLA would not be an issue from my employer's end either.

[mkannwischer]

Thanks for tagging me @mkannwischer . Sure I can give some background: These discussions started before the establishment of PQCA (see openssl/project#431 for "history" and rationale). When they then didn't really progress, as a long-time OpenSSL contributor, I more recently chose to re-prioritize my non research-community-targeting FOSS contributions to that project where we currently proceed implementing all standards in a way completely separate from PQCA for various reasons, (missing) CLAs being one. fwiw, SLH-DSA is the most mature, but work is proceeding on the other algs as well, incl. ML-KEM, see e.g., openssl/openssl#26006.

That said, as I am an independent contributor myself, I personally love to work with any other independent contributor on the same terms of any given FOSS project. So if indeed in this case all authors (and where applicable, their employers) of an ML-KEM implementation are also willing to contribute under the same terms, let's discuss concrete ways forward, ideally in an open forum like openssl GH. While I by now also appreciate the boringSSL APIs, there's (as always) room for improvement, so you may consider responding to openssl/openssl#25879 for example as and when you'd be willing/able/permitted to contribute and make OpenSSL better. Another approach may be for you to open further issues at OpenSSL explicitly targeting functional and non-functional benefits of alternative code bases. That way, the whole OpenSSL community can chime in as to merit and priority of such features. In this case, please be sure to use the tag "ML-KEM" in the issue header so they're easier to find in the "sea of issues" :-) Tagging me also would help. Or even more simply, just open a PR -- in the case of ML-KEM, be sure to target the feature branch of that name for now. Thanks in advance!

Thank you very much for all that context @baentsch! It would be great to contribute.
I've posted a comment to openssl/openssl#26006. Let's move the discussion there.

[paulidale]

In order for any code to be considered by OpenSSL, all contributors (current, future, and historical) are required to have signed the OpenSSL CCA. This is very similar to the Apache CLA. This will apply both at the individual contributor and organization contributor level.

Some clarifications/notes:

1. The project uses the Apache version 2 CLA (the only change is the project name from memory).
2. Only contributors & their employers at the time of integration need to sign CLAs (i.e. future contributors don't need to unless their changes are pulled across).

[hartm]

I've gone over this with our lawyers over the past couple of months. We can definitely make this work from the Linux Foundation perspective, provided that all of the contributors are willing to sign the CLA (and have their employers sign it if applicable). Note that this requirement would include all past contributors, too.

There are still a couple of things that need to be sorted out for this to work.

1. Do you all want everyone in the entire PQCP to sign the CLA, or only have the requirement for certain repos? This is really up to you to decide. We can make it work either way.

2. We need to figure out how to handle enforcement. Unfortunately, EasyCLA does not have the kind of cross-org support we need for this. So, we will probably have to do some kind of manual enforcement. The PQCP maintainers will need to only approve contributions from folks who have signed the CLA. We can make this a list and configure github to only accept contributors from this list, but it will still require communication with the OpenSSL team to ensure that folks have actually signed the CLA. Then, if they want to pull in code from PQCP, the OpenSSL folks can just check the contributors' list against their CLA database to be sure. Hopefully this will be not too much work for everyone involved.

So, the next steps should be as follows:

1. Go ahead and start signing the OpenSSL CLA. It may take time in some cases to get companies to sign, so I'd encourage you all to do this soon. I'd also suggest starting to try to track down folks you know have contributed; it may be hard to reach some people (but hopefully not).

2. Figure out a policy for the PQCP and CLA signing. This could be requirements for certain repos or the whole org. The PQCP TSC should pass (and clearly document) a rule on this.

3. Coordinate with the OpenSSL folks on enforcement. The more we can automate, the better, but there will likely be some things that still have to be manually checked.

Does all of this make sense to everybody? Please let me know if there are any questions. Thanks for your time!

[planetf1]

Thanks @hartm .

Just my thoughts (I think we should have finally agreement via a tsc vote)

1. Simpler in some ways if applies to whole org, however I'd be ok if we focussed just on any repos where it's required - as we can scope the contributors tightly. It then would also not prevent us taking on a new project where the cla wasn't appropriate if we wished to
2. automated is obviously preferable. At a min we should update the PR template/project contribution guide

We have a TSC this week - suggest we use some time in the meeting to talk about the practicalities.