New people, new ideas - new friends from GTC Law
|
Shane Coughlan <coughlan@...>
Dear all
I would like to introduce you to Leon and Tony from GTC Law in the US. They have some interesting ideas about how Software Bills of Materials may be leveraged to provide greater insight into supplier activities around compliance (i.e., beyond listing components). Regards Shane -- Shane Coughlan General Manager, OpenChain e: coughlan@... p: +81 (0) 80 4035 8083 w: www.openchainproject.org Schedule a call: https://calendly.com/shanecoughlan |
|
|
|
Dave Marr
Hi Leon and Tony, a warm welcome and it was good to have met you in Boston earlier this month. Looking forward to your ideas on BoMs.
toggle quoted message
Show quoted text
Best, Dave -----Original Message-----
From: openchain-bounces@... <openchain-bounces@...> On Behalf Of Shane Coughlan Sent: Monday, September 30, 2019 4:34 PM To: openchain@... Subject: [OpenChain] New people, new ideas - new friends from GTC Law ------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. ------------------------------------------------------------------------- Dear all I would like to introduce you to Leon and Tony from GTC Law in the US. They have some interesting ideas about how Software Bills of Materials may be leveraged to provide greater insight into supplier activities around compliance (i.e., beyond listing components). Regards Shane -- Shane Coughlan General Manager, OpenChain e: coughlan@... p: +81 (0) 80 4035 8083 w: www.openchainproject.org Schedule a call: https://calendly.com/shanecoughlan _______________________________________________ OpenChain mailing list OpenChain@... https://lists.linuxfoundation.org/mailman/listinfo/openchain |
|
|
|
Leon Schwartz
Hi everyone,
toggle quoted message
Show quoted text
First of all -- thanks to Shane and Dave for the warm welcome! Tony and I had a chance to catch Dave's presentation on openchain and were immediately intrigued by the concept. We do a lot of work with clients of various sizes to review their use of open source and put in place compliance policies and processes and openchain has the potential to tremendously reduce the amount of duplication of work in this area! We look forward to getting to know more about the project and helping it grow in any way that we can. Because we deal with lots of different clients who all have different risk profiles, one thing that we thought might be helpful is to include the usage information from Section 3.2 of the latest spec (perhaps supplemented by also capturing whether the component is hosted) in the bill of materials. This way, someone performing a review downstream could quickly get comfortable that the supplier is openchain-certified and then double-check that the supplier's risk-tolerance is not higher (or lower) than the downstream recipients' by reviewing the bill of materials with usage information in it. 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. We'd love to know what people think about this idea! Thanks, Leon Leon Schwartz GTC Law Group PC & Affiliates One University Ave., Ste. 302B Westwood, MA, 02090 Phone: 617.206.3357 Fax: 617.507.6127 Email: lschwartz@... www.gtclawgroup.com * Admitted only in Massachusetts. __________________________________________________ Confidentiality This email and its attachments may contain legally privileged and/or confidential information. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email and its attachments is strictly prohibited. If you receive this email in error, please immediately notify me at 617.206.3357 and permanently delete both the original and any copies thereof. -----Original Message-----
From: openchain-bounces@... <openchain-bounces@...> On Behalf Of David Marr Sent: Monday, September 30, 2019 7:38 PM To: Shane Coughlan <coughlan@...>; openchain@... Subject: Re: [OpenChain] New people, new ideas - new friends from GTC Law Hi Leon and Tony, a warm welcome and it was good to have met you in Boston earlier this month. Looking forward to your ideas on BoMs. Best, Dave -----Original Message----- From: openchain-bounces@... <openchain-bounces@...> On Behalf Of Shane Coughlan Sent: Monday, September 30, 2019 4:34 PM To: openchain@... Subject: [OpenChain] New people, new ideas - new friends from GTC Law ------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. ------------------------------------------------------------------------- Dear all I would like to introduce you to Leon and Tony from GTC Law in the US. They have some interesting ideas about how Software Bills of Materials may be leveraged to provide greater insight into supplier activities around compliance (i.e., beyond listing components). Regards Shane -- Shane Coughlan General Manager, OpenChain e: coughlan@... p: +81 (0) 80 4035 8083 w: https://nam01.safelinks.protection.outlook.com/?url=www.openchainproject.org&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Cf5fbea53b7f74e2797f308d745ff51c1%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637054835251821991&sdata=QSMg3tpx0pKmgD8iljxBsQ58YWF5fHUzKDb8DGy%2F41o%3D&reserved=0 Schedule a call: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendly.com%2Fshanecoughlan&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Cf5fbea53b7f74e2797f308d745ff51c1%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637054835251821991&sdata=oNjsR39%2FdhgMw25%2FVdPao5AJjRU2tLDM1UMld6LY7v8%3D&reserved=0 _______________________________________________ OpenChain mailing list OpenChain@... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Cf5fbea53b7f74e2797f308d745ff51c1%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637054835251821991&sdata=yanBUIlmC35ppaiMsSsY7ffMPGliE0f7KGYoWpeWQLs%3D&reserved=0 _______________________________________________ OpenChain mailing list OpenChain@... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Cf5fbea53b7f74e2797f308d745ff51c1%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637054835251821991&sdata=yanBUIlmC35ppaiMsSsY7ffMPGliE0f7KGYoWpeWQLs%3D&reserved=0 |
|
|
|
On Tuesday 1 October 2019 16:37:28 CEST Leon Schwartz wrote:
Since the compliance program must be capable of managingthese use cases, it is likely that the information would already beVery 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@... sip: matija_suklje@... |
|
|
|
Leon Schwartz
Hi Matija,
toggle quoted message
Show quoted text
Thanks for the feedback! I wasn’t as clear as I wanted to be about what we are suggesting: what we are proposing is not including the basis for the decision (as you note, the basis can be quite different for different companies and/or different use cases), but the factual description of the usage for the third party components in your BOM so those who receive the BOM can determine whether these components, used in the way that they are used by you, would be approved under their own policies. Let's slightly change/simplify your example, if you don't mind: Let's say you are using an LGPL-licensed component in your code. If I am downstream from you and receive your product, I would derive some comfort that your use of the LGPL-licensed component was reviewed and is within your open source policy (since you are openchain-certified), but I still don't know whether the use would be acceptable under my policy (as you note, different companies have different risk tolerances and approval metrics). If the BOM for your product (in addition to identifying the LGPL-licensed component and providing the license data) also includes information on how the component is used (e.g. hosted, dynamically linked, not modified) then the downstream recipient can quickly determine if the way you used the package would fit within their policies as well or if you approved the use of something they would not have necessarily approved -- best of all, they can do this without having to reach out to you for any additional information. So, what we're suggesting is including additional factual usage information for each third party component that is part of your BOM that provides the usage information you already collected during your review (to determine whether the component was acceptable under your own policy). We are not suggesting that you provide your reasoning for approval (for all the reasons you mention, and more). Does this make more sense? Thanks, Leon Leon Schwartz GTC Law Group PC & Affiliates One University Ave., Ste. 302B Westwood, MA, 02090 Phone: 617.206.3357 Fax: 617.507.6127 Email: lschwartz@... www.gtclawgroup.com * Admitted only in Massachusetts. __________________________________________________ Confidentiality This email and its attachments may contain legally privileged and/or confidential information. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email and its attachments is strictly prohibited. If you receive this email in error, please immediately notify me at 617.206.3357 and permanently delete both the original and any copies thereof. -----Original Message-----
From: openchain-bounces@... <openchain-bounces@...> On Behalf Of Matija Šuklje Sent: Wednesday, October 2, 2019 9:25 AM To: openchain@... Subject: Re: [OpenChain] New people, new ideas - new friends from GTC Law On Tuesday 1 October 2019 16:37:28 CEST Leon Schwartz wrote: Since the compliance program must be capable of managingthese use cases, it is likely that the information would already beVery 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: https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmatija.suklje.name&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Ca3b799cba489465c9bb508d7473bf66d%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637056195218769071&sdata=aFlPRf9IcWIbzcdF9MxBEf1SMnlXrBIITmDQ5ukVLX8%3D&reserved=0 xmpp: matija.suklje@... sip: matija_suklje@... _______________________________________________ OpenChain mailing list OpenChain@... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Ca3b799cba489465c9bb508d7473bf66d%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637056195218769071&sdata=lRxapWJt3cZir%2B6PvQ%2Ftax3Y61fzpbLFlh9aLLA7xhc%3D&reserved=0 |
|
|
|
Steve Winslow
Hello Leon (and OpenChain community), I've been lurking quietly on this list, but thought I'd weigh in with one piece from the SPDX side that might be relevant here. In the current SPDX spec (version 2.1), in addition to BOM information such as package and file identifiers, license and copyright info, etc., there is also a mechanism to communicate relationships between elements. This is described in Section 7 of the SPDX spec. [1] Relationship fields in SPDX allow you to specify how two different SPDX elements relate to one another. In an SPDX BOM, each element is given a unique identifier, and the Relationship is specified between these two elements in the SPDX tag-value format. For instance, to communicate that one package is a dependency of another one, you could specify something like: Relationship: SPDXRef-requests PREREQUISITE_FOR SPDXRef-mySoftware (assuming of course that you've defined SPDXRef-requests and SPDXRef-mySoftware elsewhere in the BOM...) Take a look at the various relationships in [1]. They include things like DYNAMIC_LINK and STATIC_LINK to communicate dynamic and static linking. So you could use this to communicate, for instance, that a particular file or package is statically or dynamically linked to another file, or to another package. Leon, I'm wondering if this helps solve part or all of the use case you're describing. And if additional Relationships are warranted, I'm sure the SPDX community would be interested in considering them. =) Best, Steve Winslow On Wed, Oct 2, 2019 at 10:25 AM Leon Schwartz <lschwartz@...> wrote: Hi Matija, |
|
|
|
Alexios Zavras
Thanks, Steve, for bringing attention to the Relationships part of SPDX.
The current set of available relationships is the result of a long, open discussion where we tried to imagine every possible use case. Of course, as Steve says, we are always open to extend it and include more relationships that are not yet accommodated.
-- zvr
From: openchain-bounces@... <openchain-bounces@...>
On Behalf Of Steve Winslow
Sent: Wednesday, 2 October, 2019 16:37 To: Leon Schwartz <lschwartz@...> Cc: openchain@... Subject: Re: [OpenChain] New people, new ideas - new friends from GTC Law
Hello Leon (and OpenChain community),
I've been lurking quietly on this list, but thought I'd weigh in with one piece from the SPDX side that might be relevant here.
In the current SPDX spec (version 2.1), in addition to BOM information such as package and file identifiers, license and copyright info, etc., there is also a mechanism to communicate relationships between elements. This is described in Section 7 of the SPDX spec. [1]
Relationship fields in SPDX allow you to specify how two different SPDX elements relate to one another. In an SPDX BOM, each element is given a unique identifier, and the Relationship is specified between these two elements in the SPDX tag-value format. For instance, to communicate that one package is a dependency of another one, you could specify something like:
Relationship: SPDXRef-requests PREREQUISITE_FOR SPDXRef-mySoftware
(assuming of course that you've defined SPDXRef-requests and SPDXRef-mySoftware elsewhere in the BOM...)
Take a look at the various relationships in [1]. They include things like DYNAMIC_LINK and STATIC_LINK to communicate dynamic and static linking. So you could use this to communicate, for instance, that a particular file or package is statically or dynamically linked to another file, or to another package.
Leon, I'm wondering if this helps solve part or all of the use case you're describing. And if additional Relationships are warranted, I'm sure the SPDX community would be interested in considering them. =)
Best, Steve Winslow
On Wed, Oct 2, 2019 at 10:25 AM Leon Schwartz <lschwartz@...> wrote:
Steve Winslow Intel Deutschland GmbH |
|
|
|
On Wednesday 2 October 2019 16:24:55 CEST Leon Schwartz wrote:
[…] Does this make more sense?This does make much more sense, yes. On Wednesday 2 October 2019 16:37:19 CEST Steve Winslow wrote: […] Relationship fields in SPDX allow you to specify how twoI hoped to steer this discussion into this direction, yes. One thing I’m still battling with in my mind is how the Relationship field is populated (e.g. by tools). Doing all of this by hand for a large code base would be horrendous. cheers, Matija Šuklje -- gsm: +386 41 849 552 www: http://matija.suklje.name xmpp: matija.suklje@... sip: matija_suklje@... |
|
|
|
Indira B
On the tooling side most scan tools do have an option to define how something is being used linked shipped etc.
toggle quoted message
Show quoted text
Agreed, it sure can be manually taxing to do this for every open source component found. I’ve usually done this sort of thing during remediation. On Oct 2, 2019, at 11:30 AM, Matija Šuklje <matija@...> wrote:On Wednesday 2 October 2019 16:24:55 CEST Leon Schwartz wrote:This does make much more sense, yes. |
|
|
|
Leon Schwartz
Thanks, everyone for your comments!
toggle quoted message
Show quoted text
Is there a way for the relationship section to be able to indicate whether a particular component is distributed (or hosted) as part of a larger codebase? Something like SPDXRef-A is distributed in binary form as part of SPDXRef-B (where SPDXRef-A is an open-source dependency of SPDXRef-B which is the "proprietary" codebase)? The example I am thinking of is when you have a hosted solution (so the product itself is not distributed), but some of the third party components included in the solution are part of client-side scripts (which can be considered to be distributed). It would be great to be able to identify them within the BOM. As for populating the usage information -- perhaps a way to cut down some of the work would be to only include the usage information that is necessary to assess compliance (e.g. you would not need to include any usage info regarding MIT-licensed components, but for LGPL-licensed components, you would include distribution, hosting, linking, and modification info -- or a dispositive subset thereof -- since they can all play into the decision). Since this is information that is needed as part of the internal review process, it should already be available, right? Thanks, Leon Leon Schwartz GTC Law Group PC & Affiliates One University Ave., Ste. 302B Westwood, MA, 02090 Phone: 617.206.3357 Fax: 617.507.6127 Email: lschwartz@... www.gtclawgroup.com * Admitted only in Massachusetts. __________________________________________________ Confidentiality This email and its attachments may contain legally privileged and/or confidential information. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email and its attachments is strictly prohibited. If you receive this email in error, please immediately notify me at 617.206.3357 and permanently delete both the original and any copies thereof. -----Original Message-----
From: openchain-bounces@... <openchain-bounces@...> On Behalf Of Indira Bhatt Sent: Wednesday, October 2, 2019 3:14 PM To: Matija Šuklje <matija@...> Cc: openchain@... Subject: Re: [OpenChain] New people, new ideas - new friends from GTC Law On the tooling side most scan tools do have an option to define how something is being used linked shipped etc. Agreed, it sure can be manually taxing to do this for every open source component found. I’ve usually done this sort of thing during remediation. On Oct 2, 2019, at 11:30 AM, Matija Šuklje <matija@...> wrote:_______________________________________________On Wednesday 2 October 2019 16:24:55 CEST Leon Schwartz wrote:This does make much more sense, yes. OpenChain mailing list OpenChain@... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Cd9f87b638c5142d7747808d7476cafb0%7C9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637056404496624661&sdata=4rYYW%2B2jq4Kpdg8eKSBB80uhbqBzlIkbL4wohsBKMZE%3D&reserved=0 |
|
|
|
Gary O'Neall
Is there a way for the relationship section to be able to indicate whether aI don't think we considered this use case when we developed the relationships for SPDX version 2.0 (see https://wiki.spdx.org/view/Technical_Team/Use_Cases/2.0 for the list of use cases considered). This would be a very useful thing to add to the spec. IMHO. I added a proposal in the form of a pull request against the spec: https://github.com/spdx/spdx-spec/pull/145 Please feel free to propose different wording/language on the pull request comments or as a pull request against the add-distributed-relationship branch. As for populating the usage information -- perhaps a way to cut down some ofAgree with this approach - this is the approach I have taken with most of my customers when providing audit and analysis work. Gary
|
|
|