Okay? Neither hardware nor license type has any relevance to an SBOM. On an SBOM, you list all of your software dependencies, regardless of license.
> but where does the software end and the hardware begin anyways?
Hardware is the physically tangible part of the computer. Software is the instructions that run on it. For those compiling an SBOM, I think that's probably an easily answered question.
I see them "bending over backwards" to protect their right to keep an advantage to use, if they deem it necessary, against any one else.
this is why they go to such lengths to avoid publishing what they consider to be "the secret sauce".
as I see things, that they even came up with the notion of a "software bill of materials" is a bit disingenious from my perspective. already the concept is obscure and lends itself (in my opinion) to shading, hiding, and occulting the software source code and (or) the hardware designs (as appropiate)
finally, I consider that the concept of "SBOM" (which TIL existed) is designed with the intentions I already mentioned: to occult information (anti-open) for the sake of keeping a perceived advantage (pro-centralization)
I'll give you an example of what they're intended to be useful for:
Let's say you're an organization and you use, say, 500 different pieces of software made by 100 different companies. If you learn that there's a vulnerability in a particular dependency, what do you do? In the past, there was no standard way that vendors communicated this information, so the answer is that you would go through your list of 500 software programs, and email 100 different vendors asking about each one. This is not a good process.
If, instead, everyone provided an SBOM with their software, all you need to do is run a query against whatever inventory management system you're using and you have the answer in seconds.
it seems to me that you're arguing back that SBOMs are just a list, so how can it be a big deal?
my point is an issue about the whole reality of needing SBOMs. clearly they have something to do with supply chain trust. but I think your perspective is focused too closely on the engineering aspects of the problem.
I find that the technical realities (all of which I understand to be, in the end, some kind of engineering decision) that motivate having to share vulnerabilities of all components without revealing their designs sources (of either software, hardware, both, or neither) to be morally dubious.
so keeping in mind that hardware, by this point, is stored as code so it's code, and software also has a source code, I find it necessary by this point to open source all the things!!1!
the technical problem is really essentially a matter of trust, blockchains solved this problem in the technical sense.
the opreations of large organization are typically private property... this is a touchy issue because technology corporations are essentially the government by this point
I guess I should be glad this isn't really my problem, I'm just worried about the public and political consequences of what I see as potentially dangerous mistakes being made on the idelogical level
The straw that broke the camel's back on this issue was CVE-2021-44228 -- which was a vulnerability in open source software. If you missed that debacle -- the problem wasn't that people distrust Apache or software that use Log4j. The problem was that people didn't know where all it was installed.
This was because it isn't currently a standard for software developers to provide a list of all of their dependencies, regardless of whether they're open source or not. This isn't because they are untrustworthy. It just simply isn't standard practice. SBOMs are an attempt to standardize such a list.
A blockchain isn't necessary here -- nobody is trying to lie about what version of Log4j they're depending on in a piece of software they're selling.
however, thanks to all this dialogue, do see where my own critizicism goes amiss; and for that, thanks a lot.