search

open-quantum-safe / liboqs

C library for prototyping and experimenting with quantum-resistant cryptography
https://openquantumsafe.org/
Other
1.77k stars 435 forks source link

CC0 license is an obstacle #1437

Open beldmit opened 1 year ago

beldmit commented 1 year ago

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 commented 1 year ago

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

beldmit commented 1 year ago

Thank you very much!

baentsch commented 1 year ago

@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 commented 1 year ago

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

beldmit commented 1 year ago

@Simo5 what do you think?

baentsch commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

Let's list them one-by-one:

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 commented 1 year ago

Yes, this looks viable. Many thanks!

dstebila commented 1 year ago

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 commented 7 months ago

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 commented 7 months ago

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

baentsch commented 7 months ago

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 commented 7 months ago

I believe yes. Many thanks!

SWilson4 commented 7 months ago

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

baentsch commented 7 months ago

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