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...
"Essentially" 3-Clause BSD really doesn't legally mean anything https://github.com/laurencelundblade/QCBOR/blob/master/README.md?plain=1#L52...
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.
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.
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
Does that mean that the License is acceptable for use in the Trusted-Firmware organization? Does trusted-firmware have any policy on what kind of licenses it’s the dependencies (like TF-M) are allowed to use?
-Joakim
From: Kevin Townsend via TF-M tf-m@lists.trustedfirmware.org Sent: torsdag 9. februar 2023 09:29 To: Andrej Butok andrey.butok@nxp.com Cc: Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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.commailto: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/QCBORhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GyO6OqS2c16FQO92GU7KvuNNi9WMGqFdYxuCn566p84%3D&reserved=0 to make it OSI compliant?
Thanks, Andrej
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, February 8, 2023 6:12 PM To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F54017%23issuecomment-1422934516&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M57sj3mu3pM8Rn3i7EN0Jh0pR6AjWWx2kL4y9WHWB0E%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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR%2Fblob%2Fmaster%2FREADME.md%3Fplain%3D1%23L527&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5w8gaOZE7Ap7smuhbd%2F%2FEcsCXNsl0RdxjTnZG3v6u2w%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 -- Thanks and best regards,
Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Hi Joakim,
The license is acceptable for Trusted Firmware-M with QCBOR being used as an external library.
Please refer Section 9 of the Trusted Firmware Project Charter - https://www.trustedfirmware.org/docs/Trusted_Firmware_Charter_v_2021_07_14.p... 9 c) states that the original license text needs to be used and documented. There is documentation about license here - https://tf-m-user-guide.trustedfirmware.org/introduction/index.html?highligh... but can be improved.
Understand QCBOR license is problematic for Zephyr and needs to be resolved.
HTH, Shebu
From: Andersson, Joakim via TF-M tf-m@lists.trustedfirmware.org Sent: Thursday, February 9, 2023 11:05 AM To: Kevin Townsend (kevin.townsend@linaro.org) kevin.townsend@linaro.org; Andrej Butok andrey.butok@nxp.com Cc: Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Does that mean that the License is acceptable for use in the Trusted-Firmware organization? Does trusted-firmware have any policy on what kind of licenses it’s the dependencies (like TF-M) are allowed to use? -Joakim
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: torsdag 9. februar 2023 09:29 To: Andrej Butok <andrey.butok@nxp.commailto:andrey.butok@nxp.com> Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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.commailto: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/QCBORhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GyO6OqS2c16FQO92GU7KvuNNi9WMGqFdYxuCn566p84%3D&reserved=0 to make it OSI compliant?
Thanks, Andrej
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, February 8, 2023 6:12 PM To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F54017%23issuecomment-1422934516&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M57sj3mu3pM8Rn3i7EN0Jh0pR6AjWWx2kL4y9WHWB0E%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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR%2Fblob%2Fmaster%2FREADME.md%3Fplain%3D1%23L527&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5w8gaOZE7Ap7smuhbd%2F%2FEcsCXNsl0RdxjTnZG3v6u2w%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 -- Thanks and best regards,
Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Hi all,
I think I know what the problem is. I believe it is related to the problem I have reported earlier in mailing thread https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.o... Problem occurs during built of psa_generate_database target. The same was reported by me in the mailing thread. The only difference is that I used Windows. So I have investigated the problem and found the solution, hope it will help you.
Turns out PSA arch tests use native platform compiler (e.g. GCC for windows) to compile some generated files and then these compiled files are used in the rest of the build using compiler for arm platform. <psa-arch-tests>/api-tests/CMakeLists.txt adds External project (ExternalProject_Add()) which generates the device database that is needed for the rest of the build.
As I said psa_generate_database built invokes native compiler, so call to cc1 is not the call to gcc-arm-none-eabi-10.3-2021.10/lib/gcc/arm-none-eabi/10.3.1/cc1, it is a call to linux native cc1 compiler (to compile given .c file to be executed on Linux)
I have installed llvm-mingwhttps://github.com/mstorsjo/llvm-mingw/releases and added its bin folder to PATH and this fixed the problem. I think GCC (or other native compilers) will also work.
Looks like ARM TF-M team has native compiler installed on their working machines so arch tests build works right away.
So my suggestion is to install linuz native cc1 compiler and add it to the PATH
Please let me know if this fixed the problem.
Regards, Bohdan Hunko
Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
From: Shebu Varghese Kuriakose via TF-M tf-m@lists.trustedfirmware.org Sent: 9 February 2023 15:27 To: Andersson, Joakim Joakim.Andersson@nordicsemi.no; Kevin Townsend (kevin.townsend@linaro.org) kevin.townsend@linaro.org; Andrej Butok andrey.butok@nxp.com; tf-m@lists.trustedfirmware.org Cc: Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Joakim,
The license is acceptable for Trusted Firmware-M with QCBOR being used as an external library.
Please refer Section 9 of the Trusted Firmware Project Charter - https://www.trustedfirmware.org/docs/Trusted_Firmware_Charter_v_2021_07_14.p... 9 c) states that the original license text needs to be used and documented. There is documentation about license here - https://tf-m-user-guide.trustedfirmware.org/introduction/index.html?highligh... but can be improved.
Understand QCBOR license is problematic for Zephyr and needs to be resolved.
HTH, Shebu
From: Andersson, Joakim via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, February 9, 2023 11:05 AM To: Kevin Townsend (kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org) <kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org>; Andrej Butok <andrey.butok@nxp.commailto:andrey.butok@nxp.com> Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Does that mean that the License is acceptable for use in the Trusted-Firmware organization? Does trusted-firmware have any policy on what kind of licenses it’s the dependencies (like TF-M) are allowed to use? -Joakim
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: torsdag 9. februar 2023 09:29 To: Andrej Butok <andrey.butok@nxp.commailto:andrey.butok@nxp.com> Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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.commailto: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/QCBORhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GyO6OqS2c16FQO92GU7KvuNNi9WMGqFdYxuCn566p84%3D&reserved=0 to make it OSI compliant?
Thanks, Andrej
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, February 8, 2023 6:12 PM To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F54017%23issuecomment-1422934516&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M57sj3mu3pM8Rn3i7EN0Jh0pR6AjWWx2kL4y9WHWB0E%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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR%2Fblob%2Fmaster%2FREADME.md%3Fplain%3D1%23L527&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5w8gaOZE7Ap7smuhbd%2F%2FEcsCXNsl0RdxjTnZG3v6u2w%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 -- Thanks and best regards,
Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Sorry, wrong thread
Regards, Bohdan Hunko
Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
From: Bohdan.Hunko--- via TF-M tf-m@lists.trustedfirmware.org Sent: 9 February 2023 22:55 To: Shebu.VargheseKuriakose@arm.com; Joakim.Andersson@nordicsemi.no; kevin.townsend@linaro.org; andrey.butok@nxp.com; tf-m@lists.trustedfirmware.org Cc: nd@arm.com Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi all,
I think I know what the problem is. I believe it is related to the problem I have reported earlier in mailing thread https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.o... Problem occurs during built of psa_generate_database target. The same was reported by me in the mailing thread. The only difference is that I used Windows. So I have investigated the problem and found the solution, hope it will help you.
Turns out PSA arch tests use native platform compiler (e.g. GCC for windows) to compile some generated files and then these compiled files are used in the rest of the build using compiler for arm platform. <psa-arch-tests>/api-tests/CMakeLists.txt adds External project (ExternalProject_Add()) which generates the device database that is needed for the rest of the build.
As I said psa_generate_database built invokes native compiler, so call to cc1 is not the call to gcc-arm-none-eabi-10.3-2021.10/lib/gcc/arm-none-eabi/10.3.1/cc1, it is a call to linux native cc1 compiler (to compile given .c file to be executed on Linux)
I have installed llvm-mingwhttps://github.com/mstorsjo/llvm-mingw/releases and added its bin folder to PATH and this fixed the problem. I think GCC (or other native compilers) will also work.
Looks like ARM TF-M team has native compiler installed on their working machines so arch tests build works right away.
So my suggestion is to install linuz native cc1 compiler and add it to the PATH
Please let me know if this fixed the problem.
Regards, Bohdan Hunko
Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com
From: Shebu Varghese Kuriakose via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 9 February 2023 15:27 To: Andersson, Joakim <Joakim.Andersson@nordicsemi.nomailto:Joakim.Andersson@nordicsemi.no>; Kevin Townsend (kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org) <kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org>; Andrej Butok <andrey.butok@nxp.commailto:andrey.butok@nxp.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Joakim,
The license is acceptable for Trusted Firmware-M with QCBOR being used as an external library.
Please refer Section 9 of the Trusted Firmware Project Charter - https://www.trustedfirmware.org/docs/Trusted_Firmware_Charter_v_2021_07_14.p... 9 c) states that the original license text needs to be used and documented. There is documentation about license here - https://tf-m-user-guide.trustedfirmware.org/introduction/index.html?highligh... but can be improved.
Understand QCBOR license is problematic for Zephyr and needs to be resolved.
HTH, Shebu
From: Andersson, Joakim via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Thursday, February 9, 2023 11:05 AM To: Kevin Townsend (kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org) <kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org>; Andrej Butok <andrey.butok@nxp.commailto:andrey.butok@nxp.com> Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Does that mean that the License is acceptable for use in the Trusted-Firmware organization? Does trusted-firmware have any policy on what kind of licenses it’s the dependencies (like TF-M) are allowed to use? -Joakim
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: torsdag 9. februar 2023 09:29 To: Andrej Butok <andrey.butok@nxp.commailto:andrey.butok@nxp.com> Cc: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Re: Non-OSI license issue with QCBOR
Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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.commailto: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/QCBORhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GyO6OqS2c16FQO92GU7KvuNNi9WMGqFdYxuCn566p84%3D&reserved=0 to make it OSI compliant?
Thanks, Andrej
From: Kevin Townsend via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, February 8, 2023 6:12 PM To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F54017%23issuecomment-1422934516&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M57sj3mu3pM8Rn3i7EN0Jh0pR6AjWWx2kL4y9WHWB0E%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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2FQCBOR%2Fblob%2Fmaster%2FREADME.md%3Fplain%3D1%23L527&data=05%7C01%7Cjoakim.andersson%40nordicsemi.no%7C483128b1c59e44574e5908db0a77e549%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C638115282283840850%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5w8gaOZE7Ap7smuhbd%2F%2FEcsCXNsl0RdxjTnZG3v6u2w%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 -- Thanks and best regards,
Kevin Townsend Tech Lead - LITE, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
How frustrating.
Note that permission would also be required from the other copyright holders (including The Linux Foundation) to change the license on the 15 source files that carry the original QCBOR open source license.
This is a tweak to BSD-3-Clause that appears on some open source projects initially published under The Linux Foundation copyright. Not sure what proportion originate from QUIC.
Note that the specific warranty disclaimer (“NON-INFRINGEMENT”) is explicit in Apache-2.0 and MIT licenses, but might be implied in the verbatim OSI BSD-3 license text. In the latter, the two mentioned [non-]warranties are merely listed as examples: “… INCLUDING, BUT NOT LIMITED TO, …”.
As Zephyr actively encourages the use of Apache-2.0. and accepts MIT, might an appeal be productive? On the other hand, one has to wonder why QUIC or The Linux Foundation needed to fiddle with an established OSS license?
* Andrew
From: Andrej Butok via TF-M tf-m@lists.trustedfirmware.org Sent: 09 February 2023 07:53 To: Kevin Townsend (kevin.townsend@linaro.org) kevin.townsend@linaro.org; Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.org Cc: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Non-OSI license issue with QCBOR
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Wednesday, February 8, 2023 6:12 PM To: Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.orgmailto: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
tf-m@lists.trustedfirmware.org
-
Andersson, Joakim -
Andrej Butok -
Andrew Thoelke -
Bohdan.Hunko＠infineon.com -
Kevin Townsend -
Shebu Varghese Kuriakose