I will just slowly start as I will today try to give some kind of brief overview of
SPDX tooling. There's a lot out there and I will try to capture some of that,
especially the stuff that is inside the SPDX org on GitHub. So I'm max, maybe
someone saw me already somewhere, that's my coordinates. Pick me if you have questions.
So let's talk about SPDX tooling. I think the first part that I want to go
through are the tools that are provided in the SPDX org and I think we all call
them tools, but they are all libraries and tools and the first one that we just saw,
a wonderful presentation of are the Java tools and I think they are still the most
complete and most actively developed library for SPDX. Thanks to Gary, really a great job.
And if you are unsure, I think the Java tools are a good starting point. They provide the
possibility to implement or to use them low level to implement usage of SPDX in a Java
JDK-based project or they provide a set of command line tools or tools that allow you to do some
easy tasks like converting between formats and view stuff and generate stuff. So that's always a good
starting point. I will be too fast, so there will be time for questions and I went fast through the
Java tools as we just saw them. The next set of tools are the Python tools. I think they have a
similar structure similar to the Java tools. They are also libraries and CLI tools and so
there's a library part. If you have a Python project that you want to generate SPDX, pass
SPDX, work with SPDX, they have the possibility or you can use them in your project to interact with
SPDX. And similar to Java tools, also the Python tools have the CLI part that provides some common
functionality like verifying and validation and converting of documents and files. Maybe a more
interesting thing related to the Python tools is where are they with adoption of SPDX3 and the
Python tools implement the current state of RC1 of the currently latest release candidate, but that
will soon change and it was implemented by hand, not generated from the model. So it's a good starting
point if you want to try out SPDX3 and try how it behaves and how it looks like. And it has
functionality that if you start with an SPDX2 document, it bumps that to an SPDX3 document. So
if you want to experiment with SPDX3, you could also use that to take an SPDX2 document and
just convert it to SPDX3 and look at how it looks like. It has an implementation of the
JSON-LD civilization so you can also see how the serialized format looks.
And what's next with that? I think the big change that is up on the horizon is to migrate that
manually wrote written model to an automatically generated model like we have seen in Gary's
presentation. We also want to use the shackle as an input and get the model as an output to have,
to don't make errors. The next, a pretty new part of the ecosystem that is provided in this
GitHub org is the TypeScript tools. They are called TypeScript since they are written in TypeScript,
but they actually work also with JavaScript and there's a pretty generic build system
behind that so that it should work in every related ecosystem.
What's different to the previous libraries here is that they are not trying to be the complete
universal tool that can do everything and that can convert in every direction, but instead they are
built with a use case in mind like I want to generate a software build of material of a
dependency tree so they do not yet fully implement SPDX. They do not, they can't pass files. They are
very small in lightweight to generate SPDX documents which is fairly helpful especially in the
JavaScript ecosystem where small libraries are usually preferred and based on that
there are already two plugins implemented. For example, there's a yarn plugin that allows you
with two lines of code to generate a software build of material of a yarn project and that's,
so one line is please install that plugin and the second line is please generate an
S-Bomb and then you have an S-Bomb and the second thing is plugin for rollup. Rollup is
one of these build tools in the JavaScript ecosystem that builds a single JavaScript
file from a lot of files and here we use SPDX to encode which files from the source site went
into the output so that you have traceability on the build process. So that's the second current
plugin that is also on GitHub and just as a side note to mention it also the MPM tool
recently got native support for S-Bomb generation for SPDX and CDX. That's why we didn't bother to
to implement it there but maybe at some point we can get them to use the SPDX library and therefore
they might get SPX free support at some point automatically.
The last big library in the SPDX arc are the tools for Go. They are modular, they have a lot of
the same functionality. I'm not very deep into Go development. There are probably other people
that can answer the questions there but we also have tooling in Go. So that was the first part of
tools from the tool overview. The next thing is there's also SPX free meta tooling. As we heard
in the previous presentation there's a tool that takes the spec and generates machine readable
output that can be used and Joshua wrote something that takes one of these outputs, the shackle,
and already generates Python code from that. So there's already the first building block to
generate code out of the model and it's with templating and it's generic so hopefully it will
be soon expanded with a lot of other programming languages and that might be a very valuable tool
in the future. And there are also other projects as you can imagine. That's a huge list. There's a
page where tools supporting SPDX are listed. I think I copied it rather complete but I think
I missed some of them. If you don't see yourself there, check on that list if you have a tool that
supports SPDX and I think on the page there's also described how you can add yourself to this list.
Maybe. Yeah and that's it. That's tooling and that's questions.
Hi. So I'm working on a project called Z-Hypervisor and it's based on a C and it uses C, YAML,
RST. I want to understand from a new view perspective that how do I make the project
compatible with SPDX B.O overnight? Where do I start and what changes do I need to do?
Okay so you're working on Z-Hypervisor and you want to know how to
generate SPDX for this project and it's a C project.
It's a C-Bus project so there is a hypervisor, there are tools and there are some documents.
I want to know how to generate SPDX. How to make it compatible?
I think that depends a lot on which build systems, what is happening in the build
and how can you trace what's happening. Is it hardcoded somewhere? Is it C-Make or I don't know.
And then you need to look for the right tools that can extract that information
and maybe I think there's for example you could place if they're.
Zephyr has.
I need to repeat that answer. The Zephyr repository contains
user C-Make and can produce SPDX so that might be a good point to look at.
I also say right now it's 2.3 but we will be moving into 3.0.
Right now it's 2.3 but it will be moving to 3.0.
There are a bit different flavors of S-Bombs from just source files all the way to runtime and
how many of the tools are supporting all the different types of S-Bombs.
The question is there are many many different format or different S-Bombs types like runtime,
build and so on and how many tools are supporting the different formats. I think
my good position is that all these libraries are fairly generic. They are what you use in a tool
that would generate a build S-Bombs or would generate a runtime S-Bombs. So it's a tooling
question or usage question but I think it's there are many tools that are doing one or the other
of the formats.