Hi Andrej,
We’re trying to work with the Qualcomm TSC rep in Zephyr to see if it can be relicensed, but there are about 20 authors to track down to make this happen, so it won’t be a quick solution even if it is possible.
In the interim, we’ll likely have to disable all use of the library to avoid blocking the Zephyr 3.3 release, meaning disabling use of the attestation service until a legal solution can be found.
Best regards, Kevin
On Thu, 9 Feb 2023 at 08:52, Andrej Butok andrey.butok@nxp.com wrote:
Hi Kevin,
TFM may not change the 3rd party license clauses.
Can it be solved directly with the QCBOR project https://github.com/laurencelundblade/QCBOR to make it OSI compliant?
Thanks,
Andrej
*From:* Kevin Townsend via TF-M tf-m@lists.trustedfirmware.org *Sent:* Wednesday, February 8, 2023 6:12 PM *To:* Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org *Subject:* [TF-M] Non-OSI license issue with QCBOR
We were discussing a problem with the Zephyr integration of TF-M today on the Zephyr TSC call, determining how to avoid QCBOR being downloaded at build time, which is against Zephyr project policy. Zephyr project policy is that all build dependencies need to exist in the Zephyr project Github org, and be downloaded before building.
During the discussion, it came up that QCBOR actually doesn't have an OSI approved open license, even if it appears to have one on first glance: https://github.com/zephyrproject-rtos/zephyr/issues/54017#issuecomment-14229... https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F54017%23issuecomment-1422934516&data=05%7C01%7Candrey.butok%40nxp.com%7C14ba6583e83242c04cd408db09f7a0df%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638114731398489749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TN%2BIs5am3s7hE2mywLPnIB6mIk2Zk0CVltRyE9e6LCw%3D&reserved=0
"Essentially" 3-Clause BSD really doesn't legally mean anything https://github.com/laurencelundblade/QCBOR/blob/master/README.md?plain=1#L52... https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR%2Fblob%2Fmaster%2FREADME.md%3Fplain%3D1%23L527&data=05%7C01%7Candrey.butok%40nxp.com%7C14ba6583e83242c04cd408db09f7a0df%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638114731398489749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rkEHPP1TGluA%2BnqkSguyNB%2B2XwvrX3aeG%2FjwJue5cpM%3D&reserved=0
It looks like `NON-INFRINGEMENT` has been added to the license text, which is easy to miss, but entirely changes the license terms.
This is highly problematic, since not being OSI compliant now puts us in a position where we may have to remove TF-M from Zephyr to avoid blocking the 3.3 release, due to project policy around licenses, or I need to remove anything that relies on QCBOR until the license can be sorted out, with the 3.3 release and freeze scheduled for Friday. I'll look tomorrow at disabling attestation tokens, which seem to be the main user of this, but I wanted to bring the license issues up for anyone else who requires OSI-complliant licenses since this is easy to miss, and has been missed until now days from a release.
Thought it was important enough to quickly bring up here for TSC attention, while I try to find a solution less radical that removing TF-M to avoid blocking the Zephyr release.
--
Thanks and best regards,
Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs