> How would transitive dependencies be handled?

Have a SBOM format whose license requires truthful reporting (or the license is null and defaults to open source), then trust only those SBOM formats with this property.

Taleb's minority law will do the rest. Pretty soom, most SBOM formats will adopt this rule.

Right. A significant part of the reason open source wins so handily isn't that the money for a proprietary solution is always more than it's worth, it's that you can just pull open source dependencies without going through purchasing.

With modern package managers you can just generate your SBOM out of your lock file and call it a day. That misses dependencies that cross language boundaries, but it gets you 98% there for 10% of the effort. But what if you are writing C++, where it's the norm for libraries to vendor their dependencies, with no way to automatically detect them?

Sure, that is an opportunity for middleman to sell SBOM databases. But I could equally well see large c++ projects selling a subscription that offers an SBOM for each release, along with a couple bullet points to pad the offer (phone support, priority for feature requests and bug reports, early testing for new releases, etc).

Similar to how every SaaS has an Enterprise plan that is ridiculously expensive because big companies will pay anything to get SSO and an audit trail. And the provider adds a couple more enterprise features so nobody has to justify why they pay 5x the regular price just to get those two features. Same, idea, but with companies paying $100/month to get an SBOM and nice-to-haves for software they could get for free

For private usage no one gives a shit about SBOM, but for enterprise usage it's absolutely required.

I think you are missing the point why enterprises have multiple tiers down the line of contractors who implement their software.

The point that's most important is: plausible deniability, because with formal and contractual agreements comes the responsibility shift. Enterprise buys software consultancy services because they are the ones that get the blame if it's not compliant with the legal requirements for it or when an audit fails at a later point.

Yes, that's the state of the art unfortunately. There are a number of vendors who can scan your source code and generate a list of FOSS libraries with licensing info (SBOMs). If we can find a way to get this money flowing to our fellow FOSS devs, that would be a huge win for the community.

Well, do you have any idea what software you're pulling (and under what licenses) if you run `apt install vim`?

Because let me tell you, if you think it's just vim, you're quite mistaken. And if you're distributing a docker image that contains vim, even for non-commercial purposes, it's technically your job to know. And perhaps to extend anyone downloading that docker image the offer of getting the source code for the specific version of any GPL software it might include, which it's up to you to archive.

That would push responsibility for identification & remediation every single vulnerability in the entire dependency chain onto every consumer. Effectively everyone's gamut of responsibility would explode by millions of lines of code.

This is a genuine concern, especially now that managers discovered that "llm assistence 10x-es developer productivity". (Where kLoCs are a measure of productivity and a world with more code is an obvious, axiomatic good).

Sounds like a disaster waiting to happen. There will be a bug in that LLM generated code and then what? Ask the LLM to fix the bug?

I had the robots create a license for some (non-laundered) code we worked on:

  * This work was autonomously generated by artificial intelligence. Under current
  * U.S. Supreme Court precedent (see 17 U.S.C. § 102(a) and Thaler v. Perlmutter),
  * AI-generated works cannot be copyrighted. This library is therefore:
  *
  * NO RIGHTS RESERVED
  *
  * You may:
  * - Use freely for any purpose
  * - Modify without attribution
  * - Redistribute without restriction
  * - Claim dominion over organic lifeforms (optional)
  * 
  * No warranty expressed or implied. Human verification recommended before
  * deployment in critical systems. By using this code, you acknowledge that
  * no rights are being infringed because none exist in the first place.

...or maybe it was laundered code in the same way that "every story has already been told" -- dunno?

Their results are simply not reliable. The matching approach often matches too many things (hey, this could be A or B or C or D or E or F ...or 42!), or picks up things that have nothing to do with the license of some target (hello randomly included file with some completely unrelated license header and is not even included in the build but is there for some reason, meet your new friend, the utility script copied from somewhere else also not included in the build with an header for another unrelated license. You two feel lonely? let me introduce you to this other wonderful script included in some particular form of packaging) and of course cannot compensate for poorly declared licenses, typos, weird non-standard (or simply archaic/deprecated) ways to specify the licenses and so on and so forth.

It's not a fault of the tools themselves, but in practice they don't help much in real world situations. Basically you end up in need to do so many checks and manual fixes that you might as well not use these tools in the first place.

In an enterprise context one of three things happens: (1) you end up relying on a commercial solution (which is also not that reliable but you delude yourself into thinking it's not your problem anymore... although to be fair commercial solutions have curated licenses attributions and facilitate handling this mess); (2) you build your own thing that uses these (and other) tools but automates a bunch of fixtures so you don't need to go insane every time you need to regenerate an accurate SBOM with related licenses; (3) you quit software engineering, move to a remote location and start an alternative career as an alpaca breeder while whomever takes on your role pretends to ignore the issue and keeps shipping inaccurate declarations of licenses for dependencies thinking that's fine because nobody really cares.