Just catching up – quite a thread!
Couple of inputs. I was in the discussion when we created the declared and concluded license fields, and the intent was that the declared license was a fact which can be verified by looking at the source whereas the concluded license was something where different analysis (or even different opinions) may lead to different answers. As Steve mentioned in his analysis, different tools may pick up different declared licenses, but I consider that similar to different tools may calculate different checksums for the same file if there is an implementation error – you can always to back to the source and verify and it should be treated as a “fact” for the artifact and something that should not change (if you trust the source of the Element metadata). There are a large number of scenarios where the concluded license would change for the exact same artifact: * A software provider offers a choice of licenses (e.g. commercial or GPL-2.0-or-later; GPL-2.0-only or Apache-2.0), someone in the supply chain makes a decision * There is embedded open source that forces a license onto the package supplier (e.g. copy-left licenses) * The supplier information is not correct – something I actually run into a lot is open source software where all the files have one license and the package metadata says a completely different license Best, Gary From: spdx-t...@lists.spdx.org <spdx-t...@lists.spdx.org> On Behalf Of Dick Brooks Sent: Friday, June 16, 2023 9:35 AM To: 'David Kemp' <dk1...@gmail.com>; 'SPDX Technical Mailing List' <spdx-t...@lists.spdx.org>; 'SPDX-legal' <spdx-legal@lists.spdx.org> Subject: Re: [spdx-tech] SPDX special meeting on Properties vs Relationships 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:d...@reliableenergyanalytics.com> d...@reliableenergyanalytics.com Tel: +1 978-696-1788 From: spdx-t...@lists.spdx.org <mailto:spdx-t...@lists.spdx.org> <spdx-t...@lists.spdx.org <mailto:spdx-t...@lists.spdx.org> > On Behalf Of David Kemp Sent: Friday, June 16, 2023 12:27 PM To: SPDX Technical Mailing List <spdx-t...@lists.spdx.org <mailto:spdx-t...@lists.spdx.org> >; SPDX-legal <spdx-legal@lists.spdx.org <mailto:spdx-legal@lists.spdx.org> > 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 <swins...@gmail.com <mailto:swins...@gmail.com> > 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 (#3420): https://lists.spdx.org/g/Spdx-legal/message/3420 Mute This Topic: https://lists.spdx.org/mt/99527021/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
