If you write an open source virus, and deliberately start spreading it, I don't think the licence will help your legal defence, even if that licence says "You can't sue me for deleting all your files".
The problem with Marak's latest changes is not the code itself, but his uploaded packages breaking the implicit contracts of maintaining backwards compatibility and not being malware. Perhaps if the package had been called "infinite-loop-and-spam-console", and that behaviour had been documented in the README, it wouldn't count as malware (because it is not a trojan, and there is no deception), but there's a strong case that he abused his access to NPM's infrastructure (and the wider JavaScript community) in order to cause harm.
I'm not a big fan of allowing single companies (especially Microsoft) to monopolise open source package distribution, and it sets a bad precedent if they start adding rules about which sort of packages they distribute, but I don't think it is gatekeeping if they forbid uploads of packages that literally no one would want to install and use.
In a more decentralised world, perhaps there would need to be a setting in the package metadata that says "This package is intended to be backwards compatible", and maybe even one for "This package is designed to harm the normal operation of software systems, do not run it in an environment where it can negatively affect you". By uploading or hosting packages with those metadata keys set to deliberately misleading values, it should be easier for a court to determine intent, without having to consider the details of the licence at all.
There's a kind of ecosystem resilience that could be improved (and I think gradually is improving) here.
We have utilities to determine whether a package is backwards-compatible, as far as we know -- unit tests, QA tests, integration tests, etc -- we can (under many practical circumstances) set resource bounds on computation, and we can review and detect many categories of security errors (that are arguably simply a subset of the more general category of programming and design errors -- also possible to detect).
Part of the problem, I reckon, is that the time and computation cost to run the tests in particular is often too expensive for it to be worthwhile to run them at an individual commit level.
Progress on incremental tests (determine the data-flow graph from the area of code that a commit affects, determine the set of inputs and outputs potentially affected, and run a subset or relevant tests) could help - as could providing more of these tools to individual developers, and reducing the time and expense of running costs in general.
That's a good point. It would be nice if NPM/Microsoft committed to running backwards compatibility tests on packages that had them (for packages that were significant enough and tests that were efficient enough).
This would require a convention that packages indicate in their metadata where the backwards compatibility tests are, and for each package's code to be run against the tests in the previous version of the package (or all previous versions with the same major version number?).
A slightly different approach would be for packages to write tests for the specific functionality of their dependencies that they rely on, and NPM could collect that distributed test suite and warn the test writer if a newly published version of one of their dependencies wasn't backwards compatible. NPM could even store such packages in a staging area (for a probationary period) where the dependency solving algorithm of npm wouldn't look by default.
The problem with Marak's latest changes is not the code itself, but his uploaded packages breaking the implicit contracts of maintaining backwards compatibility and not being malware. Perhaps if the package had been called "infinite-loop-and-spam-console", and that behaviour had been documented in the README, it wouldn't count as malware (because it is not a trojan, and there is no deception), but there's a strong case that he abused his access to NPM's infrastructure (and the wider JavaScript community) in order to cause harm.
I'm not a big fan of allowing single companies (especially Microsoft) to monopolise open source package distribution, and it sets a bad precedent if they start adding rules about which sort of packages they distribute, but I don't think it is gatekeeping if they forbid uploads of packages that literally no one would want to install and use.
In a more decentralised world, perhaps there would need to be a setting in the package metadata that says "This package is intended to be backwards compatible", and maybe even one for "This package is designed to harm the normal operation of software systems, do not run it in an environment where it can negatively affect you". By uploading or hosting packages with those metadata keys set to deliberately misleading values, it should be easier for a court to determine intent, without having to consider the details of the licence at all.