Differences between the 2.x and 3.0 specification/migration  ## Metadata - Author: [[YouTube]] - Full Title: Differences between the 2.x and 3.0 specification/migration - Category: #articles - Document Note: --- tags: [spdx, software-bill-of-materials, migration] author: Gary O'Neill source: YouTube reference: https://www.youtube.com/watch?v=-_6C8EG0pTA date created: 2024-12-19 15:30 --- # 🏷️ Title: Differences between the 2.x and 3.0 specification/migration ## 🧰 Action Inbox - [H1] Review migration document for 2.3 to 3.0 specific recommendations — Google Docs format #migration - [H2] Consider profile requirements when implementing SPDX 3.0 — core and software profiles mandatory #profiles - [H3] Update tooling to handle relationships as independent elements — structural change impact #tooling ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [SPDX Migration Document](https://docs.google.com/document/d/1migration) - [SPDX 3.0 GitHub Repository](https://github.com/spdx) ## 📝 Summary - Gary O'Neill presents the structural and detailed changes from SPDX 2.3 to 3.0, focusing on migration impacts - Major structural changes include profiles for simplification, independent relationships for flexibility, and external reference restructuring - New use cases drive additional complexity while simplification efforts attempt to reduce overall burden - Migration requires significant tooling updates due to fundamental model changes - Key goal is supporting larger, more scalable implementations while maintaining backward compatibility concepts ## 📖 Main Content SPDX 3.0 represents a significant evolution from 2.3, driven by three primary motivations: supporting additional use cases (security, AI, build information), simplifying the specification through profiles, and improving flexibility for scalable implementations. The most impactful structural change involves moving relationships from element properties to independent elements. In SPDX 2.3, once an element is "minted" (delivered), it cannot be changed. This meant adding new relationships required creating entirely new elements with duplicate information. SPDX 3.0's independent relationships allow new connections between existing elements without modification. Profiles introduce both conformance requirements and organizational structure. Each profile defines minimum fields needed for specific use cases (security requires version information, licensing requires declared licenses). This addresses the primary user complaint that SPDX appears overly complex by allowing users to focus on relevant subsets. External document references are restructured into two classes: imports (providing verification information) and namespace maps (enabling shorthand references). This separation improves both readability and verifiability while maintaining existing functionality. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=0) — [H1] Introduction and Speaker Background - Key idea: Gary O'Neill represents the 2.3 user community perspective on 3.0 compatibility - Evidence: "I'm usually known as The Tool Guy... one role that I play in spdx 3.0 is represent the community that is using spdx 2.3" #### ⏱️ [00:02:15](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=135) — [H2] Three Primary Drivers for Changes - Key idea: Additional use cases, simplification, and flexibility motivate SPDX 3.0 changes - Evidence: "Why are the changes... additional use cases... to simplify... flexibility" #### ⏱️ [00:03:45](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=225) — [H3] Flexibility Example - Git Commit SBOMs - Key idea: Current document-level requirements prevent efficient incremental updates - Evidence: "I'm going to produce an s-bomb on every git commit... how can I do that if I have to reproduce every single element" #### ⏱️ [00:05:20](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=320) — [H1] Profiles Structure and Purpose - Key idea: Profiles serve three functions: conformance requirements, namespaces, and organizational structure - Evidence: "Profiles is introduced really for Simplicity... conformance requirements... namespace... organization" #### ⏱️ [00:07:10](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=430) — [H2] External Document References Restructuring - Key idea: Split functionality into imports (verification) and namespace maps (readability) - Evidence: "We separated out into two different classes the functionality that makes it more readable and the functionality that makes it verifiable" #### ⏱️ [00:08:30](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=510) — [H1] Relationships as Independent Elements - Key idea: Moving relationships from properties to elements enables post-creation modifications - Evidence: "Once you create an element it's done... we moved the relationship out to be its own element" #### ⏱️ [00:11:15](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=675) — [H3] Entity Restructuring - Key idea: String-based person/tool fields become structured entities with naming authorities - Evidence: "We have a string field for person tool... we're making it much more structured in 3.0" #### ⏱️ [00:12:45](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=765) — [H2] File Type Changes - Key idea: File type enumeration replaced by media type and software purpose fields - Evidence: "File type enumerations has been replaced by two Fields... media type... software purpose" #### ⏱️ [00:14:20](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=860) — [H2] Package URL Elevation - Key idea: Package URLs promoted from external identifiers to top-level properties - Evidence: "Package URLs... now a top level property so we've elevated it up" #### ⏱️ [00:15:40](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=940) — [H3] Removed Properties - Files Analyzed - Key idea: Most hated property in SPDX 2.3 removed, functionality replaced by profiles - Evidence: "Files analyzed... this is the most hated property in spdx and everybody is happy to get rid of it" #### ⏱️ [00:17:25](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=1045) — [H2] Property Renaming Examples - Key idea: Several properties renamed for clarity and consistency - Evidence: "External document ref that was really confusing... we've changed package file name and file name just a name" #### ⏱️ [00:19:10](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=1150) — [H2] JSON Array Pluralization Simplified - Key idea: JSON arrays will use singular naming for consistency - Evidence: "All of the arrays are pluralized... that's gone we're just going to use singular" #### ⏱️ [00:20:30](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=1230) — [H3] New Classes for Use Cases - Key idea: Extensive new classes added for AI, security, and build profiles - Evidence: "Whole bunch of classes and properties added... to support some of the new use cases and profiles" #### ⏱️ [00:21:50](https://www.youtube.com/watch?v=-_6C8EG0pTA?t=1310) — [H1] Migration Document Reference - Key idea: Living document tracks all migration changes with specific recommendations - Evidence: "There's a document that's kind of a living document that we're recording all of the migrations with very specific recommendations" ## 📚 References - [SPDX 3.0 GitHub Repository](https://github.com/spdx) - [OpenChain Automation Working Group](https://www.openchainproject.org/) - [SPDX Migration Document](https://docs.google.com/document/d/migration) ## 🗣️ Paraphrase - SPDX 3.0 restructures the specification to support more use cases while attempting to simplify through profiles that let users focus on relevant functionality - The most significant change moves relationships from being properties of elements to independent elements, enabling post-creation relationship additions without duplicating data - New structural components like profiles, restructured external references, and elevated package URLs aim to improve scalability and flexibility for larger implementations ## 📰 Newsletter **SPDX 3.0 Migration: What WordPress Developers Need to Know** The SPDX community is preparing a major update that will impact how we handle software bills of materials. SPDX 3.0 introduces "profiles" that let you focus on specific use cases - perfect for WordPress developers who primarily need licensing information without security complexity. Key benefits for WordPress projects: - **Simplified licensing profile** focuses on just the fields you need - **Flexible relationships** allow updating dependency information without recreating entire SBOMs - **Better tooling support** with libraries for multiple languages The migration will require tooling updates, but the community is providing comprehensive migration guides and maintaining compatibility concepts from 2.3. **Resources:** [SPDX GitHub](https://github.com/spdx), [OpenChain Automation](https://www.openchainproject.org/), [WordPress Security](https://wordpress.org/about/security/) ## ✅ Action Items #### OSPO - License Compliance: Review SPDX 3.0 profile requirements for internal tooling compatibility - Software Inventory: Plan migration timeline for existing SBOM generation processes - Developer Support: Prepare training materials on relationship model changes - Policy & Governance: Update SBOM policies to reflect new profile-based requirements #### Community - Maintainers: Evaluate impact of relationship changes on existing SBOM workflows - Contributors: Consider contributing to JavaScript/TypeScript SPDX library development - Sponsors: Budget for tooling migration costs and training initiatives #### WordPress - Core: Assess SPDX 3.0 adoption timeline for WordPress.org infrastructure - Plugins: Prepare guidance for plugin authors on SBOM profile selection - Hosting: Coordinate with hosting partners on SPDX 3.0 migration plans - Security: Leverage new security profile capabilities for vulnerability tracking - Documentation: Create WordPress-specific SPDX 3.0 migration guides ## 🧪 Hypotheses - Profile-based organization will reduce perceived complexity for new SPDX users - Independent relationship elements will enable more scalable SBOM implementations - Structural changes will require significant tooling investment but improve long-term maintainability - Human-readable formats will become less important as UI tooling improves ### 📊 Methodology - Survey existing SPDX 2.3 users on migration concerns and timeline preferences - Analyze tooling ecosystem readiness across different programming languages - Measure complexity reduction through user testing of profile-based workflows ### ❓ Questions - How will the relationship-to-relationship capability affect graph database performance? - What percentage of existing SPDX 2.3 implementations will require significant refactoring? - Will profile-based simplification offset the complexity of new use case support? ### 🔮 Future Research - Develop automated migration tools for common SPDX 2.3 to 3.0 transitions - Study scalability improvements in large enterprise SBOM implementations - Investigate AI-powered SBOM analysis tools leveraging new structured metadata ### 💡 Implications - Practice: Migration requires significant planning and tooling investment for current users - Policy: Organizations need updated SBOM policies reflecting profile-based requirements - Security: Enhanced metadata structure enables more sophisticated vulnerability correlation - Education: Training materials must emphasize conceptual model changes, not just syntax - Funding: Development resources needed for library updates and migration tooling ### 🧠 Learning Styles Assessment Reading level estimate: Grade 14 (College level due to technical specification content) #### 👀 Visual learners - Present: Slide presentation with structural diagrams - Improve: Entity relationship diagrams showing 2.3 vs 3.0 model differences #### 🔊 Aural learners - Present: Live presentation with Q&A interaction - Improve: Recorded podcast-style migration guide #### 🗣️ Verbal learners - Present: Technical terminology with contextual explanations - Improve: Glossary of renamed properties with before/after comparisons #### 🧩 Kinesthetic learners - Present: Migration document with step-by-step recommendations - Improve: Hands-on workshop materials with example transformations #### 🧠 Logical learners - Present: Systematic enumeration of changes by category - Improve: Decision tree for profile selection and migration prioritization #### 🧑‍🤝‍🧑 Social learners - Present: Community meeting format with collaborative Q&A - Improve: Working group participation opportunities for migration planning #### 🧘‍♀️ Solitary learners - Present: Comprehensive reference documentation - Improve: Self-assessment checklist for migration readiness #### 🌿 Naturalistic learners - Present: Evolution metaphor for specification development - Improve: Ecosystem impact analysis of migration across tool chains ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Structured heading hierarchy and clear section organization - Improve: Alternative text for any visual diagrams or slides #### Keyboard navigation - Present: Standard presentation navigation controls - Improve: Ensure any supplementary materials support keyboard-only access #### Contrast and readability - Present: Standard presentation contrast levels - Improve: High contrast versions of technical diagrams #### Text resizing and reflow - Present: Scalable presentation format - Improve: Ensure migration documentation supports text scaling #### Media and captions - Present: Video with audio content - Improve: Accurate captions and transcript with technical terminology #### Forms and interactions - Present: Q&A interaction format - Improve: Accessible forms for migration planning and feedback ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global community participation acknowledged - Improve: Time zone considerations for international collaboration #### Inclusive language - Present: Technical focus with minimal jargon explanation - Improve: Plain language summaries for each major concept #### Neurodiversity support - Present: Structured presentation with clear section breaks - Improve: Executive summary and detailed technical sections separation #### Representation - Present: Community-focused approach with multiple perspectives - Improve: Diverse case studies from different organization types #### Psychological safety - Present: Open Q&A format encouraging questions - Improve: Anonymous feedback mechanisms for migration concerns ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear enumeration of changes with specific examples throughout presentation - Inductive strength: Migration complexity assessment based on past community feedback patterns - Causal reasoning: Use case requirements driving structural changes well-explained - Analogical strength: "Minting" metaphor effectively explains element immutability concept #### Fallacies - Appeal to authority: Minimal - primarily relies on technical requirements rather than authority - False dilemma: None identified - acknowledges tradeoffs and ongoing debates #### Tone of voice - Overall tone: Technical and practical, with community-focused perspective on compatibility concerns ### 🛡️ DARVO Analysis - Deny: No defensive patterns identified - Attack: No attacks on critics or concerns - Reverse victim/offender: Not applicable to technical presentation - Emotional cues and rhetoric: Straightforward technical presentation without manipulation ## 🎯 Conclusion - Document Tags: [[tooling]] [[profiles]] [[migration]] - Summary: Differences between the 2.x and 3.0 specification/migration - URL: https://www.youtube.com/watch?v=-_6C8EG0pTA so um I I kind of missed this morning uh Roundtable introduction so introducing myself some of you know me I've seen a lot of you here is by the way it's great to be back in person with a lot of people we've been on the phone with I'm Gary O'Neill I've been involved with spdx since the beginning with Kate uh I'm usually known as The Tool Guy I wrote some of the initial tools it was supposed to just be a pretty printer but now it's like thousands of lines of code and does all kinds of stuff but I've been involved from the very beginning one role that I play in spdx 3.0 is it's a kind of represent you know the the the the community that is using spdx 2.3 and think about compatibility so if there's something that just absolutely won't work in 3.0 I'll raise a huge red flag if there's something that makes it hard I'll kind of raise a yellow flag so um so with that as kind of the perspective I'm going to go through a comparison of 2.3 to 3.0 from a migration perspective so those of you that are new to SPD X I'll apologize in advance this is probably going to sound a bit tedious to you from those of you that are using spdx2.3 today I think you'll find it a bit more interesting but I'll also try to point out some of the more fundamental changes um in the model that are more conceptual uh especially at the beginning so that it'll give you a little bit more of a context for you know what's being changed so to start out um a lot of this was covered already but why are the changes you've seen some of the additional use cases already presented clearly they need additional Fields it also impacts some of the structural changes one of the the next major reason for changes is to simplify the number one feedback we've gotten from the very beginning from the very first survey we've ever sent out on spdx people we ask people you know what's your biggest concern about spdx it's just too complicated and I think I think a lot of that relates to the large number of use cases we support and so if you want to do to you know licensing you know you got these fields if you want to do security you got these fields if you want to have detailed Source information you got these so you look at it in aggregate it looks really really complicated so we made some changes some structural changes that we believe will simplify the specs so that was definitely one of our objective now I will admit at the same time that we've been simplifying we've been making it more complicated because we've been adding more use cases as well so I'm hoping the net effect by all this is it is simpler and it covers more use cases and the last one is flexibility and this this one actually has a fairly substantial impact on the structure of spdx now let me let me give you an example about flexibility today in spdx 2.3 if I want to send spdx information to you I have to include it in an entire document so I got to wrap everything up in one document and send it to you we had one person in in the spdx community saying hey I'm going to produce an s-bomb on every GitHub commit or every git commit I should say every git commit they're going to produce one and it's only going to be these little teeny changes so how in the world can I do that if I have to reproduce every single element every single file you know reproduce everything and then how will these amend relationships that tie it all up that's just crazy so we've made some structural changes to make it a lot more flexible and I think in the end made it a lot more scalable too so one thing you're going to see in spdx 3.0 is much larger implementations of spdx with much larger numbers of elements that I think is is pretty exciting so that's another one of the things so let me let me go over some of the structural changes the first one is profiles which you know there's a good question raised earlier on the profiles profiles is introduced really for Simplicity now profiles can be a little confusing because we're really kind of talking about three different things when we talk about the profiles um the first thing is conformance requirements so if I'm giving you an s-bomb and I'm telling you this s-bomb can be used for security it supports a security profile it better have some of the minimum requirements for security I better be able to correlate it back to a database of vulnerabilities I better be able to have the version information for the packages and these things may or may not be interesting to people who want to use the licensing profile but if I'm using the licensing profile I better have a concluded license I better have a declared license so when we we you can think of these as like conformance points one of our contributors from miter introduced that term to us so these conformance points are part of a profile they're also a name space now what I mean by a namespace is if you look in our git repository each directory has is for the profile and that's going to be a different name space and it just helps us organize it you know we organize the information so that if you're interested in this you can search on that namespace and ignore the stuff you don't want to see and the last thing is actually how we organize you'll see different teams that actually are producing these uh different work groups around the different profiles so that's the that's the way profiles work we are introducing a mandatory uh New Field which tells which profiles you're supporting and at a minimum you would be supporting the core profile and most likely you'll be supporting the software profile but beyond that all the other profiles are really the choice of you as the producer or you as the consumer what you're requiring of your producers another structural change is the external document references so in uh when today in spdx 2.3 this this I know is going to be the most tedious slide I apologize for especially those of you who are not in 2.3 in 2.3 if you want to reference an element that's not in the spdx document we you basically have an external document rep that points outside of that in spdx 3.0 we moved this down into each individual element so it can actually support uh the uh the references externally and we split it into two different classes there's not one class anymore but two one that describes the Imports so basically the Imports will say this is where I got it from this is the package this is a check sum of the spdx document this is you know enough information to know where it came from and the namespace map gives you the information about the shorthand references within the document itself so we separated out into two different classes the functionality that makes it more readable and the functionality that makes it verifiable and but all that functionality is there but it is a structural change and it will impact if you have tooling you'll have to adjust the tooling to the to the new format relationships I I think this is one of the most impactful and I guess there was a question on relationships as well relationships are important to us in the spdx community um for in spdx 2.3 a relationship with a property of the element so when I produce an element and I deliver that to you I tell you what all the related items are the problem with that is that if I want to change that relationship I have to create a new element because once you create an element okay let me go off on a little tangent this is a very important point for sbdx once you create an element it's done once you deliver that element once you ship that element it's we call it minted it's like you've minted it and you cannot change it again because people are relying on that data so that element is minted now I want to add a new relationship oh I got to go you know create a whole new element with all the same information so let me pause there I see a couple looks is that does that make sense yeah that's a very important concept okay so in spdx 3.0 we moved the relationship out to be its own element so instead of it being a property of an element itself it's its own thing so you can now create a new spdx document using the external refs that I was talking about a slide ago and I can point from one element to another so if I want to introduce a new build relationship or if I want to introduce a new security you know information relationship like a a Vex information I can just drop in an element and I don't have to change a thing on the from and the two everything's updated it's very important for the scalability makes sense all right um there's a few other miscellaneous those are the big ones by the way entities which I think we're going to rename to agents I don't know this may get renamed but uh there is a we've restructured right now in spdx 2.3 we have a string field for person tool or whatever it's just a stream right and you can parse it or you know you know deal with that as you wish we're making it much more structured in 3.0 where we've separated out you know you know identities that are entities that have some kind of a uh what's it called the uh the the naming Authority you know so so you can go to an authority and know that's who the person is or maybe it's just a uh uh you know just you know just a name of something or an email that you have but it's much more structured there file type enumerations has been replaced by two Fields so it's a little bit structural we have a media type which is uh basically we're using the uh the standard uh media type strings that are standardized so we've moved completely to that and then the content to the file in enumeration we've moved to uh software purpose for the purpose of the of the file as well so we've separated the purpose from the the media type and we've moved again to a complete standardization so we're not inventing our own uh media types anymore which is kind of nice uh package file name and package checksum have been replaced by a relationship from a package to a file again this improves the flexibility external identifiers we split that into two different things so we actually now have an external identifier which has this kind of naming Authority associated with it and an external reference which doesn't so um so some Fields require an identifier you know for for Providence or security reasons and some fields are okay just having a reference um so we we and some of the use cases require that distinction package URLs any any fans of package URLs here okay one two okay good good it's now a top level property so we've elevated it up from being just one of many external identifiers reference identifiers or references to being a property of every element so it's easy to find and something that you can almost if you want to have like a primary identifier you can use it for that in spdx 3. annotations and relationships or independent uh elements I already talked about relationship annotations are the same way so you can add annotations after the fact and Snippets have been simplified so I won't go into the details on Snippets because quite honestly not that many people use them maybe after Jeff's talk well more people will I hope so but uh we've simplified them um and I'm going to go through some some really more details of the migration uh here's some classes and properties that are removed files analyzed those of you familiar with 2.3 this is the most hated property in spdx and everybody is happy to get rid of it so that's gone it's actually the functionality is replaced by profile so you it's still the functionality is still there it's just covered by profiles rather than through this property the license info and files right now it's removed but there is an issue to bring that back in again but there is a proposal that this is redundant with declared files and is no longer needed and I think there's one that I missed on the properties removed yeah I think those are the those are the main ones um a number of properties got renamed uh some of these I'll be honest with you I pushed back on and wasn't successful so if there's anything up here that gives you a heartburn you know feel free to uh to raise issues the first one I definitely agree with which is external document ref that was really confusing because we have external reference and external document rough they mean two totally different things and uh that's that's caused a lot of confusion we've gotten feedback on that in the spdx2 so that's fixed we've changed package file name and file name just a name uh as part of the model we changed version to package version um and then the with there's a few licensing chain name changes that go with the with addition operator that was presented earlier extracted license info custom license and uh actually I think we changed package purpose back to primary package purposely I put in a request for that yeah so which may be uh maybe a structural change that's there's an open issue right now in spdx 2.3 we have a package purpose um one of the things one of the tooling that I support is a round is a uh translation tool between Cyclone DX and spdx and you need a package purpose to be able to translate a cyclone DX has this thing called the type which we call a purpose and there's only one in Cyclone DX so if I have four of them in spdx and one in cyclo DX which one do I pick so we need a primary package purpose there are some in the community that would like to have additional purposes to be expressed so we may end up with two properties one primary package purpose in one package first that's that's yet to be decided and the last renaming has is specific to Json right now in Json all of the arrays are pluralized so in the model we'll have like you know proper DX and then in the uh Json will say property X's you know to make it plural that's gone we're just going to use singular we're going to simplify it and it's just going to be singular and may read a little odd to some people but we decided it's more important to be consistent within the spdx serializations than to attempt this complex algorithm of making it pluralized there's a whole bunch of classes and properties added I'm not going to go over these because quite honestly these are very related to the prior presentation so I think you got a lot better you know overview of what these things that are being added here but these are all to support some of the uh the new use cases and uh and profiles so um that's that's my detail of it and backing up a little you know from from the big picture um these changes that we're talking about should provide more flexibility especially with the new relationship structure provide better support for scalability I'm hoping the net result is a simpler spdx implementation and as always we're always adding new use cases with the profiles by the way I'm very excited about the AI work that's going on I think that's so cool that we're you know supporting that in the next release and then uh just write this down in your notes uh the now we'll we'll upload these so you can uh you'll be able to copy and paste this there's a there's a document that uh that's kind of a living document that we're recording all of the migrations with very specific recommendations on how to upgrade from 2.3 to 3.0 so the structural changes are in there all the renames and then as we make changes between the release candidate one and release candidate 2 will be updating that document with that so that's what I have and am I the last presenter good thanks for staying awake on the last presentation very simple question yeah why is that final document not marked down why it's still Google looks [Laughter] I don't know that's just what I picked good question we should move it to markdown though I think you're right and and tie it to the release yeah yeah yeah yeah but it's a good point point well taken yeah or getting any thoughts about uh creating Assurance in the s-bombs during the development process have you seen any best practices how people collect that information that goes in desk bomb fields so when you when you say Assurance can you describe a little more what is being assured so the elements you're presenting right it's The Last Mile whoever generated it you just trust him right ah gotcha so yeah there's a few things and and this isn't really unique to spdx3 there there's um there's one one part of that problem we've tackled I think reasonably well actually I'd say there's there's two out of three parts we've tackled and one we've decided not to okay when it comes to Insurance Assurance One is we have creation information in the 2.3 and 3.0 spec that fully uh identifies who created who's responsible for that spdx document in 3.0 the creation information is now tied all the way down to the element so you can have a document and it can you can actually have different creation information for the different elements but you know who created each and every one when they created it in in all of that the second thing that we we did tackle is if you're referencing a an element that's not in your document but is externally there is verification mechanisms to make sure that that document wasn't tampered with so we have verification and checksums and we also have verification checksums and and hashes for the artifacts that are pointed to by or represented by the metadata in the spdx document so you know so if you can actually get a hold of that artifact you can check Summit look to see what the checksum value of the spdx document and that'll so that's all there the one thing we did not tackle is how do I know you know there's no digital signature on the on the s-bomb itself and and that was a conscious decision uh because you know once you get into that you need to have a certification Authority you need to have a whole infrastructure to support that and we thought it would be best left to other standards you know so we'll produce this chunk of bytes right and then we would encourage other standards Community you know Sig store others you know to actually wrap that in a you know some kind of a digital signature standard so I think there's a lot of interest in including that we just don't want to duplicate what other standards have done okay so I have a question for the build profile um is there support for self attestation for a secure build like there's a new um nist requirement that you know people who are selling software the government must self-attest that they have a secure build is their way to do that on the build profile yeah I think there's um so the this ssdf attestation I think that covers a little bit more as well I'll talk to build but um one at least isolated to that part of the build I think we we don't explicitly say it because the format isn't necessarily well at the time writing wasn't even published but I think we could see that as a use case where you could include that as an excellent reference as part of the build element for that particular component yeah in your first slide about structural changes you mentioned conformance uh namespace and organization what is the purpose of organization I didn't catch oh um that's just it's internal to the spdx community it's how we organize ourselves so we have like a a uh a weekly meeting for the core team and then we have like a bi-weekly meeting or every other week so it's just how we organize ourselves I just mentioned it because it's confused you know it's like why are you calling this meeting the profile you know it's it's kind of part of how we organize the noun yeah exactly so I was curious um generally uh and maybe this is a very general question like who uh like our are the consumers of these spdx documents ever considered to be like end users like I'm thinking of of people who are like you know they receive like uh consumer electronics device and like is is that something that that they can review to see like oh well what's in here like what kind of code can I get that sort of thing like is that a kind of an intended use case yeah so um yes it's a short answer you know we do intend for it to be delivered to end users there is a an ongoing debate about the serialization formats and what are the trade-offs between human readability and machine readability uh within the community um but there is one format in 2.3 it'll be interesting to see if it's feasible to support this in 3.0 I think it is is the spreadsheet format so we talk about tag value we talk which is a text format and we talk about Json we talk about all these others but I'll tell you in my job I deliver spdx documents to end users and it's it's in the spreadsheet format because lawyers love spreadsheets so that's how I send out the uh uh you know the the formats so so yes going back to the first presentation from Steve I noticed that one of the operators mentioned in Expressions was a unary or later operator the plus symbol and my understanding was earlier this was deprecated because license IDs are just strings that represent licenses so does this mean there's now a recognition that several licenses in a list are successive revisions of the same license yes Gary I can speak to that if oh go ahead all right I don't know if I'm still on the audio hey you are yes I'm looking around where did that voice come from okay go ahead Steve um yeah so just to respond to that the uh so that plus operator the or later operator so just to be clear that's always been present or at least for years and years has been present what it's meant to signify is that the applicable license is the corresponding license that's specified or any later version of it um as far as spdx is concerned were not like if you look at the spdx license list there's not any sort of syntactic meaning or anything that we're we're defining to say this license is a later version of that other license or anything like that so it's not necessarily like SPX isn't going to isn't in the business of saying this you know this version 2.1 is later than that version 1.3 or kind of other ways of specifying it's more meant to signal to the consumer of the s-bomb that the included license or the declared license says it's this one or any leader version so there's nuances around it particularly when it comes to some of the gnu licenses um due to some of the requests that came from them and the FSF about how to how to communicate uh only or or later in the context of some of the gppl lgpl and so on so it's short version it's complicated but that I guess just to say that plus operator has always been there and so we're just signaling it will continue to make current so um Kate had mentioned that you with 3.0 you might go to ISO to get it certified what are the criteria to make that decision boy um do you want me to try answering that okay yeah I think it's stability of this back you know it's a lot of effort to go through ISO and you know we want to make sure we don't have to go through it too frequently so once it's fully stable um and and we feel like the rate of change has kind of come down on it I think that's when we'll go through ISO Gary we go through the past which means we're in the field and in use and so we go through that path to go into ISO at least that's how we did with the 2-2 spec and we'll probably do the same thing here our challenge is going to be moving from this model version we've got right now to updating our docs will be a nice little challenge for us so it won't be quick I want to go back to one of the question that gentlemen asked about uh human readable format and you mentioned you love spreadsheet is that another way to present because I see there will be a lot of consumer electronics especially in the healthcare sector that may require some visibility into what's in there or especially vulnerabilities before somebody can start using for critical Healthcare needs yeah yeah and I you know we're definitely considering you know Tech can support continuing to support tag value and that's an ongoing like I don't think we've come to a resolution yet on that but it's definitely an ongoing discussion on you know what's and that's kind of like the next step for spdx by the way now that we have the model kind of solid you know still being reviewed you still have an opportunity you know to influence it but uh we're going to start shifting our Focus to the serialization format I'll give you my personal opinion on this um and I know this is gonna invoke a reaction from some of the other spdx community but my personal opinion is I think having like a tag value type of format makes a lot of sense with certain profiles but with some of the other profiles which are very complicated trying to force that into a flat two-dimensional structure is going to be extremely difficult so my opinion is we support it but we limit what profiles we support it for we'll see I don't know yeah uh actually I would say that that is a great opportunity for you know if there are any startup companies out here to actually Implement uis for these because what what's nice about spdx 3.0 is that it's easily encoded into like a database format so there's a schema right there for you to implement and we're working on serializations that you can convert from your database schema so you can make SQL queries get Json and then display that Json in like something written in react.js so these are all things that can be pretty easily implemented and so my my humble opinion about this is that um you will no longer want to look at spreadsheets they'll be there'll be some pretty UI that you would rather like to look at um my question is more on the defect side um I think one of the use cases I'm thinking too is like um I'm scanning for vulnerability but I made troll like usually we throw like a couple scanners at it um and I think in kind of like the decision making it's helpful to know like um kind of looking at the evidence of like which kind of this particular skin came from um would that be encodable today or like how would you a good day yeah yes it is the so you want a way to communicate the scam that picked up the cve yeah I think would that be in the evidence it's increation info yeah yeah Thomas go ahead yeah so there is an optional Fields uh so in sfx 2.0 you have the creation info field where you can say basically which tool created the uh the whole as-bomb there's also that's on every element in sdx Trooper now so optionally you can for every element where you have vulnerability information or you can basically say like this was created by this tool so if you have say and there's also uh relationships so there's multiple ways how we can do this but it is possible to exactly say which ones candidate actually I need to look at the license profile because there I need to do if the book's the same but again only now for the first release these two came together and we need to make sure that both mechanisms will work the same but it's possible to show multiple because again I worked personally on OS review kit or ort and we have multiple security scanners and multiple license scanners basically giving information into the S1 and it was always tricky to tell which one is which and now for especially for security we're introducing a lot of different uh Asians we call them now I always keep the word actor so basically you can exactly say that this tool organization or person uh did a particular thing that's all possible but it's all optional so if you want to you can include it if you don't want to you don't have to I think you could also use like a published by relationship besides the creation info but then you there will be microphones so that will be on the relationship though because the uh the the relationship of vulnerabilities um affected a package affected by vulnerability is encoded within the relationship and not the individual yes but you can this is the weird thing where people really have to get their head around relationships or elements so you can link to relationships you can point with relationships to relationships I know graph databases don't like that so I guess it's it's so I guess that's okay for the new model right that's like yeah but this is the relationships on relationship we moved the relationship to be a uh an element and by doing that relationships are allowed to have relations I had a debate with one of the other community members William it's like nobody's ever going to use relations relationship and then these things come up it's like oh man maybe I'm wrong you know it does make it more complicated though so we we have this discussion in the implementers group and I was tasked to communicate that we're not very happy about that so uh having relationships pointing to other relationships is going to rake a lot of internal representations on existing tools so if we can constrain them not to I mean I know this is this opens a whole kind of works but um just voicing the opinion of that group is it the uh having a um undirected graph is that the issue Cycles in the graph yeah by the way Cycles in the graph are possible in 2.3 right now too so yeah but you can dedup them right you candy dupe them so so uh before opening for other questions like this I would like to know so how many people here are working on spdx tools or as one Tools in general all right like around half a little bit more how many people are new to spdx or to as films okay all right so if it if at any point gets boring or you need more clarification please we've got another question here thanks I've got a question about tooling now the previous talk mentioned a couple of examples of Builds on GitHub actions and some yocto bills and how the the metadata you need to uh to build I guess a build element was was already there for GitHub actions um but what's the state of tooling for actually getting that data out into a usable form is it still all custom work that has to be done in all cases or are some of the cases like yocto and GitHub actions there's tools out there that do the heavy lifting for you already yeah I think that um in terms of like tooling implementing some of this I think on the high level like the inputs and the things that all captured there definitely will be some fields that need a little bit more instrumentation or like a little bit more intention on the tooling to do another platform with this is um with regards to you know other standards like salsa they are kind of also being pursued I think the idea that we looked at in this group is are you looking at Salsa and reproducible builds there's a lot of information already out there if any build tools do produce those kind of documents we would then be able to do a direct translation to the build profile as well so I I think that in general there is a good amount of information that is captured by build tools which meet some use use cases but not in some so I think in general most of the use cases can be met with information available today if you're looking at like safety then it may require a little bit more instrumentation like you know you have a p Trace to make sure that you're capturing every single command that you're writing um but yeah I think that's that's a decent approach to that and so one of the things with PDX documents so we have it for python go and drop Java yeah and so these libraries if you hook into them with two three today we'll be making sure that they're available for 3-0 so if you wanted to abstract and minimize your burden back and forth and be able to consume I'd say hook into these libraries that we're working and putting out as part of the community and that should give you an accelerator in addition to what's happening in yakuto I'll also mention it in Zephyr we've been doing the generation directly out of the build and so the information is there every time you build an image you can have the effectively ERS bombs multiple s-bombs that relate to each other created and so I can point you in a dashboard that has over 400 boards across six apps after this it's already there and you can just anything that says built or past you can download the yes bombs as part of the images so it's it's eminently doable the Octo is also showing that you can do it with your tool chains because you have to basically you build your tool chain that then goes and builds the images the libraries and so forth that then assembles it so what we're going to need for safety you can see elements of it being happening already today and I think with the three I will be able to take it even further yeah so just to add to what Kate said in 2.3 today you know github's producing spdx uh Zephyr uh yakto we have a maven plug-in we've just introduced a uh what is it the uh help me out Brandon the maven and Gradle we got a Gradle plug-in that produces so those particular build environments are are covered with tools that are available today and uh you know many more and if any of you are in a particular tooling ecosystem and want to contribute we'd love for you to contribute open source in this area just talk to me and we could look at bringing it in by the way Kate mentioned libraries anybody use JavaScript or typescript okay any interest in producing a library for us that's next on my list you know so feel free to contribute uh Gary maybe to ads we're missing one more thing what's that can you hear me Gary yep we can hear you go ahead okay so uh also what I did for 3.0 so there is again for me right now in the time of any as well where lots of tools produce Aspen but a lot of information is incorrect or missing and that's partially due to the the build tools itself not giving you all the information or the information is incorrect and we couldn't always translate it so in in 3.0 I added several additional fields that should allow build tools to directly put the raw data that they have directly as external references on the uh on the on the package level and then other tools can then process that because a lot of the metadata people familiar with open Supply is the metadata practice is wrong and the burden was always if you want to get package the idea is always with SPX we go Upstream to the package managers and the factory managers who directly produce s-bombs but sometimes even the packaging managers they cannot correct all the data for instance a misspelled get up URL right so what do you want in order to 2.0 if you want to translate that to a download location if you would the tool would get stuck and then basically yeah it wouldn't translate properly now in 3.0 the tool could still output it as a reference link even if that link is broken and then a further to the tool chain can then basically work and process it because like working on clearly find errors I can tell you that about 40 of all metadata for all the major ecosystems is broken in one form of another and sometimes slightly broken sometimes really broken a lot broken yeah and so that that's why I said in uh that's why I order New York we have this whole creation mechanism where you can fix it but said if all goes well for spdx 3.0 will Implement boards and there will be a getup action and a GitHub Pipeline and we'll support we are supporting 20 plus different package managers out of the box that will generate SPX 3.0 for 20 different package manages and one goal uh hopefully a little bit luck at lunch after you go it depends how long we take yeah and you know on the broader topic of you know going Beyond just the build there there is a uh uh there's an open chain tooling work group um and if you're not familiar with that that's a good forum to join and uh discuss Tooling in general including ort or the uh ort that uh Thomas is working on plus a few other scanning tools that are open source in nature and of course there's a lot of commercial tools out there too that I'm sure you're familiar with that that actually will do the analysis and generate s-bombs so lots of tooling out there more needed uh Gary the group is now renamed it's open chain automation working group renaming things on me okay open chain automation working group the name the name the current name of the group yes thanks Thomas I may go back to my previous comments about defects exposure in s-bomb from a user perspective that's very time consuming especially with the CI CD deployment where you will not have time to look at all the defects whether or not to accept the software and deploy so having defects somewhere in the s-bomb that's machine readable and you can have if AI is supporting do the impact analysis you could have machine making the decision for Green Field deployments good point I don't know if the current that you want to do I'm just curious I mean I am new uh to some of these tools as any of the tool makers do using AI powered tools to to take some of the data no because I can see with vulnerabilities this would be a huge opportunity to build a tool uh yes or no so in the opportunity automation group we had discussions on this and for it's two parts if you look at licensing using AI is not really useful um because in licensing actually we're looking for the opposite so we're not looking for like the Apache license we can find a million examples of Apache license and detect it properly but you're looking for the anomalies and there have been several experiments looking for those Anonymous with AI it didn't really work coming to security it's interesting yes you can Powers basically CES and all the broken information to get better metadata but the problem is still and if you're familiar with security and you look at the security data providers the information that you get is generally terrible um to the point that I was looking today whether I could figure out for like even a lot of the permission or if the GitHub repository was mentioned for the project it's not there it's all not properly structured it's all not so yes there is still a lot of work to be done but that's why you now also see like things like osv and all of the others coming in basically doing an open source version of the security feeds to basically work on getting that data better because it's I'm sorry to say a lot of the data that we get from the commercial tools is useful but not perfect it's running AI on it would really be tricky and we have done experiments with it it's terrible yeah we run into two issues with you know automating security one is correlation you know we get information about an s-bomb and correlating that to a database isn't perfect we don't have a good ID structure in spdx external refs is the secret to that put as many external refs as you can find if you've got the software ID put that in if you got what used to be called git bomb which is now called something new um put that in you know uh certainly pearls package URLs or the or the the favorite ones download locations can be used put them all in because as Thomas mentioned you know the the metadata is not perfect it doesn't correlate maybe if the Pearl's wrong but the Swit is right you know you can correlate and you can find the information there the other problem we run into is stale data so somebody I mean I ran into this all the time as you know as Thomas just mentioned uh you go to the GitHub you know uh home page and somebody moved it or renamed it or something so the url's all messed up so uh stale data is also an issue because the s-bombs are produced at one point in time but you may be looking for the information based on that fsbomb at a much later point in time and lots of things can change on the internet so we were talking a bit about tooling and I think it was mentioned that for example in in Zephyr there's some some tooling that created um these spdx documents automatically and I was I was just wondering if there's um like thinking in terms of license compliance like I know we've got the the license profile and we also have the build profile and and a lot of uh licenses especially the copyleft ones uh require build uh and well and installation information and so I'm just wondering if there's a way to or if it's been considered to have it either required or or at least highly suggested when using certain licenses where where these requirements are known to exist to also have a build profile to go along with it to assist people in in complying with these terms of the license because I I think that's a common area where at least in my research that that there's often often some something lacking okay I could go for it Steve did that sorry he wrote sorry okay sorry I can speak to that and then you feel free to jump into um yeah I think definitely I think one of the ways that I understand spdx kind of from the early days has talked about license compliance um has been the idea that an spdx document or an SPD s-bomb is helpful it's useful for compliance but it itself is not meant to kind of represent or consist compliance part of the idea being that spdx as a project is kind of studiously trying not to make legal decisions or legal opinions or say this is what you should do or should not do to comply with this or that license we represent instead focusing on representing metadata trying to enable other folks to you know kind of being the Upstream for representing the metadata but let other organizations other folks provide recommendations about how to use it how to use SPX data to comply with licenses so I think some of what's there some of how we think about structuring licenses structuring the other metadata is definitely informed by what the general requirements are for the licenses so in the particularly in things like some of the relationships that have been previously defined for spdx23 and earlier there are different relationship types in there having to do with the different ways that uh files or packages can be linked to one another the different ways that one can be a distribution artifact or metadata about or various other things so it's kind of I think the concept From spdx's perspective of being this is information that is helpful for and can inform your decisions on compliance but then leaving it to the downstream users or other organizations to you know provide their own recommendations about how to do compliance based on that Kate sorry I didn't mean to jump in there so I'll let you know I'm going to carry it on all good it's all good Steve so the other side of it is as long as people use the spdx identifiers a lot of the tools are able to pull the licensing information out and surface it in the metadata if not it takes scanners and other tools and things like that to guess but if we've got the IDS in both in the Zephyr project in the Octo project they're pulling it out and making it visible and available now to Steve's point we're trying to make it available invisible we're not trying to be a policy engine there are other organizations I'm thinking in particular I think oh saddle and a few others in Europe that want to consume the spdx and issue recommended for policy and so that's probably where like again it's separation of responsibilities and we're focusing on trying to get the data as accurate as we can and move it forward and then other people will say okay hey oh you're looking at this GPL uh you should be doing this this and this oh you've got Apache do this this and this and so there was you know I think um jelane put some stuff out about that and others have put up recommendations but um automatically applying it and so forth we are saying that is not our space that's someone else to do it okay we just want to make sure that the information is available so it's easier to automate this type of thing for sure yeah I appreciate that it's it's good to know where the kind of the recommendations should come in versus just the data right one more thank you uh I have a request to a serialization group uh I barely appreciate if you you could share the working draft for the Json schema or Json context because Japanese are difficult to attend the Lego meeting so and because of the time zone so I we are catch up with by emails or some minutes but I mean it's uh sometimes located at the GitHub sometimes located at in isabad and so so sometimes in an email yes so it's very difficult to catch up with so I appreciate it if you shared on some certain place such as GitHub and so yeah yeah so um yeah the serialization you know as I mentioned that's going to be our next focus and I I think that's a very reasonable request um the serialization group actually meets at a time that I can't attend either so I'm in the same position as you but I will pass along that request and we are going to have a a special meeting just on serialization shortly after this meeting and uh between Kate and I will bring that request in that we document the schema yeah and the other thing that's going to happen with the spdx GitHub repo the model repo it'll actually generate a schema so when we check in a new uh changes to the markdown files it'll it'll regenerate the Json schema so it'll be current that that tooling isn't working quite yet but it should be working within a month or so much I think that's all okay all right thank you thank you [Applause], Differences between the 2.x and 3.0 specification/migration, YouTube, 01ka7p199pyq9hs8f57z0m7501.