3 ms·

oh the lengths they go through to avoid open source in this case the length is about "11–14 minutes" of text

deleted 3y ago
[deleted]
CharlesW 3y ago
Given that this describes a binary deliverable, what about this is anti-open source? Even their examples point to https://spdx.org/licenses/LGPL-2.0.html https://spdx.org/licenses/LGPL-2.0.html.
bee_rider 3y ago
I don’t think SBoM is solved by Open Source necessarily. It makes the problem easier maybe, but it doesn’t really solve it. If you want to use Open Source code in an environment, it is necessary to validate all of the code (or know who validated it), including all the dependencies. The maintainers don’t have any obligation to help you, and it is a tedious job that they might not be interested in (or maybe you are in the policing or defense sectors any the maintainers find your application objectionable).
kube-system 3y ago
Because the topic has nothing to do with software licensing. The SBOM requirements being discussed apply to software of any license type.
- narinxas 3y ago
  open source also applies to hardware designs but where does the software end and the hardware begin anyways?
  - kube-system 3y ago
    > open source also applies to hardware designs 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.
    - narinxas 3y ago
      so let me rephrase my original comment using more text 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)
      - kube-system 3y ago
        I'm honestly having trouble understanding your comment. SBOMs are just a list of dependences. Creating such a list is not a new concept, but it is one that is gaining traction recently. This is useful for people who use software, for example, if they learn that a particular dependency has a vulnerability in it, they can quickly determine if they are affected. 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.
        narinxas 3y ago
        my point has very little to do with process 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!

deleted 3y ago

[deleted]

Given that this describes a binary deliverable, what about this is anti-open source? Even their examples point to https://spdx.org/licenses/LGPL-2.0.html https://spdx.org/licenses/LGPL-2.0.html.

bee_rider 3y ago

I don’t think SBoM is solved by Open Source necessarily. It makes the problem easier maybe, but it doesn’t really solve it. If you want to use Open Source code in an environment, it is necessary to validate all of the code (or know who validated it), including all the dependencies. The maintainers don’t have any obligation to help you, and it is a tedious job that they might not be interested in (or maybe you are in the policing or defense sectors any the maintainers find your application objectionable).

kube-system 3y ago

Because the topic has nothing to do with software licensing. The SBOM requirements being discussed apply to software of any license type.

narinxas 3y ago
open source also applies to hardware designs but where does the software end and the hardware begin anyways?
- kube-system 3y ago
  > open source also applies to hardware designs 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.
  - narinxas 3y ago
    so let me rephrase my original comment using more text 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)
    - kube-system 3y ago
      I'm honestly having trouble understanding your comment. SBOMs are just a list of dependences. Creating such a list is not a new concept, but it is one that is gaining traction recently. This is useful for people who use software, for example, if they learn that a particular dependency has a vulnerability in it, they can quickly determine if they are affected. 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.
      - narinxas 3y ago
        my point has very little to do with process 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!