search

open-quantum-safe / liboqs

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

Review & automate license management #1514

Open baentsch opened 1 year ago

baentsch commented 1 year ago

liboqs integrates various code bases under one "quantum-safe friendly" API. For some algorithms, integration is done manually, for some automated (copy_from_upstream, copy_from_xkcp). While care has been taken to document the resultant "zoo of licenses", more locations than one exist for this, e.g., "spdx-identifiers" in all source code files, a "summary spdx-identifier" in the algorithm documentation sheets, separate "LICENSE" files (originating with but possibly not in line with the upstream code bases) and a central LICENSE file valid only for the liboqs API, pointing to the sub-folder LICENSE files.

For research purposes, where publication (of code and results) is norm and goal, it arguably is sufficient that code has a license -- which liboqs already provides. For integration into commercial products (including OS distributions) this arguably is insufficient (see e.g., #1437).

If the goal is to be able to create binaries suitable for inclusion into commercial software distros (?), e.g., RedHat, all code in liboqs arguably needs to have unambiguous license statements. Given the large corpus of "external" code (liboqs already counts 225 "LICENSE" files -- even before the inclusion of LMS/XMSS) this needs to be fully automated, such as to allow creation of binaries that can be used in commercial distributions (e.g., MIT, Apache2) and those that can be used in truly open, e.g., research settings (e.g., CC0, GPL).

This issue is to propose work to review and automate all license handling within liboqs -- with the ultimate goal to allow liboqs (and its subprojects and users) to select at build time only those algorithms/code bases using specific licenses, e.g., "commercialization friendly" (e.g., MIT, Apache) or "fully open source" (e.g., GPL) or "research friendly" (arguably any).

Thoughts about the need (and timeline and willingness to support this work) for this particularly welcome from anyone possibly having a commercial use case in mind, e.g., @vsoftco @christianpaquin @bhess @crockeea @beldmit @thb-sb (already thumbs up or down would be helpful to gauge interest in this boring "legalese" issue :)

ghost commented 1 year ago

I'd be happy to help!

dstebila commented 1 year ago

Excellent suggestion, Michael! Yes I think it makes sense to have an automated process for this, and to include the check of the output in the test suite.

baentsch commented 10 months ago

Suggest to close as per https://github.com/open-quantum-safe/liboqs/issues/1437#issuecomment-1907717069: This would basically benefit companies worried about licensing terms. And as that concern seems to be remedied by (manually) ensuring STD algorithms being MIT or Apache2 as a FOSS project we may save the effort. This of course does not preclude implementation by someone commercially interested in the feature. Keeping it open for some time to gather feedback: It still feels valuable, but as no-one found time to implement, it cannot be that valuable... Maybe worthwhile implementing only in a non-research branch/version?

planetf1 commented 9 months ago

Catching up .... I think the principle is really important, as came out in issue 1437 above. I think as long as it is clear that standard algorithms will be mit/apache2 licensed (and therefore generally ok from a commercial aspect) it's a good first-base. It enables the core algorithms to 'get out there' through a variety of package managers, inclusion in existing open source and commercial software, and cloud services.

Going beyond does make logical sense, but is probably a case of diminishing returns purely for those working on the non-std algorithms. If there is a specific new algo that a company needs to commercialise then they'll need to work on the licensing of it in any case, and to expect to just take an algo in dev without contributing (including to making the license acceptable or developing tooling to guard) isn't reasonable ?

One additional step we could take is to

baentsch commented 9 months ago

I'm not aware of any review checklists

See/amend https://github.com/open-quantum-safe/liboqs/wiki/Release-process

baentsch commented 9 months ago

there may be additional tweaks needed in build/docs for oqsprovider

By all means, create PRs to add those as you(r company) see(s) fit. fwiw, oqsprovider historically does have a stronger focus on the "STD" algs (surely in CCI) but it would be good to document/qualify this.