Hi Tom
Le lun. 25 oct. 2021 à 18:59, Tom Rini trini@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
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 trini@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.
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! 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.
Hi Daniel,
Le jeu. 28 oct. 2021 à 16:01, Daniel Thompson daniel.thompson@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 trini@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:
Does the product contain any code whose license requires you to make available the complete corresponding source code (CCSC) for that component?
[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.
boot-architecture@lists.linaro.org
-
Daniel Thompson -
François Ozog