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 3^rd 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-1422934516

"Essentially" 3-Clause BSD really doesn't legally mean anything https://github.com/laurencelundblade/QCBOR/blob/master/README.md?plain=1#L527

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