Is Open Source Free If We Aren’t Allowed to Break It?(thenewstack.io)
thenewstack.io
Is Open Source Free If We Aren’t Allowed to Break It?
https://thenewstack.io/is-open-source-really-free-if-we-arent-allowed-to-break-it/
4 comments
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.
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.
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.
I think if you put code out there in such a fashion that use of it depends on your version of it (whether that be the community culture at large, or just specifically your way of going about it), then you have more of an obligation not to just take it down without warning people and giving them time to transition to either a forked package, or their own local copy, or whatever. It certainly harms the individual developer's reputation who does such a thing, even if one indeed has the ultimate right to do so.
Of course, if this pushes people away from modern dependency hell, then it may just be a good thing.
Of course, if this pushes people away from modern dependency hell, then it may just be a good thing.
No, merely putting code out there for others to use creates no obligations at all. None of the open source licenses create any such obligations either.
I didn't just say that. I said that if you put your code out there in such a form as people rely on your instance of it, you have an obligation to not break them without warning. Don't want that obligation? Don't put the code out there in that form, put it out in such a way that people can't rely on your specific upload to use the software. If that means "don't use X package manager", then so be it.
No, using a package manager creates no obligations on the author of the software.
I think dependency hell is inevitable and every language coming up with their own solution for packaging and dependency handling is just making it worse and at the cases like this just catastrophic.
lol companies that made so much money off of free software now crying because they took it and were too lazy to also test that it keeps working before crapping it out into the world to handle all of our sensitive data.
This caused problems for more than just "companies that made so much money off of free software". In fact, I dare say that those companies were least affected, and it was the poor unpaid free software developers who trusted Marak's packages to maintain backwards compatibility that ended up scrambling to do the extra unnecessary work to clean up his mess.
Nah I don't believe it.
Also reports that Marak Squire’s GitHub has been restored.
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.