Hi Daniel, Le jeu. 28 oct. 2021 à 16:01, Daniel Thompson <daniel.thomp...@linaro.org> a écrit :
> On Tue, Oct 26, 2021 at 08:21:22AM +0200, François Ozog wrote: > > 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? > > Without discussing laws, contacts or licenses? No. > I’d like to split the discussion in two and keep this thread on characterization when firmware comes with binary components. The licensing aspects of an assembly of TFA and U-Boot and OP-TEE is a separate matter on which the characterization can build on. Could you open a new thread to discuss those matters ? > > To be honest I think it is still a "no" even if we were to carefully > step into such discussions. A checklist, by its nature, does not easily > accept that laws, licenses and contracts do not cleanly divide the world > into two halves. There are always a blurred edge. > > > > 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? > > It might be possible to make checklists based on commonly used terms > from the licenses. Essentially try to match the blurred edges of > licensing to the blurred edges in the checklist itself. > > Things like: > > 1. Does the product contain any code whose license requires you > to make available the complete corresponding source code (CCSC) > for that component? > > 2. [If #1 is YES] Have you provided the complete corresponding > source code for all components whose licence requires it? > > Note however that the above list contains some subtle errors! The OSF checklist is the result of a few years of technical study and lawyers work. So I guess there may be more thought process needed. > > Specifically it does not properly cover cases where both Heinrich and I > agreed that the GPL would require the release of the CCSC for a > *different* component. > > Overall it is not entirely clear that such a list can be useful. These > bear traps are why I suspect "no" is the answer here. Anyone using the > checklist would be better advised to discuss facts for their software > with their lawyers! > > > Daniel. > -- 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
