David,

 

There is no guesswork needed to “know” the terms of use with SAG-PM

 

Gary’s tool and other tools can “know” the license that is in effect for SAG-PM 
by reading the SBOM provided by REA. There is no need to “guess” (conclude) the 
SAG-PM license.

 

Thanks,

 

Dick Brooks

  

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

 

 <https://reliableenergyanalytics.com/products> Never trust software, always 
verify and report! ™

 <http://www.reliableenergyanalytics.com/> 
http://www.reliableenergyanalytics.com

Email:  <mailto:[email protected]> 
[email protected]

Tel: +1 978-696-1788

 

 

From: [email protected] <[email protected]> On Behalf Of David 
Kemp
Sent: Friday, June 16, 2023 12:27 PM
To: SPDX Technical Mailing List <[email protected]>; SPDX-legal 
<[email protected]>
Subject: Re: [spdx-tech] SPDX special meeting on Properties vs Relationships

 

Note that "Steve's tool is confident that package X has license A" allows the 
SPDX Package X element created by Steve to have a license A property.

Gary's tool can create an SPDX Package X element with a license B property.

It's when both Steve and Gary want to re-use the same SPDX Package X element 
created by Dick, but apply different licenses to it, that relationships are 
required.

v/r,
David





On Fri, Jun 16, 2023 at 9:49 AM Steve Winslow <[email protected] 
<mailto:[email protected]> > wrote:

(cc spdx-legal)

 

For what it’s worth, here are a few of my thoughts on this:

 

* concludedLicense [0] is definitely something that different people / tools 
can reach different answers about.

 

* As currently drafted for SPDX 3.0, I believe declaredLicense [1] is also 
something that people / tools can reach different answers about. Although it is 
talking about the license information “actually found in the software,” tooling 
may e.g. find different licenses, or assign different license identifiers to 
them (including custom licenses). I don’t see declaredLicense as something 
intrinsic and globally agreed-upon given the way the field is defined.

 

* Additionally, keep in mind that the “same software” (e.g., the same bytes on 
disk) might be distributed to different users under multiple or differing 
licenses. E.g., a software package might be distributed under an open source 
license, with a separate proprietary license agreement negotiated with a 
specific recipient; or a software package which is under FOSS license A and 
later additionally licensed under FOSS license B, without updating notices 
within the work itself. I think this might not affect declaredLicense, if the 
software’s contents are not modified; but certainly could affect 
concludedLicense.

 

My point with the last item is just to say that I’m not convinced the license 
is something “intrinsic” to the software, in an immutable or inherent sense. 
But at the same time, a software artifact doesn’t have to have (and in my mind, 
shouldn’t be assumed to have) just one single global SPDX ID associated with 
it. Multiple SBOM creators can create different SPDX IDs to talk about the 
“same” piece of software. 

 

I don’t know which way this tilts things in the “properties vs. relationships” 
discussion, given the tech team’s approaches for SPDX 3.0, but just sharing in 
case this is relevant. I’d encourage others from the legal team community to 
weigh in as well if they have different views here.

 

Best,

Steve

 

[0] 
https://github.com/spdx/spdx-3-model/blob/main/model/Software/Properties/concludedLicense.md

[1] 
https://github.com/spdx/spdx-3-model/blob/main/model/Software/Properties/declaredLicense.md

 

 





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5187): https://lists.spdx.org/g/Spdx-tech/message/5187
Mute This Topic: https://lists.spdx.org/mt/99523557/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to