Re: New people, new ideas - new friends from GTC Law


Matija Šuklje
 

On Tuesday 1 October 2019 16:37:28 CEST Leon Schwartz wrote:
Since the compliance program must be capable of managing
these
use cases, it is likely that the information would already be
collected during the review process, so including it in the
bill of materials would hopefully not be too burdensome as it
would really help downstream reviewers align the risk
tolerances for certain use cases.
Very interesting idea, but I’m not entire sure I follow how/where
the two intersect.

§3.2 (of OpenChain Spec 2.0) is about having a documented
procedure that should accommodate for common use cases, and a
bill of material (e.g. SPDX file) typically includes facts such as
package name and version, files (with hashes), license and
copyright situation, and technical details.

If I understand you correctly, what you propose is to include the
(basis for the) decision _why_ a package was included (or not)
into facts about the package.

Here’s what I mean, based on an imaginary example:

Let’s say I have a package that is (MIT AND LGPL-2.1-or-later AND
Apache-2.0) that I want to use.

Let’s say my (super simple) inbound licensing policy says:
• MIT is always OK
• Apache-2.0 is in general OK, but watch out for details and in
not allowed for stuff where we have a patent that we deem
valuable, also not allowed in projects that are (L)GPL-2.*-only
• LGPL-2.1-or-later is OK for dynamic linking (e.g. in Java), but
as most others I’m just too lazy to deal with how to fulfil its
obligations with static linking

Where should I put this information in then? And how much of it?

Do I store it as a comment to my product’s BoM, the BoM of the
used package, or inside the latter to individual files that are
licensed under individual licenses?

Do I store the (relevant part) of the licensing policy or the
decision?

Do I change it for every use new use case I (dis)approve of and
then need to provide new BoM for the same package of the same
version?

If that is so, I am not entirely sure that is very useful, as it
depends on a case-by-case situation and could murk the waters of
the bill of material’s clarity on the licensing/copyright
situation of a package.

Also, I fear while this additional information might be
interesting for my direct clients, that is where it would stop.
The reusability of the BoM would be very much weakened by this
additional opinion embedded within the fact-based data.

The risk tollerance also depends on the context. For example a
SaaS company has completely different risk factors to take into
account than an embedded company, with a software company
somewhere in the middle. And then there are also (more and more)
companies that do both. E.g. the same package under the same
license(s) could be perfectly fine for SaaS, to be included in
traditionally distributed software, and even embedded in certain
devices, but not in other devices. Or the difference would be
depending on technicality (e.g. programming language) or
combination of other packages that the products depends on.

Please don’t understand this as if I’m trying to dismiss your
idea. I’m merely trying to understand it better. It is a
fascinating proposition, but we need to make sure it holds water.


cheers,
Matija Šuklje
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje@gabbler.org
sip: matija_suklje@ippi.fr

Join main@lists.openchainproject.org to automatically receive all group messages.