Hi Tom
Le lun. 25 oct. 2021 à 18:59, Tom Rini <tr...@konsulko.com> a écrit : > On Mon, Oct 25, 2021 at 05:41:44PM +0100, Daniel Thompson wrote: > > 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). > > So, this might be an unpopular opinion here, but perhaps the Canonical > or Linaro lawyers could chime in with some non-binding thoughts? > Engineers arguing about the law tends to not be productive. i agree. From my standpoint, there are products on the market that assemble firmware components such as TF-A , U-Boot and OP-TEE in various ways : so lawyers have done their job and it is possible. My question is: can we further characterize the distributed firmware with regards to parameters described in the checklist? If there are binary components in the mix, how much a platform owner (in the checklist sense) can rebuild the open source portion, include the binaries and redistribute the result? > > > -- > Tom > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
