Does OQS-BoringSSL repository require a license exemption?

[dstebila]

As noted in open-quantum-safe/boringssl#114 (comment), the OQS-BoringSSL repository is under a mix of licenses, not just MIT License. The OQS Technical Charter says that "all new inbound contributions to the Project must be made under the MIT License", but that "The TSC may approve the use of an alternative license or licenses for inbound or outbound contributions on an exception basis." Does the fact that the repository was brought with the stated license mean that an exemption is implicitly already granted, or does the TSC need to explicitly vote to make such an exemption?

[baentsch]

As stated before I'd think this is logical/implicit and we could save the hassle voting. But I guess the LF legal folks will want to have the final say, right @hartm?

[planetf1]

The original issue also discusses the DCO at length.

My understanding is that the github dco bot checks for the presence of a signoff (which can be added in text or with --signoff etc) of every commit excluding merge/bots

The contributor updating the fork will be doing a merge - so should be all good
The committer for all other commits seems to be 'Boringssl LUCI CQ' - but this doesn't seem to be known to github. The code in the DCO bot is here and perhaps author is null? If so there isn't a problem, plus we still have the DCO for additional contributions we make within oqs?

I agree with the principle that since this is a fork, it's infeasible to expect signoffs if that project doesn't use the same mechanism, and doesn't make sense to manipulate commits from upstream.

There is also the option of allowing remediation commits (integrator adds an additional commit in the PR) - but how viable this is may depend on the workflow when merging. More info in the docs

So, on DCO - did the dco bot actually block it?

The license question is still valid though.

[dstebila]

I've created #17 to grant approval to use the LICENSE file in the BoringSSL repository.