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


Gary O'Neall
 

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.
I 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 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?
Agree with this approach - this is the approach I have taken with most of my customers when providing audit and analysis work.

Gary


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:
[…]
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 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.
I 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:
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmatija.su
klje.name&amp;data=02%7C01%7Clschwartz%40gtclawgroup.com%7Cd9f87b6
38c5142d7747808d7476cafb0%7C9941d107cf654f6e882317722f4e981a%7C0%
7C0%7C637056404496624661&amp;sdata=FIwgS4b3D0xjTv5F%2Feh9XkoMq4Vi
12iLdrsTssEWtHY%3D&amp;reserved=0
xmpp: matija.suklje@...
sip: matija_suklje@...



_______________________________________________
OpenChain mailing list
OpenChain@...
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
s.linuxfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&amp;data=02%7C0
1%7Clschwartz%40gtclawgroup.com%7Cd9f87b638c5142d7747808d7476cafb0
%7C9
941d107cf654f6e882317722f4e981a%7C0%7C0%7C637056404496624661&am
p;sdata
=4rYYW%2B2jq4Kpdg8eKSBB80uhbqBzlIkbL4wohsBKMZE%3D&amp;reserved=0
_______________________________________________
OpenChain mailing list
OpenChain@...
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linu
xfoundation.org%2Fmailman%2Flistinfo%2Fopenchain&amp;data=02%7C01%7
Clschwartz%40gtclawgroup.com%7Cd9f87b638c5142d7747808d7476cafb0%7C
9941d107cf654f6e882317722f4e981a%7C0%7C0%7C637056404496624661&a
mp;sdata=4rYYW%2B2jq4Kpdg8eKSBB80uhbqBzlIkbL4wohsBKMZE%3D&amp;res
erved=0
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

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