So if I understand correctly

  * npm allows a module to be deleted
    so all fetches of published name-oldversion fail
  * npm allows you to take-over the name of a deleted module
    and publish name-newversion
  * npm does not allow you to "re-publish" name-oldversion
    which had existed before the deletion
    but npm ops forced this publish for your special case

That's a strange combination of constraints. If you're going to reserve the name-oldversion permanently, you might as well leave the content there too. (Except, I guess, for license compliance...)

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.

While I can appreciate the predicament this presents, do you not feel like you are going against the wishes of the original author by essentially overtaking him and publishing his code against his will?

The author's explicit wishes, in no uncertain terms, are that anyone can "do what the fuck they want to with it" [0][1]. I think when he did this, he gave up (willingly, and with a bit of profanity) the right to have any say at all about whether, how or by whom it was published.

[0]http://www.wtfpl.net/

[1]https://github.com/azer/left-pad/blob/master/package.json#L2...

The author also said "if you volunteer to take ownership of any module in my Github, I’ll happily transfer the ownership" in the blog post.

Which is a nice gesture, but since the wtfpl seems to give up any pretense of ownership on the part of the author, it's also irrelevant. Anyone can do what they want with it. If he wanted to keep tighter control of the code he should have published under a more restrictive license.

And, if he wanted people to take the time to be polite and contact him through his github account, maybe he shouldn't have wrecked so many people's builds.

The "ownership" I assume is referring to ownership on npm. I was just saying that, based on that excerpt from the blog post, it sounds like the author didn't actually want to keep tighter control of the code, and that re-publishing the code doesn't really go against the author's wishes.

I'm pretty sure the ownership he's referring to is the github repo. Since he unpublished from npm, he has no control over those names.

Well the code was open sourced. Isn't that sort of the point of open source?

Lol, so if I'm understanding you correctly:

Someone was nice enough to write some software, that is clearly indispensable. They were nice enough to not charge money for it. They were nice enough to support it, again free of cost. They were also nice enough to open source it, such that if it ever became more convenient for you to fork/change/do whatever you want with, that you would be able to.

And when that same person is being bullied (regardless of legalities) and instead of building them up, helping them fight against their bullies, you decided to shrug your shoulders, go against their wishes, exploit the fact that its open source, and when asked if you felt bad about it, responded: (paraphrased) "Well... technically..."

On the one hand: Really? You don't even feel bad about it? Do you not see that it is machiavellian? You don't even care enough to use the age old "better of two evils"/"end justifies the means"/etc arguments? Bold.

On the other hand: Kudos! I don't think I would be able to pull it off like you do.

Are you serious? Nice enough to yank it without giving anyone advanced warning, (likely) knowing that it would break numerous projects? My guess based on the timing of his article and his petty argument with kik, is that he intended to cause this commotion to draw attention to his complaint against kik. He could have give the community warning so that major projects could have switched over to another package. So no, I don't feel bad for the guy, I think he's being childish.

I had the same interpretation. "I'm gonna take my ball and go home"

"This park sucks. I'm going to another. Everyone is free to join me."

To be honest,

I really don't care either way about this situation.

I truly find humor/curiosity in the attitude of the grand parent.

The author offered to transfer the repo to anybody willing to take it.

https://github.com/azer/left-pad/issues/4#issuecomment-20006...

You really publishing his code again is "going against his wishes"?

He made his point and got a lot of attention to the situation, he isn't responsible for the packages anymore. I would not assume that he wants further disruption or objects to people using his code.

If the author did not want other people to be able to fork/redistribute that code, they should not have published it under an open source license.

If they did not want other people to be able to register those package names on npm, they should not have relinquished control of them.

Hah, “indispensable”. It pads strings. Here, I wrote an alternative:

  function padLeft(s, width, padCharacter) {
      var d = width - s.length;

      return d <= 0 ?
          s :
          (padCharacter || " ").repeat(d) + s;
  }

Keep in mind that `String.prototype.repeat` exists in far fewer contexts than a simple loop. The whole point of using a module is that you don't have to worry about _how_ it works when implementing it in your project.

That’s also the whole point of using a function.

(For what it’s worth, I changed it from this to show off ES6.)

  function repeat(s, times) {
      return new Array(times + 1).join(s);
  }

  function padLeft(s, width, padCharacter) {
      var d = width - s.length;

      return d <= 0 ?
          s :
          repeat(padCharacter || " ", d) + s;
  }

Sure. And it's easy to copy and paste into a few different projects that you maintain. What happens, however, when you decide to use multiple characters instead of a single character (to create a pattern for example)? Now your padding is two or more times as long as needed. So you write a little extra logic but now you have to update multiple projects to implement that same change.

I think what's great about external modules is: * you only need to update the package file to get the benefits of new versions of dependencies * you can call `require('left-pad')` instead of what can end up like `require('../../utils/string').leftPad` * your code only describes _what_ it's doing, not _how_ (declarative programming)

> What happens, however, when you decide to use multiple characters instead of a single character (to create a pattern for example)?

Then you can’t use left-pad, because it doesn’t support that and you don’t maintain it. So you make your own module to suit your needs, which is a very good thing and returns somewhat to the actual point, which is that anyone can make their own left-pad that matches the existing module, so the author’s wishes wouldn’t have a huge impact even if they were that the module stayed down, which they weren’t. Phew!

Obviously not your choice, but it's a problem of using 0.0.x versions; no flexibility for the crate author to push minor updates.

If you want the flexibility of pushing minor updates the flipside is you need to provide a definition of what constitutes minor - at which point you should be on 1.x.

That's absolutely not true.

The fact that so many depend on exactly the version 0.0.3 indicates it is.

What if it were 0.3.0 instead? The common dependency relation would allow 0.3.1 too and allow you to easily deliver a minor update.

Thank you for fixing something that should have never been an issue. You allowed many developers to have a life after work :)