On Mon, Oct 25, 2021 at 03:59:49PM +0200, Heinrich Schuchardt wrote: > 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.
This is very much an example of "each case turns on its own facts". PSCI is a generic protocol. It is based on traps. Its primary purpose is to decouple components that run at different trust levels. TF-A is not the only implementation. U-boot is not the only client. Such facts make it unlikely that TF-A would become a derived work of u-boot simply because u-boot gets PSCI services from TF-A. To be clear I agree there are definitely circumstances that could lead an OP-TEE TA, OP-TEE itself or TF-A being combined with u-boot (rather than aggregated alongside). A OP-TEE TA to assist with variable storage could certainly reach this level, especially if it's interfaces were specifically designed to match the u-boot driver model (although this still may not impact TF-A). Daniel. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
