4 ms·

What a state of things where we have to fear installing software, and rely on vendors to scan things ahead of time, because our supply chain is such a mess and

What a state of things where we have to fear installing software, and rely on vendors to scan things ahead of time, because our supply chain is such a mess and our tooling is so incapable of (and uninterested in) protecting us.

sunaookami 3mo ago
No way to prevent this says only package manager where this regularly happens.
- insanitybit 3mo ago
  Every major package manager is just as fucked.
Insimwytim 3mo ago
You cannot call it a supply chain, if you have zero contractual relationships with the authors of the solutions you are using. [1] https://news.ycombinator.com/item?id=44434355 https://news.ycombinator.com/item?id=44434355
- cryo32 3mo ago
  Oh that one really makes you think doesn’t it.
- stingraycharles 3mo ago
  I mean, that’s just arguing over whether or not the definition of “supply” implies “compensation”, which isn’t very interesting imho. The grandparent’s point remains the same, the software ecosystem and its supply chain or however you want to call it is a hot mess.
  - xgulfie 3mo ago
    Traditionally the term "supply chain" has implied a buyer/seller relationship
    - stingraycharles 3mo ago
      I think that’s up to debate, and my point is that debating whether free software counts as “supply” or not is really not that interesting.
- insanitybit 3mo ago
  So what?
madeofpalk 3mo ago
What would a solution to this look like? What would it take to not fear installing software? This isn't a npm problem, its a computing problem in general. Spaces like this are generally pretty against any sort of restrictions or limitations being put on computers under the name of safety (see Manifest v3)
- jchw 3mo ago
  Manifest v3's actual motive was so shamelessly transparent that most of us just don't allow the "safety" argument for it to really be entertained. I don't have a suspension of disbelief rich enough to pretend I don't know.
- dwoldrich 3mo ago
  For libraries, I like the Gnu Affero Public License[1]. If you run the library in software with that license, you have to publish all the source of the entire project that incorporates it. No corporation could tolerate this, though, so the library vendor can negotiate a commercial license of their software for appropriate fees. That said, corporations are not going to want to negotiate fees with 100's of vendors over constantly fluctuating dependencies in their software. This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. Similar to Amazon's Dynamo API, whatever the next big language/ecosystem is needs to be designed around _billing_ and automatic license management for # of deployments, seats, call volumes, etc. [1] https://web.archive.org/web/20260712154038/https://www.gnu.org/licenses/agpl-3.0.en.html https://web.archive.org/web/20260712154038/https://www.gnu.o...
  - skissane 3mo ago
    > This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. I don't think this idea is going to go anywhere. If a package is available for free, on convenient licensing terms, developers will use it. If you make them pay, many developers will prefer to just build it themselves. Coding agents make that easier than ever. Buying a package involves a lot more paperwork – it needs to go through procurement – and introduces new risks, e.g. what if the vendor increases their prices There are potential exceptions – software with really advanced algorithms (e.g. solvers for optimisation problems); safety critical software; software needing regulatory certification (e.g. there are some Australian government APIs they won't let you call unless you've hired an auditor to certify the software you are calling them with, and the relevant government agency has approved the auditor's report) – but those exceptions are relatively rare, and the existing solutions are arguably adequate to handle them I also think it is different for packaged SaaS applications [0] because there the buyer isn't a developer, it is someone non-technical, and "use a coding agent to build it yourself" isn't within their comfort zone or risk appetite (at least, not yet). [0] conflict of interest disclaimer: work for a SaaS vendor

sunaookami 3mo ago

No way to prevent this says only package manager where this regularly happens.

insanitybit 3mo ago
Every major package manager is just as fucked.

Insimwytim 3mo ago

You cannot call it a supply chain, if you have zero contractual relationships with the authors of the solutions you are using. [1] https://news.ycombinator.com/item?id=44434355 https://news.ycombinator.com/item?id=44434355

cryo32 3mo ago
Oh that one really makes you think doesn’t it.
stingraycharles 3mo ago
I mean, that’s just arguing over whether or not the definition of “supply” implies “compensation”, which isn’t very interesting imho. The grandparent’s point remains the same, the software ecosystem and its supply chain or however you want to call it is a hot mess.
- xgulfie 3mo ago
  Traditionally the term "supply chain" has implied a buyer/seller relationship
  - stingraycharles 3mo ago
    I think that’s up to debate, and my point is that debating whether free software counts as “supply” or not is really not that interesting.
insanitybit 3mo ago
So what?

madeofpalk 3mo ago

What would a solution to this look like? What would it take to not fear installing software? This isn't a npm problem, its a computing problem in general. Spaces like this are generally pretty against any sort of restrictions or limitations being put on computers under the name of safety (see Manifest v3)

jchw 3mo ago
Manifest v3's actual motive was so shamelessly transparent that most of us just don't allow the "safety" argument for it to really be entertained. I don't have a suspension of disbelief rich enough to pretend I don't know.
dwoldrich 3mo ago
For libraries, I like the Gnu Affero Public License[1]. If you run the library in software with that license, you have to publish all the source of the entire project that incorporates it. No corporation could tolerate this, though, so the library vendor can negotiate a commercial license of their software for appropriate fees. That said, corporations are not going to want to negotiate fees with 100's of vendors over constantly fluctuating dependencies in their software. This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. Similar to Amazon's Dynamo API, whatever the next big language/ecosystem is needs to be designed around _billing_ and automatic license management for # of deployments, seats, call volumes, etc. [1] https://web.archive.org/web/20260712154038/https://www.gnu.org/licenses/agpl-3.0.en.html https://web.archive.org/web/20260712154038/https://www.gnu.o...
- skissane 3mo ago
  > This is why the next big language/software ecosystem needs to integrate payments to vendors in their repository system. That way, commercial license management can occur between the ecosystem owners and the corporate customers and all the vendors get paid their fair share. I don't think this idea is going to go anywhere. If a package is available for free, on convenient licensing terms, developers will use it. If you make them pay, many developers will prefer to just build it themselves. Coding agents make that easier than ever. Buying a package involves a lot more paperwork – it needs to go through procurement – and introduces new risks, e.g. what if the vendor increases their prices There are potential exceptions – software with really advanced algorithms (e.g. solvers for optimisation problems); safety critical software; software needing regulatory certification (e.g. there are some Australian government APIs they won't let you call unless you've hired an auditor to certify the software you are calling them with, and the relevant government agency has approved the auditor's report) – but those exceptions are relatively rare, and the existing solutions are arguably adequate to handle them I also think it is different for packaged SaaS applications [0] because there the buyer isn't a developer, it is someone non-technical, and "use a coding agent to build it yourself" isn't within their comfort zone or risk appetite (at least, not yet). [0] conflict of interest disclaimer: work for a SaaS vendor