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
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
