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.
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.
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?
Jesus. This is a disaster. At this point, the only responsible thing to do is to avoid NPM.
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...
You, my friend, are being US biased.
i take that back, npm is a security risk that should be avoided.
now i need a new package manager.
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".