On 10/25/21 15:32, Daniel Thompson wrote:
On Mon, Oct 25, 2021 at 01:51:34PM +0200, Heinrich Schuchardt wrote:
On 10/25/21 12:43, François Ozog wrote:
Hi
back in April we had a workshop on firmware sustainability. Since then a number of discussions related concerns on closed source components in TF-A and U-Boot communities. We are also approaching a technical maturity level
U-Boot is licenced under GPL. You must not include any code which is not licensed under GPL or a compatible license (cf. https://www.gnu.org/licenses/license-list.html) into U-Boot. This disqualifies any closed source component but also open source which is not GPL compatible like OpenSSL.
The BSD-3 license of TF-A is compatible with GPL.
For closed source TF-A components distributed with U-Boot the following GPL exception *MIGHT* apply in some cases:
"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
The GNU GPLv2 "mere aggregation" language must also be mentioned when looking at the license effects here.
If TF-A and u-boot were merely aggregated together on the same storage media then the license of one would not influence the licensing of the other.
I am doubtful that one component being responsible for copying the other into memory would change this.
Think of U-Boot's UEFI variables managed by an OP-TEE module (Standalone MM), or U-Boot (or Linux) invoking PSCI. These are not cases of mere aggregation but come close to the operating system case. But TF-A is not an operating system.
Best regards
Heinrich
Daniel.
If you include TF-A within the U-Boot binary, all included TF-A components must comply to the GPL license. This is typically the case if U-Boot SPL loads BL31.
on SystemReady that it looks timely to revisit this aspect.
Would it be a good move to adopt the Open System Firmware check list https://www.opencompute.org/wiki/Open_System_Firmware/Checklist as part of SystemReady?
SystemReady should require that the firmware complies to the license requirements of its components.
Open sourcing more firmware components increases the trustworthiness of the platform.
Reading the Open System Firmware Checklist some requirements remain unclear to me: The boot ROM that is part of the SoC lithography mask is firmware. The checklist requires that firmware can be updated which is obviously impossible for the boot ROM.
We need a list of software components that the requirements shall apply to. Besides TF-A and U-Boot, please, consider if secure zone software like OP-TEE modules and trust zone shall be included into the requirement.
Best regards
Heinrich
*NOTE1: believe SystemReady is at right level as it addresses compliance of platforms. EBBR is a technical recipe to make it work for a particular environment (like SBBR) and so not the best place to deal with redistribution license of binary blobs and other platform owernship aspects.*
*NOTE2/ Adoption could come in different forms: referring to it, crafting a similar one for SystemReady scope, any other smart ways of doing it.*
Cheers
FF
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture