Armijn raises a valid concern. We’ve avoided dynamic information in the past, but even with version 1.0 you could argue the “Concluded License” could change over time if new information is available after publication of the SPDX document. We’ve certainly seen project home page links change over time as well.
Since having the end of life information available is useful for a few use cases and the frequency of change should be relatively low, I’m of the opinion we could include this as an optional field. One suggestion is to define the field as the valid information at the time the SPDX document is created. That way, even if one of these fields changes later, the SPDX document still records valid facts. Regards, Gary From: [email protected] <[email protected]> On Behalf Of Kate Stewart Sent: Friday, May 20, 2022 5:41 AM To: SPDX-general <[email protected]> Subject: Re: [spdx] End Of Life Tag in spdx #spdx On Fri, May 20, 2022 at 2:32 AM Steve Kilbane <[email protected] <mailto:[email protected]> > wrote: Armijn said: > Current information inside SPDX documents is largely static […] > This would make SPDX a lot more cumbersome, as not only do the documents need > to be generated, but they also need to be updated all the time to avoid > falling out of sync I have no opinion on end-of-life either way, but wouldn’t the same argument apply to security vulnerabilities? Sort of. Security information is even more likely to change after release, EOL for open source components supported by the community may, but much less frequently. Thinking so far, is that this would start out as an optional field, so that those who do know the information when assembling an SBOM can include it. Example: you are using a product that contains the linux 4.9 kernel. You know from the community (https://kernel.org/category/releases.html) that it will go out of support Jan 2023 (as of today, but this may evolve), so including this information, which could then be queried by a script around then, and then determine next steps, is going to be much more efficient then expecting all consumers of your product to add it manually. Similarly certain distros have expectations of EOL for support from the community (https://wiki.debian.org/LTS). To your point, there may well be a contract with a supplier, with a date that extends this, and in that case there are likely processes already in place to track/monitor/etc. in an organization. However those consuming open source based products are not necessarily tracking the upstream components EOL, and probably should be. Adding this field, as optional, enables more efficiency. Thanks, Kate -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1527): https://lists.spdx.org/g/spdx/message/1527 Mute This Topic: https://lists.spdx.org/mt/90941107/21656 Mute #spdx:https://lists.spdx.org/g/spdx/mutehashtag/spdx Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/spdx/leave/2655439/21656/1698928721/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
