liboqs
liboqs copied to clipboard
open-quantum-safe
CC0 license is an obstacle
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!
I've raised issues with the SPHINCS+ and neon-ntt team who did the aarch64 implementations for Kyber and Dilithium.
@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 @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?
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 @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 :(
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.
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.
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?
The NIST algorithms seem to have the licenses suitable for our purposes now.
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?