It's his software and he can do with it as he pleases. It's an MIT license, so there's no warranty whatsoever. I'm not convinced that GitHub has any business suspending his account.
If he can do as he pleases, can't GitHub as well?
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
11–20 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#12Earlier quoted context omitted.
GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.
That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?
If they wanted to publish it for themselves, wouldn't they make a private repo?
I'm (honestly) trying to understand why GitHub can't just go ahead and remove any account as they see fit.
Edit: Am I being downvoted for asking a question?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#13Earlier quoted context omitted.
GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.
That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?
The keyword is malicious, which does not lend nicely to be deconstructed by reductionism.
If the intent of the push was to damage downstream users of the software then it is malicious towards them.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#14Earlier quoted context omitted.
GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.
Why would the developer of any software that comes explicitly without warranty be hold responsible for downstream breakages? It's not as if one could force people to upgrade to newer versions and they can always keep depending on the old releases.
From the point of view of GH the license is irrelevant, what they see is that a project they host is in practice being use to distribute malware.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#15Earlier quoted context omitted.
GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.
Why would the developer of any software that comes explicitly without warranty be hold responsible for downstream breakages? It's not as if one could force people to upgrade to newer versions and they can always keep depending on the old releases.
In general, warranties only relate to accidental problems and have nothing to do with intentional sabotage.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#16So people learned basically nothing from leftPad.js ?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#17So people learned basically nothing from leftPad.js ?
What were they supposed to learn? "Don't have dependencies"?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#18Earlier quoted context omitted.
GitHub ToS allow terminating accounts for malicious behaviour, which I'd argue that purposefully breaking downstream code is.
That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?
If they're malicious, yes?
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#19Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#20So people learned basically nothing from leftPad.js ?
What were they supposed to learn? "Don't have dependencies"?
Add a layer of indirection between you and the source of your dependancies so you can control them?
Just a proxy that delays new version availability for a week would protect you from this.
But yarn add directly from the account of a madman who made your dependency is so much easier.