CC0 license is an obstacle

[beldmit]

Dear colleagues,

we are planning to package liboqs for Fedora. We build liboqs with -DOQS_ALGS_ENABLED=STD to minimize support of non-standardized algorithms.

We found that the folders

./src/kem/kyber/pqclean_kyber*_aarch64
./src/sig/dilithium/pqclean_dilithium*_aarch64
./src/sig/sphincs/pqclean_sphincs*

contain CC0 license which is not acceptable for Fedora by default (and AFAIU, other Linux distributions).

I believe that for aarch64 we could fallback to a generic (slower) implementation in the compile time, but it's obviously not the best possible option.

Is it possible to get in contact with the authors of these implementation to get an agreement about double-licensing of these implementations? MIT, Apache2 or smth else is fine for our purpose.

Many thanks in advance!

[dstebila]

I've raised issues with the SPHINCS+ and neon-ntt team who did the aarch64 implementations for Kyber and Dilithium.

[beldmit]

Thank you very much!

[baentsch]

@beldmit As this "big company license madness" (pardon the quip from someone believing in all benefits of open source) apparently isn't sth easily resolved what about this proposal: Would it make sense/resolve your issue to add a (cmake) build define that ensures only MIT code gets included in a build? Or do you(r downstream :) need all code (incl. unbuild pieces) to be "license clean" from your perspective?

[beldmit]

I'll ask my colleagues but I have a feeling it's acceptable.

[beldmit]

@Simo5 what do you think?

[baentsch]

@beldmit @simo5 Any update on the above? Would it help if we'd introduce an "OQS_BUILD_MIT_ONLY" flag, for example? Or more generically an "OQS_PERMITTED_LICENSES" string to be set to suit any taste?

[dstebila]

With https://github.com/PQClean/PQClean/pull/488 landed in PQClean, once we update liboq, the aarch64 implementations of Kyber and Dilithium in liboqs should be acceptably licensed. That just leaves SPHINCS+; I've pinged them again on https://github.com/sphincs/sphincsplus/issues/49.

[beldmit]

@beldmit @simo5 Any update on the above? Would it help if we'd introduce an "OQS_BUILD_MIT_ONLY" flag, for example? Or more generically an "OQS_PERMITTED_LICENSES" string to be set to suit any taste?

Sorry for the delay. I'm afraid it doesn't help because we need all 4 algorithms :(

[baentsch]

Sorry for the delay. I'm afraid it doesn't help because we need all 4 algorithms :(

Let's list them one-by-one:

• Kyber: Apache2 for reference code as per https://github.com/open-quantum-safe/liboqs/blob/main/docs/algorithms/kem/kyber.md
• Dilithium: Apache2 for reference code as per https://github.com/open-quantum-safe/liboqs/blob/main/docs/algorithms/sig/dilithium.md
• Falcon: MIT as per https://github.com/open-quantum-safe/liboqs/blob/main/docs/algorithms/sig/falcon.md
• Sphincs: MIT as per https://github.com/sphincs/sphincsplus/issues/49. This just needs to land in liboqs.

That looks OK for me, no? Thus adding something like "-DOQS_PERMITTED_LICENSES=MIT|Apache-2" would allow creation of a binary with "suitable" licenses for your purpose. Just not optimizations if those authors don't agree to a "commercialization friendly" license.

[beldmit]

Yes, this looks viable. Many thanks!

[dstebila]

That looks OK for me, no? Thus adding something like "-DOQS_PERMITTED_LICENSES=MIT|Apache-2" would allow creation of a binary with "suitable" licenses for your purpose. Just not optimizations if those authors don't agree to a "commercialization friendly" license.

Yes, but I think we should be careful about making sure the logic here doesn't get unwieldy.

[SWilson4]

It looks to me like this will be resolved if/when PQClean integrates the upstream Sphincs+ licence changes and we run copy_from_upstream. Assuming the PQClean update is straightforward, it shouldn't require too much effort on our part.

@beldmit @simo5 is this still something you would like to see done?

[beldmit]

The NIST algorithms seem to have the licenses suitable for our purposes now.

[baentsch]

The NIST algorithms seem to have the licenses suitable for our purposes now.

In that case, could we then consider closing https://github.com/open-quantum-safe/liboqs/issues/1514 (without implementing it) assuming you'll simply build liboqs setting OQS_ALGS_ENABLED=STD?

[beldmit]

I believe yes. Many thanks!

[SWilson4]

Is it safe to close this issue as well, @baentsch?

[baentsch]

I would say so; but I'd suggest leaving that to the author of the issue.

[SWilson4]

@beldmit Is this resolved from your perspective? (i.e., am I OK to close this issue as completed?)

[beldmit]

Sure, thank you very much!