I've Just Liberated My Modules | Hacker News Reader

I've Just Liberated My Modules

medium.com

1,573 pointschejazi797 comments

The fact that this is possible with NPM seems really dangerous. The author unpublished (erm, "liberated") over 250 NPM modules, making those global names (e.g. "map", "alert", "iframe", "subscription", etc) available for anyone to register and replace with any code they wish.

Since these libs are now baked into various package.json configuration files (some with 10s of thousands of installs per month, "left-pad" with 2.5M/month), meaning a malicious actor could publish a new patch version bump (for every major and minor version combination) of these libs and ship whatever they want to future npm builds. Because most package.json configs use the "^1.0.1" caret convention (and npm --save defaults to this mode), the vast majority of future installs could grab the malicious version.

@seldo Is there a plan to address this? If I'm understanding this right, it seems pretty scary :|

[1] https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...

That's not how it works. You can't publish left-pad 0.0.3 again.

Unless you're npm: https://twitter.com/seldo/status/712414400808755200

ooh gosh, they should really do something like ban new projects from using those names until they figure out a better solution, hopefully with the module author.

Seems that we should now prefix any package name with a random string like 'skdjdihsawqy'. This way you could maybe avoid to be the target for some of those 'has to proof itself' lawyers.

Or, you know, prefix with author's username, a la Github.

Like, can my github username be kik? And if I have created years before they founded kik?

How many years before github would that be?

(Edit: this was written under the assumption that the lawyers in question are working on behalf of kik, the cheap clothes company, not kik, the messenger company. The original article is unclear about that)

This really has to be attacked at the root: let's all stop pretending that a sequence of characters can be owned. Before the web came along, people were completely sane about the protection of brands. Nobody had delusions about string ownership, but deceptive abuse of brand names was suppressed just as well. Enter the web, and suddenly corporations start thinking they somehow deserve exclusivity for their stupid little three-letter-acronym, at first on the DNS, now, apparently, also in search engine hit lists ("oh noes, someone might google themselves onto github instead of our site, people will start wearing NPMs instead of our clothes!").

Ding Ding Ding!!!

This would solve classes of issues with the npm ecosystem (many of which remind me of trying to register a domain name) like name-squatting, trying to think up a marketable-but-untaken name, and ownership transfer.

OP claimed a bunch of sweet dictionary words (concat, iframe, door, bud, alert, map) and new owners are now claiming them and it's a security disaster. But it'd be a lot less interesting if they unpublished "azer/map", "azer/alert", "azer/iframe", etc. and new owners republished under their own names.

Elm packages got this right: http://package.elm-lang.org/

So left-pad is too important to be removed but Kik isn't? What if the author had originally called left-pad Kik? Why is it ok for the Kik trademark holder to break thousands of builds but not the module author?

That's a good point. Very inconsistent behavior by NPM here.

This is a very good question. I was going to make the argument that the author merely continued what NPM Inc. started, and that if you fault him, you should also fault NPM Inc., but then I noticed that NPM Inc. didn't unpublish his module, but transfered the name to another account, which is much worse, if you think about it.

The ultimate conclusion is that if it's anyone's fault, it is the fault of the person who relies on NPM Inc. when building his software.

I'm a known downer of npm and node in general and this illustrates how bad npm is about this... You can't just change owners to kik on npm without the previous maintainer's permission. NPM has violated the trust of the community and will continue to do so until someone forks npm and makes an honest community out of it.

What's next? If I have foo.bar domain, can kik come and say I can't have foo.bar/kik or kik.foo.bar? To the people who think npm is right, what if you owned foo.bar and Google decided they didn't want to deal with kik lawyers and redirected kik.foo.bar to kik.com?

couple of days ago i was all smug from upvotes for calling npm best practise.

i take that back, npm is a security risk that should be avoided.

now i need a new package manager.

Notice that I didn't talk about the node package manager, but about the author and the company NPM Inc. (and their registry service).

It's not that your "build got broken", it's that you had a broken build process. You are the one at fault. You chose (perhaps unconciously) to rely on various entities, their services, their whims, and they proved to be unreliable.

The simplest solution for those who write an application is to commit the dependencies into the repository as well. This significantly lowers the amount of entities relied upon when building it. (Alternatively, have your own registry, whatever.)

Then you can discuss issues like the ideal module granularity, ethics of this or that actor, names and trademarks, etc. without worrying about your "broken build".

Well, now I'll upvote you for saying something else that seems wise, so it's all good.

> I noticed that NPM Inc. didn't unpublish his module, but transfered the name to another account, which is much worse, if you think about it.

Jesus. This is a disaster. At this point, the only responsible thing to do is to avoid NPM.

I feel like the best way to avoid a disaster like this is for developers to avoid using registered brand names when they write their packages.

It's not difficult, since there are all sorts of rights brand owners can't get you on.

1. You don't really need a catchy name for an open source project, since you're not in competition for funds. Call it something descriptive. Descriptive words can't usually be protected, so you should be fine.

2. In most countries, using your personal name is fine irrespective of any IP rights.

3. If you want to use a catchy name anyway, check on the USPTO TESS database for registered rights. If any are live, choose another name.

Remember when Groupon tried to register Gnome for software applications[0], and the open source community (rightly) came out in force supporting the Gnome foundation? But when it's the other way round, it makes no difference.

The problem isn't IP law, it's just bias.

[0] http://www.pcworld.com/article/2846632/groupon-decides-to-le...

...and do the same for the 200+ or so independent countries in the world with their own databases?

You, my friend, are being US biased.

That's pretty interesting. I wonder if it's within npm's legal right to distribute someone else's IP in such a way that they do not desire. Granted the license is WTFPL but does that include taking over the IP itself?

> Granted the license is WTFPL but does that include taking over the IP itself?

IANAL but "do whatever the fuck you want to" would seem to include literally everything including taking over the IP.

Yeah I get the "do whatever the fuck you want" but in a legal sense I wasn't sure that could (or did) include actual ownership. I thought that had more to do with copyright and any other IP transferring. Then again I also said I had no idea :)

The more I think about this license, the more I wonder if it's even legally enforceable. How do you enforce a license whose only terms are that it has no terms?

The WTFPL's own website mentions that it's never been tested in court.

> Granted the license is WTFPL but does that include taking over the IP itself

Well, I'm certainly not a lawyer, but I personally think thats in the spirit of the "Do What the Fuck You Want to Public License"... And at the end of the day the IP is still owned by the original author; the distribution of it has changed.

Uh... which part of "DO WHAT THE FUCK YOU WANT TO" is actually unclear here? Is there a word or phrase that you're not grasping?

"DO WHAT THE FUCK YOU WANT TO" clearly includes not only taking over the IP but also RE-LICENSING IT under whatever terms you like. That's kind of what "DO WHAT THE FUCK YOU WANT TO". Do. What ever the fuck. You want to.

How is this unclear? I'm kind of baffled.

Licensing doesn't really have anything to do with copyright / trademark / IP in general. It just grants you the ability to use something in the way specified.

I'm not aware of case law where a license has been able to move the original IP from one party to another; I've only heard of that happening through standard legal documents.

But I also pointed out that I wasn't sure how it would shake out anyway and was seeking feedback.

But why are you saying the copyright was transferred? I don't see anything that implies that. Someone got a copy of the code under an irrevocable license that grants them to right to re-publish it, and that's what they are doing.

> But why are you saying the copyright was transferred?

I don't think I did?

> I don't see anything that implies that. Someone got a copy of the code under an irrevocable license that grants them to right to re-publish it, and that's what they are doing.

Yeah mostly curious if the original author could, say, use the DCMA or something similar to force npm to take it down if he really wanted to.

I mean, you mentioned "take over the IP" and "move the original IP from one party to another", but I don't see why you're asking that, as NPM hasn't taken over any IP (nor has the new user), they simply redistributed the code.

npm didn't take it over, another user did and npm helped re-publish the unpublished version. I already answered the why I asked that..."mostly curious if the original author could, say, use the DCMA or something similar to force npm to take it down if he really wanted to."

But the user didn't take over the IP, it only took over the name on NPM's registry.

As for the DMCA, usually not since most FOSS licenses are explicitly irrevocable, but with the WTFPL, who knows.

> But the user didn't take over the IP, it only took over the name on NPM's registry.

That's almost the same thing. Like if someone dropped their domain name and you grabbed it up. The customer / user isn't going to notice a difference but it's now being represented by someone else.

I don't think anyone cares enough to really do anything about this though. Mostly curious if it was possible to do something about it but I'm guessing the waters are pretty untested.

Post Berne, I believe copyright is the default. It may be WTFPL but it appears to be surprisingly hard to actually put something into public domain based on the brief reading I've been doing.

> Granted the license is WTFPL but does that include taking over the IP itself?

In some jurisdictions you have "moral rights" in addition to your copyright - but even in those, I'd expect the WTFPL constitutes a license to falsely claim authorship of the covered code. I mean, the text pretty clearly authorizes you to do so on its face, and courts lean pretty strongly towards reading words under their plain, normal meanings. IANAL.

IANAL either, but moral rights are often (usually?) inalienable, so I doubt any license can waive them in those jurisdictions.

That said, I don't think "un-unpublishing" code (even under your own account) is the same as claiming ownership, just redistribution.

Yes, but I can publish an evil left-pad@0.0.10, and if you're not shrinkwrapping or any sub-dependency has left-pad: "^0.0.3", it will pull in the evil 0.0.10 version.

EDIT: I stand corrected. See below, looks that's not the case specifically for "0.0.x" versions, but gets progressively more relaxed if there's a non-zero minor version specified. However, many of the unpublished packages had varying major and minor versions, which would have the more loose caret range behavior.

No it won't... The caret specifier for 0.0.x packages means "this version and this version exactly".

He's right, for `0.0.x` versions it means "this version and this version exactly"

https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004

And to be honest, it's news to me. Sorry i impulse downvoted you...

No problem! It's not super well-known since they switched from tildes to carets and tildes didn't behave that way.

Some examples of how it works:

    ^1.2.3 := >=1.2.3 <2.0.0
    ^0.2.3 := >=0.2.3 <0.3.0
    ^0.0.3 := >=0.0.3 <0.0.4

Why dont they just use that version notation ? (>=0.0.2,<0.1.0) will be much simpler

For every single dependency in most projects that honor semver? ^ is just an extremely convenient shorthand.

You're right, I added an edit to my comment.

That's an interesting side effect.

Wouldn't (shouldn't) npm block same named modules from being uploaded with a different username?

Proposal: go with a java based naming system: com.yc.mymodule.

All installations would require the user to use com.yc.* in package.json and all users would be required to register as a com.yc style organization name. Thus only one user can remove/add that exact module.

npm has namespaces, but they are optional and not hugely adopted as of yet.

Hmm but then is the scope/namespace reserved for each user that reserves/uses it? If I publish @andy9775/left-pad can someone publish under @andy9775/other-module or can only I publish under @andy9775/...?

If so, why is no one using this???

Yes, namespaces are specific to your username. Nobody else can publish packages under your username namespace.

I think it's less common because it was released along with private modules and is often conflated with them. Basically all packages are still namespace-less. TBH I never thought about the benefit they'd have until now.

Ideas for improvement:

- Add 2 factor authentication for npm publish

- When you npm install, add a warning for all the versions that got published without 2 fac

- pre-install/post-install scripts should require user to accept or refuse. The simple action of running npm install shouldn't run arbitrary code.

- make shrinkwrap by default (and fix all the issues with it) so that running npm install doesn't use different versions when used over time.

- make updating a version an explicit decision via npm upgrade

Hmm, how does that help?

  User A: Publish package X1.0 (with 2 factor auth)
  User B: Download with npm package X1.0
  User A: Unpublish package.
  User C: Publish package X1.0, malware code (with a different 2 factor auth)
  User B: Somewhere else, download and install package X1.0

For that to work, every package should be signed in package.js so that when you download a different version, you know about it. Also, I don't think it should be possible to alter previous versions. Package X1.0 should always be X1.0.

EDIT:

Seems like it's impossible to re-upload X1.0, which fix this issue. I thought once a package was unpublished, it was possible to republish the exact same version.

When a package transfers ownership or is removed/re-added, it's not possible to republish the same version as one that has previously existed.

Of course, this doesn't save you if you're installing `^1.0.0`, the maintainer deletes the package, and someone else uploads a malicous `1.0.1`.

The package.json should allow pinning publisher usernames and optionally public keys, and shrinkwrap should pin hashes, not just versions.

I edited my post while you were writing yours ;-) Thanks for the clarification.

This seems like a serious security risk. Is there any solution? Would using version numbers without the caret work?

Signing using private key?

There is no need to sign. Just keep a cryptographic hash (SHA256 is a good bet) of the package in the dependencies manifest, and check it after download.

Using a git repository gives you that for free.

SHA1 collisions are affordable for large actors now and getting cheaper all the time, so git, with its SHA1 assumptions hard-coded, unfortunately doesn't protect you anymore. But the local hash approach is a good one, proven in pip 8 (Python) and npm-lockdown (JS).

More for new versions of same software where the account might be highjacked but hopefully the key wasnt. I dont think a hash would help.

Attacker changes package, then changes hash in manifest to match. Checks pass, users are compromised.

Attacker clones git repo, creates new commit with trojan, pushes to repo with compromised credentials. New users clone compromised repo, others pull and fast-forward. All hashes are valid.

You need to read the Strong Distribution HOWTO: http://www.cryptnet.net/fdp/crypto/strong_distro.html

I don't get it. If I keep a hash of every dependency in my project, and an attacker change a dependency, I will detect the attack by computing the dependency hash and comparing it with the one stored in my project (for example in the dependencies lock file), which cannot be changed by the attacker.

> ...which cannot be changed by the attacker.

That's fine on your personal system, where you manually update your package's dependencies and manually update the hashes of your package's dependencies.

Now, what happens if an attacker compromises the repo where people download your package from? Or what if he executes a MitM attack on the repo or a user who downloads from it? He can change the entire package, including all manifests, all hashes, etc. Users who download it will be none the wiser. By the time someone notices and corrects it, people will have downloaded the compromised versions and be infected.

The only thing that protects against this is strong crypto signatures. For example, if a Debian mirror were compromised and an attacker uploaded compromised packages, users would be safe, because apt would refuse to install the packages, because they would fail signature verification.

Please read the link I gave. It explains everything in detail.

Not only is there a solution, but it's pretty well known computer science. Use public key cryptography to create a digital signature. It's not even a novel use of this -- .NET has been using this to sign assemblies and packages from day one.

I think he means a solution to the current problem of the packages being replaced with malicious ones, not the problem with npm not supporting package signatures.

Package signing by the package's author /is/ the solution, right? This way the only entity that can publish a valid update is the the package author. This still has the problem of bootstrapping the trust relationship, and leaves the door open to the author publishing a malicious but signed package or the signing key being stolen and used to do the same. However if you don't trust the package author to be responsible or take precautions against the keys being stolen then you're essentially taking on the burden of implementing of your required functionality.

We also need some way to link packages to authors. In the Java world packages are supposed to be in a namespace that's the reverse domain name, so you could (potentially, theoretically) connect that up with something like DNSSEC and enforce that people can only publish packages for domains that they control. (Though even that is really just punting the problem up to the DNS registries).

I like your use of "Look, even .NET does this, people".

So we need gpg signed packages :> And... all packages should be namespaced under the author who published them. And... I kind of want to say "once it's published, it's forever".

