I agree, Steve.
Third party assertions about license info should not be considered authoritative by a relying party, however the producer declaration should be considered authoritative. 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: Steve Winslow <[email protected]> Sent: Friday, June 16, 2023 10:38 AM To: [email protected] Cc: SPDX Technical Mailing List <[email protected]>; SPDX-legal <[email protected]>; David Kemp <[email protected]> Subject: Re: [spdx-tech] SPDX special meeting on Properties vs Relationships Thanks Dick. I agree, when a licensor is filling in the declaredLicense (or the concludedLicense) for their own software, there shouldn’t be any ambiguity. The differences are more likely to occur when someone is creating an SBOM for another licensor’s software. In that case, I believe either declaredLicense or concludedLicense could have different values applied by different people / tools. Best, Steve On Jun 16, 2023, at 9:56 AM, Dick Brooks <[email protected] <mailto:[email protected]> > wrote: Steve, Thanks for sharing your insights. REA creates an SBOM for our SAG-PM product, in which we declare the license that is in effect for the product. There is no ambiguity in this regard. I think your view may be based on an analysis performed to “conclude” the license for a software product, but this is not the case in REA’s case as the producer of SAG-PM, we are declaring the license that is in effect in our SBOM for SAG-PM. Thanks, Dick Brooks <image001.png> <image005.png> 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: Steve Winslow <[email protected] <mailto:[email protected]> > Sent: Friday, June 16, 2023 9:49 AM To: SPDX Technical Mailing List <[email protected] <mailto:[email protected]> >; SPDX-legal <[email protected] <mailto:[email protected]> > Cc: David Kemp <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: Re: [spdx-tech] SPDX special meeting on Properties vs Relationships (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 On Jun 16, 2023, at 8:57 AM, Dick Brooks <[email protected] <mailto:[email protected]> > wrote: I concur with David. A license is in effect a “terms of use” contract which an end user agrees to. The SPDX SBOM need to be very clear on the license that is in effect for the software. But, I too am not a lawyer and defer to the legal experts on this point. Thanks, Dick Brooks <image001.png> <image004.png> 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] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of David Kemp Sent: Friday, June 16, 2023 8:24 AM To: [email protected] <mailto:[email protected]> Subject: Re: [spdx-tech] SPDX special meeting on Properties vs Relationships Although it's a technical question, the preferred approach should be driven by the legal use case. * Security classification is an inherent part of a document, and changing it means making a different document. * Annotations can be added to things after the fact, and anyone can chime in without changing the artifact. So if the legal team thinks declared and/or concluded licenses are intrinsic to the meaning of the artifact, like classification, they are properties. If different people can have different opinions about those licenses or the opinions could change over time, they are relationships. I don't have a dog in this or an opinion on which better reflects the legal status of those licenses, but the technical approach should reflect policy. David. On Wed, Jun 14, 2023 at 4:20 AM Alexios Zavras <[email protected] <mailto:[email protected]> > wrote: Hi all, During the tech call yesterday, we decided we should have an extra meeting to advance on the topic of modeling the licensing info. The three questions that will drive the discussion are: 1. Do we prefer declaredLicense to be a property or a relationship? 2. Do we prefer concludedLicense to be a property or a relationship? 3. Do we prefer both of the above to be of the same type? I think it was made clear that any answer is possible and we can make things work. This is about how strong our preferences are and reaching compromises... I've put the names of people who expressed interest in participating explicitly (and I don't have David Edelsohn's email), but everyone is welcome to join! In order to determine whether we can find a suitable timeslot this week, I created an online poll: please, if you want to attend, mark your preferences at https://dud-poll.inf.tu-dresden.de/spdx-prop-rels/. All times are in UTC! I'll leave the poll open for 24 hours or so. -- zvr Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de/> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5185): https://lists.spdx.org/g/Spdx-tech/message/5185 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]] -=-=-=-=-=-=-=-=-=-=-=-
