Yes you got it right. The third point was the special exception / grey area.

For the record they made sure the exact same code was published to 0.0.3 so that I didn't maliciously inject anything. I control subsequent versions though.

Now that you own it what's to stop you from pushing out a new version with a slightly reworked string pad function under a commercial license (say a $100 per use fee)? Could make quite a pretty penny. Kind of crazy that this is possible at all.

What's to stop an original author doing the same thing? This isn't a new danger.

I think the point is the author is a new person.

You meet someone at a conference and the next conference he shows up again and you should know right away he's not actually somebody else.

Why on earth would someone pay for that if the code is already open source?

That's not the point, of course no one would pay $100 for a string pad function. The point is they own the source of code that thousands of people will potentially pull from without realizing it's a different owner who might have different intentions. Not trying to say what they did is wrong or bad (it saved a lot of people's butts I'm sure)--it's more just highlighting the massive issue with NPM package publish & unpublish.

v0.0.3 is open source, though there is no license in the Github repo, so murky, but NPM says its WTFPL

Since old code is under a very permissive license, then the new owner could create v0.0.4 add code and make the new version closed with a restrictive license.

This is where a license like GPL would benefit overall, since all future code requires to be under the same license.

Either way, it seems like a dangerous policy to allow someone to re-own a previous owned and published module. Licensing is not the real threat but malicious code that potentially could be deployed.

> there is no license in the Github repo, so murky, but NPM says its WTFPL

The WTFPL licensing comes from the package.json file, which is in the GitHub repo.

Yeh, my mistake. I missed it in package.json was looking for a LICENSE file.

Now I'm seriously wondering if npm is a goldmine for GPL infringement. If someone has an insane dependency tree with 1000 entries then there is bound to be at least some GPL in there forcing everything else to be GPL too.

Exactly--there's a great bug thread on the Atom text editor where they laboriously dug through hundreds and perhaps even thousands of dependencies to see if any had licenses that were incompatible with theirs. It looked like a complete nightmare and you can see the end result if you go to the View License menu in the editor--it's hundreds of little licenses.

With 1000 of dependencies, I would be much more worried that one of them are proprietary licensed (or was ripped from a place with no copyright license attached and then had a new license added the original authors permission). Imagine distributing a "$100 per use" software for a few years without paying, and how the court system would react.

I guess this is why debian takes licenses so serious.

Sadly, there's nothing insane about 1000 entries when it comes to npm. That's the reality of pretty much any non-trivial project, especially with React and Babel.

People can still just use the older versions that are immutable.

Except this very same string of events makes it quite obvious that versions aren't systematically immutable.

And vast numbers of people are suddenly shocked (shocked!) to realize there's no mechanical verification of stuff like this. It can all happen whimsically, and the result isn't just a loss of service, it's service with different results and no verification nor notice.

> Except this very same string of events makes it quite obvious that versions aren't systematically immutable.

From this thread it sounds like: a) npm specifically overrode their normal process to allow him to publish new code at the same version number b) npm did verify that the code he was publishing was the same as the old code at that version number as part of this.

So sounds like immutability of specific versions is systematically enforced by npm?

"npm" is two things in this picture: the server and centralized service, and the software tool on everyone's build/dev machines.

There's a difference between trusting a server to do something, and having the software you're using check that the server hasn't changed its behaviors in ways that may... fuck with the continuity of your zen.

If someone can decide to do a special thing that happens to break all promises, and my side of the tooling doesn't let me know, much less let me confirm acceptance of the changes, then my side of the tooling is seriously deficient.

And in a situation where this tooling then starts executing new code from a new author on my host as my user without any authentication except "trust the server"... the same behavior describes $script_kiddie_virus_of_the_week! "download code from C&C server; run it, thanks:D" What's the difference between this and outright RCE exploit? "good intentions"?

I'd rather have something more than "good intentions" controlling what code ends up running on my computer, thanks.