GPG isn't strictly necessary if you trust NPM's authentication system (of course, that's a big "if" for many folks).

Publish forever (barring requests to remove for legal compliance or whatever) is a good idea. Or at the very least, it should be a default option. And if you install a dependency that isn't "publish forever", you should get a warning.

What if such a system was implemented using IPFS[0] (or similar) for storage?

[0] https://github.com/ipfs/ipfs

I'm surprised all package managers don't use an IPFS-like system that uses immutable state with mutable labels and namespaces. Now that IPFS exists, and provides distributed hosting, it's even easier.

No signatures, no (at least!) an IPFS mirror as a backup option - how can one trust NPM or the likes?!

NPM doesn't even have immutable versions. Many would love to see this improved.

What you mean by that? It used to be possible to republish a version (it broke our build when a dep was republished with a breaking change, that's how I learnt about it) but this was fixed some 2-3 years ago IIRC

As much as I agree, IPFS is still very much under construction and I don't think any known package managers got started after IPFS was reliable.

You can experiment with ipfs-backed git remotes though. That's already possible.

Yes the IPFS implementation might change but not the content multihash addressing. Linking to data with those addresses is the generic 'package management' that solves all these problems (references to mutable data at mutable origins, circular dependencies, data caching, namespace conflicts). The specifics of resolving links will hopefully be something we don't think about much.

I've played around with ipfs.js for resolving links into eval'd js at runtime and imagine a npm replacement would be pretty trivial. The IPFS peer to peer swarm seems stable to me but you could also dump all your hash-named files into a s3 bucket or something as a fallback repo.

gx is a generic package manager on top of IPFS that uses git-style hooks for adding per-language support. It's already being used to manage dependencies on the go-ipfs project: https://github.com/whyrusleeping/gx

Bonus: there's also a IPFS git remote implementation! https://github.com/cryptix/git-remote-ipfs

Somewhat related, I just coincidentally stumbled upon https://github.com/alexanderGugel/ied . "Upcomming Nix-inspired features", to paraphrase their README, could well prevent this debacle.

(And btw, We Nix users very much do hope to start using IPFS :).)

Git has crypto for a reason. Every package manager must have it too.

There’s already apt-get over Freenet: http://127.0.0.1:8888/freenet:USK@oRy7ltZLJM-w-kcOBdiZS1pAA8...

There is already gx package manager: https://github.com/whyrusleeping/gx

Looks like the npm team will not be removing the ability to unpublish packages - see reply by core committer "othiym23" on https://github.com/npm/npm/pull/12017

https://github.com/npm/npm/pull/12017#issuecomment-200131039

There are a lot of problems with NuGet, but they got this right. I do wish there was a way to mark a package as deprecated, though. For ages, there was an unofficial JQuery package that was years out of date.

`npm help deprecate`

Yep, unfortunately the same does not exist for NuGet.

Read the whole thread. Rather concerned by the final one. "Locking temporarily" to get away from the discussion?

That feels sort of like the online discussion equivalent of sticking your fingers in your ears and going "la la la I'm not listening".

I don't expect someone in their position to be unable to ignore a conversation and "take a break" but I would expect them to be capable of doing so without resorting to "suppressing" the ongoing group discussion.

Or it's a "we're discussing internally, and would rather not deal with the shit-show that Github issues becomes once the issue becomes politicized and rampant misinformation and misguided activism take over."[1] There will be plenty of time for people to froth at the mouth and complain that they chose one way or the other once they've made a clear decision, which as of the locking the thread to collaborators, they have not (the current thinking has been outlined, but they said they are thinking about it).

1: See the recent systemd efivarfs issue at https://github.com/systemd/systemd/issues/2402 and associated HN discussions, which was solved through a kernel fix. Pitchforks abound.

I suspect your right, but honestly... His choice of language sounded much less like 'were thinking as a team', and much more like 'your all talking too loudly, you've given me a headache, so i'm going to shut you all up for a while'.

You mean the response that says, verbatim: "I'm thinking about the points that have been made, and I'm sure that we as a team will consider them going forward" ? Sure, he also says for now the behavior won't change, but that's the sane thing to do with the errors are rare, as changing something too quickly may introduce new bugs or unforeseen problems. Honestly, your interpretation of that comment is the exact reason why it's good to shut it down for a little while. The conversation gets so charged that even a "we need time to think about it" response is viewed negatively.

> And... I kind of want to say "once it's published, it's forever".

This is effectively the norm with more traditional, curated package managers. Say I release a piece of open source software, and some Linux distro adds it to their package manager. Under a typical open source license, I have no legal right to ask them to stop distributing it. They can just say "sorry, you licensed this code to us under X license and we're distributing it under those terms. Removing it would break our users' systems, so we won't do it."

The difference is that NPM is self-service - publishers add packages themselves, and NPM has chosen to also provide a self-service option to remove packages. I honestly wouldn't have a problem with them removing that option, and only allowing packages to be removed by contacting support with a good reason. (Accidental private info disclosure, copyright violation, severe security bug, etc.)

  I honestly wouldn't have a problem with them removing that option, and only
  allowing packages to be removed by contacting support with a good reason.
  (Accidental private info disclosure, copyright violation, severe security 
  bug, etc.)

Even Rust's Cargo won't allow you to revoke secrets [1]. I think this is the correct policy.

[1] http://doc.crates.io/crates-io.html#cargo-yank

Aside from secrets there is also sensitive data. If someone accidentally uploads some personal information, they need a way to remove it if, say, they receive a court order ordering them to remove it.

I'm not sure how the court could force you to do something you can't possibly do...

They would force the provider to facilitate the removal.

"So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct." "You're being honest with me." "Yes, your Honor." "Will the computers continue harming the plaintiff's interests if shut off?" "... That would be dreadfully inconvenient, your Honor." "Do you have a more convenient solution?" "No, your Honor." "You are hereby ordered to turn off your computers in 48 hours." "... You can't do that." "I can do a lot of things, including jailing you if you disobey my lawful authority. 48 hours."

Engineers often think that they are the first people in history to have thought "Hey, wouldn't it be easy to pull one over on the legal system?" This is, in fact, quite routine. The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.

How about a blockchain-based NPM? Can't take all the computers down.

Legal, shmegal.

Yep, but someone should implement that first. Package repositories have pretty much centralized control still, and will have for foreseeable future.

You can still be jailed for contempt of the order, though.

"I've found a clever workaround for court orders" doesn't work around that bit.

OK, now tell me how you can remove this file from BitTorrent (it's Fedora 18 KDE)

magnet:?xt=urn:btih:14f146cdfaef83951ca9d3ac647e18e1977d1367

I'll wait

It's not about whether the removal is logistically possible, it's about whether a court can punish someone for failing to carry out the removal.

Even when the former is actually impossible, a court could still punish for the latter. "Ha ha ha I use technology to cleverly show how futile your orders are" is not the kind of thing you want to say to a court with broad contempt powers.

If the "forbidden" action was previous to proceedings and carried out in good faith by unknown parties, it would be very hard to sanction anyone.

The court can't punish you for not being able to do the impossible. That's ludicrous. "We have shut down all of our servers, yes. We can't stop people from downloading this, no"

Pay damages, then.

Pay damages because someone else uploaded something by accident and you can't fix it? It doesn't work like that.

It only doesn't work like that in the context of safe harbor laws.

If the safe harbor law protection doesn't apply, and the defendant is responsible for the illegal behavior, the defendant can absolutely be held legally liable and pay the legally-appropriate punishment.

Why should you pay the damages for something that's not on your server?

That's because all laws make sense and all people who enforce and judge them are understand this.

that's why we'll kurtzweill ourselves into the computers that can't be shut down!

Would that work if you did it before the court order?

No.

Just live outside of the United States, and you'll be fine.

Yeah, there's literally no other courts outside the USA.

Yeah, because the US doesn't have treaties with most of the world...

Or something like http://ipfs.io/

IFPS is cool, however pretty far away from being usable as a package management system... Some package management system could use it as a backend, though.

In fact, gx[0] is such a package management system.

[0]: https://github.com/whyrusleeping/gx

Huh NPM already handles git?

http://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdX...

npm already replicates to hundreds of other servers. Right now, it is practically infeasible to actually remove packages permanently.

> The legal system interprets attempts to route around it as damage and responds to damage with overwhelming force.

In other words, Hulk Hogan vs Gawker.

What Patrick says is technically true. But before granting the "extraordinary remedy" of an injunction, U.S. courts would apply the traditional four-factor test, which includes assessing:

+ the balance of hardships between allowing the conduct in question to continue vs. issuing the injunction;

+ whether the damage being caused by the conduct in question could be satisfactorily remedied by a payment of money as opposed to a mandate or a prohibition; and

+ (importantly) the public interest.

See, e.g., the Supreme Court's discussion of the four-factor test in eBay v. MercExchange, 547 U.S. 388 (2006), https://scholar.google.com/scholar_case?case=481934433895457...

That's why I'm looking into IPFS(https://ipfs.io) as part of my infrastructure. How that would look then, with IPFS...

> "So what you're saying is, your computers cannot possibly not continue damaging the plaintiff's interests." "That's correct."

> "You're being honest with me." "Yes, your Honor."

> "Will the computers continue harming the plaintiff's interests if shut off?" "No it wouldn't, your Honor.".....

And suddenly things like NPM can transfer the data to other machines, and those machines themselves can also provide to others. Deletions are impossible if people still want the content.

And IPFS guarantees that if a single node has the data, then any node can download it and also be part of the cloud that provides the data. Once it's out, it's impossible to retract.

This why sites that don't allow package authors to "unpublish" have contact information so that data deletion can be handled on a case-by-case basis.

If they receive a court order, and there is no technical way to do that, then the court is out of luck. "A court might order it in the future" is not a design constraint on your decisions today.

Sure there's a technical way to do it: you unplug the server hosting it (or more likely, your hosting provider does that for you).

No court is going to shed any tears over fact this has wider consequences than if you'd been able to comply with a narrower takedown request.

This combined with the cost of hosting (I remember the ruby community freaking out over rubygems costs a couple years ago) makes me think maybe we're evolving towards decentralized dependency hosting. Something like Storj where users offset hosting fees with blockchain payments when dependencies are fetched.

The go solution seems more reasonable and achievable- the host is part of the namespace. Instant decentralization.

There's nothing preventing decentralization with npm now; it's a matter of configuration. Tying the namespace to a host seems more like instant excessive coupling.

Tying namespaces to a hostname isn't really that controversial -- it's no different than email.

If you want to be your own provider then host your packages on your server(s) and tell your users to add npm.cooldev.me/packagename to their configuration.

If you don't want to host your own then you can choose from a few public providers like npmjs but then have to be subject to their guidelines, policies, and fees.

Throw in some automatic bittorrent support in the client to help offload costs and you've got something great.

npm already supports all of that except the bittorrent bit, with the proper configuration, and without requiring that idiosyncratic namespace convention. [0] I don't think bittorrent is actually relevant to most use cases. Most people complaining here just don't want their site to go down, so they should vendor or fork all their deps and run their own registry to support that. Downstream users of public modules can either go through npmjs or perform the same vendoring and forking work themselves.

[0] https://docs.npmjs.com/misc/registry

There have been links to child porn in the Bitcoin blockchain. To date, this has not resulted in any courts preventing full nodes from running in the US.

This is what happens with Clojars. It is possible to remove packages, but it requires a manual email to the admins, along with an explanation, e.g. published internal lib accidentally. This prevents scenarios like this, but also cases where people want to 'clean up' things they no longer need, even though others are depending on them.

That's a good idea, but what if Kik lawyers come knocking on your door saying that you're breaking the law and this package cannot stay there forever, or for any moment longer?

Well it shouldn't be hard...oh wait. This is javascript. Good luck then. :)

I think I'd just want to add that namepsacing by author doesn't entirely fix the problem. For the fewer instances where there is a collision, we still have this issue with lawyers asserting trademarks.

"Would the real Slim Shady please stand up?"

We want multiple 'kik's and multiple Shady's simultaneously. So record the gpg sig of the author in package.json, and filter the name + semver against just their published modules when updating.

Depending on how unique you need to be:

npm install <module> --save

npm install <author>/<module> --save

npm install <gpg>/<module> --save

On a side note, npm-search really sucks. It lacks a lot of fine-grained filtering. I'd love to be able to search by tags, or exclude results with an incompatible license, or even prioritize results by specified dependencies. npm-search needs love.

Do they seriously not use any sort of public key cryptography to sign packages? Frankly, for a project that's been around as long as NPM, that's downright irresponsible if that's the case. That's like package management 101.

Most of the programming language Package managers that I've seen either don't have the facility or it's not widely used.

Maven central requires GPG signatures for every package, so all major libraries on the JVM have GPG signatures.

(Whether anyone's checking them is another question, but at least you can if you want to)

I really doubt anyone checks them. It's not integrated or enabled by default, there's no way to pin keys in the build files, etc. GPG isn't the solution to such problems, unfortunately.

In one of my old projects (bitcoinj) we did write a Maven plugin that let you put the hashes of the dependencies into your build file.

However it's rare to see Maven/Gradle builds that accept version ranges. And once downloaded it's cached.

There's a plugin for checking it in maven ( http://www.simplify4u.org/pgpverify-maven-plugin/plugin-info... ) that allows pinning the keys.

Ranges are rare but I'm not sure why - maven actually has very good support for them. I guess it's just that they're not the default?

Version ranges can create inconsistent builds. That's why they're not default and that's why they're not really recommended.

A spectacular failure just waiting to happen.

For example, RubyGems it's possible to sign them, but it's not used as much as it should be because option security never gets used. Waxseal is a gem to sign other gems.

Generally though, it's a worse vulnerability than bitsquatting because it gives quarter to silent, advanced, persistent threats by definition. (Dynamic, untrusted code modification either in-flight or at-rest in difficult to prevent/audit ways.)

The primary way for change to happen is for some company to get hacked, but then it will only change for that one platform because most people are reactive not proactive. Changing this proactively seems painful, but it's less onerous than the risks of the alternatives. The key point is to make end-to-end verification and public key management mandatory and simple.

You can use github and get namespacing under the author.

IMO, this could end npmjs of they don't fix the issue.

And always use head? I think we still need versioning (potentially fuzzy). Also, isn't that what bower does/did?

You can provide any tag, sha, or branch which can be supplied as an argument to git checkout.

You don't get any prepublish hook when pushing to a git repository though, so you can't do things like preprocess with babel, typescript, etc, unless you check in the compiled source.

You do, actually, if you've setup the git repository correctly.

https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Check out the pre-push, pre-receive, update, and post-update hooks.

Those hooks aren't tracked in the repo though, are they? In many cases that will be inconvenient.

They're placed in the repo itself, under .git/hooks, rather than in the working tree. If you want to version them, you can always place a symlink in .git/hooks and have it point to a file inside the working tree. Note that this won't work for bare repositories (which have no working tree), but usually in that case you want a separate deploy process where a sysadmin (or build script) manually copies over files, to prevent a random dev from borking the repository, which a bad update hook can easily do.

(This doesn't help with the GitHub case. But then, as we saw from the recent CocoaPods story, using GitHub as your CDN is probably not a great idea either.)

Well, sure, but that's complicated, and ".scripts.prepublish" in package.json is not. I'd love to have the git knowledge to do what you've described here without googling and frowning, but I don't have that yet, and I've been using git for years. Whereas I could use package.json to accomplish the same task on basically the first day I used npm.

All the more reason to seek better alternatives?

NPM could go blockchain. Tune for fast commits, eventual consistency and slow deletes. Slow enough to allow modules with global names to be replaced. https://github.com/ethereum/wiki/wiki/Ethereum-Development-T...

I'm left thinking of how Go does it, whereby repositories are downloaded via git or whatever version control software's URL. Making it impossible for the admins of "NPM" to take down a package. Add in IPFS and you've got one heck of a "package manager" I guess Go's approach is not really a "package manager" but nobody can truly stop you from downloading from a git repository, and if they do, you can go to the forks etc.

The vendor experiment provides a nice solution to that problem. Check in the vendor directory into your own repository and you always have the required source code available, even after the original author removes his repository on github.

Without IPFS, pretty sure authorities can order to take down the repository and all of the forks.

The same can happen with GitHub repositories, though, that is how the vast majority of Go packages get published.

It's almost as if privately controlled, centralized archives are a bad idea.

1. However, it would deal with GP's problem - that is, that somebody else could upload a package with the same name as one of the ones removed and cause ... surprises the next time someone runs npm install.

Github repos are namespaced to their owners, at least, radically reducing the potential for this kind of thing.

2. /s/github/whatever . As long as there's a public URL from which something can be cloned, the idea still works, as long as that URL doesn't someday point to something completely different. Again, not impossible, but less likely than with NPM.

3. There are, like it or not, real advantages to centralised archives - discoverability, optimisation of dependency resolution, etc. 'Privately controlled' is an elastic idea - it seems to me that there's a difference between a non-profit foundation, say, and a for-profit company like NPM or GH, but both are 'privately controlled'. The question is whether these advantages outweigh the disadvantages. In my opinion, they do.

IPFS with public keys per developer and signing of packages would solve that.

About your third point, discoverability and optimization of dependency resolution can be solved by a proxy, in a decentralized system, like the one used in Go.

Hasn't hurt Java devs any. Although we have plenty of mirrors and no concept of unpublishing.

Except Go isn't GitHub specific, I could use BitBucket, Gitlab, or any service I setup myself. Even locally, just like git itself I suppose. Go supports other tools like Mercurial as well as others.

It's just as bad. Commits can be re-written and/or deleted. I've always been surprised that anyone thought release management based on SCM commits was a good idea. It's not.

Also explaining nicely with real life to the face why you should only use specific versions, or at least specific ranges for your dependencies.

could we just move our javascript package manager to an organisation rather than a commercial company?

then please use named scope as default like@cycle/core @reactivex/rxjs.

That's how it used to be, more or less. Then they commercialized "to better be able to support the infrastructure".

> Is there a plan to address this?

Too late. Every package name on the list has been claimed already by a randomer with unknnown intentions.

Legally isn't it totally NPM as a company to publish existing versions of left-pad because those versions were already released under a license that allows redistribution, whether the author wants them to or not? Or can the author effectively veto this?

Good question. Under something like GPL or Apache, npm (or anyone, really) would have a clear legal reason to continue using and redistributing the code; there's nothing the copyright holder can do about that (unless you actually violate the license terms). Under WTFPL, that's certainly the intent of the license, but I haven't heard any court declaring a case based on WTFPL, so you don't actually know what the courts would make of it. But in general, yes, I'd bet a court would let people do what the f* they wanted once they got some code under WTFPL.

The separate question is: ethically or business-wise, do they want to continue publishing code from an author who explicitly tells them not to? Legally they (almost certainly) could, but as a FOSS business, would they want to?

Software Licenses are pretty easy for the basics - after you read the whole thing.

From what I can tell[0], left-pad was released under the "Do what the fuck you want public license"[1], so I suppose NPM can do whatever the fuck they want, including redistribution.

[0] https://www.npmjs.com/package/left-pad (although I suppose its possible the library was added after the package was re-added -- I don't see a license on the GitHub page)

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

As I understand it, even if a package is unpublished, that does not (normally) free up its name.

Because NPM knows a module has been unpublished, it can try to be smart about it and change existing package.json so there will be no more updates to that module.

I also think dependencies should be non-flat/tree/static. So that you only have to trust one dependency, and not all of it's child dependencies and their dependencies too. You should only need to manage your own dependencies, not other peoples dependencies.

There should also be a way to contact everyone who use your module, so you can tell them about critical bugs etc.

I wrote to kik's chatbot, maybe she has a heart https://twitter.com/andrejlr/status/712887779185831936?s=08

This is extremely severe. Any package i install might after x levels of sub-dependencies pull in one of these names which are potentially pwned. React and Babel pulled in a few of them to take some well known examples.

I would say the whole npm is pwned until these packages are either restored or that the package name is blacklisted/reserved. Is it possible to blacklist packages locally so I get warned if they are pulled in as sub dependencies? I don't trust every package maintainer to be quick enough to remove these dependencies.

One interesting thing to me, is that it is pretty clear that the kik lawyers pretty dramatically over enforced their trademark.

For those who don't know, the purpose of trademarks is to prevent customer confusion; essentially we don't want people to be able to sell cheap knock-offs of someone else's thing without the general public being able to easily distinguish between them. In practical terms, trademarks are "scoped" by their "goods and services" declarations.

For example, Apple the device manufacture[1] and Apple the record label[2] could both be trademarked because they had non-overlapping goods and services declarations... until iTunes started selling music[3].

If you look at kik's trademark application[4], you can clearly see that the trademark is limited to chat/media consumer applications, a pretty obvious over enforcement.

[1] http://apple.com

[2] http://applerecords.com

[3] https://en.wikipedia.org/wiki/Apple_Corps_v_Apple_Computer

[4] https://trademarks.justia.com/858/93/kik-85893307.html

That's not necessarily true if Kik were planning to open up some kind of API. Also, the way the law works in the US encourages corporations to overreach. If you don't try to protect your trademark from every possible angle, it can lead to your loss of it in a court battle. A lot of times, lawyers will send out letters without caring how the recipient responds -- they only need to have sent the letter at all to have covered their bases.

> That's not necessarily true if Kik were planning to open up some kind of API.

Surely opening up a new API doesn't give them retroactive rights to the name in that space.

As someone pointed out in another thread, you similarly couldn't name a package something like "facebook" even if Facebook had no API.

facebook may be a bad example. they named themselves after a generic directory that many colleges have been giving out for decades.

See also: YellowPages.com, Salesforce.com, etc. Just because something exists in real life (and used to describe a non-digital version of the same thing) doesn't mean it can't then be trademarked.

Sum had to change the name of its yellow pages application to nis because yellow pages is copy righted.

You don't seem to be very well informed.

there is a package called facebook: https://www.npmjs.com/package/facebook and it doesn't seem to be owned by facebook?

It doesn't have anything to do with the API. Kik (the company) registered the name and have rights to the name.

Technically, Kik (the company) registered their trademark in the class "Computer Software" [0]. That means that no-one else can use the word Kik (and the logo) for this class of activity. The key issue is when the registration happened. Since they've been going since 2009, and Kik (the software project) only started in 2015, Kik the company was there first.

The reason their lawyers are asking for "Kik the project" to change name is because trademarks can become generic if you're not seen to protect your mark [1]. As a private company (particularly VC funded), IP has a lot of financial value: the business will be valuing their trademark. If they don't protect it then they'll be "throwing money away".

The fact that the business world (and VC's generally) highly value IP is why most people over-register. If they didn't go for wide classes, and then in a few years decided to work in a particular area they might not have rights to their "own name" in that class.

It's a case of the Open Source and Business world-views clashing.

[0] Someone else in the thread found the specifics but the link doesn't work for me. [1] Everyone knows the example of Spam.

> Everyone knows the example of Spam.

Please show an example of someone other than Hormel Foods Corporation marketing a meat product using any derivative of the name 'Spam' and getting away with it.

Spam was mentioned because it's a brand name that became generic because it wasn't protected aggressively enough. Coke, Xerox, and Kleenex are other classic examples of brands that are commonly used generically, and the company owning their trademarks must aggressively send threats (that they rarely follow up on) just out of legal necessity.

Spam very aggressively protects their trademark. So aggressively that it lost a trademark lawsuit against Spam Arrest. (They lost cause people don't get food and junk mail confused)

Indeed, Hormel once sent nastygrams about their trademark to the ASF over our Apache SpamAssassin software. Trademark owners can ask everyone to use or not use their own names. Actually going to court - or actually winning - is far far rarer.

> A lot of times, lawyers will send out letters without caring how the recipient responds -- they only need to have sent the letter at all to have covered their bases.

That is not what happened here though.

Any chance someone at Kik the company wanted to create an npm module and decided the escalation to lawyers was the right way to resolve things? Seems like the lawyer was more interested in getting possession of the name on npm then actually fighting for a trademark. It doesn't even sound like they bothered with a formal cease and desist.

https://medium.com/@mproberts/a-discussion-about-the-breakin...

Guess that answers that. Bob may have been going beyond what he should have or what they intended but in the end he represented Kik and they have to take responsibility for that.

They have the responsibility to defend their trademark, otherwise it could be abused by a rival claiming they did not adequately defend it. That said, NPM could have just said, "No, stop bothering us" and the lawyers might have backed down, satisfied their attempt to defend the trademark fulfilled their duty.

You do not have to defend your trademark against people who are not infringing it. You can only infringe a trademark when you use the mark in the same context it's registered in.

IANAL.

>They have the responsibility to defend their trademark

This is not limited to only issuing cease and desists. Kik Interactive can offer a zero cost license for the trademark if they want to assert their ownership, but let the project continue to use their name.

Some lawyers do not favor low-conflict resolutions, and would not recommend such to their clients.

> They have the responsibility to defend their trademark, otherwise it could be abused by a rival claiming they did not adequately defend it.

Agreed, but you can do this without pissing off everybody in the universe.

http://www.businessinsider.com/jack-daniels-wrote-what-has-t...

Before, I had no idea who kik was. Now, I know them as a bunch of jerks.

Big fail for a "social media" company.

Yeah but literally nobody is going to care about this outside the programmer community, and we're not their target audience.

"Are you a developer? Kik has open-sourced tools and libraries to help you create great web experiences ..."

This is on their homepage. They want developer to use their Pedo enabler API.

They weren't defending their trademark. They overstepped their declared industry and maliciously had another's software altered with no valid reason.

NPM should have already had policies in place to prevent this kind of tampering with its repository.

I hear this all the time but have never seen an actual example? Are there any? (Where defense was existent but perhaps incomplete, not nonexistent)

Yep, I was going to say the same thing. As you say we can look up the US trademarks [1, 2] and see that this mark covers:

    Computer software for use with mobile phones and portable
    computing devices to:

    - download audio, video, digital photos and programs;

    - electronic payment systems, namely, a computer application
      software used for processing electronic payments to and
      from others;

    - computer software for use with mobile phones and portable
      computing devices to create video and digital photos to share
      with other users; computer software for use with mobile phones
      to launch other applications and connect to other software
      services.

That's it.

[1] http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4804:lir...

[2] http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4804:lir...

USPTO Trademark Pro Tip: search links are session specific. Use the blue TSDR button's link instead:

https://tsdr.uspto.gov/#caseNumber=86930821&caseType=SERIAL_...

"Providing an interactive website featuring online non-downloadable software" indicates to me that there could indeed be confusion in a repository of software code to be used by other applications.

I'd suggest it's certainly not obvious over-enforcement.

But TFA's "Kik" seems to be sort of a "project generator" like yeoman or something. There is no overlap between that and even the generously expanded description of the litigious "Kik" that you cite.

So, in your opinion, if I built a software application that let you design and order plate glass in decorative form to be placed in the walls of your house and named this app "Windows" would Microsoft's inevitable attempts at protecting their trademark be overreaching? The windows I named my app for are physical things and Microsoft's are virtual, but I'm releasing a software product called "Windows."

Both kik names exist in the realm of software. There's an argument to be made for confusion.

Yes, even this faintly ridiculous fake example of painstaking mental construction would be overreach. No one would ever download your hypothetical architectural software expecting to get an operating system.

As a public service, some toilet or compost bin manufacturer ought to start "violating" trademarks by naming toilets etc. after litigious companies. We'd all get a kik out of hearing them argue that database consumers are likely to confuse the Oracle database with the Oracle water closet. [EDIT: "Sure it's a CRUD app, but I'm more interested in Deletion than Retrieval!"]

Of course there are arguments to be made; lawyers are involved.

People with experience in software wouldn't likely confuse the two pieces of software. But most people think "computers" and stop there. Most people visiting an app store would see "Windows" for 99 cents, buy it, then complain when it wasn't Microsoft Windows. They wouldn't read descriptions, and they don't know what an operating system is.

Confusion. Microsoft is very likely to prevail in the infringement lawsuit.

Those products would not conflict there isn't a giant category called computers and further you can't just take a generic word out of the English language and take possession. Apple is a generic word for example but not in computer technology.

This matter has even already been litigated. Microsoft Windows is a valid trademark, Windows is not defensible.

Please see lindows aka linspire.

That case was settled and a decision from a court was never reached. That is pretty far from claiming a Windows trademark is indefensible.

Microsoft's claims were rejected by the court, which asserted that Microsoft had used the term windows to describe graphical user interfaces before the Windows product was ever released, and that the windowing technique had already been implemented by Xerox and Apple Computer many years before. Microsoft sought a retrial and after this was postponed in February 2004, offered to settle the case. As part of the licensing settlement, Microsoft paid an estimated $20 million, and Lindows, Inc. transferred the Lindows trademark to Microsoft and changed its name to Linspire, Inc. [0]

Oh yeah, it seems like M$ were on the verge of winning that appeal, and only discontinued (and paid Lindows a multiple of its annual profit) out of pity.

[0] https://en.wikipedia.org/wiki/Linspire

Funny that you picked that example windows is actually not a valid trademark at all. This has been tested in court.

Can you provide a link to a case? The only one I recall is about Lindows and that case settled out of court.

Just a general comment about the whole thread: trademark law is far more complicated and particular than you know (unless you're an IP lawyer; then you might appreciate it). Not only are developers used to problems that can have provable or obvious answers, trademark law really hasn't caught up with the speed of the internet, especially the instant and global reach that a domain name has.

- The only thing you can say about a trademark dispute like this, given the information that's public, is that "it depends on the specific situation as well as the perception of a large enough user base who might get confused".

- Trademark owners can ask (or C&D demand) just about whatever they want. What they could actually force you to do in a court is far, far less than what they typically ask.

The Apple thing doesn't work though, for a specific reason: it's a very common word/name.

Smith is a very common surname. If one person starts the Smith Automobile Company and another person starts the Smith Farm, obviously there's no issue there. That's because none of us invented "Smith", it's understood to be a common name, etc.

On the other hand, if I start "The Google Paper Company", I'm pretty damn sure I would quickly and easily lose that case, despite the fact that google does not sell paper. And nobody would think that is weird, because Google is very obvious an invention (Yeah, I know, "googol", but the spelling makes it unique).

"Kik" is a lot closer to the "google" situation than the "apple" situation.

That is not how trademarks work. Feel free to start the Google Paper Co. Uniqueness is not a merit for trademark infringement. To infringe you have to be a competitor.

That is incorrect. You are also infringing if people could reasonably assume an affiliation due to your use of the trademark, which would definitely be the case with Google Paper Co. You're basically piggy-backing on (and diluting) the brand recognition they've built.

You are correct in that my Google example would likely be trademark infringement because Google is a famous mark. Kik is not a famous mark, so for this case the famous/well-known aspect of trademark infringement is entirely moot.

And keep in mind that the OP I was responding to was arguing that if the name is unique it gets extra protection. That's false. Fame offers extra protection, uniqueness does not.

"According to Kik Interactive, as of December 2015, Kik Messenger had approximately 240 million registered users, and was used by approximately 40 percent of United States teenagers." https://en.wikipedia.org/wiki/Kik_Messenger

Are you sure a court wouldn't consider that qualifying as a famous mark? I'm not going to dig into case law, but my guess is it very well could be.

"Evidence relevant to the fame of a trademark may include sales, advertising and revenue figures; geographical scope of use; channels of trade; registrations in home and other countries; past enforcement efforts; and the results of consumer recognition surveys (provided the survey methods are approved by the courts in that jurisdiction)." http://www.inta.org/TrademarkBasics/FactSheets/Pages/FamousW...

> Are you sure a court wouldn't consider that qualifying as a famous mark? I'm not going to dig into case law, but my guess is it very well could be.

Teenagers represent 9.5% of the US population meaning that 3.8% of the US population (using their 40% figure) have "used" their app. Alternatively the 240 million registered users would imply about 3.5% of the total global population has used it.

I can say that I honestly have ZERO doubt that "kik" would never be ruled famous by any possible measure.

I don't know whether you're right or not, but I do know it isn't prudent to have ZERO doubt about anything - but especially legal matters - without first doing the relevant research. And even then, courts disagree all the time, so I can't imagine ever being 100% certain that a ruling would never go a certain way.

To be even reasonably certain in this case, I would need case law of similarly well-known brands being challenged. Do you have some? Capturing 40% of their target market seems pretty well known to me, but again, that's meaningless without the case law.

That is how some trademarks work. Google is by now a famous mark and, as such, gets additional protection beyond what mere mortal companies do: http://itlaw.wikia.com/wiki/Famous_marks

I guarantee you won't last long if you start a Coca-Cola School of Hairdressing, even though the beverage company doesn't compete for that business.

If that is the case, then it just further invalidates the argument for Kik because it is most certainly not a famous mark.

Famous and "Unique" aren't the same thing. I was responding to the theory that because "Google" is a made-up word, they'll receive extra protections. That's false. That said my example was a bad one, since Google is a famous mark Google Paper Co. would likely be infringement.

Feel free to start Kik Paper Co, however.

Tell that to the Olympic Restaurant (http://www.nytimes.com/1994/11/13/sports/olympics-an-interim...) and Olympia Pizza (http://www.olympiapizza.com/About.html) and Olympic Gyro (https://www.techdirt.com/articles/20120713/06513919689/us-ol...) and Olympic Provisions (http://legacy.kgw.com/story/money/business/2015/02/20/olympi...) ...

Check out the case law about Mcdonalds v Quality Inns (re: McSleep Inns)

Mcdonald's was able to show that there would be consumer confusion DESPITE Mcdonald's not doing hotels nor Mcsleep inns not doing food.

As a result, Mcdonalds basically has an open trademark enforcement on "Mc-" whatever.

While I'm not fond of the judgement here, it was nonetheless decided thusly, and contradicts your otherwise accurate (so far as I know) statement. (And to weaken my own point, I believe Apple lost a similar case about i<whatever>, so nothing here is clear and reliable.)

Most Germans wouldn't know that kik is also a chat app ;-)

"KiK is the largest textile discounter chain in Germany and operates about 3,200 stores in Germany, Austria (since 1998), Slovenia and Czech Republic (since 2007), Hungary and Slovakia (since 2008), Croatia (since 2011) and Poland (since March 2012)."

https://en.wikipedia.org/wiki/KiK

Being from Germany, I had initially assumed that was in fact the company in question. I was wondering why a textile discounter would care about some NPM module...

Haha.

There is a British company selling eCigs called Kik.co.uk too.

Seems Kik is a fairly common term, even for companies.

This shows the claims from kik messenger are not valid, at least in Germany.

I applaud this action and while I'd like to point the finger at NPM, there's no real other method to fix historical package versions that depend on this.

It is worth pointing to the silly state of NPM packages: Who decided that an external dependency was necessary for a module that is 17 lines of code?

  module.exports = leftpad;
  
  function leftpad (str, len, ch) {
    str = String(str);
  
    var i = -1;
  
    if (!ch && ch !== 0) ch = ' ';
  
    len = len - str.length;
  
    while (++i < len) {
      str = ch + str;
    }
  
    return str;
  }

Developers: less dependencies is better, especially when they're so simple!

You know what's also awesome? The caret semver specifier[1]. You could install a new, broken version of a dependency doing that-- especially when other packages using peerDependencies rely on specific versions and you've used a caret semver specifier.

[1] https://github.com/lydell/line-numbers/pull/3/files

https://en.wikipedia.org/wiki/Unix_philosophy

Taking an idea to the logical extreme is an effective means of invalidating said idea. How many UNIX utilities are 17 silly lines long?

A bit of code duplication would go a long way towards bringing sanity to JS land.

Quite a bit are pretty small.

For example: http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c

Erm, that's not a very good example. You're pointing out some ancient source file from back when unix had no package management. These days echo.c is part of coreutils, a large package which is economic to manage dependencies for at scale.

It's interesting to think about the distinction between promiscuous dependencies (as pioneered by Gemfile) and the Unix way. I like the latter and loathe the former, but maybe I'm wrong. Can someone think of a better example? Is there a modern dpkg/rpm/yum package with <50 LoC of payload?

Edit: Incidentally, I just checked and echo.c in coreutils 8.25 weighs in at 194 LoC (excluding comments, empty lines and just curly braces). And that doesn't even include other files that are needed to build echo. Back in 2013 I did a similar analysis for cat, and found that it required 36 thousand lines of code (just .c and .h files). It's my favorite example of the rot at Linux's core. There's many complaints you can make about Unix package management, but 'too many tiny dependencies' seems unlikely to be one of them.

The main point in support of your argument is the fact that Unix utils are bundled in larger packages instead of shipping in single-command packages. Think of Fileutils, Shellutils, and Textutils... which got combined to form Coreutils! Ha! That leaves only Diffutils, for the time being anyway.

But none of Fileutils, Shellutils and Textutils was ever as tiny as many npm or gem modules.

I thought how commands are bundled into packages was the entirety of what we were discussing. That was my interpretation of larkinrichards's comment (way) up above. Packages are the unit of installation, not use. Packages are all we're arguing about.

My position: don't put words in God's mouth :) The unix way is commands that do one thing and do it well. But the unix way is silent on the right way to disseminate said commands. There you're on your own.

Underscore/lodash is a great bundle of functions that do simple things well. And it's a tiny enough library that there is really no need to split it into 270 modules.

I support packages of utility functions. Distributing them individually is a waste of resources when you have tree shaking.

I trust a dependency on lodash. I don't trust a dependency on a single 17 line function.

While I agree with you, tree shaking is relatively new in the JavaScript world thanks to Webpack 2 and Rollup.js before that, if you had a dependency you brought it's whole lib into your project whether you used one method or all of them. So just including Lodash wasn't an option for people who cared about loading times for their users. A 17 line module was.

Closure Compiler's advanced mode (tree shaking) has been around since 2010.

Lodash has been modular since 2013.

What on earth is cat doing that it needs 36KLoC (with dependencies)?

I'm starting to see where http://suckless.org/philosophy and http://landley.net/aboriginal/ are coming from (watch Rob's talks, they're very opinionated but very enjoyable).

Yup! In fact the only other data point I have on cat is http://landley.net/aboriginal/history.html which complains about cat being over 800 lines long back in 2002 :)

I didn't dig too deeply in 2013, but I did notice that about 2/3rds of the LoC were in headers.

>"When I looked at the gnu implementation of the "cat" command and found out its source file was 833 lines of C code (just to implement _cat_), I decided the FSF sucked at this whole "software" thing. (Ok, I discovered that reading the gcc source at Rutgers back in 1993, but at the time I thought only GCC was a horrible bloated mass of conflicting #ifdefs, not everything the FSF had ever touched. Back then I didn't know that the "Cathedral" in the original Cathedral and the Bazaar paper was specifically referring to the GNU project.)"

The version of cat.c here: http://www.scs.stanford.edu/histar/src/pkg/cat/cat.c has 255 lines in the source, and brings in these headers:

#include <sys/param.h> #include <sys/stat.h> #include <ctype.h> #include <err.h> #include <errno.h> #include <fcntl.h> #include <locale.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h>

which are needed for things like memory allocation, filesystem access, io, and so on.

One can imagine alternative implementations of cat that are full of #ifdefs to handle all the glorious varieties of unix that have ever been out there.

yes, let's blow up the entire concept that's worked fine for the ~5 years of node's existence because one dude did something extreme.

Woah woah. Hold on there. Lets not throw around strong words like "worked", "concept", "entire", "fine", "did" when discussing NPM.

This. I'm on Windows. Npm never worked for me, like not at all. Npm has cost me lots of wasted time, I know I should be thankful for this free product, but, but, Grrrrr...

Windows has always been a problem for Nodeland, thankfully Microsoft is working on making that better.

is unpublishing a module extreme?

I wonder how long /usr/bin/true source is.

On Linux, it's 30ish lines, with half of those there to make false.c able to reuse some code. (I know, it's stupid.)

In OpenBSD, it's 3 LoC IIRC.

On at least one OS I worked with, it was 0 bytes long because /bin/sh on an empty file returns true. (I think that was IRIX 4.x.) OTOH, that's slower than the executable from a 3 LoC do-nothing program.

Longer than one might think...

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/true...

Which is useful for binaries. Libraries, there tends to be a lot more aggregation. If this wasn't the case, you'd see libc spread over dozens and dozens of libraries like libmalloc librandom libstring libarithmetic libsocket libprocess libfilesystem libafilesystem (hey, async ops have a different api) libtime, etc.

Why would this be a bad thing? I don't need a random number generator if I just want to allocate memory.

Because a lot of little libraries makes namespaces more complicated, makes security auditing more difficult, makes troubleshooting more difficult as you have to start digging through compatibility of a ton more libraries, makes loading slower, because you have to fopen() a ton more files and parse their contents, etc. Add on top of that those little libraries needing other, probably redundant little libraries, and you can start to see how this can turn the structure of your code into mush really quickly.

At this point, optimizing runtimes to only include necessary functions, and optimizing files to only include necessary functions are both things that are pretty much a solved problem. For example, azer has a random-color library, and an rng library. Having both of those as azer-random or something means that someone automatically gets all the dependencies, without having to make many requests to the server. This makes build times shorter and a lot easier.

Sometimes, in order to best optimize for small, you have to have some parts that are big. Libraries tend to be one of those things where a few good, big libraries lead to a smaller footprint than many tiny libraries.

Not to mention maintenance. Low-hanging fruit here: left-pad, depended on by fricking everyone, <em>is owned by one guy</em>. That is not how you build a serious utility library that people should actually be using in real products. (You also probably shouldn't license it under the WTFPL, but that's another thing). When you aggregate under a common banner, you get maintainers for free and your project might have a bus factor better than 1.

Some of this things you mention are true, but:

> makes security auditing more difficult

What? If you go all the way, you just review all dependencies too. And if they have a good API, it's actually much easier. For example if your only source of filesystem access is libfilesystem, you can quickly list all modules which have any permanent local state.

Splitting huge libraries into well designed categories would make a lot of reviews easier.

> Having both of those as azer-random or something means that someone automatically gets all the dependencies, without having to make many requests to the server.

Also disagree. One-off builds shouldn't make a real difference. Continuous builds should have both local mirror and local caches.

Yeah but that's not the world of NPM. It's a clusterfuck of a maze of near duplicate dependencies with no hierarchy or anything. There's no organization or thought. It's just a bunch of crap tossed together to encourage cargo cults programming.

Think about the test matrix.

Let it suffice to say that Linux distributions (and some closed OSes) try very hard to prevent package fragmentation. Experience has shown many times that excessive fragmentation leads to proliferation of unmaintained libraries.

In this case the npm ecosystem is providing more of a surrogate standard library. Imagine if there were no libc, for example, and so people had to reimplement all those functions; would you really want one package per function because of how "Unix philosophy" it would be?

This is where the JavaScript ecosystem is right now -- JS doesn't have the kind of robust standard library other languages take for granted, so you end up with a lot of these things that look like they should be stdlib functions, but are instead third-party packages the entire world has to depend on for a usable programming environment.

I don't understand the standard library argument at all. Standard library is always limited, there is always something that's not included - then what?

This has nothing to do with the JavaScript standard library but the insanity of NPM. There are modules that have even more dependents than `pad-left` despite being included in the standard library (e.g. https://www.npmjs.com/package/date-now, https://www.npmjs.com/package/is-positive, https://www.npmjs.com/package/is-lower-case)

The argument is that things like formatting a string -- including padding it -- should not be add-ons, they should be built into the core distribution you get as part of the language.

I didn't say it shouldn't be part of standard library, I am saying that there is always something that isn't part of the standard library. My point is: if this module was something that shouldn't be part of standard library, what argument would you then use?

I think you're assuming libc is more robust and useful than it actually is. Libc is extremely minimal (and is full of pitfalls as well).

JS has an extremely large and robust standard library in comparison.

Personally i'm going to use an installable module for something even that small, because i can, and it works.

The benefits from an install registry don't go away just because the module is very tiny...

Why would i spend my time re-inventing the wheel for every little thing i do? And if i'm not reinventing, then i'd be copy/pasting which is much worse. At best that's a waste of time and effort to properly document the source, and at worst it's stealing or license violations.

I don't care if a module is a single line, if it does what i need it to and is well tested, then i'll use it. That might seem silly, but the fact is that it's pretty much no overhead, and no software is immune from bugs (even a 16 line function), so updates might be useful in the future.

Yeah, there is a chance that stuff like this can happen, but within an hour there were several alternatives to solve issues with installs, i'd say the system is working pretty well. Plus with proper software development techniques (like vendoring your dependencies) this wouldn't even be a problem at all.

By this logic, every Stack Overflow snippet should be a module. I'm almost hesitant to suggest this since many people who read this will be capable of building such a thing.

I'm not saying that everything should be a module, but that well designed, well tested bits of code should be modules.

These 17 lines had 100% test coverage and were used by a stupidly large amount of people (read: battle tested), why not use it?

As is pointed out elsewhere in this thread, echo.c is roughly the same size, does that mean it's not a worthy program?

"echo" is not versioned and delivered on its own. It's part of gnu coreutils (which contains ~ 100 utilities), or part of various BSD core distributions (more than 100 utilities, plus the kernel and libc), and also built-in to shells.

IMO that doesn't change anything.

The fact that in JS land it would be it's a standalone module means you get more choice in what you need (no need to pull down 100 programs if you only need 1 or 2).

You have the same amount of choice. There's no reason that you have to use the other hundred pieces of the package. In the Unix world, there's nothing precluding you from deciding to use the FreeBSD version of tar but keeping the rest of the GNU utilities there.

I guess it's a philosophical difference.

But to be fair this would have the same outcome if left-pad were part of a library that included another 50+ libs (that he also wrote and published, and subsequently un-published today).

More choice, but now you need 50 different modules from 50 different authors to duplicate what would be in one good standard library, any of which could have bugs or be pulled out from under you for a multitude of reasons that are beyond your control.

Choice can be a bad thing too - when there are 10 different modules for doing a moderately complex thing, you have to figure out which one is best for your project, and whether it's still actively maintained, bugs are fixed, how do they feel about making breaking changes, etc.

>now you need 50 different modules from 50 different authors

Not necessarily, take a look at lodash and friends. There is nothing stopping bundling of tiny modules into big "libraries" to be used.

As for the rest, you need to do that validation anyway. But if it were bundled in a large library there is MUCH more code that you need to review.

with something like the module "left-pad", it's a no brainer to use the library. I know that it's under an EXTREMELY open license, the code is really small, and by vendoring your dependencies (you are vendoring your dependencies right?) this whole issue would have been a 5-10 minute fix that only needed to be done when you want to upgrade your dependencies next time.

But also, if you're shipping things to users browsers, please cut out all the stuff you don't use. I don't want to download 100 extra module's worth of JS code because it was bundled.

Realistically 17 lines of code is total overkill for this function. In many cases you could achieve the same thing more efficiently in a single line.

Feel free to show a smaller implementation that's more efficient.

I've seen several "one liners" in this thread already, and most of them either blow up when something that's not a string is passed in (regardless of how you view strict typing, js doesn't have it and this shouldn't happen), or are extremely slow comparatively (most of them creating and destroying an array every time they are called).

Plus this has 100% test coverage (even as trivial as it is, it still counts), and is "battle tested" (something like 2.5 million installs per month counts for something).

Sorry, but i'll stick to left-pad vs 20-seconds of thought one-liner.

> Feel free to show a smaller implementation that's more efficient.

How's this:

  function leftpad (str, len, ch) {
    ch = (len -= str.length) <= 0 ? '' : !ch && ch !== 0 ? ' ' : String(ch);

    while (--len > 0) ch += ch[0];
 
    return ch + String(str);
  }

No local variables, less manipulation of the input string, the string grows at the tail which is more efficient, and the code is much shorter.

(With a bit of work you can use the longer ch string that is built to reduce the number of string appends even more by appending multiple characters at once. Although probably not worth it for this function.)

No offense, but that code is much more difficult to understand. If your goal is to minimize the amount of lines, then you succeeded. If the goal is to produce both correct and readable code, then there's room for improvement.

If you are talking about a module that everyone just includes and expects to work, then I'd imagine the goal would be a combination of correct and efficient, not readable.

> No offense, but that code is much more difficult to understand.

I strongly disagree. My code has no magic initializers (the -1 in the original) and a simple linear code path, with no branching. It's very easy to read and understand.

The ternary operator at the top is simply read from left to right, it's not complicated.

> If your goal is to minimize the amount of lines, then you succeeded.

My goal was to maximize efficiency. Often that means less lines, but that was not the overt goal. And in fact this version runs faster, and uses less memory.

> If the goal is to produce both correct and readable code, then there's room for improvement.

You think so?

Then now it's your turn - rewrite this (or the original) to make it as readable as possible. I think you will find that a: mine is more readable than the original, and b: you won't be able to (need to) change much except to lift the len initializer out of the ternary operator in the first line onto its own line.

I wasn't planning on passing a non-string to my function. The type-checking only needs to happen because this is a needlessly generic function

Okay, but then when you pass a string that's just `12` in and get `16` instead of ` 12` don't blame javascript...

I didn't intend to, although since I was going to prepend a string to the start that would be a rather surprising result

Why not just put it into the core? Why should it even be a module at this point?

Because in JavaScript there are many different implementations of engines, and they run on all kinds of stuff. Adding something to the standard is not a small task, and it means that it's now extra code that needs to be installed on practically every single PC.

And that doesn't remove the need for a library like this (or your own implementation) for a long time because you can't rely on a brand new release to be available for everyone.

The overhead is in your management of your dependencies. The size of the module isn't the problem, it's the fact that you end up using so many of them (especially recursively).

Consider this specific case. This author moved all their modules from one hosted location to another. Now, if you want to use these modules from that author, you need to update the scripts and configs that install them (some package.json files in this case). In a better world, like the C or Python world, you might need to update one or two urls which point to a couple of this author's popular libraries (maybe one you use directly, and one used by one of your handful of direct dependencies).

In this crazy npm world, this author has 272 modules. Maybe 20 are in widespread use ... it's already a lot of work to figure that out. Maybe you use a couple directly, and your dependencies have private recursive sub-dependencies on additional copies or versions of these or other of this author's modules! Maybe you have to cut your own versions of some of your dependencies just to change their package.json to refer to the new URLs! Anyway, you probably have to sift through hundreds of your dependencies and sub-dependencies to see if any of them are included in these 272 moved modules.

I've seen npm dependency trees with over 2000 modules (not all unique of course). That's totally unmanageable. I think that's why privately versioned sub-dependencies is a big feature in nodejs: so you can try to ignore the problem of an unmanageable dependency tree. But if you need to make reliable software, at some point you need to manage your dependencies.

I agree that NPM needs to push namespacing much harder, as that would make the whole process much easier.

Also a "provides" field could go a long way into stopping issues like this. Allow packages to say that they provide a package in them that is compatible with another in these version ranges.

That would let "API compatible" packages be dropped in to replace even deeply nested packages easily, and would allow easy "bundling" in big libraries while still allowing easy creation and access to "micro libs".

I really believe that composing tons of small libraries is the way to go, but there needs to be better tooling to make it work. In my (admittedly not extremely expirenced) opinion, bundling many small libs into one big package to make it manageable is a symptom of a problem, not its resolution.

This will become easier with rollup, webpack@2, and so on, which can effectively reduce the penalty of including large modules like lodash by tree-shaking out all of the parts you don't use. I would expect many more utility libraries to then be aggregated into a single package/repo and for users to simply pick and choose functions at will.

Re-inventing the wheel in 17 lines of code is called programming.

> Developers: less dependencies is better, especially when they're so simple!

No! The opposite of that. Lots of little µframeworks, defining composable and generic types, is much better than a giant monolith.

The Swift Package Manager is taking this approach, and I think it's great: https://github.com/apple/swift-package-manager#modules

The caret character doesn't appear anywhere in the semver spec, so whatever that does, it's non-standard: http://semver.org/

If your modules are small and well-defined, they probably won't need many versions anyways - they might just stay on 1.0.x forever. If you want to do something different, it might make more sense to just write another module.

The caret character is a specification in NPM, not semver. It's designed to work within the semantic versioning rules to ensure you get the latest version which includes bug fixes, but also won't include breaking changes.

For example, ^1.3.2 will allow anything greater than 1.3.2 but not 2.0.0. It also has special behaviour that makes it more strict for projects with a major version of 0. If your dependencies follow semver then you'll get bug fixes and security updates without having to do anything or worry about breaking changes.

More info: https://nodesource.com/blog/semver-tilde-and-caret/

...and I am in my little python world with "batteries included"...

And I in Java and .Net world, where it is more like "nuclear reactor included..."

...Only that, in Java, it's not exactly the nuclear reactor you want, which forces you to use someone else's solar power plant, and then they deprecate the original nuclear reactor (because it's known to leak uranium) in favor of a second nuclear reactor, which still doesn't work that well because it's the wrong polarity, so now you have three energy sources available in your project and if you plug your lamp into the wrong outlet everything explodes (see the Date/Calendar mess).

Less dependencies are better. This job is to communicate everything you do in a software project: its reasons and its purposes for every piece. For example, application code that will never be in a public API does not need anything as complex and thoroughly considered than a generic library. When it comes to writing a 10 line function that is represented in an existing module, the most likely reason is that I am writing it for my own purposes and without having to explain why I brought in a package to answer a very small problem.

I implemented KeyMirror from NPM once. It's a simple array->object transformation. It's been in production for months without issue. But, I initially got guff from my boss over it for not using the package. If anything, the package is just an example proof-of-concept of an extremely simple idea. But, carrying the bloat of another package next to more relevant packages seems to be more important here than just merely owning a simple piece of code like this.

This dichotomy is silly. You should write as little code as possible to do the job required, and should use only the dependencies required. This might be none, or nearly everything, depending on what your app or library is supposed to do.

How do you read an article like the one this thread belongs to and come away with "Seems reasonable, I need more of that"?

Trivial dependencies are a code smell, a liability, and an operational headache.

It gets worse than that.

https://www.npmjs.com/package/uniq https://www.npmjs.com/package/array-uniq https://www.npmjs.com/package/array-unique

I think you're mistaken about the caret semver specifier. Using the caret for versions less than 0.1.0 offers no flexibility at all.

For 0.0.x versions of packages the caret means "this version and this version only", so it won't break anything here...

Source: https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004

Having a multitude of small utilities like this is a great thing with many advantages.

It may seem simple to write leftpad, but if 1000 projects that need it all write their own version, there will be at least 2000 more software bugs out there in the wild because of it. If you think that's rediculous, you're not being realistic about the huge disparity in skill levels of industry programmers as well as the considerable rush under which many projects are done.

Also important is that every time I can use a public ally available utility instead of writing it myself, it's one less thing I have to think about. The benefit of making less decisions really adds up, saving a ton of mental capacity to focus on the more important parts of my project. Even the simplest methods require some thought to design.

I know there are disadvantages (such as what happened as the topic of this post), but there are also ways to mitigate them. As far as having many versions that all do the same thing, there is usually winners and losers over time. Because of this I believe that eventually the dependency graph shrinks overall.

Note that I wouldn't advocate creating utilities for things that are not very generalizable.

I've never used npm, but doesn't it take at least as long to find, evaluate, and install a package like left-pad as it would to just write the function yourself when you find you need it?

Personally, no, but even if it did, what if a bug is found in the future? The community fixes the bug, not necessarily you!

The possibility of having bugs in code you don't control (that usually has a clause for no warranties) is an argument for implementing it yourself, not against it. Don't forget how hard it is to get a maintainer even agree on whether something is 1. a bug 2. that needs to be fixed.

Fair point. One does run the risk of having bugs in code out of their control by using a package manager such as NPM, but one gains a swath of other programmers inspecting the modules for bugs. And in module repositories for interpreted languages, its very much in your control to fix any bugs you might find, regardless of what the maintainer might say about it.

If someone already wrote the base code, we can always fork it and fix a bug or add a feature ourselves if it runs contrary to what the original authors desires.

Even getting a response just so you can know what the original author desires can take a long time and there is no warranties or guarantees that you will even get any response. To me, all the downsides that come with dependencies are not even close to worth it for saving 15 seconds.

Who cares what the original author desires?

If you fixed the bad behavior you're experiencing, and the original author's effort saved you hours or days of coding, what's the downside?

Perhaps I'm not arguing for 15 second long code changes. But other than typing a single if statement, what takes literally less than one minute to securely change in any partially-complex project?

The reality, however, is that if you took this point of view, you will spend your time reinventing the wheel, introducing bugs and wasting resources. That's how it works in real life.

Would simply copying something into your project as small as 17 lines make for a good compromise?

No - then you won't get updates easily and everyone reading your project would have to make sure that your copy of the module hasn't diverged from the original module before working with it, especially if it's a larger module that has full documentation and a community of people who know how to work on it.

I've never seen so many programmers advocate copy/pasting code before... it's really surprising!

Something about javascript makes people crazy...

That's what I thought, but what concerns me with 100's or even 1000's of dependencies is managing them. Things like figuring out which ones have security issues without reading the issue tracker for each.

No. I could find, evaluate and install that package quicker than I could write the code that carefully. And the second time I need it, it's just "remember, install". Also, keeps my code small and focused.

Do you not read the code of packages you're including in your projects? I usually do at least browse through the "beef" of the code for anything I consider adding as a dependency. And try to figure out what's the level of maintenance I can expect, history of bugs, sometimes try to contact the authors, etc.

In short: it would take me a whole lot more time to evaluate whether or not to depend on something as trivial as leftpad than to write it myself. I'm pretty confident I can do that in a minute or two and I trust my collaborators to not break it.

It's not one less thing to think about which is exactly the point. If you install 1 dep and it has 100 deps you now have 101 things to think about.

Or, you could look at it, it's 101 fewer things to think about. Besides, we're talking about a package that doesn't have any dependencies.

It doesn't have any dependencies yet -- what if leftpad decides it should depend on "pad", which depends on "stringutil" which depends on "unicodeutil" and "mathutil", etc.

I'm curious since it strikes me as a hard problem to solve: How do you resolve having to deal with security issues with tens or hundreds of dependencies (and their dependencies)? How do you even know whether they have a security issue or a version bump is just a bug fix without digging into each one on a regular basis?

How do you know that you, as a lone developer, aren't writing insecure, unperformant, buggy code?

That's a fair point. But what would concern me, as a lone developer, is liability if you get hacked due to a known vulnerability in an npm module. If the company is looking for a head to roll and someone points out it was a known and resolved issue in later versions that could be a problem for me.

Does npm let you tag releases as security fixes? That would make automation to discover it possible.

NPM itself is clearly faulty, but I don't think the concept of outsourcing logic to dependencies is. If something is complex enough to have a legit security vulnerability, it's probably the sort of thing I don't really want to write myself. And yeah, that comes with the responsibility to stay up-to-date. But pretty sure my head would rightfully roll anyway if I wrote my own bootleg SSH protocol and got my company exploited.

> As far as having many versions that all do the same thing, there is usually winners and losers over time. Because of this I believe that eventually the dependency graph shrinks overall.

That's... very naive. No one goes back and rewrites perfectly working code just to change a library. If it works don't touch it. Computers don't care, and if you rewrite it, you're introducing a bug. Also, there's plenty of new code to write! And oh yeah you have a billion little libraries, all used by an engineering culture constantly distracted by the new shinny, so you're going to be stuck with libraries that that haven't updated.

You're gonna have a bad time.

Someone with more JS experience can chime in, but isn't this really inefficient in JavaScript? Wouldn't appending rather than pre-pending be better due to the way strings and memory are handled? Or at the bare minimum create the left padding in the loop and tack on str after? Can you use ch.repeat(len) + str; yet in node or if not just do the same idea of doubling in size ch until len is satisfied?

    while (++i < len) {
      str = ch + str;
    }

And isn't this a bug?

leftpad("x", 2, '00') will return "00x"

Essentially all JS engines implement string concatenation lazily as ropes so there isn't much difference.

Well, you can do it in O(log(n)) time instead of O(n) time. But n is unlikely to be large enough for this to even matter a little bit.

Less dependencies is definitely better, but that doesn't mean "write the code because we can't install it via npm.

A developer could come along, find this library, and hard-copy it into their source repo. The tested source code is there, and they don't have a dependency on npm.

This wouldn't work quite so well for large packages (chance of bugs is high and so patches are important), but for something like this? Just ditch npm.

The solution (IMO) is between those: Use lodash's padding functions. It's modular by default so you don't bring in the whole library, JDD is a performance junkie, and it's lodash so it's not going to get unpublished.

If not, writing it yourself works too. Or advocate for a better string stdlib.

"A little copying is better than a little dependency" - Rob Pike

> Developers: less dependencies is better, especially when they're so simple!

I tend to agree, but this is conflating the issue of having dependencies with delivery.

It's perfectly ok to build small and compose large, with some of the smaller constituents being external dependencies, but the problem here is that the delivery of the packages isn't immutable and static. When you publish a package to npm, you don't publish it along with a copy of all your dependencies (by default, there are mechanisms to do this however.) The external dependencies will be pulled in separately when people install your package. What you're suggesting could still be done with an external dependency, just by making sure you it's only external at development time, but at publish it is truly bundled along with your package. This obviously comes with other costs, like the inability to dedupe packages.

Who decided that an external dependency was necessary for a module that is 17 lines of code?

This is an advantage of language concision. In coffeescript this isn't even a function, it's just a one-line idiom:

  (ch for [0...len]).join('')[str.length..] + str

Reading some of the comments reminds me old tale about a young man, that every morning on his way to work passed by a beggar and gave him a coin (that was back when coins actually had some value). One morning though the beggar notices the coin is smaller than usual, and he asks:

- Why you gave me a different coin today?

and the young man says:

- I got married and now I'm starting a family, I need more money so I can not give you as much anymore.

And the beggar cries out:

- People, look at this putz, he got married, and now I have to feed his family?!

I think the fact that we get so many awesome things for free is unbelievably lucky. I mean, not only we work in the one of the more generously paid jobs, we also get a lot of the tools we need for free! How cool is that? But some people think that if they are given those awesome things for free, they must deserve it and whoever gives them owes them forever. That's not the case. Yes, it is annoying to find somebody who contributed before does not want to do it anymore. It is mildly inconvenient and it can be improved. But let's not lose the perspective - the author does not owe us or npm continued support. It is sad he does not want to do it anymore, but that's what open source is about - people can take it over, and it happened within a single day. Such resilience is something to be proud of, not something to complain about.

Reminds me of this: https://www.youtube.com/watch?v=7rMpCud1IwQ

> But let's not lose the perspective - the author does not owe us or npm continued support

On the other hand, he wanted his work published in the community registry where they got exposure and were made into dependencies in lots of projects.

When the author offered their modules and then suddenly walked away with them, lots of innocent devs who built their projects with his modules got hurt. He did more bad than good overall, especially that he unpublished hundreds of modules at once without warning, not just one. He should carry some responsibility for that.

The author can publish and unpublish all he wants from his personal site where there are zero expectations that it will continue to exist, but when he's doing it from a public repository where he received a lot of confidence from the community, he should at least make sure his users don't suddenly fall flat. Now people will start wondering if a module with millions of installs in the last month is still going to exist tomorrow.

> Now people will start wondering if a module with millions of installs in the last month is still going to exist tomorrow.

That's a smart thing for people to wonder when there is a very real possibility that it won't. I'm not going to applaud the author's action here, which I consider reckless, but it did bring attention to how fragile this "essential" infrastructure really is.

It's not reasonable to be skeptical of every package. When you do that you get a mess of locally stored packages that end up out of date.

Should really just be a 'publish is forever' mentality

It is absolutely reasonable to be skeptical of every package. You probably shouldn't be on the bleeding edge of packages and likely ought to have locally stored packages.

You of course need to audit and improve your local store, but you need to do that with your dependencies anyway

> When the author offered their modules and then suddenly walked away with them, lots of innocent devs who built their projects with his modules got hurt. He did more bad than good overall, especially that he unpublished hundreds of modules at once without warning, not just one. He should carry some responsibility for that.

Blame NPM. They were the ones shutting down his module and giving it to someone else. That's the first of the crazy parts.

> Now people will start wondering if a module with millions of installs in the last month is still going to exist tomorrow.

That's a good thing. People should be aware of it - and be aware of the fact that all awesomeness of the open source world is maintained by continuous - and often unseen and unpraised - effort of thousands of people. Who are mostly known when something breaks but not much otherwise. It's ok not to think about it every minute, but it's also useful not to forget about it completely - and that we shouldn't take it for granted as it is in no way law of the universe, it is a consequence of continued effort and continued good will.

Doesn't this go both ways, though? NPM developed and maintains the software and servers used to publish and serve this author's packages, bringing the author fame, glory, and as the author is demonstrating, a serious megaphone, all at no cost to the author. If the author doesn't owe NPM anything, NPM shouldn't owe the author anything even for publishing these evidently valuable packages, right?

Taking it a bit further: npm is worthless without useful modules being published. So it stands to reason that module authors should be cautious because the company that runs it clearly won't push back.

I would say that sans a cease and desist, if not a court order, they shouldn't have done anything at all. Certainly shouldn't have turned over the name to them. Better missing and breaking builds then being controlled by someone with completely different intentions.

A more accurate story would be: A young man is giving a piece of wood for free to a beggar. Then one day, when the beggar has constructed a house using the wood, the young man asks it back :

- But you gave it to me!

- It was for free, so don't dare you to complain

If it was given with the (maybe implicit) clause that there was no limit of time, I don't see how the thing being free give you the right to take it back, especially from people who have used it to build something. Sure the first act was charitable, but in the end you cause more harm than good.

It's more like the young man telling the beggar that he can come cut the wood from his land for free. Then one day the young man stops letting the beggar cut his wood for free. He's not taking back the wood that's already been cut. The problem is if the beggar wasted the wood he did take, and took for granted the assumption that he would always be able to get more.

Relying on something continuing to exist on the internet, without making your own backups of it, and you're going to have a bad time.

Despite your username, you're not a douche for pointing this out

Interesting, but there is also the broken builds issue. 100% agree with your last sentence though.

Your builds are broken because your build process made the false assumption that you could always get another piece of wood. You could have used the first piece of wood you were given for your build over and over, but you chose to essentially toss out the piece of wood every time your build finished.

It is instructive what kind of mental contortions people use when they think they deserve something (including continued labor) for free.

We agree that nobody deserves support, I was responding to the story regarding the broken builds issue.

FYI I'm the one who republished left-pad after it was unpublished.

I think of it similar to letting a domain name expire. The original author removed the code and I forked it and published a new version with the same package name.

The main issue was there were so many hard coded dependencies to 0.0.3 so I asked npm support if they could allow me to re-publish that version and they complied since I was now the maintainer of that package.

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

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.

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.

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.

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.

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.

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.

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.

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."

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!

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.

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.

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.

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.

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.

This is a surprisingly effective protest action. It got the attention of an incredible number of people very quickly, and the damage is mostly limited to wasting the time of a bunch of build cops.

I don't have much of an opinion on his actual reasons for protesting, but I do think it was a pretty cool protest.

EDIT: For those with a short attention span, the first paragraph is a drastic metaphor, the second is making my point.

If a kid does not get cookies at home it can shoot all its classmates. Lots of media coverage, the kid will get "the attention of an incredible number of people very quickly".

NO.

For me, publishing code under a FOSS-license means giving back to the community. Anyone who then decides to cause collateral damage in that community was never in for the community in first place. Sorry, that sucks. It causes extra work to developers who rely on your code. They have to spend time to fix a non-issue. Time they could spend with friends and families. If I was a js-coder, the author would be blacklisted for life. If I was an employer, the author would not get permission to publish code created during work hours under a FOSS-license without the company having a private repo. Such a reaction actually costs real money to lots of people. And it is a great disservice to the FOSS-community because it sets a precedent.

I think you missed the caveat about the actual damage caused. Wasting people's time is nowhere close to murder.

And I think you missed the point of my response. I chose a admittedly drastic picture to get across the point about causing collateral damage.

Hyperbolic analogies don't prove points though.

Hyperbolic analogies are a perfectly valid tool for refuting absolute statements, in particular arguments of the form 'the end justifies the means'.

If someone argues that some $noble_end is served by $means_under_debate, as a justification for the means, that argument can be refuted by giving a circumstance where the same $noble_end is served by some $extreme_means where both parties can agree that $extreme_means is never justifiable.

Then once we've agreed that the form of that argument doesn't work, it is reduced to 'the ends justify sufficiently noble means', we can move on to discuss whether the $means_under_debate are sufficiently noble, setting aside the fact they they lead to $noble_end.

You must be really fun to be around.

Really, comparing this to mass murder, well done. It's more like he had a bunch of toys, someone stamped on one of them and he took the rest home with him whilst the other kids are still playing with them.

These are his repositories which he created, he is welcome to remove the code, and others are more than welcome to rehost (as they require).

If you are depending on npm (or any other build tool such as composer, whatever) or on Github, you really need to have a backup plan when the shit hits the fan.

There wasn't any equivocation in the parent between this event and mass murder.

The mass murder example is a counter point to the (implied) argument in the grandparent that "[getting] the attention of an incredible number of people very quickly" is the same thing as an effective protest.

It is possible to get lots of attention for your action without that attention translating to support for you or your cause.

The parent continues to discuss how they believe there was damage above and beyond "wasting the time of a bunch of build cops" and explicitly states what they think the damage would be.

Perhaps choosing a different example would have been more tasteful, and may have avoided this side discussion and being flagged to oblivion, but it did not ever claim the two events were equivalent.

It's possible that the mass murder example, while not directly compared with the original action, is implied equivalent by the mere juxtaposition of the two but I don't think that was the parent's intent.

> publishing code under a FOSS-license means giving back to the community

As far as I can tell his code is still up on github. He removed it from a poorly implemented distribution channel on which many people happen to unwisely depend. I'm amused at how much people are concerned about this breaking apparently production code. It will serve as a good lesson to many inexperienced and lazy engineers, I suspect.

The "attention" he's going to get is people annoyed at him for breaking their shit carelessly over a petty dispute with a third party. I have some stuff at work that uses NPM, and I don't know if he broke it, but my thoughts right now are "fuck that guy" and "I would never use NPM again if I knew how catastrophically badly designed it is" and more broadly "if the JS community is this amateur and petty I'm writing my next server in something else"

> but my thoughts right now are ... "I would never use NPM again if I knew how catastrophically badly designed it is"

Then the protest was effective.

only in the most narrow sense. His cause, whatever it is, isn't furthered, but now everyone involved (including him) looks bad, and a lot of innocent people have had their time wasted fixing something that shouldn't have broken. It's a loss for everyone involved. He looks petty and untrustworthy, npm looks amateurish, kik gets bad publicity, and everyone using this junk is stuck with their face in their palms.

Don't blame the guy who pressed a button that allows you to unpublish a core module. Sure, it was done on purpose this time, but what if it happened by accident. Your "package manager" shouldn't be this fragile.

I can blame both of them.

And how do you look, having used a package manager that allows such an action without preparing for this eventuality?

Your point eludes me. I guess you're implying I'm stupid for having trusted a standard well known tool?

See you in enterprise :`D

Azer has contributed awesome modules to the community, but such a move _obviously_ messes with a bunch of people who previously didn't trust npm, but Azer. Npm works fine. There might be issues with it, but the reason builds are failing right now is that he decided to unpublish all of them - in a move that feels very kneejerky, despite him claiming that it's the opposite.

If this had been actually in the interest of the community (because he thinks that npm isn't acting in our interest), he'd give people a fair warning. I could have lived with a "Hey, this was my experience, it sucked, I'll unpublish things in 30 days. Please update your dependencies." We know how to deprecate things gracefully.

And we wouldn't be talking about it.

If that was his goal, to make noise, then that was a pretty "destructive" way to spark a discussion.

You make a spark to set a fire, dude.

Didn't NPM break builds by completely swapping out the contents of a known module?

Obviously NPM should not be relied on, but this really makes the case.

NPM will arbitrarily modify packages without notice -- this could be the unwinding of NPM.

You give people too much credit. The vast majority won't notice or care.

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

(elsewhere in this thread)

I assume they're talking about the kik module.

I was.

How does a 30-day notice work unless you have a way of reaching out to people using your modules? It just seemed so unrealistic that even 1% of people would actually see such a notice before things start to fall apart.

You bake deprecation notices into npm, to be displayed during install. He has more than 3m installs a month, if he really wanted to, he could have easily display a giant "npm sucks" banner during every single install. Same message, but it wouldn't immediately hurt people who trusted his modules.

> Same message, but it wouldn't immediately hurt people who trusted his modules.

Perhaps he wanted (because of his rage on npm) to hurt people that trust(ed) npm?

I'd be very curious to know if this was true, because the actions taken certainly seem like that's the possible intent.

Our build system eats deprecation notices with eggs for its breakfast. While I'm sure that they exist, I've never worked with a developer who paid much attention to deprecation notices unless they were looking to actively update a module.

They'd notice it when doing a local `npm i` for development.

I highly doubt if most continuous build/delivery systems actually have a person looking at the build output to take some action. That’s why, centralized build systems should not just let the packages disappear but unfortunately that’s not the reality. This is also the reason why there are languages like Go out there that do not rely on centralized package management.

Ironically, this demonstrates the same realization that he had, that when you depend on someone's modules, it is their "private land" too, and when they want to do something rash, they can do it and you will suffer consequences, unexpected and possibly undeserved.

It's the same issue we all experience, trusting people and institutions and finding out that that sometimes that trust can be violated.

> Ironically, this demonstrates the same realization that he had, that when you depend on someone's modules, it is their "private land" too, and when they want to do something rash, they can do it and you will suffer consequences, unexpected and possibly undeserved.

Best comment in this thread.

> but the reason builds are failing right now is that he decided to unpublish all of them

If builds are failing, it's because people did not set things up correctly to account for the fact that npm can and will go down or not be reachable. There are well known, well established practices for handling this. Frankly, if this affects your builds, you probably have bigger issues to address.

npm does not work fine if packages can be trivially removed (even by those who posted them), breaking everyone's builds.

I am obviously a old fossilized ancient developer. This situation seems like insanity.

not the unpublishing part. the part where the thing that you require to sell/publish/do your job isn't under control or isn't stored within your organization.

Am i wrong in thinking that you should just have a local copy of all of your source code dependencies. would it really take that much longer?

It's pretty common, to name only the ones I'm more used to Ruby has gems, Java maven, Perl CPAN, Node NPM, Python pip. All languages have package managers nowadays and has been like that for a long time. They give you the way to make local repositories but I don't know anybody doing it. Maybe developers working inside some companies have some process to go through the company repo. Setting up the repo and maintaining it is quite an overhead and somebody has to pay for it. But I agree that it's the sane way to work, maybe not the most profitable.

Edit: typos

fair enough, but i'm still shaking my head. these places can't have QA departments.

When are you from, 2005?

It's been like this so long now even MS use this model with nuget.

You sound seriously out of touch.

No, he's just careful and professional.

Pulling packages from npm on every build in relying on it seems like fine for a little startup that no one would actually care if it went down for a day or two. That's fine.

But there are plenty of applications where it would be a catastrophic fuck up to break things because someone somewhere decided to delete something.

This is some sort of joke right?

99% of developers will use npm directly, anyone claiming otherwise and also claiming that everyone else doesn't have a QA department because they do this is completely OOT and from a different decade.

This thread has massive upvotes and a mass of comments precisely because this is what everyone does. It's utterly ridiculous to claim otherwise.

your logic is flawless

Yes, I am from a different decade. I am still running things inside plain simple virtual machines, not containers, and using MySQL at day job. I am totally not a cool kid.

Everywhere I've worked has had a local install of Nexus or Artifactory which acts as a caching proxy in front of Maven Central, as well as being a location to store internal builds. Artifactory's pro version can sit in front of pretty much any package repository known to man (NPM, Docker, RPM, APT, Maven, PIP, gem, you name it it's probably in there).

NPM makes it quite awkward to use a non-standard repository, and often builds will download stuff from GitHub on-the-fly rather than hosting all their sources in NPM. It's not my favourite package manager :(. But you're going to need to put your own packages somewhere, and there's little reason not to make that somewhere not also cache your external dependencies.

Not wrong at all. Certainly would have saved people here.

Maybe there's a commentary about progress and the quality of the infrastructure that some incident hasn't made people cache dependencies yet...

In case anyone is wondering what was in the now broken dependency - here is the source code in full:

  module.exports = leftpad;

  function leftpad (str, len, ch) {
    str = String(str);

    var i = -1;

    if (!ch && ch !== 0) ch = ' ';

    len = len - str.length;

    while (++i < len) {
      str = ch + str;
    }

    return str;
  }

https://github.com/azer/left-pad/blob/master/index.js

17 lines of JS causes so much havoc. Knew this would eventually happen, but I thought the code would have been more interesting

the more basic the functionality the more widespread its usage.

I'm using npm / browserify etc in anger for the first time today. This is a horrible issue to have run into and it's left a pretty sour taste.

The fact that it's possible for someone to unpublish 17 lines of js and break the install of major bits of infrastructure for everybody is pretty insane. It seems like at a minimum the dependency tree should be traversed to see what the flow on effect will be. Should it even be possible to revoke an old version that's depended on by other libs?

These few lines of js cost me a couple of hours tonight! :-/

Should one not be able to unpublish? What if there's a bug in a released version, and it's going to take a while to fix? Or what if you simply no longer wish to be associated with the organization anymore?

  > if you simply no longer wish to be associated
  > with the organization anymore?

Given that it's open source, (specifically WTFPL in this case), that's not something you can actually. Or rather, it _is_ okay for npm to republish stuff: that's part of the license.

I don't think it's relevant - if there are other libraries depending on it, the code probably needs to stay. Maybe there's a bug but it's been worked around. The library has been up long enough for others to depend on it and publish their own code using it.

You could have a "soft" unpublish so the module is still available for any libraries that depend on that specific version but it won't be picked up in the "greater than" version case.

In terms of the owner wanting to have it taken down, there should probably be a licence flag that hands control over to the host so at the very least an audit can be carried out before removal.

EDIT some discussion rather than downvotes would be nice. In this case we have a library with a totally permissive license, used by screeds of other libraries, with 2.4M downloads a month. The pragmatist in me says that there should be some mechanism by which pushing a button shouldn't screw up everyone's day. Let's discuss potential solutions.

Rust/Cargo solves this with a `yank` option. Cargo will no longer automatically switch to that version, but if you already use it, nothing changes (though there might be a warning or something)

I don't want to sound like a old grumpy man but here goes anyhow. I was looking into using node.js, react, etc after many years of writing web apps using Python and Quixote (obscure web framework like Flask). The whole Javascript technology stack looks pretty insane of me. Getting a working React environment requires a huge number of packages to be pulled down by npm. Browserify requires a bunch more. Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained? Semver is not a magic bullet.

Also, seems like a security disaster waiting to happen (I don't use CDN because I like to make sure I review code before putting it on my important websites). Linux distributions like Debian have put in huge effort into making a packaging system that is secure and doesn't lead to dependency hell. You can argue how successful they have been but, and maybe I'm ignorant, I don't see the same effort and level of maturity in the Javascript/npm ecosystem.

As an alternative to React, I'm looking at Mithril. It's relatively small and has no dependencies. I'm quite a bit more comfortable building on that foundation as opposed to a giant house of cards.

What dependencies are required? I would have thought that for basic, no-frills use, you could just load react.js and use it with no other dependencies. Are you referring to the tooling setup required for JSX? I've never used react, just curious.

    react_demo$ du -sh node_modules/
    25M     node_modules/
    react_demo$ ls node_modules/|wc -l
    79
    react_demo$ cat $(find node_modules/ -type f ) | wc -l
    287767

I think I installed react, react-dom, browserify (globally), babel. The exact details are not really important, being inexperienced with react I probably installed stuff that is not strictly necessary. However, the ease of pulling in a huge amount of dependent code makes me concerned. For a long lived stable application you will have to maintain those dependencies (at a minimum, have 3rd party maintainers who you can trust to maintain it, not break your app, not inject security issues into your app, etc).

Have had the same experience tonight - browserify etc 12 modules, 75MB, circa 12,000 files. I guess it's just the npm way but it's definitely a bit shocking for those of us who are unfamiliar with it.

That's amazing. I had no idea things were so bad.

But are those strictly react dependencies? Seems more like a demo that was doing a lot more than just using react. Eg, browserify is mentioned, but that's a totally separate project from react, completely orthogonal. So inexperience seems like a big factor here..

It's the ecosystem that's being complained about here it seems, rather than react specifically.

"I don't want to sound like a old grumpy man". Hmm you failed :). On a serious note you might have noticed that there are 2 major camps of node users those who came from web frontend devs & ones adapting node at large scale enterprises/projects (paypal, walmart, netflix, joyent) so as you might guess there are solutions to address situations like this (e.g. run your own registry etc).

The frontend part of my team is using Mithril for a serious project. They seem to be enjoying it. It was chosen for the reasons you listed.

> Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained?

Spot on. Imagine deploying an application, in 2018, that pulls down 1000 libraries, 300 of which are 6 years old versions and contain vulnerabilities (or just bugs) involving data on transit. Who is going to do all the work to backport fixes in every affected version of each library?

If things continue on the current path, I would be surprised if a typical 2018 node/NPM-based application only pulled in 1000 libraries (transitively). I just checked an application under development here:

$ ls node_modules | wc -l 517

Then I checked the current Angular 2 repository:

$ ls node_modules | wc -l 804

(Kudos to NPM 3 for finally flattening node_modules; in addition to reducing duplication and making life less miserable on Windows, it is now much more obvious how the transitive dependencies explode.)

Given the ongoing trend toward each dependency having more dependencies of its own, 1000 doesn't sound like much of a stretch. How many of those 1000+ will be up to date and lacking in critical security or functionality bugs? It sure won't be 100%.

It makes me look longingly at languages which ship with a reasonable standard library.

Javascript has an almost non-existent standard lib. Obviously Python ships with most of the kitchen sink in core. You're not grumpy, but you're misguided.

Why not create one big package that's a lib? Call it "batteries".

In fact, it already exists: Jquery.

A lot of people like to think that software fragmentation comes without any drawback. Having many tiny libraries and/or multiple versions hurts in the long term.

> In fact, it already exists: Jquery.

Not these days. A lot of JS is written server-side. I'd say the likes of Underscore/Lodash are closer to being a JS "stdlib".

You sound like a grumpy old man.

> Recursive dependency resolution is nice and all but isn't this going to create a massive technological debt that needs to be maintained?

Keeping each package small and self-contained reduces the technical debt. If you depend on a monolithic library like Django, an update can be months of work with impact all over your code. If you depend on the same amount of code, but split into 100 smaller libraries, everything becomes much easier to maintain.

> Semver is not a magic bullet

It's pretty close. Having an ecosystem where everyone follows it religiously because all the tooling is built around it is really nice.

> Also, seems like a security disaster waiting to happen (I don't use CDN because I like to make sure I review code before putting it on my important websites).

It doesn't have to be. Reviewing all the code you depend on is a fool's errand IMO, but if you want to do it then NPM makes it very easy.

> Linux distributions like Debian have put in huge effort into making a packaging system that is secure and doesn't lead to dependency hell. You can argue how successful they have been but, and maybe I'm ignorant, I don't see the same effort and level of maturity in the Javascript/npm ecosystem.

The node ecosystem has been very good at avoiding dependency hell. It's well designed. They could stand to learn from Debian on the security front though.

I've been using Mithril for about a year for multiple single-page apps and it's great. I'd definitely recommend it.

> These few lines of js cost me a couple of hours tonight! :-/

Every dependency has some costs and some risks stemming from the need to trust in another person. If you're only using 17 lines of code, those costs dwarf the cost of code maintenance.

Though, there are probably ways to improve the package system such that less trust is necessary. Or even just ways to use the existing system better.

(bit offtopic) but what about:

module.exports = function leftpad (str, len, ch) { return Array(len).join(ch || ' ') + String(str); };

Almost, but the existing code only pads when the str length is less than that of len.

Ahh you are right, all makes sense now, thanks!

You need to go something like:

  module.exports = function leftpad (str, len, ch) { return Array(Math.max(0, len - String(str).length)).join(ch || ' ') + String(str); };

Unfortunately we need to wrap str twice so maybe a one-liner is not quite in place.

Also, this doesn't support zero padding with ch=0.

Cool, I like the Math.max. Two liner then str = String(str);\n...

So this I guess

module.exports = function leftpad (str, len, ch) { str = String(str); if (ch === 0) { ch = '0'; } return Array(Math.max(0, len - str.length)).join(ch || ' ') + str; };

And I did not notice the 0 check in the original code either :-D

The array + join is slower

http://jsperf.com/leftpadtesting

Repeat + slice is too

http://jsperf.com/leftpad

Update: NPM takes "unprecidented action [...] given the severity and widespread nature of the breakage" and un-un-publishes left-pad

https://twitter.com/seldo/status/712414400808755200

Seriously, it's a disgrace that Javascript has such piss-poor string handling built into it's standard library that such a thing is necessary.

Coming in ES7!

Which I might be able to use by 2020 or 2025... Enterprises are still dragging along on IE8 and 9.

This is incredible. They screwed the author about ownership once and then they did exactly the same thing again.

Did they? Most open source licenses aren't revokable - you don't have to stop distributing the code just because the author asks you to stop. That seems especially true in this case, considering the author chose[1] to license left-pad under the WTFPL[2]. I'd say re-publishing the package counts as NPM doing "whatever the f* they want" with the code.

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

[2] http://www.wtfpl.net/txt/copying/

Presumably, if the original author had changed the licence and pushed to npm prior to change of ownership then npm wouldn't have been able to do this?

Sounds like we could start seeing npm specific releases with different licences to the github repo (or npm specific branches with different licencing)

Obviously npm could re-publish the non npm specific code, but that would be more manual than a simple revert of an unpublish.

You can't retroactively change license. Sure, the author could push a new version with a new license, but the old versions would still be governed by the old license.

Even if Azer had relicensed the code, NPM had a copy of the code released under the original one, which can't be revoked.

Yeah, I appreciate that, but if this becomes a general concern that npm can grant ownership to whoever it deems acceptable (even to the point of republishing existing versions), then could we start seeing e.g. WTFPL with npm exceptions style licence fragmentation.

The source could still be readily available to anyone to republish as they see fit, but only as a different name / version.

Not condoning it, just thinking that the original author surely has the right to do this if they plan ahead (judging by the npm backlash that has been building over a single entity holding all the keys some may be starting to think this way).

All open source licenses allow the licensee to republish your code - that's part of the definition. It's not going to trigger license fragmentation because any exceptions will make it not open source.

If you want to enforce that other people use different names for their forks, the usual way to do this is with trademarks - this is what e.g. mozilla and redhat do. Npm should respect your trademarks, and if someone else publishes a project under your trademarked name you can make npm take it down... which is exactly what originally happened here.

Yes, I was rather neutral at first, but this is a complete dick move on NPM's behalf. Essentially they've just given the module to another owner.

If you delete a module, the name becomes free. Someone else grabbed it and publishing code he has a license to redistribute under it. NPM is "only" fudging with the version number, the author gave the module away.

I can't agree. The author licensed the code under WTFPL, meaning he directly authorized anyone to do whatever with it in pretty much the most explicit and unambiguous terms possible.

Here's the WTFPL in it's entirety:

   0. You just DO WHAT THE FUCK YOU WANT

Writing a 15 line function shouldn't grant someone the right to break an entire language ecosystem

I think the real issue though here is technical - does npm really allow mutation of published assets like this? That's a shitty situation that can only lead to unreliable builds

First, you should never have a dependency for 15 lines.

Second, you sound just like people when pointed at modern art says "I could have done that" and I believe the correct response is "you didn't."

> First, you should never have a dependency for 15 lines.

If those 15 lines are called throughout your codebase, you should do what? Re-write the 15 lines and stuff them into a lib that you maintain? And everyone else should do this, too?

If a library is widely useful, it's widely useful regardless of how many LOC it contains.

Yes. With dependency you are giving up control and in return you save time in not having to implement the dependency. If the LoC is small you get practically nothing in return and so the only reason to do it is ideological.

Many times it is even faster to write a trivial "module" yourself than even discover it on npm, let alone reading and verifying it. Hell, NPM 3.x is so slow that it's literally faster to write any 1 liner "module" than it is just to install it.

"Reuse" is just a means to an end, it doesn't make sense to do it only for its own sake.

Pray tell, what is the minimum size that should be required before permitting a dependency? Constant-time string compare is only 5 lines or so, should we cutpaste security critical functions too? "We ran your code on $new_arch and discovered a timing attack." "It's not my fault!@# The professionally maintained and reviewed implementation was too small to depend on!@#!"

This feels very wrong to me. I know, open source, etc., and it's likely that the source license allows it provided the license remain intact, but still... For better or worse (worse, IMHO), the author decided to un-publish his nam modules. He asserted his authority over that package of his code. For npm to usurp his authority, even if the licensing allows it, feels wrong.

By choosing to publish his work as open source, he made it possible for npm to do this. One of the great things about open source licenses if that the original author decides to remove their work (regardless of whether on valid grounds or not), the community can still access it.

If he wanted the ability to prevent who is able to reuse and distributed his code, a proprietary license would have been a more suitable choice.

Nope, nothing wrong. The code he wrote is his, but he doesn't own the npm namespace, which is all anyone cares about here at this point.

But you know what also _feels_ wrong? people who had no involvement in this at all having their day get fucked up because of this one dude who _suddenly_, just now realized that npm isn't going to really help him out and did the internet equivalent of taking your ball and going home.

Agreed, that feels wrong too. But is npm supposed to be the recess supervisor in this metaphor, taking the ball back and giving it back to the other kids?

If he wants to control where people get his software, he should have published it under a proprietary license. Not saying he does, though.

Fair enough. I would posit that he didn't ever expect that the npm folks would undo his actions, even if his decisions were/seemed rash.

He doesn't care if anyone takes over the leftpad module.

He unpublished leftpad

Someone else republishes leftpad as a new owner

Since npm won't allow you to publish old versions, stuff is still broken since the depended on files have a hard dependency on v0.0.3

npm (the company) forces a republish on v0.0.3 or I guess an ununpublish.

The particular license chosen for this module doesn't put any limitations on the code - the 'do whatever the fuck you want' license is as permissive as it gets. If the author doesn't like that, he might want to choose a less permissive license next time around.

This is why you should vendor it. What is "it"? All of it, whatever it may be. You should be able to build your systems without an internet connection to the outside world.

I say this with no reference to particulars of your language or runtime or environment or anything else. This is merely a specific example of something that could happen to a lot of people, in a lot of languages. It's just a basic rule of professional software development.

I agree. I use and love NPM and others like it, but when it comes down to it, i check-in my dependencies when my applications get "released".

Committing the updates is only one more step, and in my experience it's not even another step since we already have a rule that new installs or dep updates need their own commit.

It becomes even more important in an "enterprise" environment. I have machines here which are blocked from executing node.exe (at the time, the binary I had wasn't signed).

I have machines here that have to authenticate via SSPI/NTLMv2 to a proxy to get out to the net. And don't even get me started on the SSL MITM we have here.

I can't run your startup's app here. I can't run your new build tool here.

And the endless list of risk reducing stuff like this (and not just in IT either) is exactly why big companies are slow. Big corps need figure out how to create small disconnected divisions instead of consolidating common services for cost savings. If one of your tiny divisions gets hacked it doesn't take down the rest unless your all on the same systems burdened by the same laundry list of security and policies.

Or have a decent package management setup? Or just use an existing one, it's been working for 20 years. Package management is a solved problem, just use an existing one and move on.

I'm not sure - is there a guide to setting up our own NPM mirror to prevent this happening in future?

I don't think "vendoring" in the sense of copying all your dependencies into your source tree is a good idea. Source and dependencies are different things and well worth using different tools for. You absolutely do want to ensure that your builds are reproducible even if the upstream libraries go away, but there are ways to do that without putting their source in your source tree.

I don't undertand why this isn't the most common reaction, maybe people don't want to take this much responsibility over their builds since they've grown used to it being "taken care of" by these central package repositories for them?

Still relying on internet connection for builds to pass seems rather silly to me.

Sadly there is a user @nj48, who already published empty modules and took the names [1].

Is this a joke or something coordinated with the community?

[1] https://www.npmjs.com/~nj48

EDIT : The hijacked modules look suspicious. http://www.drinchev.com/blog/alert-npm-modules-hijacked/

@nj48 is just some troll who took all the names. Not sure the intention of @nj48. The hijacked modules are not dangerous at this point, but that could easily change and cause serious issues.

I've never felt good any time I have to use node modules and see this gigantic stream of dependencies come flying down. It's even more painful when you need to assemble license information for your software and crawl through _every single dependency and all of their dependencies_ to find their licenses, etc. to check they are OK to use in your software. Just look at the View License info in the Atom text editor some time for a truly insane wall of text (over 12,000 lines!!). IMHO the entire node / NPM system is seriously flawed with so many tiny dependencies for trivial stuff.

Note: There's a cool tool that scans your dependencies and exports all their license info into a csv/json. I've used it before and it's a lifesaver.

https://github.com/davglass/license-checker

I think that unfortunately this was a foregone conclusion. Copyright law, like most other laws in our society, favor corporate interests.

I support his stand on principal, however. Azer is a talented developer and has an impressive life story, and has certainly contributed more to society than a social network well know for invading children's privacy.

https://medium.com/@azerbike/i-owe-my-career-to-an-iraqi-imm...

https://en.wikipedia.org/wiki/Kik_Messenger#Controversies

So, this has nothing to do with copyright law. The word "Kik" is not a creative literary work. It is a registered trademark though:

http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4804:lir...

I don't think there's a problem with trademark law here, I doubt that their claim is legally enforceable against the name of an npm module, as it's pretty obviously outside the goods and services which their mark is registered for. The problem is that npm are capitulating to what I suspect is an invalid request. As is often the case, people are scared of lawyers and forget that they have rights.

Copyright law is not at all related to this. It was a trademark dispute. You might've fallen into the trap of grouping several unrelated laws into "Intellectual Property", a misnomer which confuses confusion when discussing such laws.

Good points...I threw out copyright law when trademark is the better terminology

did you see how he responded to Kik's request? https://medium.com/@mproberts/a-discussion-about-the-breakin...

Not sure I follow this completely...

You start a project with the same name as a company, which owns the registered brand and are surprised when some 3rd party complies with legal suggestions to make an adjustment?

Seems kind of silly to expect that NPM would want to fight for your project name when you didn't seem to do your own due diligence when picking a name. Also, a bit backwards to go remove all your modules as well, therefore breaking builds.

a) from what I understand, his project was there first.

b) NPM shouldn't have to fight it unless they are requested to, the trademark claim was ridiculous to begin with. Regardless of the claim, enforcing it would have taken years... I'm not saying NPM shouldn't have comply with the request and rename the package but definitely could/should have handled this better.

c) the guy wrote: "NPM is no longer a place that I’ll share my open source work at, so, I’ve just unpublished all my modules." I think it's pretty clear why we pull all of his modules.

  > the trademark claim was ridiculous to begin with.

npm's lawyers disagree with you, and they're lawyers.

EDIT: cool HN, -2 for stating a fact. Sure, I don't disagree that this lawsuit is kind of silly, but npm's laywers don't think this suit is _frivolous_, which is what matters.

Layers tend to be conservative, and have also been known to make mistakes. I don't think it's crazy to question their decisions.

3 letters of a NPM developers package? for real?? I'm pretty sure the owners of Kik wouldn't care that that developer package is named Kik. I can find 1000s of mentions of Kik online which validates the trademark. Starting from @kik on twitter to an online project of a random student.

Pursuing a NPM package names?????? for real?!

If you've ever worked with lawyers you would have known that they would always be on the conservative (safe) side without understand the business implications.

If npm's lawyers were Apple lawyers, I think Apple stance on privacy might be different.

Sorry, but was there actually a lawsuit in this case? It sounds more like KIK emailed some people at NPM and NPM just said, "OK", then replaced a known module with some other thing.

It's only a matter of time until NPM is socially engineered into replacing a module with something more malicious, if it hasn't already happened.

There was a threat of a lawsuit. npm's lawyers decided that this threat was not frivolous.

How do you know what they thought? It seems just as likely to me that they didn't see much merit in the complaint, but didn't think it was worth fighting since IP law is such a mess in the US that even clearly baseless complaints can drag on and become expensive.

Because npm stated it publicly on Twitter.

Huh, really? That's strange. I just checked both @npmjs and @izs and don't see any comment on the merits of the complaint now.

I follow a _lot_ of their employees on twitter, and by now, I don't remember which one had the best tweet about it tbh.

Further comment: turns out that npm lied about this. So I'm just straight-up wrong.

Thanks for the followup. Hopefully this moves on to better places.

Given what I know about your politics and philosophy, I find it pretty funny that I have to say this:

1) As "just a fact" it's irrelevant. With some interpretation added, it contributed something. However...

2) As participants in a market economy, the lawyers' primary interest may not be the letter of the law or what is theoretically winnable in court, but what will give npm the least hassle. I'm not sure if that's the case in this particular trademark case, but we all know lawyers sometimes do counsel the path of least resistance. And maybe that's even wise. But it's worth being clear about that ambiguity, rather than just saying "lawyers said it, I believe it."

P.S. I think your comment isn't super helpful but I didn't downvote you.

My point is mostly that often, when it comes to law, lay-people talk about what they _wish_ the law was, rather than what the law actually is. And yeah, lawyers can be wrong too. But sometimes, things that seem common-sense aren't actually legally correct, and this is one of those cases. It does feel silly that a messaging company can threaten to sue over an unrelated software package, but that's just part of how intellectual property law works.

> My point is mostly that often, when it comes to law, lay-people talk about what they _wish_ the law was, rather than what the law actually is.

That is why the law should be formalized such that correctness proofs for argumentations can be given and in doubt even be checked independently by a computer. Exactly because of the possibility of different opinions and wishes, coming up with such a high standard should be considered a maxim.

While I can appreciate this sentiment, I'm also not sure that removing any sort of interpretation is a good idea. Look at the horrible impact mandatory minimum sentencing has had, for example. Flexibility can be bad, but it can also be very good.

> Look at the horrible impact mandatory minimum sentencing has had, for example. Flexibility can be bad, but it can also be very good.

That is rather an argument why in doubt one should not put such harsh punishments into the law - a thesis which I support.

My background is in 20th century Anglo-American philosophy, which spent a great deal of time seeing how far one can push formalization or quasi-formalization of interesting concepts. I wish I had a good capsule version of why I think this won't work, but it won't. Formalization is a tool, and an important one, and there probably are areas where a more formal approach to law could pay off. However, attempting to remove all ambiguity, vagueness and subjectivity is liable to leave you with paradoxical results.

Perhaps you could start with this: to formalize any set of laws and criminal procedure similar to the actually existing law, you'll have to define knowledge, and that is a quagmire (http://www.unc.edu/~ujanel/Gettier.htm--you don't have to read the entire paper, but at least read the first section for a feel of how nasty the project gets. If you need more background, here is the description of what the Gettier problem is: https://en.wikipedia.org/wiki/Gettier_problem).

I just read about the Gettier problem: In my opinion one should better model knowledge as some kind of estimators for probabilities and being justified on some statistical criterion. This should in my opinion avoid the whole Gettier problem (but perhaps introduce some completely different ones?).

I prefer the definition of knowledge given by Orson Scott Card, if I'm not mistaken: something you believe to be true. It doesn't have to be justified and it doesn't even have to be true - you just have to believe it.

I know that the Moon is about 400,000 km away from the Earth. I have never measured the distance and I haven't even tried to check if it's plausible: I read it somewhere and accepted it as such.

There are a near-infinite set of complexities in legal cases. Trying to create a formalism for such laws would require solving the entire field of ethics to decide at which point something might be considered "reasonable doubt".

> to decide at which point something might be considered "reasonable doubt".

As far as I know this is a mostly done problem (google "statistics").

I don't think you understand what "reasonable doubt" means in a legal setting (Google "reasonable doubt").

There's a huge different between an actual lawsuit and the threat of a lawsuit. Kik's lawyers were being bullies, and NPM caved in, instead of standing up for one of their users who seem to have contributed a lot to the community.

> they're lawyers.

Which means if they say "it's very serious threat" and the code gets deleted everybody would think they are serious lawyers even if the claim looked ridiculous - because you see, lawyers said it's serious and who are you to argue?

On the other hand, if they ever say "it's ridiculous" and then they get sued, they could be fired or at least suffer damage to their reputation for not preventing it.

Thus, there is exactly zero incentive for the lawyers - at least ones acting purely according to near-term incentives - to ever take even a minimal risk and declare anything like that ridiculous. They have all incentives to always react as if it was 100% genuine infringement - because that costs very little and has no risk.

Some lawyers and companies are more civic-minded and reject some ridiculous requests and take risk because that's the right thing to do. But you can not require people to be heroes.

On the other hand, we are not lawyers, so we have all the incentives to proclaim how ridiculous the whole thing is.

IANAL but looking at kiks trademark [1] I'm not so sure sadly.

>Computer software for use with mobile devices, namely, computers, personal digital assistants (PDAs) and mobile phones for downloading, displaying, transmitting, receiving, editing, extracting, encoding, decoding, playing, storing and organizing text, sound, images, audio files and video files

Organising text is what Kik (the project) does, so it would infringe the trademark?

1 - https://trademarks.justia.com/858/93/kik-85893307.html

This trademark doesn't cover the word "kik", but the whole design. They have other trademarks too, so maybe there is one that covers just the word.

Regarding (b), did NPM itself have any legal liability? If not, they could simply say "your beef is with the author of the package, but we'll of course comply with a court order that requires us to transfer ownership".

(I suspect, though, that NPM might have some legal liability, and Kik [the company] could sue them regardless, which would suck for them.)

His project is only 6 months old, it seems? Kik has been around for years (I used it a long time ago, before iMessage was a thing).

Is that really silly? Coming up with a project name in an unrelated project in the technology space? That's akin to Ajax Detergent (https://en.wikipedia.org/wiki/Ajax_(cleaning_product)) wanting all jQuery wiped off because there is a $.ajax() function in jQuery. Look, it even has a $! Chaching with every occurrence!

It's not an unrelated technology space! Kik is a messaging platform. It's EASILY conceivable that they might want to publish a nodejs API. It's also easily conceivable someone looking to interact with their platform would type npm install kik. They're entirely in their rights to see this as stepping on their turf.

That. Is. Not. How. Trademarks. Work.

A trademark gives you protection of a mark within a specific industry. "Software" is not a specific industry. They do not get wholesale ownership of the term.

And if you blindly install a module, expecting it to be some official release without looking it up, you're an idiot.

See class 9 of the Nice categories. If you claim a trademark For class 9 it includes "all computer programs and software regardless of recording media or means of dissemination, that is, software recorded on magnetic media or downloaded from a remote computer network." Also mind the way this practically works: A company will try to register a mark in as many categories as possible.

That's just incorrect.

NICE Class 9 is far more extensive than that:

"Scientific, nautical, surveying, photographic, cinematographic, optical, weighing, measuring, signalling, checking (supervision), life-saving and teaching apparatus and instruments; apparatus and instruments for conducting, switching, transforming, accumulating, regulating or controlling electricity; apparatus for recording, transmission or reproduction of sound or images; magnetic data carriers, recording discs; compact discs, DVDs and other digital recording media; mechanisms for coin-operated apparatus; cash registers, calculating machines, data processing equipment, computers; computer software; fire-extinguishing apparatus."

Computers programs are a part of 090373 which has a breakdown of ~100 subcategories.

There are 45 Nice classes. Being in the same top-level class is not confusingly similar. Unless you think Kik Marine Compasses and Kik Instant Messenger might be confusingly similar.

trademarks do not work this way. in order to infringe on trademark, you actually have to be in the same business. OP did not want to fight a legal fight, which is understandable. And NPM can on their own discretion to do whatever they want, and they prefer to avoid legal battles as well.

Here's a highly downloaded 11 line module with lots of dependents.

https://www.npmjs.com/package/escape-string-regexp

I stopped searching at 1.

I've certainly benefitted from the vast ecosystem of npm. I greatly appreciate the work that goes into making this ecosystem what it is. However, I think we need to be a bit more critical when it comes to acquiring dependencies. Especially authors of very prominent packages.

Fun fact: one of my projects (a web api) depends on over 700 unique name/version modules.

Fellow programmers. This is embarrassing.

Sindre basically treats npm as his snippet database. I don't see anything wrong with it.

See:

https://github.com/sindresorhus/ama/issues/10#issuecomment-1...

If NPM wants to stay relevant and a serious contender, they need to have more clear policies in case of IP issues. In this case, the companies weren't even in the same space. Republishing someone's package who has chosen to unpublish and leave your platform is akin to Facebook resurrecting a Facebook profile because they had a lot of friends and the social circle ripple effects would be too high for feed quality for other users, so they chose to reactive the account AGAINST the author's wishes. WHAT?!? We need an open source NPM alternative, yesterday.

As best I can tell, before NPM restored it, Azer had transferred ownership to somebody else, who wanted to republish the old version but couldn't. So they do appear to be respecting the maintainer's wishes.

That's not how the dependencies in npm work, for most who explicitly replied on owner/project-name notation. Even worse, when unpublished, someone (i.e. malicious actor) could have registered a global name for this or one of many hundreds of packages he wrote, and inject malicious code in all projects from babel to react to my side projects. NPM really got caught with their pants down on this one, and veered into the wrong by opting to unbreak tens of thousands of packages vs. doing the right thing.

> We need an open source NPM alternative, yesterday.

NPM is open source.[1] You don't want an open source NPM, you want a distributed consensus NPM where nobody has absolute power to censor or destroy other peoples work.

It seems like a prime use case for a DHT, possibly with some blockchain functionality identifying ownership of namespaces that people can reserve, like namecoin.

[1]: https://github.com/npm/npm

I was referring to NPM as in the npmjs.org project, with is a repository, user management platform, etc. Very interesting suggestion in creating a blockchain NPM hosted alternative, with namespace ownerships.

Wow, very interesting post for me. Earlier today, at work, we ran into an issue where `npm install` was failing because the `shuffle-array` module wasn’t found. Investigation showed that the cause was that it was unpublished today. We found that this was a required dependency of the `match` module and this was in our dependency list in`package.json`.

We investigated and found out that it had been erroneously committed — it’s actually a memory game and has absolutely no place in our webservice project. :) (Mistakes happen… dependency audits can be worthwhile!)

Now, some hours later, I found your post on HackerNews and was really shocked to see, hey, this is exactly why it was unpublished. Quite a chain of events. Never thought I’d figure out why the modules were unpublished, but now I get it! Thanks for the explanation.

[crossposted from the medium article]

funny thing, but assuming that kik is related to kik.com

if you look here http://dev.kik.com/build/, they promote their own server eg. "Our open source web server Zerver can help serve your cache manifest properly, as well as doing other speed boosting stuff like automatic style inlining."

this Zerver is on github and build with npm

https://github.com/jairajs89/zerver/blob/master/package.json

I did not run the build but I'm pretty sure that now their server is not building anymore as it depends on babel

call that irony ;) ?

I had my suspicions that this was all motivated by wanting to grab the npm package name "kik" and the fact that they use node and npm almost cements that for me. I have a feeling this was never about protecting trademarks at all.

I think it's amusing to see this from the perspective of the company. Some guy uses your trademark without your permission so you tell him to knock it off. He refuses, so you go around him, and so he protests... by fucking over all of his users. In a dispute that doesn't involve them. And people are celebrating this.

Yes if you start from the axiomatic base that the earth is flat, a lot of people around you are starting to sound awfully silly.

Then you realize that if your assumptions are wrong, any conclusion from them is valid.

I for one wholeheartedly support him. The more collateral damage he causes, the more people are awareness he raises. While the solution to his problem is unclear at this point, it'll at least get us talking, and find out what all of the stakeholders can do better next time, and we as a community to prevent this from ever happening again. I entirely supports his actions.

"awareness". Awareness of what? His trademark infringement?

Imagine this from the perspective of a hypothetical user. He's cranky and on a tight deadline, and suddenly his project is broken because some dumb dependency three layers away that he's never even heard of broke because some guy decided to throw a tantrum, and now his software is broken and he has to emergency rewrite part of it. All because this guy didn't bother to check if "kik" was a name he was allowed to use.

> "awareness". Awareness of what? His trademark infringement?

Alleged trademark infringement. Since his project was unrelated to Kik's business, it is questionable whether it was actually trademark infringement or over-zealous lawyers.

What if left-pad was trademarked? It's not the developer who decided to throw a tantrum, the lawyers of this company did.

Awareness of how fragile npm is, both in terms of trusting it to always be available for your deploy but also on the mutability of packages there. What if someone unpublished one single well used package and someone else snapped it up to publish malicious code, it could have taken months before somebody noticed.

Bleh, involving brand names or trademarks or whatever on a library that doesn't even seem to be commercial is a pretty dick move to begin with.

And his protest is against npm, who allowed someone to appropriate his work. The users are collateral damage, but really, can you blame the guy? Given the circumstances, urging users to ditch npm isn't a bad idea.

The thing about trademarks is if you fail to defend them, they can be considered "weak" and you can lose your rights to it. If you have a trademark and it's important to you, it's in your best interest to defend it so you don't lose it. It doesn't matter if it's a "dick" move or not, or if the infringement was non-commercial, he was messing with their trademark, and if they want to keep it they have to actively defend it.

[Oops, see the correction at the bottom]

Re: the common refrain that always pops up with these stories about how companies are "forced" to defend their trademarks lest they lose control of them

The issue I have with this argument is that, while I accept that it's largely true that once you try to obtain a trademark in a given domain that you have to defend it, nothing is forcing anyone to overbroadly define the reach of their trademark. Kik is a mobile communication app company without a household name, whose name is an obvious web2.0 style construction (so not unlikely to be replicated by chance) who asserts that their trademark applies to the entire software industry[1]. Kik elected to enter that difficult to defend position, and that's a common decision among companies that get negative press for overaggressively asserting trademarks. These companies are culpable for the social impact of their strategic decisions, and so I have no issue with blaming them for the results.

Asserting a not particularly creative trademark like Kik for the entire software industry was an aggressive stance in the first place, so I don't think that the apparent fact that you can't let competitors blatantly use your trademark without defending it absolves them of culpability here.

When you try to defend a trademark against a tiny, not-for-profit non-competitor, you come off as an entitled bully. Companies should take that into consideration when staking out their trademark territory. It works for some (Trump's hard to avoid here, and at one point it looked like Palantir was using the "I don't care if people don't like me" thing to great gain), but if that's not the DNA of your company, then you should consider whether you're biting off more than you can chew in your trademark assertions. If you can handle the heat of that kind of aggression, then more power to you, but don't come crying about how you are obligated to defend your unreasonably aggressive initial position when you get a little negative press.

[1] Which is almost a misnomer. The software industry is more of a meta industry that touches essentially every other industry these days. This underscores just how aggressive a claim it is that a given trademark covers the entire software industry. It's essentially saying that undue market confusion would result if the name were used for a mobile game, a text editor, an aerospace software testing product, an ETF platform, a medical devices operating system, an animations library, or even a platform for programming robotic legs to kick nearby objects [which would obviously be a more suitable home for the trademark of the identifier 'Kik' :D ]

[edit: grammar]

[correction: @overgard: Jeez, I meant to transfer this comment to a top level comment, because there's nothing wrong with your comment here, it's just related to a sentiment that has seemed to be subtly off to me for a while in a way that I couldn't put my finger on. Reading your comment just kicked off that old thought process that has been churning in my mind for a while.

I didn't intend to tee off on this specific comment, because I really don't have any problems with this specific comment, the aspects that I'm complaining about are really outside the scope of what you are saying.

But now that I know that I forgot to transfer it to a new comment window, and instead responded in this thread, the beginning, which was meant to represent a stronger general argument, looks condescending to me (inaccurately generalizing someone's comment in direct response to them? Ugh... that is sooo not what I was going for). This wasn't at all my intention, and I'm really sorry if it gives that impression. I apologize for any confusion or negativity that the error may have caused.]

You missed part of the story. From the article, it sounds like npm decided to play the "We're a private company" card and was threatening to take control away from him, so he decided to disassociate himself from them. And because of the way npm's system works, this broke other packages and the new maintainers had difficulty fixing the problems.

Aren't trademarks only relevant to products or services?

This was what I was thinking while reading the post.

Also, I recently checked and https://github.com/tylertreat/comcast is still alive and well.

kik.com is a product/service. kik the library is a product/service.

Hey since you love authority, you realize that NPM decided to change the ownership of the kik module without asking his permission right? Life isn't black and white.

About a year ago I tried to unpublish a version of a library I'd pushed to Elixir's hex.pm package manager but the API rejected it. Turns out they only allow you to revert publishing for an hour after you push.

It was a little inconvenient at the time but in light of this I can very clearly see the wisdom of that decision.

This broke a number of builds that depended on the (previously) published modules, here's a GitHub issue showcasing that: https://github.com/azer/left-pad/issues/4

"eventually create a truly free alternative for NPM."

Which will either comply with copyright laws, or get blasted off the 'netz and break everyone's build...

The rules are messed up, but dramatic gestures and abstract hopes that "free software will save us" aren't going to fix them.

This is a trademark dispute, not a copyright dispute. (And since Kik the company doesn't market a product in the field of command-line programmer tools, whether they have a legitimate case is arguable.)

There are other distribution architectures, both organizational and technical, which would be more resistant to IP claims, especially frivolous ones.

Trademark fields are broad AFAIK. "Digital stuff" is a single category, and both kik the messenger and azer's kik fall there.

They also require consumer confusion. I don't know how you could confuse a communications app for a javascript module.

What if Kik uses Node and they broke their own builds inadvertently by enforcing their trademark. 0_0

Small modules they say. Small standard lib is ok they say. Just going to point out that in a lot of other languages, string padding is just built into the standard lib.

brouhaha, this is why you should not put node_modules into .gitignore (same for PHP's composer.lock and vendor/ folder).

To be honest, I have waited for something like this to happen so that people finally wake up and realize how deeply and truly compromised the JS ecosystem really is. 11 SLOC not available any more and all over the internet builds are breaking etc.?!

And please, why isn't essential stuff like this in the JS standard string library?

> brouhaha, this is why you should not put node_modules into .gitignore (same for PHP's composer.lock and vendor/ folder).

You should obviously not do that if you are writing a library. You shouldn't publish vendored modules on npm. If everybody did this everybody would end up fetching 100MB packages.

Not adding node_modules to .gitignore would be a very wrong way of solving this issue.

For a library yes, but if you're writing software you absolutely must. npm actually deduplicates and flattens your dependencies to reduce clutter.

some node modules compile platform specific binaries

Ew yes, haven't thought of that, but the code that compiles said binaries usually can be re-run to recreate the binary.

Better, you should run your own NPM repository, which transparently caches packages from the main repository. Unfortunately, that's not nearly as easy with NPM as with (say) maven -- the only turn-key solution I'm aware of is Artifactory, and then only in the pro version, and configuring npm to use it is a bit awkward.

Here's [1] a list of all modules that were liberated. Some serious land-grab opportunities there

[1]: https://gist.github.com/azer/db27417ee84b5f34a6ea

> Some serious land-grab opportunities there

It sums up the biggest issue with npm. Modules shouldn't be a name but a namespace + a name , just like composer. Someone shouldn't be able to have a monopoly on names like "web" or "async". It should be "some-namespace/module-name".

Absolutely. All packages should be namespaced by org or author. This also brings up a very real malware injection possibility:

* User removes 'alert' from npm, last version was 1.1.0

* Consumers with "alert": "^1.0.0" now have broken builds

* Troll grabs "alert", publishes 1.1.1 with a "postinstall" hook that steals personal data / installs a trojan / deletes data

* Major numbers of development machines and some production environments are now compromised

Shrinkwraps should also include a package hash to protect users against the repository. I'm starting work on a PR to `ied` that will do this.

Does this mean that I can no longer safely run `npm update`, or ask anyone to download my Node.js project and tell them to run `npm install`? Because the npm repo has in effect been compromised and is unsafe to use, until further notice?

That's what I'm assuming right now anyway. I'm not going to upgrade any Node.js dependencies or run `npm update` or tell anyone to run `npm install`.

If you look at the list of liberated libraries ( https://gist.githubusercontent.com/azer/db27417ee84b5f34a6ea... ) — it's "impossible" for me to know which ones of all these libs I use indirectly via some other libraries, and ...

...Elsewhere in this discussion: (https://news.ycombinator.com/item?id=11343297)

> > Is there a plan to address this?

> Too late. Every package name on the list has been claimed already by a randomer with unknnown intentions.

Sounds dangerous to me. ... And I wish there was some way to get notified, when this issue has been fixed somehow.

Even if those trademarks would include a tool like kik, it is completely brainwashed to enable trademarks for three letter words and enforcing them on software packages names.

What are we supposed to type for package names in 10 years. 'abshwjais_kik', or will it be hipster to use unicode like in 'κικ'.

My god! It's full of attack vectors! https://github.com/substack/provinces/issues/20

kinda a dick move to unpublish a module not created by you. but hey NO TIME FOR THAT when your HONOR of naming something kik is in jeopardy from npm.

Definitely, definitely, not a knee-jerk reaction.

Why isn't GitHub the source of all node packages? npm supports it very nicely.

I mean: why don't people write `npm install user/repo --save` instead of `npm install package --save` every time already?

because it does not make sense: I don't want the sources, I want a usable package...

Because there's no version control that way. If I depended upon babel/babel (or whatever it's called on Github), when it changed from v5.x to v6.x, it would have broken my build.

You can ask for a specific tag/branch using Github dependencies using babel/babel#v5.x

In addition to what other people have said, the exact same thing could have happened even if the project was only hosted on Github. Github could receive a DMCA notice, take down the repo and buf.. gone.

Seems odd that a patent lawyer is being involved in a trademark dispute. Also, given the fact that he didn't make any money off it, I severely doubt that it would ever go to court.

If you ask me, I'd bet that it's because the brand behind the 'concerned' trademark is up to something and they are just doing their homework.

Trademark disputes (unlike copyright and patent disputes) are often and need not be about money. US trademark law also has a fun "use it or lose it" provision that requires trademark holders to actively defend their mark.

The package author decided to unpublish the package. A new author has now stepped in and re-published the package (yay open source!) and deps are fixed.

And the reason for unpublishing is at https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...

The incredible resilience/fragility of open source all in one thread: https://github.com/azer/left-pad/issues/4#issuecomment-20006...

NPM 'un-un-published' the needed version: https://twitter.com/seldo/status/712414400808755200

E: Did not realize I was linking the author their own tweets.

Hi everyone, please read this explanation from Kik's head of messenger about how this played out: https://medium.com/@mproberts/a-discussion-about-the-breakin...

We're sorry for our part in creating the impression that this was anything more than a polite request to use the Kik package name for an upcoming open source project.

s/polite request/politely-worded threat/

Good for him, if that platform isn't working go somewhere else.

The major problem here is relying on a central authority like NPM in the first place.

I like how npm even encourages you to create packages in place of the "liberated" ones when you try to visit their now missing pages:

https://www.npmjs.com/package/abril-fatface

  abril-fatface will be yours. Oh yes, abril-fatface will be yours.

  mkdir abril-fatface
  cd abril-fatface
  npm init
  # work your magic…
  npm publish

That's actually their standard 404 message: https://www.npmjs.com/package/lukegt-test.

The problem here is that NPM is a private company in an institutional role.

You will always have some very common dependencies which, if brought down or altered, could compromise a lot of projects.

The problem is that npm has to act like an institution, not like a private company.

My congrats and respect for his decision. Through actions like this companies might understand that the current trademark (and patent) law is only benefiting lawyers.

And wouldn't it be wonderful if as a result of this the build for KIKs Pedo API are broken?

I don't think Kik is the bad guy here. This npm module was rather new (<6 months?), while Kik Messenger has been around for years, and is VERY popular with the young crowd. They are both software. It would be like the author naming his module 'imessage' or 'spotify', except this is with a company that isn't as visible to the HN crowd.

I personally think him not knowing Kik existed was odd, and not googling the name at all even odder. Even still, I think Kik's response and npm's response were perfectly valid.

Looking at the voting of the comments here makes me sad for what has become of the HN community.

The number of coders complaining about an author exercising the basic of intellectual property rights is too high.

1) all coders should understand authors right be the code free or closed;

2) there is no excuse for someone whose value is based on creativity to ignore how IP works (the good and the bad part) because our comfortable incomes come from the protection these rights gives to our work

3) if your code is broken for 11 sloc, maybe you depend too much on others work and you have no value yourselves.

Benevolent persons sharing their code on their free time owes you nothing.

Repay authors whose code you use.

Buy closed source software, and at least respect the free software authors. It costs you nothing already.

> 3) if your code is broken for 11 sloc, maybe you depend too much on others work and you have no value yourselves.

That is very out of touch with the reality of development on the modern JS stack. Babel is a key transpiler that allows people to target multiple browsers with consistent JS, and it was completely broken by this move. Are you suggesting that everyone rewrite their own babel? I guess if they don't they have no real `value`.

I worked in ad industry. We had are own 3k lib with code inspired by jquery to deal with that problem of "fixing the browsers incompatibility", because vanilla JS does ,not exists when DOM/browser functionalities are added to the equation.

I learned to use CSS without framework, and it helps a lot both writing efficient CSS selector and fast loading HTML that is reactive ... and maintainable easy to fix/deploy CSS. Once you learned it.

Yes I suggest that it can be done. But I cannot do it anymore because no modern coders want to learn all that. Thus my CTO, and colleagues always complained that it should not be done this way.

Well ... I used to complain to much dependency is fragile, vulnerable and they say, let us follow the hurd.

I say, your code is expensive to write, maintain, support.

They said no. Else we find no one, and no one wants to learn this ol' shit.

Look where we are today?

The mass can be wrong I guess. Being right makes you jobless but at least when the bubble will explode I will be valuable again. And I will make people pay a lot for my skills of having no skills in babel, angular 2, react ...

Less is more. Especially for a backend coder.

IED [0] + IPFS [1] + GPG looks like a dream come true.

Note: IED could be much faster than NPM installer due to parallel downloads, which would work great with the slower IPFS.

[0]: http://gugel.io/ied/

[1]: https://ipfs.io/

That sounds super neat. I wonder how you could bootstrap a IPFS package repo from an existing one like npm's.

EDIT: just came across an IPFS backed npm registry mirror project: https://github.com/diasdavid/registry-mirror

The good outcome of this nasty incident (especially with the followed hijacking) is that it was a wake-up and (hopefully!) package managers will take notice!

Assuming it's kik.com that complained, the complaint to take down the kik NPM module seems legitimate. They've clearly been around a lot longer, are known by more people, and are in an overlapping market.

It seems like a lot of people would expect a kik module in NPM to be related to the company in some way, and it wasn't.

kik module could have been called kik-messenger

Else even http://www.kik.de/ could claims kik for an API to it's merchandise

Was that lawyer overreaching? I don't know. But for this guy to expect npm to use their resources to defend him (which they may even possibly lose!) and get mad at them is... a bit presumptuous? Github isn't open source either so is he going to get mad when the lawyers send them an email about kik?

If the kik in question is kik.com then

>Are you a developer? Kik has open-sourced tools and libraries to help you create great web experiences that can be discovered and instantly shared by Kik's 240 million users.

Rather sounds like a valid use of the law, not necessarily nice but valid. They are in the same space, open source web development.

Also, they've been around for several years, versus this guy's "kik" project which was created in late October 2015.

It seems like a legitimate complaint, IMO.

It's so easy to avoid name collisions that it doesn't even make much sense to think about it. And trademarks aren't even a feature of the capitalism he so seems to hate: OSS uses names for the same marketing purpose as companies do and larger projects register those trademarks.

NPM Inc like to pretend NPM is infrastructure so they should act like infrastructure. Reinstating the unpublished version of the unpublished module was okay. Taking down a package over an unclear trademark dispute without also informing the author and the public about their reasoning was not.

For all we know the claim may have been invalid and npm just doesn't want to risk legal expenses but because they made the decision in private we won't know until they release the prepared statement.

Lol that satire flipped bit site even caught it http://www.theflippedbit.io/2016/03/23/developer-outraged-as...

Open source community needs to aggregate a list of lawyers who will consult on these sorts of things (related to the community at large) pro-bono. This way all parties on the open source side can feel a little less pushed around and bullied and a little more protected.

The best part would be to learn that the claim was not valid in the first place. At the very least, having representation would provide for some wiggle room where you can have days if not weeks to resolve the issue, instead of feeling you have to take immediate action.

And what if in the judicial system of the country that the programmer lives in there is a different legal situation than in the country that the Node.js Foundation (the US)? And what if there are npm mirrors in third countries where the legal situation is different in a third way?

Can we talk about how patents own namespaces? If I have a little "kik" soccer tournament that no one knows about, then it's fine. As soon as the namespace collides with the HUGE, vastly connected internet, it's a "problem".

We're going to run out of proper nouns, folks.

> Can we talk about how patents own namespaces?

This has nothing to do with patent law. It's a trademark dispute. The two types of laws are as unrelated as property law and contract law.

Also: https://twitter.com/seldo/status/712414400808755200

In all honesty, I think npm handled this whole situation poorly. I'm not excusing the dev's behavior but I take issue with npm removing the module as well as arbitrarily restoring left-pad (with the cop-out of same name, different dev) WTFPL notwithstanding.

For those defending Kik's trademark, its like MS trying to trademark the word Windows. Didn't work that well for them either.

https://en.wikipedia.org/wiki/Microsoft_Corp._v._Lindows.com....

kik has lawyers all over the world... because it is the platform of choice for pedophiles and sexual predators. there are many billable hours spent responding to doj/states attorney subpoenas. (http://www.trentonian.com/general-news/20140728/pedophile-on...) (http://woodtv.com/2015/02/02/sexual-predator-warns-parents-a...)

I've been warning of the potential for issues like this for quite a while and would be really grateful for people's feedback on this approach to try and insulate your projects from them https://github.com/JamieMason/shrinkpack.

Its not completely there yet, but I think there's something worth exploring further in this idea.

So what keeps Kik from going after Github?

https://github.com/starters/kik

Github has proper lawyers.

Well, nothing - in fact, you should remove your comment, because if leadership from Kik sees it, they'd technically be obligated to initiate legal action to defend their trademark. The likelihood that they see it is very low, but...

I am a heavily invested user of JavaScript and the surrounding ecosystem and the security aspects of the npm package system has been in the back of my mind for a while. As I don't consider myself an 'expert' in all things npm and package management I've deferred to the general consensus, which didn't seem to mind too much about the security problems npm exhibits (This reminds me of the sub-prime crisis).

I think an event like this is a really positive thing, as it promotes discussion about something that is exceedingly important. All it takes to exploit this vulnerability is a bit of time and effort, it looks really easy to inject malicious code into any number of 'de-published' packages. I hope that some kind of name spacing and / or locking of npm packages results from this and that the javascript ecosystem continues to mature and develop in the right direction. Npm inc have an opportunity here to do the right thing. If they don't then there's going to be a mutiny and a 'better' alternative will supersede npm. Bower anyone? ;)

I've been reading in the comments regarding 1) the practical effect of breaking builds and 2) the security issues of how package names can be reused on npm once they are unpublished (versioning aside for a moment).

I wonder what other, similar, packaging distribution platforms are vulnerable to this sort of thing? I am not speaking from knowledge of any of the procedures of any of those I'm about to mention, but I have and do depend on some them. Thinking about this issue and some of those other tools that pull long strings of dependent packages does give me pause. Especially the replacement of some dependency with less than friendly code... breakage can be managed, but silent invaders...

Does Perl & CPAN, Rust & crates.io, or Ruby & RubyGems.org suffer these same issues and it just just hasn't been a problem yet? Do they have means of avoiding this? Again, I haven't studied the question... but I think I may :-)

With crates.io, users cannot delete their packages. They can 'yank' a version, which means that no new packages can depend on it, but existing packages can.

So in this specific case, there are two packages: kik, the subject of the legal threat, and left-pad, another module by the same author. If we were compelled through legal means to remove a package, as administorators, we could, which is what happened with kik. However, if said author got mad at us, they couldn't _delete_ their other packages, only yank them, and so people's builds would not break, like they did here.

Does that make sense?

(IIRC Rubygems acts in the same way)

It does. Given that I've started a project in Rust which will have such dependencies, I feel even better that clearly there has been some good thinking put into this.

I've had deploys break because gems were removed from RubyGems.org. Using CI as a gate isn't sufficient because a gem can be removed in the window between a completed CI run and the deploy. Making it harder, generally if you have a gem installed locally you won't notice the problem until you need to install it on a fresh system.

It used to be the case that a yanked gem was simply removed from the gem index, but the file was still published, so you'd still be able to install it. Now the gems are deleted, eliminating that option.

So, other systems are definitely susceptible and it does burn people. I just don't think we've seen an issue on this scale yet. The largest I've hit have been when the twitter gem was yanked in advance of Twitter's shutdown, a fog-XYZ gem being yanked as new versions were released, and at least one yanked version of net-ssh.

The only really effective way to avoid this is to mirror all your dependencies yourself (and not honor upstream yanks) or vendor all your gems. I know of exceedingly few people doing this.

I've yet to encounter a legitimate cause for a yanked gem. But I worry more that a bad actor gains credentials to a high profile account and just wreaks havoc on the ecosystem. On that note, I have found and reported users that've committed their RubyGems.org credentials to GitHub in a "dotfiles" repository.

Dear Everyone Doing Devops: do not build gems on your production servers. Build a tarball, test the tarball through dev/staging, deploy the tarball to production.

For any value of tarball- literal tarball, deb/rpm (actually CPIO under the hood, but who cares), prebaked AMI (not tar at all), docker image (tarball of JSON + nested tarballs. Seriously, it's tar all the way down).

Everything will be better. Roll forwards. Roll backs. Speed. Attack surface. Reliance on 3rd party services that will rate limit you hard.

http://martinfowler.com/bliki/ImmutableServer.html

Your point is well-taken. Broken deploys are just the extreme case. You'd run into the same problem if two devs on the team just happened to install libraries at different times. One would get it, one would not. And you don't get a remotely helpful error message in that case. So, you're back to mirroring or vendoring everything you need anyway. Arguably that's better, but why even bother with a centralized package management system at all then?

Does this series of tweets [0] seem rather odd to anyone? He seems to be calling people soulless and pondering his own "Power and Responsibility".

[0] https://twitter.com/izs/status/712510512974716931

That is some serious highfaluting language going on in those tweets. Something something if you play the game something something...

The whole thread is just really astounding. I am rather neutral on the drama here, but I am certainly coming away with a real distaste for npmjs just from reading that.

You and me both. I wish I could up-vote your comment twice!

The problem here is that there is a single petname space (pet namespace? pet name space?) administered by one organisation but used by everyone.

With a different system, the author could have a key $foo, and call his package ($foo kik), and that wouldn't interfere with (us-trademark-office kik).

As done by Maven for a decade.

But hey, Java sucks, move fast and break things, right?

Wow, this is an amazing outcome here.

Why is "unpublishing" something that can happen in npm? What's the point? I can see the downside, what's the upside?

A few reasons off the top of my head:

* People sometimes accidentally publish bad info. Passwords, private keys, personal information, etc... being able to remove that is a big plus

* if a critical security issue were found in a package, removing that version and adding a new one will practically "force" updates to happen.

that first bullet point really makes sense to me - feels like there's "no right answer" for that one. i wonder if some kind of time frame would help - one has 72 hours to unpublish, etc.

thanks for answering!

Maybe one possible way to fix this problem is to let you unpublish it as long as no one else downloaded it. I.e. once I've got your security, then you're already compromised and you need to change it.

Why don't people just use lodash?

https://lodash.com/docs#padStart

It's well-tested, well-maintained, performant, with good documentation and has custom-build to leave out functions you don't need.

I had that same thought the other day. We are ending up with thousands of 11-line "micro-libraries" that just cause huge dependency issues and have limited usefulness. Like you said, lodash is well-tested, well-maintained and performant with good docs. So why isn't it just used more by these libraries? It shouldn't be a size problem either, if you really want to you can require individual lodash functions in node.

My project didn't 'use' left-pad -- yet it was affected by its removal. The story here is not about the specific project that was removed but that in the npm architecture it is possible for a single maintainer to negatively affect hundreds of people and projects with ease.

And when a lodash (trademark holding) company knock the door and sey "hey, you cant use lodash anymore", what happen then? Will npm remove it or replace it?

If there was ever an issue I'd work with npm to come to a resolution that didn't break 25% of npm.

Why yes, depending on a third-party, external package manager is a huge risk. I have always believed that open source projects should be fully inclusive of any and all dependencies. This event has not changed that opinion.

There's a PR open to remove "unpublish" from NPM here:

https://github.com/npm/npm/pull/12017

I love how it was said that something like this has "only happened 3 times in the last 2 years". The fact that it's so easy to break npm is hilarious, and of course the maintainers don't care.

This is a really bad decision on npm's part. Kik's laywer has pulled a fast one on them. Kik has no right to enforce the Kik trademark beyond the limited set of goods and services listed in the trademark application [1]. Kik is a registered word mark for mobile messaging software only. That's why the trademark database contains many entries for just the word Kik, other companies own the use of that word for other goods and services.

I'm really surprised that npm didn't push back against this. It's not like npm isn't full of trademarks:

https://www.npmjs.com/package/pepsi

https://www.npmjs.com/package/coke

https://www.npmjs.com/package/kfc

https://www.npmjs.com/package/virgin

https://www.npmjs.com/package/sprint

https://www.npmjs.com/package/nba

https://www.npmjs.com/package/nfl

https://www.npmjs.com/package/google

https://www.npmjs.com/package/yahoo

https://www.npmjs.com/package/skype

https://www.npmjs.com/package/word

https://www.npmjs.com/package/excel

https://www.npmjs.com/package/unix

https://www.npmjs.com/package/windows

https://www.npmjs.com/package/osx

[1] http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4804:lir...

Trademarks: even more understood to modern programmers than C++ multiple inheritance.

Trademark owners - especially registered ones - can ask you to treat their mark any way they like. Legally, they can only try to enforce the basics of trademark law, but trademark litigation is typically expensive and risky.

USPTO Pro Tip: links to their search are session-specific. You have to use the blue TSDR link to share:

https://tsdr.uspto.gov/#caseNumber=86930821&caseType=SERIAL_...

I don't see the issue here. If the name is taken the lawful way (and Kik is a clothes store chain as well as a chat app, so it's even taken twice) why fight it or be angry about it? Just take another name.

That said the decisions by NPM are also hard to follow. Why allow someone else to take over ownership of a package? Why allow anyone to take down published versions of an open source package? If you publish open source stuff on my site I have all the right to keep that stuff in that version and share it with others. That's pretty much what FOSS is about, right?

> This is not a knee-jerk action.

The only thing knee-jerk and honestly irresponsible is not warning anyone first, especially knowing how much his modules were depended upon.

Otherwise, there's nothing wrong with this.

The whole point was demonstrating what npmjs.com has reserved the right to do to any user at any time.

Sounds like npm didn't give him advance warning for kik either, so way to prove a point.

npm really shouldn't let authors unpublish. It should definitely be impossible to overwrite a published package version (it is, but only for the past year or so).

When you install express, you install 40 dependencies. Each of these has separate maintainer(s) and coordination is optional. If we're going to allow this dependency mess to grow organically, npm needs to be strict about what gets published and we need to be really careful about depending on anything but a strongly pinned version.

Quick script to test if your project is using any of the modules he unpublished:

  for module in $(curl -s https://gist.githubusercontent.com/azer/db27417ee84b5f34a6ea/raw/50ab7ef26dbde2d4ea52318a3590af78b2a21162/gistfile1.txt); do grep "\"$module\"" package.json; done

If any names appear you should replace them or force that specific version always (remove ~ or ^ before it). If nothing appears you're probably good.

Snyk added a 'test-unpublished' command to check all dependencies, but "is currently limited only to the packages Azer just unpublished, as opposed to all unpublished packages."

https://snyk.io/blog/testing-for-unpublished-packages/

I'm not sure node is a safe choice for such a script, given one of the dependencies (or one of the dependencies' dependencies and so on) could use one unpublished module now or at some point in the future.

That's why I chose bash for mine: https://github.com/trumbitta/kik-check

Not a Package Manager (NPM)

By complying with kik's request, npm has set a precedent for library authors that basically means: in doubt, you will lose your package name, even if you dispute the trademark.

This means npm apparently wants everyone to handle trademark disputes like Jade did: https://github.com/pugjs/pug/issues/2184

This type of thing is one of the reasons I suggested before that a module registry could and should be a distributed peer-to-peer system.

In order to check if I was affected by any potentially malicious hacker that gets ownership of one of the existing liberated modules and adds malicious code on them, I have created a small script to check that:

https://github.com/albertfdp/did-azer-break-my-stuff

I think this blossoming episode leads me to believe that if you are running a production app, then you need to be hosting your own internal npm, and updating that from the global npm. That way when something like this happens you are able to continue on, and not have many issues, like the builds braking that are being reported on github.

Sounds like something that would not likely happen on other repos like the CPAN/CRAN/CTAN.

Perhaps the JS community at large would be better off with a similar system? I remember sometime long ago that there was a JSAN effort: http://www.openjsan.org/

I'm adding this bash script to the conversation. https://gist.github.com/mbranch/f77e62d91f46972dcc32

It reports on the inclusion of unpublished modules in all package.json files found in deeper directories.

Aftermath of situation from left-pad. Some says that it started to break major projects like react-native.

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

The ability to "unpublish" a package is fundamentally strange, because it enables situations like this.

It's also strange that people put so much trust and faith into a private company to host and distribute packages – largely for free – and then rile against them when they do stuff like this with infrastructure they own. NPM is not some free and open space, it's a private company with private interests. You should expect them to do whatever they need to protect those interests – which may or may not coincide with public interest.

I hope this resolves in more people getting involved with projects like IPFS and Nix, that may ultimately provide some recourse to the issues of centralized package management.

I read the whole damn thread and nobody, nobody links to the assholes that deserve to be kik-ed.

More details of the story: http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

NPM is a for profit, so they're a SPoF from lawyers and governments seeking to control others.

The other issues is a lack of distributed package/artifact replication which makes it possible to take down an entire ecosystem by unplugging a few servers.

My biggest issue with npm is the lack of verifiable build. Even if I read it on github, I have absolutely no idea if that's exactly what the person uploaded to npm. I very well could have malicious code and not know it.

Perhaps someone has already suggested this, but what if npm had some sort of "unpublish block" if any modules depended on yours? Or maybe some sort of notification to the dependent package owners. This doesn't solve the issue of unpublishing dependent free packages, nor does it solve someone taking over and putting malicious code, but it would encourage a more responsible behavior when removing a highly depended upon package.

Can NPM not add to their TOS and features a "notice period"? With a grace period for errors e.g. if published and older than one week to remove a package you have to give notice first, e.g. 2 months. With a suspension before actual removal?

With some avenues for expedite removal/suspension ie security and legal, which would have removed kik quicker but not leftpad.

Whether people would be aware of the notices or ignore them is another issue.

Thanks to this, I hope people will consider the way too common deployment approach when during the build time you pull stuff from npm (or whatever external package manager/repository), and if it fails, the build fails.

This is fine for small projects. There are tons of applications where availability is less important then development speed.

However, not being aware of the risks and tradeoffs you're making is just plain simple insanity.

this is why your dependencies should be checked into git

Then how can you ever install anything in the first place?

Having no understanding of the broader js context I assumed the comment to mean "all library dependencies should be checked in, build tools should be defined & specified & able to fully recreate the build given they are installed".

For the record this is a well known & frequently advocated for build pattern.

Fair enough, I guess I was just thinking of the issue I'd run into with trying to actually install anything in the first place.

In the case of npm though, installation brings down a lot of files so it's not super efficient. I've installed 15 packages and have over 12,000 files (75MB) to show for it.

this is not a serious burden on git, plus they will rarely change

You can still do npm install / npm update, just do git add -A node_modules && git commit right after.

WOW.

I've been doing the exact opposite for a long time now.

Specifically with Nuget packages, because I could just trust that the package would be there.

Considering that node_modules often has something like 4000 files in it, this seems like a huge problem to me. Especially considering the amount of redundancy in node_modules.

Uggh... unfortunately if the trust of the package distribution sites is violated then there's no other choice than to check in dependencies.

I'm not happy about this at all.

actually quite convenient: besides having piece of mind, it really simplifies builds and deploy, all for the cost of a few extra mb in your git

oh geez.... welcome to trademark law

Google.

(why is this getting frontpage HN coverage?)

a trademark is a globally enforceable right (madrid agreement) and one has an obligation to protect ones mark from "dilution" from others in the same category:

i.e. if you are selling "apple" garden shovels, you needn't worry about crossing into "apple" computer land, but I guarantee you that they already registered that mark for "home electronics" etc.

Most countries require formal registration of the trademark (they are searchable in online databases) and most will go on a "first filing" basis. but several, including the USA, go by a "first usage" basis and require you to prove your use of the mark in public...

it's a long shot, but you can always look of that company has, in fact, registered that mark, and in which country/territory are they claiming usage rights.

(for example, they can't be a local computer shop named "apple computers" that only sold to locals since 1854, that suddenly sells computers on the global market, as there is already a global entity with that name registered)

The trademark issue is actually of minor importance here. What is being highlighted is that a publisher of a large number of npm modules removed all of his modules. This broke some people's builds, but, more importantly, drew attention to 2 HUGE security issues:

1.) NPM arbitrarily gave control of a package to a 3rd party, who can then do all manner of evil with it, if they so prefer.

2.) The namespaces of all of these somewhat widely-used packages are now up for grabs. That is, you could make your own malicious version, upload it to NPM, and now all of those builds in all of those different projects will now use your malicious code.

The issue isn't trademark, it's security. That's why it's on the front page of HN.

We gotta support: http://puu.sh/nQOLH/d225ff95d3.png

"This situation made me realize that NPM is someone’s private land where corporate is more powerful than the people, and I do open source because, Power To The People."

This is true of all package distribution systems. There's always a small elite of admins who regard the system as their territory (and usually have no respect for the authors).

People contributing should be well aware of this.

Well done OP! I stand in solidarity with OP. I think this is a good way of showing our resistance to corporate power - by boycotting them.

If your project use the packages in the list, and got broken due to this. Here comes a solution https://medium.com/@viktorw/how-to-fix-npm-issues-in-your-pr...

The only Kik I knew was the Cola: https://p2.liveauctioneers.com/1164/26545/9944497_1_l.jpg

So this lawyer he's from what company? Cause there seems to be quite a lot a Kiks around these days (Kik Messenger?)

For everybody discussing decentralization of NPM in the comment threads down below, please read the following thread: https://github.com/nodejs/NG/issues/29

Much of the thinking work has already been done.

While I don't disagree with OP's angst, fuck them for choosing pride over working products. It's irresponsible and shows a complete lack of maturity. I'll make sure never to consume their modules in the future. God forbid they have a bad day and decides to insert malicious code into their modules.

You should greatly thank him for highlighting the flaws in your system if this caused significant issues.

What he did is analogous to someone breaching a trust system by doing something untrustworthy. If the argument is we shouldn't have trust systems, fucking bravo. Isn't the world a great place?

It's high time people publishing packages on NPM audit their dependencies. I bet 80% of them are unnecessary.

> npm took the name away because they reasoned that more people would think that `kik` the pkg would refer to kik the app. full stop.

https://twitter.com/ag_dubs/status/712669386511949824

If I call my module pizza, are they going to send me an email about naming it pizza? Let's think about that. If a company owns kik as a trademark, I'd offer some money to buy it off before trying to act like a tough guy. At least be soft first if your goal is get rid of kik module out there.

I don't believe pizza is trademarked or can be trademarked in any jurisdiction.

On the other hand, apparently you can name a package twitter[1] without any problems.

1. https://www.npmjs.com/package/twitter

All of this is dependant on complaints. Certainly Twitter the company could come after and get twitter the module taken down. They have enough twitter related products that overlap conceptually with an NPM module. They've seen no need to up to this point. That doesn't mean they aren't theoretically violating the trademark...

Meta: please don't upvote for agreement if facts are asserted that you cannot corroborate. And please carefully consider whether you only believe or actually know something is true. A lot of patent falsehoods are being asserted and upvoted in this thread.

Atom.io is not impacted, I think it's a good thing that apm is running on its own network.

Like trusting Github is much better?

I think it's a bit better, they do have a track record to fight over zealous legal claims - like this one. The Github repository is still untouched.

Check your project for these liberated modules using (yay) this module https://www.npmjs.com/package/affected

I'm confused weren't scoped packages added to avoid all of this sort of thing? Kik should just have used "@kik/kik", and the original package author should have been left alone.

How does serving his modules from a different corporate-controlled repository (github now instead of npm) serve his purpose of "liberating" the code from potential corporate meddling?

Trying to help with damage control: https://news.ycombinator.com/item?id=11346633

"This is not a knee-jerk action"

Yes, it is. The fact you did not know about a company branded "Kik" does not make you excempt from the law. A law which, surprisingly enough, is being used in a reasonable situation here. Your package and their segment are closely enough related in context that people could assume they are actually related, giving you the power to essentially break their business if you do bad stuff.

In this case it's not really a trolling coming from them. You don't just brand your new beer brew "Coca-Cola" - there's no reasonable argument to do that besides being a troll.

P.S.: holy crap npm is so broken I'm glad I'm on the backend side of life.

They are not exempt from the law, but in this case the law does not actually support Kik's exercise of trademark. NPM's staff buckled under the lawyers' threats, but had it gone to court the case would get thrown out. Kik's trademark does not cover the functionality of this project.

What would Stallmann say?

Shoot him an email if you're interested. rms@gnu.org.

If I can buy a domain from ICANN for 10 bucks and then sell it to a company for a million... Why can't this guy reserve the right to sell this to that company for a million?

Nobody is going to pay anything for a package name when NPM Inc. can just yank it out of your hands at their discretion.

Reading the article I thought it was some massive popular framework. But when I visited the library's github page, it seems to have only 8 favorites. Am I missing something?

left-pad is used in babel. And a lot of ppl use babel

I guess I need to clarify. If it is indeed the case that he's doing this for a repo with 8 favorites, this guy is essentially using everyone who uses his other libraries as hostage just for vanity. It would be a different story if he had 100+ favorites on that project because then he would be standing up for the entire group who's working hard on it, but I can't think of any reason for doing this other than being selfish

I have read the post and I still have no idea what NPM is.

A miserable pile of micro-dependencies, apparently.

This seems like a fairly childish response. I'm not pro-copyright, especially in software, but "someone took my made up name" seems like a dumb reason to unpublish the rest of your work.

> "NPM is someone’s private land"

No shit npm is a privately owned company? That hasn't changed before nor after you took these actions.

> "Power To The People"

This is what I don't get. All of the modules that were unpublished seem unpopular / not used so I don't know what impact this will have, but how does screwing over users of open source software equate to power to the people?

Sounds like NPM should move to pulling in the code from specific github tags or something? although I suppose, github is also "private land"...

I'd like to liberate your modules

The new pickup line

We should just troll them and created packages with kik in name like:

kik-looser iKik only-kik true-kik true-kik2 real-kik

Yet another example of the JavaScript ecosystem being pretty much garbage.

To be clear, I'm not attacking the author here. He released left-pad at version 0.0.3; no responsible developer should be using that in production code.

I really just hope that this guy just didn't know what he was doing and what effect it would have.

Otherwise it is totally irresponsible to mess up a big project like babel just because you control a few lines of trivial code.

Or is it irresponsible from the company to let loose your lawyers on a FOSS project because it uses a three letter word as a package name?

Can't believe the dev is made out to be the bad guy here.

It may be a "few lines of trivial code" but it is still his code and he has the right to do whatever he wants with it. He tried the reasonable thing, NPM didn't oblige, he pulled the rug. Serves them right. If it's a few lines of "trivial code", then maybe big project Babel should stop using that "trivial code"?

And why does this yet-another-messenger-flash-in-the-pan app "Kik" get the right to mess up big projects just because they control 1 permutation of 2 letters of the English alphabet?

responsible behavior is on a sliding scale, he had the rights to do this, but he could have been more responsible by first publishing a notice he was going to do it in a week, and even more responsible if he figured out the big projects using his code and sent them all an email ( but that would be a lot of work, hence the greater responsibility undertaken - I mean I sure wouldn't go through that trouble)

Was he irresponsible? That seems a bit much, I think he was at responsibility level average - he did what he had the right to do and with good reason after NPM treated him badly and published a good document outlining the reasons, which I guess was helpful for people seeing why using NPM at all might actually be irresponsible.

But he could have been more than responsibility level average.

npm will improve after this and that is a net good thing which comes from this.

Seriously? "When I started coding Kik, didn’t know there is a company with same name. And I didn’t want to let a company force me to change the name of it. After I refused them, they reached NPM’s support emphasizing their lawyer power in every single e-mail CC’ing me. I was hoping that NPM would protect me, because I always believed that NPM is a nice organization."

a) Ignorance is no excuse.

b) Expecting others to fight for one is lame. Either have the balls and fight or STFU.

"Summary; NPM is no longer a place that I’ll share my open source work at, so, I’ve just unpublished all my modules. This is not a knee-jerk action."

Wrong, that is the prototype of a knee-jerk action.

Last but not least, whining about it in public in the hope "something will happen" is pathetic.

What I'd suggest (though now it is too late): Rename the module to comply with legal claims, put up a new module under the old name that throws errors when called that describe the reason so developers see it and put shame on the threatening company/lawyers.

> Wrong, that is the prototype of a knee-jerk action.

No it isn't; and he made that clear, he objects to their actions and is taking action of his own.

> Last but not least, whining about it in public in the hope "something will happen" is pathetic.

No, it's called protesting, and it's exactly the correct thing to do. Calling it pathetic is itself pathetic.

> hat I'd suggest (though now it is too late): Rename the module to comply with legal claims, put up a new module under the old name that throws errors when called that describe the reason so developers see it and put shame on the threatening company/lawyers.

You're completely missing his point if you think this suggestion is at all reasonable.

He made it clear he doesn't want to consider it a knee jerk, which has approximately zero relationship to whether it actually is.

Protesting trademark law sounds like a lot of useless fun. It may be the "correct" thing to do, but it will have no result.

He's not protesting trademark law; he's protesting that NPM just handed over his module to someone else.

> He made it clear he doesn't want to consider it a knee jerk, which has approximately zero relationship to whether it actually is.

A knee jerk reaction is an immediate unthinking emotional reaction; when you detail out your thought process in a lengthy well articulated blog post to explain your actions, it isn't knee jerk by definition. There was nothing at all unthinking about his actions or his protest. Point in fact, when someone explains to you why something isn't a knee jerk reaction, it automatically isn't. His making it clear has an approximately 100% relationship to the fact that it isn't.

> You're completely missing his point if you think this suggestion is at all reasonable.

Is this the kik we're talking about?

http://dev.kik.com/ https://trademarks.justia.com/858/93/kik-85893307.html

Is the point that kik should just give up on their company trademark?

Just because they've trademarked "kik" doesn't give them complete control over all instances of that 3 letter string in the world. See the 8 factors of trademark infringement, and trademark law in general; this is just a kik lawyer being threat happy.

+1 also US Trademark != the whole world. NPM should have handle this better!

US trademark is what's dangerous to NPM Inc., the US company running NPM. We don't know anything about how they "handled" it before it came to this, except that they did decide against the article author. What should they have done differently?

It's not good that NPM-the-piece-of-infrastructure is vulnerable to this, maybe a registry like this shouldn't be under control of a single company, but we don't know enough to decide what options NPM Inc-the-company had.

I hope they clean up/better communicate their policies around this, once they have them figured out (e.g. the package dispute page doesn't discuss trademarks).

> What should they have done differently?

Not given them control over his code just because it had their name on it. They could have taken it down, but they didn't, they just gave some company ownership of his module, not cool.

> Just because they've trademarked "kik" doesn't give them complete control over all instances of that 3 letter string in the world.

Agreed - hence why I looked up the actual trademark in the first place. I wasn't expecting to find out they were in the software development business too.

> See the 8 factors of trademark infringement

I'm assuming these? (Google turned up 1 hit - which in turn was 404ed - for "8 factors of trademark infringement") http://www.bitlaw.com/trademark/infringe.html#factors

Keeping in mind IANAL:

1. The marks appear very similar, with the possible exception that kik the company appears to have no meaning behind "kik". Similar enough that I have to specify "kik the company." 2. Both appear to provide services aimed at developers. 3. The plaintiff's mark appears to be strong enough to fill the first page of Google, and for overprotective parents to overreact to. 4. I was momentarily confused which kik I was clicking through to at least once.

Am I misweighing or misinterpreting things to think that the first 3 points, at least, point towards infringement? Do you agree that these appear to be among the more important ones?

"The first five of these factors are examined in every trademark infringement action." "Of these eight factors, the first two are arguable the most important."

> ... and trademark law in general

If you have any recommendations, feel free to share.

> Is the point that kik should just give up on their company trademark?

You can't possibly think that's the point he's making. Did you even bother to read the article?

There are no legal claims to be made over NPM package names. NPM has a policy for assigning names and third party attorneys don't get a say.

Are you serious?

>Seriously

What is the legal basis for the claim that NPM package names are somehow exempt from trademark and other law?

NPM does not offer packages as commerce. The package removed was not used in commerce. The KIK trademark does not claim any functionality related to the removed module.

What legal basis is there that NPM packages are subject to trademark, or other law?

NPM takes its names from the package.json file. The law has no say over what one may put into their package.json file.

Offering a product/service for free doesn't exempt it from trademark law. I couldn't make an open source word processor and call it "Microsoft Word".

The US Federal Government only has the ability to regulate interstate commerce. Kik, the project, does not engage in commerce. Also, npm (the package manager) is not a commercial vehicle.

>I couldn't make an open source word processor and call it "Microsoft Word".

Sure you could, you just couldn't use it in commerce.

> There are no legal claims to be made over NPM package names.

Why not? An NPM package name is the name of a piece of software, and software names are very much covered under trademark law.

An NPM package name is just what NPM scraped from a package.json file.

The technical details of how package names enter their system aren't really relevant from a legal point of view.

I believe that is what I said.

> There are no legal claims to be made over NPM package names.

> b) Expecting others to fight for one is lame. Either have the balls and fight or STFU.

Is this a joke? In the world of hilariously over litigious rich companies crushing people with the threat of lawsuits? If you don't have the balls to defend your company vs patent trolls shut the fuck up? Hahaha.

He neither contacted a lawyer on his own to check whether kik's claim was valid nor did he contact npm while he still received all mails from kik to npm in Cc. He was just trying to sit it out and then caused a lot of collateral damage by pulling all his modules.

I have dealt with a few such problems myself and more often than not a simple counter demand that the other party should substantiate their claim was enough to make the claim go away.

And this is not even a multi-billion dollar patent troll - it was merely about a trademark, which every lawyer should be able to check in 30 minutes.

can i kik it?

RIP Phife Dawg

Wow, first they steal a package from the original author, then they do this. Why will anyone want to publish to NPM after this again?

Right now I have serious doubts about the whole npm infrastructure...

All legality, copyright law, etc. aside, how did this even create a problem?

Even on small projects, basic build engineering dictates that you are cognizant of which package versions against which you are building. Furthermore, all packages should be locally cache-isolated on your build server (or local box if you do not have a build server). Building against the most "up-to-date" versions of remote dependencies puts you completely at risk for situations such as this, let alone at the mercy of malicious updates to such remote dependencies.

What sane (pun intended) person would ever build against the most recent version of all packages (including small ones such as this) from a remote build server? Also, for larger (i.e. more than several employees) type operations, how could QA possibly function when building from "most recent version of all packages"?

All these entities that are suffering because of this should immediately fire all their build engineers, because they are not only a reliability concern, but, more critically, a vulnerability concern.

Hopefully NPM will think of this in the future, next time they try something like this.

Let's remember that NPM Inc has also been toying with the idea of banning IPs associated with "bad people" for behaviour outside of NPM itself.

In other words: they think it's morally justifiable to ban a company's IP address(es) from the NPM service because one of their employees said something objectionable on Twitter (not involving NPM or any of its representatives). And what should the company do if their employee gets them banned? Why, fire them of course.

Care to give a source for that claim?

Would love to but @izs deleted his tweets a couple of hours later.

The entire ordeal happened back in January (I think), around the same time as some other npm drama (e.g. https://github.com/nodejs/node/issues/3959 and https://github.com/nodejs/TSC/issues/21 and https://github.com/nodejs/NG/issues/26, leading up to https://github.com/nodejs/NG/issues/29) -- the twitter incident gets referenced in some of the comments.

There are however plenty of comments by NPM representatives (including izs) that they see it as a moral obligation to uphold their CoC even beyond the scope of NPM itself (implying what izs proposed).

There's a fundamental divide going on between people who think open source (code, not communities) should be attached to certain moral values and those thinking it should be agnostic of social issues. Similar to the Open Source vs Free Software divide in the 1990s.

Except while the FSF was the one arguing on moral grounds before, the new movement is actually in conflict with one of the main concepts of the GPL: authors should not be able to restrict how code can be used and by whom (i.e. you can't prohibit people from using code for evil if it should be GPL compatible).

> This is not a knee-jerk action

Seems like it. Why break everyone's builds? You could just keep the modules there and then declare you will only keep them updated elsewhere?

Maybe he wants the developer community to class action kik.

I think what actually is a knee jerk reaction being irresponsible with your dependencies and blame others for your lack of foresight.

He doesn't owe you anything. You and other should be thankful for him to have allowed you to use his code. Fuck that entitlement bs.

Except of course that the library in question is 12 lines of code. And that you might not even know that three levels down your dependency tree someone used that module.

> I think what actually is a knee jerk reaction being irresponsible with your dependencies and blame others for your lack of foresight.

Er.. actually I don't use NPM.

> He doesn't owe you anything. You and other should be thankful for him to have allowed you to use his code. Fuck that entitlement bs.

Yes but I belong to the adult world, so if I had a package that load of people relied on, wrongly or rightly, I wouldn't just drop it knowing it would be harmful to other projects, just for the sake of causing chaos. It's all about the mens rea.

Extremely dick move on behalf of the developer. Why would you remove modules that other people are using in production?

Did you think a small team like NPM would go head to head with a company having full time lawyers? And for what?

you should ask for your money back

Why is that a dick move? What would you do if npm or github goes down tomorrow?

Vendor your dependencies if you want to make sure your own project doesn't break.

I am not affected by this. It just seems like a childish move that only hurts the users. NPM did not go against its ToS.

Neither did he.

He was threatened by lawyers the real assholes are Kik for taking hiring lawyers to ask him to rename his module

Reply on news.ycombinator.com