Oh, and let us not forget: the library never made it past 0.0.3.
You know, because there could still be some major features left on the roadmap.
For padding strings.
On the left-hand side.
Arabic support w/ unicode maybe?
So, “un-un-publishing” is reversing the author’s decision without his consent, which may be viewed as forking his code and publishing your “derivative work”, which is still however called by the same name, which probably breaks an implicit copyright owned by the original author in the absence of an explicit license. Is this right?
P.S. OSS folks, don’t neglect licensing your work, no matter how trivial.
The package was explicitly licensed with the extremely-permissive WTFPL. A new author forked the code and adopted the name of the abandoned package, which is a long-established allowed behavior on npm. The only new action was we honored a request by the author to re-publish the old code under the old version number.
The package used to be BSD, I think this change was never published:
I was looking for a license in the source on GitHub and didn’t find one. Of course, if ownership of the package was explicitly transferred to a new owner, everything should be fine.
Ok, thanks! Also in theory, a package can have a different license from the source :-)
I really hope this makes people re-evaluate their dependencies on many small modules in NPM; you really don’t know what’s going to happen to external libraries. A few months ago I wrote the 5 line function for left padding strings and some tests and moved on.
It would also be nice if the standard library had more support for tools like this.
https://lodash.com/docs is not a bad group of utilities.
Hah, I just wrote an internal blog post called “Lodash Functions We Probably shouldn’t use.” There’s a lot that duplicates the standard library in there.
I’d be shocked if they didn’t use the standard library functions where possible.
According to kik.com the company has been around for 7 years (vs 5 months for the kik project) and they release code and have APIs used by millions of people (vs almost no exposure for the kik project).
There’s also http://dev.kik.com/ for developer information, API references, etc. It seems a kik module in NPM that wasn’t related to kik.com would be misleading and not what a lot of people would expect.
The author needs to grow up and accept he screwed up with the name, because it seems like a pretty clear case of accidental trademark violation. Throwing a tantrum and unpublishing a bunch of stuff is going to backfire and make him look childish.
Then again, people have been typing kik accidentally ever since they started typing lol (qwerty right hand shift one place left).
So what? Unless they started a business and released software named “kik” afterwards, it’s completely irrelevant as far as trademarks are concerned.
Does the npm module in question cause confusion as to the source or sponsorship of the goods or services involved? This is, from what I understand, one of the key measures of trademark violation. Before today I had never heard of either KiK, so I wouldn’t know (there are apparently other things referred to by Kik).
Regardless, it sounds like the user in question would have to take KIK Interactive to court over the issue to get their js module reinstated, which I am sure would be quite expensive and likely not worth the author’s time.
If I search NPM for Flickr, I get a library for using the flickr.com API, as I’d expect.
If I search NPM for imgur, I get a library for using the imgur.com API, as I’d expect.
If I search NPM for youtube, I get a library for accessing youtube.com API, as I’d expect.
If I search NPM for twitter, I get a library for the twitter.com API, as I’d expect.
If I search NPM for uber, I get a library for the uber taxi service API, as I’d expect.
If I search NPM for kik, I get this confusing library that isn’t immediately obvious whether it’s related to the kik.com API or not. Seems confusing to me.
This guy’s library was 5 months old and used by almost nobody. kik.com’s lawyer asked nicely before contacting NPM directly. It would have been trivial for the author to rename his library, and it would have had no negative consequences, but instead he decided to throw a fit on the internet. Somebody was being a dick, and it wasn’t kik.com.
As expected, there are lots of counter examples.
If I search npm for target, I get some random library – not something to do with Target the store chain.
If I search npm for apple, I get some random library. Maybe? Hard to tell without a readme.
If I search npm for google, I get an apparently un-authorized (the module was clear to point this out to me, so I mentioned it) module for searching google.
I get your point though. I certainly agree with you that the response from the guy to the lawyer seemed quite dickish as well.
I don’t know. If you chose trivially simple and short names for your company you need to accept those names are going to turn up elsewhere.
Which is why you spend time, resource, effort and money establishing trademarks, and the rest. Not that I’m saying that trademarks are necessarily the best thing for the world, or otherwise, but that’s the establised system that’s in place to arbitrate this kind of stuff, and someone throwing a tantrum when it bites them on the ass because they didn’t do a quick Google before naming their library is … not going to help anyone, particularly that person.
The name isn’t the issue. Reusing the name for a very similar product or service is the issue.
I wonder, if the situation were reversed and kik.com were the ones violating an open source project’s trademark, would as many people be on their side?
You can’t create a beverage called “Coke” and expect not to be sued if you don’t change it when notified.
If your build system talks to the internet, maybe rethink your life decisions?
I think it is valid. I would have it download to a local folder so that the next time it doesn’t need to talk to the internet unless you delete the cache file/folder. Otherwise you need to tell your users, “get these 4 packages first, then we can talk”. I know this system can be abused and malicious scripts/packages can be run/installed, but when it is working it is great for end users and should require less support from the developer.
Alright everyone back to using Ant, Make, and hand compilation because this guy thinks dependency management is for for idiots.
My guess is that @hank is suggesting you should run an internal artefact server which archives your dependencies, or if that’s too much, vendor whatever your dependency management tool pulls in.
The point is reproducible builds, not throwing away dependency resolution.
It’s just another twist on http://www.whoownsmyavailability.com/
The npm guidelines used to explicitly state this, and tell you not to use npm in your build process unless you setup your own registry. IIRC they changed it (and now the registry page is bare-ish) when they started pushing their enterprise offerings such as On-Site and repositories as a service (“Private Repositories”).
The effects of capitalism on computing. ;P
How does NPM allow somebody to mass-unpublish their own libraries?
I think it’s great that they do. That’s how it should be. It’s the author’s library, not NPM’s.
Thanks for linking to the guy’s blog. Beautiful stuff, and love the “you broke my code but more power to you for standing up for your principles” comments.
Is that really how it should be? Authors of packages released to NPM—or for the sake of argument to any other centralised repository of libraries—publish their code under terms of free or open source licenses. The act of releasing an artifact (note the key word: releasing) entitles maintainers of a particular repository to redistribute the source code freely as long as they obey terms of the particular license.
In this case, left-pad was published under terms of the extremely permissive WTFPL. It uses somewhat coarse language to give licensees virtually all the rights, and among others, the right to freely redistribute.
The right of redistribution matters. Once a particular library becomes an important node in the dependency graph of a serious and growing ecosystem its just too risky to let it disappear. This case demonstrates it aptly. I would argue that a healthy and responsible community should actively pursue the goal of maintaining availability of critical components of the ecosystem. Otherwise stories like this hit front pages of all tech news sites and the entire community suffers.
Mistakes? Sure, they do happen. But there are means to address them. Consider Clojars, the central repository of the Clojure ecosystem. You uploaded something accidentally? No worries, just open an issue, explain the situation, and tag it as delete-request. Maintainers will review your request and will act accordingly. The process is transparent and prevents situations like the calamity we’ve just witnessed.
Are JS developers really so lazy/incompetent that they can’t just rewrite a pad-left function on demand as needed instead of pulling in an entire library (whose only purpose is to left-pad strings)?
Given the community’s push for modularity, people tend to use packages that have an established user base over writing something themselves. Call it lazy, but it seems to be a fairly common trend across languages.
The kicker is this dep was a sub dep of other things a given app used (vs a direct dependency), to the best of my knowledge, the only way to fix the situation is to fork every dep that uses left-pad, add similar functionality and update the package.json file.
I was very pleased when @jrick pointed out that cargo (rust’s package manager) let’s you handle this situation with ease!
If you want to backdoor node apps, there are now plenty of available, established package names you could recreate that people already depend on. Enjoy!
This was not a possibility, actually. Furthermore, all of the packages in question have new maintainers that are being monitored very, very closely.
Do you need explicit permission to reclaim the previously used name? I didn’t gather that from the post or tweet which made it seem like you could adopt the name without intervention.
But I probably should have checked that rather than my “ready, fire, aim” approach above.
I don’t believe that you did, no. But you did need npm’s help in order to publish old versions of the package, so the new maintainers could have only made new versions.
Well, that’s still a problem then, since most people are using the caret syntax in their package.json, right?
Most of the packages seem to have been claimed by this unknown actor, who appears to have bumped the version number on every single package.
I think there’s some subtitles around the karat and 0.0.z versions in this specific case, but generally, you’re right, I think.
who appears to have bumped the version number on every single package.
Yeah, that’s the only way to get it to show up that way, you have to publish a new version so the new metadata is applied.
It seems the lack of a (default) lockfile makes this worse.
Why does NPM allow for infringement notices on libraries?
If you’re running a service that hosts user-submitted content you have two choices: a) be responsible for any infringing content you host b) follow the infringement notice process that allows you to be covered by the “safe harbour” provisions. Guess which one anyone with sense chooses?
Anything your service allows, it should allow doing via API. Whether to allow unpublishing of libraries at all is a legitimate question with arguments for both sides.
The three cardinal virtues of a programmer are laziness, impatience and hubris.
What is the purpose in continually adding language features to the JS spec if there is no attempt to update the standard library?
Keep the language and libraries separate, allow each to evolve at their own pace.
What you’re missing is that the JS library infrastructure is good enough to make this easy. Frankly this whole thing sounds like pretty good infrastructure handling one developer’s misbehaviour rather well.
Frankly this whole thing sounds like pretty good infrastructure handling one developer’s misbehaviour rather well.
Exactly! It’s impressive that, considering everything, the situation was resolved very quickly and at low cost.
Also maybe this will spur more high profile projects to maintain an artifacts server :)
This is the reason why, in my opinion, the vendoring mechanism advocated by Go is better than a central registry (like npm, PyPI, RubyGems or crates.io).
crates.io’s FAQ claims that a central registry is good for discoverability (find popular packages) and speed (fetch only necessary data instead of the whole git repository), but a proxy could provide the same benefits to an ecosystem based on decentralized repositories and vendoring.
Isn’t this more about the ability to squat names in a namespace?
Why should the string kik be owned by any one individual or entity? Package dependencies are infrastructure. Make them longer. I’m partial to username/package, but I could also see package#id, like battle.net does with usernames.
I’m not sure what tags to put on this exactly.
I put in “law” and “culture” as suggestions, though I’m not really convinced it fits in either. The tag suggestion system is useful for this. :)
Regarding #4, ES2015 did update the standard library, ES2016 will do so later this year, and there are several proposals pending for subsequent versions. One of those proposals includes the specific functionality mentioned here: https://github.com/tc39/proposal-string-pad-start-end/blob/master/README.md
Relevant blog post about the package’s removal: https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c
In case you’re one of those frameworks that broke (holy christ) use underscore.string instead.
In case you’re one of those frameworks that broke (holy christ) use underscore.string instead.
~95% of the pulled NPM modules have already had their names claimed by a single, anonymous actor.
Maybe this is a good time to remind people of rimrafall?
This person has bumped the major version of every package to 2.0.0. As far as I can tell, most of the original packages were on versions <= 1.x.x.