npm was a mistake.
-
@0xabad1dea @tribut the twist ending here is that the non-hobbyist code is worse, because the people who don’t want to pay for the basic safety checks aren’t actually the hobbyists.
(The solution is strict liability here for the people billing for software and services, no liability for the hobbyists, not “no warranty expressed or implied” for hobbyists charging you nothing and “that, but also mandatory arbitration” for corporations raking in billions)
@glyph @0xabad1dea @tribut The EU is trying that, right? Does Geomys have strict liability for all of Go? Or does Google? Why would Google let Geomys maintain Go if the liability falls on them? Does a maintainer with a Patreon have strict liability? What about a maintainer who scored their first $10k support contract, which is not enough to pay both taxes and E&O insurance?
I understand the desire to stick it to the man, but the system needs to be viable, not just desirable.
-
@glyph @0xabad1dea @tribut The EU is trying that, right? Does Geomys have strict liability for all of Go? Or does Google? Why would Google let Geomys maintain Go if the liability falls on them? Does a maintainer with a Patreon have strict liability? What about a maintainer who scored their first $10k support contract, which is not enough to pay both taxes and E&O insurance?
I understand the desire to stick it to the man, but the system needs to be viable, not just desirable.
@filippo @0xabad1dea @tribut this is my point. Nobody pays for go. So nobody would have liability for it. Google owns google ads, and if google ads fucks up, google should be liable for it. If google pays geomys for assurances about go and those assurances are not met and damages result to google ads customers, liability can flow upstream. I don’t think this is how they are doing it in the EU, but I don’t fully understand their approach.
-
@filippo @0xabad1dea @tribut this is my point. Nobody pays for go. So nobody would have liability for it. Google owns google ads, and if google ads fucks up, google should be liable for it. If google pays geomys for assurances about go and those assurances are not met and damages result to google ads customers, liability can flow upstream. I don’t think this is how they are doing it in the EU, but I don’t fully understand their approach.
@filippo @0xabad1dea @tribut I think questions about whether e.g. a patreon incurs liability, have to do with what representations are being made. My (tiny) Patreon is mostly interested in software as bizarre performance art and blogging about my gripes, not infrastructure indemnification. But I also do tidelift, and I signed some contracts saying ai will follow certain security policies for that (tiny) portfolio, and I take those obligations seriously, so it’s different.
-
@filippo @0xabad1dea @tribut I think questions about whether e.g. a patreon incurs liability, have to do with what representations are being made. My (tiny) Patreon is mostly interested in software as bizarre performance art and blogging about my gripes, not infrastructure indemnification. But I also do tidelift, and I signed some contracts saying ai will follow certain security policies for that (tiny) portfolio, and I take those obligations seriously, so it’s different.
@filippo @0xabad1dea @tribut give me right-wing oil-billionaire think-tank levels of money and me and my staff will write you the whole regulatory framework in a few months, no problem
-
@filippo @0xabad1dea @tribut give me right-wing oil-billionaire think-tank levels of money and me and my staff will write you the whole regulatory framework in a few months, no problem
@glyph @0xabad1dea @tribut So would strict liability be mandatory, or something that can be offered as part of a contractual relationship? Because I don't see how the latter opt-in version is different from the status quo. As you said, there are already entities that do that. If it's mandatory, then you need a better answer to all the previous questions, because the rules need to adjudicate when it's mandatory and when it's not, and who it falls on. Clients do pay Geomys for Go.
-
@glyph @0xabad1dea @tribut So would strict liability be mandatory, or something that can be offered as part of a contractual relationship? Because I don't see how the latter opt-in version is different from the status quo. As you said, there are already entities that do that. If it's mandatory, then you need a better answer to all the previous questions, because the rules need to adjudicate when it's mandatory and when it's not, and who it falls on. Clients do pay Geomys for Go.
@filippo @glyph @0xabad1dea @tribut at the moment there's no liability at all for most software failures. that's that whole thing about "no warranty, not even the implied warranties of merchantability or fitness for a particular purpose." if clickthrough agreements are taken at face value, nobody even has a remedy if a program turns out to be something completely different from what was advertised.
-
@filippo @glyph @0xabad1dea @tribut at the moment there's no liability at all for most software failures. that's that whole thing about "no warranty, not even the implied warranties of merchantability or fitness for a particular purpose." if clickthrough agreements are taken at face value, nobody even has a remedy if a program turns out to be something completely different from what was advertised.
@ireneista @filippo @0xabad1dea @tribut You are correct that there need to be rules to adjudicate where responsibility for specific things lie. And there needs to be a pretty complex process of determining what constitutes "negligence" so we know when punitive damages are allowed. Not a process unique to computing. Here's a 20-page regulatory report on types of pickles https://www.ams.usda.gov/sites/default/files/media/PicklesStandard.pdf
-
@ireneista @filippo @0xabad1dea @tribut You are correct that there need to be rules to adjudicate where responsibility for specific things lie. And there needs to be a pretty complex process of determining what constitutes "negligence" so we know when punitive damages are allowed. Not a process unique to computing. Here's a 20-page regulatory report on types of pickles https://www.ams.usda.gov/sites/default/files/media/PicklesStandard.pdf
@ireneista @filippo @0xabad1dea @tribut The principle that I'm advocating for here is just the implied warranty of merchantability, which commercial software vendors routinely disclaim or attempt to disclaim in their EULAs, with zero consequences.
-
@ireneista @filippo @0xabad1dea @tribut The principle that I'm advocating for here is just the implied warranty of merchantability, which commercial software vendors routinely disclaim or attempt to disclaim in their EULAs, with zero consequences.
@glyph @filippo @0xabad1dea @tribut then, we agree on that part
(and we don't feel that we've figured out much beyond that) -
@glyph @filippo @0xabad1dea @tribut then, we agree on that part
(and we don't feel that we've figured out much beyond that)@ireneista @filippo @0xabad1dea @tribut more generally, I think contracts of adhesion should be illegal. Maybe there ought to be some blanket de-jure terms you're allowed to apply for a "software license", or a "terms of service". But licensing a piece of software (or website) with custom terms ought to be like getting a mortage. Apple wants to have a custom license for every iOS, they can have everybody come down to the Apple Store, bring a lawyer, initial every page and get it notarized
-
@ireneista @filippo @0xabad1dea @tribut more generally, I think contracts of adhesion should be illegal. Maybe there ought to be some blanket de-jure terms you're allowed to apply for a "software license", or a "terms of service". But licensing a piece of software (or website) with custom terms ought to be like getting a mortage. Apple wants to have a custom license for every iOS, they can have everybody come down to the Apple Store, bring a lawyer, initial every page and get it notarized
@glyph @filippo @0xabad1dea @tribut in our childhood, we witnessed several purchases of early versions of Microsoft Office which did involve doing exactly that (it was before the lawsuits that established the current clickwrap doctine were fully resolved)
-
@glyph @filippo @0xabad1dea @tribut in our childhood, we witnessed several purchases of early versions of Microsoft Office which did involve doing exactly that (it was before the lawsuits that established the current clickwrap doctine were fully resolved)
@glyph @filippo @0xabad1dea @tribut sorry - not Office, just Word. we're pretty sure it was sold as individual program back then.
-
@glyph @filippo @0xabad1dea @tribut sorry - not Office, just Word. we're pretty sure it was sold as individual program back then.
@glyph @filippo @0xabad1dea @tribut anyway we're all for the basic idea but don't underestimate the lengths corporations will go to on a matter of principle, when the principle is "we're not responsible for anything"
-
@glyph @filippo @0xabad1dea @tribut anyway we're all for the basic idea but don't underestimate the lengths corporations will go to on a matter of principle, when the principle is "we're not responsible for anything"
I mean, I kinda hate to say it, but I think the way out of this would be something more like the Apple App Store, where some company gets paid by other companies for FOSS packages review and support, and accepts the liability if one of those packages gets popped. Basically, cyber insurance for software dependencies. If your corporation uses packages they provide, and their packages are responsible for a breach, and it's shown they didn't do their duty of care to provide quality products, the liability is on them.
There used to be companies that would do that sort of thing for Linux repos. I doubt they exist anymore because nobody wants to take on the time and investment and risk of all that.
I mean at the end of the day, it'd be kinda the death of FOSS in corps since the company who is providing the package repo is going to pretty massively restrict what packages and libraries they include. But it'd meet the requirements of ""Software Supply Chain Security ".
-
R AodeRelay shared this topic
-
npm was a mistake. the concept of pulling live dependencies that are not collectively managed by a QA team but each individually managed by many thousands of people with wildly varying skill and availability is inherently doomed to constant incidents.
@0xabad1dea Now you got me thinking.
Some of the package managers I have seen do not make an effort to expose a number of details I would think are important like the licence and owner of the package.
Sure, Nuget DOES support multiple repositories, but the developer still has to actively seek out information package by package. It also seems to be commom to publish into the public Nuget Feed, rather than different groups getting their own feed.
NPM takes it further by not having any silos, which also means no control or prediction. Instead of adapting these in during the Pad Left incident, and encouraging a system where you know who provides your shit, NPM just said "You can't take things down anymore."
Maybe we do need a completely new dependency management system.
