-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CC0 license is an obstacle #1437
Comments
I've raised issues with the SPHINCS+ and neon-ntt team who did the aarch64 implementations for Kyber and Dilithium. |
Thank you very much! |
@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 ( |
I'll ask my colleagues but I have a feeling it's acceptable. |
@simo5 what do you think? |
With PQClean/PQClean#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 sphincs/sphincsplus#49. |
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. |
Yes, this looks viable. Many thanks! |
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 @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. |
In that case, could we then consider closing #1514 (without implementing it) assuming you'll simply build |
I believe yes. Many thanks! |
Is it safe to close this issue as well, @baentsch? |
I would say so; but I'd suggest leaving that to the author of the issue. |
@beldmit Is this resolved from your perspective? (i.e., am I OK to close this issue as completed?) |
Sure, thank you very much! |
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
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!
The text was updated successfully, but these errors were encountered: