The python-awscrt package uses some code from aws-c-io[0] which has an OASIS[1] license. This license isn't included in Fedora's allowed license list[2]. I've opened a discussion upstream[3] to see if it's possible to build awscrt without this particular code. It appears to be used for mutual TLS authentication in a few different places. I haven't found a cmake flag or other thing to toggle to exclude it. [0] https://github.com/awslabs/aws-c-io/tree/main/source/pkcs11/v2.40 [1] https://github.com/awslabs/aws-c-io/blob/main/THIRD-PARTY-LICENSES.txt [2] https://docs.fedoraproject.org/en-US/legal/all-allowed/ [3] https://github.com/awslabs/aws-c-io/discussions/621 Reproducible: Always
@mhayden I contacted the SDE Michael Graeb that is familiar with this project. I have added an account for him to contribute to this directly. I have copied his comments below around this issue. >It's possible we're not doing the license thing correctly here. We don't actually include any executable source code, just 3 header files: >https://github.com/awslabs/aws-c-io/blob/main/source/pkcs11/v2.40/pkcs11.h >https://github.com/awslabs/aws-c-io/blob/main/source/pkcs11/v2.40/pkcs11f.h >https://github.com/awslabs/aws-c-io/blob/main/source/pkcs11/v2.40/pkcs11t.h > >These header files define the PKCS#11 API: >https://en.wikipedia.org/wiki/PKCS_11 > >Oasis is the organization in charge of the PKCS#11 standard: >https://www.oasis-open.org/org/ > >One of the most respected, non-profit standards bodies in the world, OASIS Open offers projects—including open source projects—a path to standardization and de jure approval for reference in international policy and procurement. > >https://www.oasis-open.org/committees/pkcs11/charter.php > >The purpose of the PKCS 11 Technical Committee is the on-going enhancement and maintenance of the PKCS #11 standard, widely used across the industry as a core specification for cryptographic services. The PKCS #11 standard, originally developed under the leadership of RSA Laboratories, specifies an API, called Cryptoki, for devices which hold cryptographic information and perform cryptographic functions. The API follows a simple object-based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a cryptographic token. > >The reason these headers are in python-awscrt: > >We support MQTT connections for IoT devices >These MQTT connections often perform Mutual TLS, where the IoT device has its own private key and certificate. >These private keys are often stored in hardware, rather than in software >PKCS#11 is a standard API for interacting with security hardware. The way this works is, an application loads a 3rdparty shared-lib that implements the PKCS#11 API, then calls those functions. That shared-lib then communicates with the security hardware. >So python-awscrt needs to know the functions and structures in the public PKCS#11 API, which is why we've included these headers >Here's are threads of other people having the same confusion: >https://github.com/latchset/pkcs11-provider/issues/76 >https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/2QXHMTZ47DMMARJVI6PUMSYUPVFAGLCV/ >https://mail.openjdk.org/pipermail/jdk-dev/2021-May/005526.html >https://github.com/opendnssec/SoftHSMv2/pull/412 >https://gitlab.isc.org/isc-projects/bind9/-/issues/414 >https://github.com/containers/podman/issues/13906 > >Seems like a lot of them have used headers from somewhere else. Or they decide it's not a problem. It is confusing that the files from the committee in charge of the API are bad. And the solution seems to be copying someone else's copy of the same API? Is that correct? I have a very hard time understanding this stuff. > >I noticed that someone from Redhat is on the PKCS#11 committee: >Robert Relyea, rrelyea, Chair >https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 >Maybe someone to contact about this? > >Would headers with a different license solve your problem? >Or should we not even be mentioning the Oasis license because they're just headers?
Michael brought up an interesting question: Robert Relyea rrelyea is chair of the OASIS TC. Should this open source license be part of Fedora? I have added him here to see if he can comment on that.
Thank you, Nicolas! 👏 Licensing and legal things are definitely outside my area of expertise, but I work with some people who know this area well. I'll make sure they see Michael's update.
The issue is that the OASIS license is not an open source license, because it seems to limit the freedom to make modifications (although it's also possible to read it as self-contradictory on this point, which is at least as bad). This is not a new problem and it is not limited to OASIS but is a common problem arising out of the use by open source projects of content from standards organizations which historically had a misguided approach of attempting to use restrictive copyright licensing to advance the interests of the standards org. (OASIS has in recent years made an effort to pivot towards supporting open source development but I don't think that affects any sufficiently old standard.) In any case, the problem for the Fedora Project is that the license does not conform to Fedora's licensing policies. We *could* make a special exception, as we do in a number of other problematic cases, but it would be preferable not to. The license probably could be ignored in this case (being "just headers") except that the header files in question contain comments which are possibly minimally copyrightable and thus covered by this license. Fedora applies the strictest licensing standards to code, including comments in code. If we deleted the comments that might solve the problem, though that would be rather unusual and I'm not sure if that's a path anyone wants to pursue.
Would this file be an acceptable replacement? https://github.com/latchset/pkcs11-headers/blob/main/public-domain/2.40/pkcs11.h > /* This file is in the Public Domain */ It was created by another project that ran into the same Oasis licensing issues: https://github.com/latchset/pkcs11-provider/issues/76
(In reply to Michael Graeb from comment #5) > Would this file be an acceptable replacement? > > https://github.com/latchset/pkcs11-headers/blob/main/public-domain/2.40/ > pkcs11.h > > /* This file is in the Public Domain */ > > It was created by another project that ran into the same Oasis licensing > issues: > https://github.com/latchset/pkcs11-provider/issues/76 Yes, this seems to be equivalent to my suggestion of stripping the comments out of the original headers.
Fixed in the latest release. v0.20.4 of aws-crt-python on Github: https://github.com/awslabs/aws-crt-python/releases/tag/v0.20.4 0.20.4 of awscrt on PyPI: https://pypi.org/project/awscrt/ Here's the pull-request where the OASIS license was removed, and replaced with Public Domain headers: https://github.com/awslabs/aws-c-io/pull/623
@mhayden I saw your comments on the pull request. Is this all good to be resolved now? Is there anything else outstanding on it?
All we need now is to update the package in Fedora!
awscrt 0.20.5 is now in rawhide.
Awesome! Thank you everybody!