
I've Just Liberated My Modules - chejazi
https://medium.com/@azerbike/i-ve-just-liberated-my-modules-9045c06be67c
======
callmevlad
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-...](https://medium.com/@azerbike/i-ve-just-liberated-my-
modules-9045c06be67c#.6je6fouj8)

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

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

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

~~~
smaddox
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.

~~~
viraptor
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.

~~~
noffle
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](https://github.com/whyrusleeping/gx)

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

------
nordsieck
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](http://apple.com)

[2] [http://applerecords.com](http://applerecords.com)

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

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

~~~
tantalor
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.

~~~
bsder
> 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...](http://www.businessinsider.com/jack-daniels-wrote-what-has-to-be-
the-nicest-cease-and-desist-order-of-all-time-2012-7)

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

Big fail for a "social media" company.

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

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

------
larkinrichards
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://github.com/lydell/line-numbers/pull/3/files)

~~~
cballard
> 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](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/](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.

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

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

~~~
whatever_dude
...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).

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

~~~
visarga
> 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.

~~~
mc808
> 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.

~~~
drumstyx
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

~~~
monknomo
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

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

~~~
shruubi
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?

~~~
krapp
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/](http://www.wtfpl.net/)

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

~~~
perennate
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.

~~~
krapp
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.

~~~
perennate
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.

~~~
AnkhMorporkian
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.

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

~~~
jlg23
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.

~~~
thejosh
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.

~~~
Cogito
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.

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

~~~
jsprogrammer
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.

~~~
laughinghan
> 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)

~~~
brazzledazzle
I assume they're talking about the kik module.

~~~
jsprogrammer
I was.

------
jimjimjim
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?

~~~
pmontra
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

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

~~~
mattmanser
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.

~~~
gedrap
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.

~~~
mattmanser
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.

~~~
gedrap
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.

------
chvid
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](https://github.com/azer/left-
pad/blob/master/index.js)

~~~
aidos
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! :-/

~~~
nas
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.

~~~
nyan4
> 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?

~~~
kylecordes
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.

------
cammsaul
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](https://twitter.com/seldo/status/712414400808755200)

~~~
spdustin
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_.

~~~
swang
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.

~~~
spdustin
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?

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

~~~
spdustin
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.

~~~
swang
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.

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

~~~
Klathmon
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.

~~~
voltagex_
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.

~~~
brazzledazzle
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.

------
drinchev
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](https://www.npmjs.com/~nj48)

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

~~~
lasdfas
@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.

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

~~~
SlashmanX
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](https://github.com/davglass/license-checker)

------
jwiley
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://medium.com/@azerbike/i-owe-my-career-to-an-iraqi-
immigrant-2c075a495b25#.355he9y0b)

[https://en.wikipedia.org/wiki/Kik_Messenger#Controversies](https://en.wikipedia.org/wiki/Kik_Messenger#Controversies)

~~~
cyphar
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.

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

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

~~~
gariany
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.

~~~
steveklabnik

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

~~~
hyperpape
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.

~~~
steveklabnik
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.

~~~
wolfgke
> 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.

~~~
hyperpape
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](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](https://en.wikipedia.org/wiki/Gettier_problem)).

~~~
wolfgke
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?).

~~~
mdpopescu
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.

------
joeandaverde
Here's a highly downloaded 11 line module with lots of dependents.

[https://www.npmjs.com/package/escape-string-
regexp](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.

~~~
sotojuan
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...](https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328)

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

~~~
zanny
> 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](https://github.com/npm/npm)

~~~
aioprisan
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.

------
nchelluri
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]

------
zwetan
funny thing, but assuming that kik is related to kik.com

if you look here [http://dev.kik.com/build/](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](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 ;) ?

~~~
brazzledazzle
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.

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

~~~
aeze
Aren't trademarks only relevant to products or services?

~~~
exception_e
This was what I was thinking while reading the post.

Also, I recently checked and
[https://github.com/tylertreat/comcast](https://github.com/tylertreat/comcast)
is still alive and well.

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

------
chejazi
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](https://github.com/azer/left-pad/issues/4)

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

~~~
gojomo
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.

~~~
pygy_
Trademark fields are broad AFAIK. "Digital stuff" is a single category, and
both kik the messenger and azer's kik fall there.

~~~
dublinben
They also require consumer confusion. I don't know how you could confuse a
communications app for a javascript module.

------
dham
What if Kik uses Node and they broke their own builds inadvertently by
enforcing their trademark. 0_0

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

------
mschuster91
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?

~~~
spriggan3
> 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.

~~~
mschuster91
For a library yes, but if you're writing software you absolutely must. npm
actually deduplicates and flattens your dependencies to reduce clutter.

------
vulpes
Here's [1] a list of all modules that were liberated. Some serious land-grab
opportunities there

[1]:
[https://gist.github.com/azer/db27417ee84b5f34a6ea](https://gist.github.com/azer/db27417ee84b5f34a6ea)

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

~~~
STRML
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.

------
KajMagnus
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...](https://gist.githubusercontent.com/azer/db27417ee84b5f34a6ea/raw/50ab7ef26dbde2d4ea52318a3590af78b2a21162/gistfile1.txt)
) — 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](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.

------
tobltobs
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 'κικ'.

------
jonathankoren
My god! It's full of attack vectors!
[https://github.com/substack/provinces/issues/20](https://github.com/substack/provinces/issues/20)

~~~
swang
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.

------
fiatjaf
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?

~~~
Havvy
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.

~~~
SlashmanX
You can ask for a specific tag/branch using Github dependencies using
babel/babel#v5.x

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

~~~
kelnos
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.

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

~~~
Arnavion
And the reason for unpublishing is at [https://medium.com/@azerbike/i-ve-just-
liberated-my-modules-...](https://medium.com/@azerbike/i-ve-just-liberated-my-
modules-9045c06be67c)

~~~
binaryjohn
The incredible resilience/fragility of open source all in one thread:
[https://github.com/azer/left-
pad/issues/4#issuecomment-20006...](https://github.com/azer/left-
pad/issues/4#issuecomment-200060983)

------
kikcomms
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...](https://medium.com/@mproberts/a-discussion-about-the-breaking-of-
the-internet-3d4d2a83aa4d)

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.

~~~
insin
s/polite request/politely-worded threat/

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

------
lukegt
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](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

~~~
cooper12
That's actually their standard 404 message:
[https://www.npmjs.com/package/lukegt-
test](https://www.npmjs.com/package/lukegt-test).

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

------
tobltobs
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?

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

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

~~~
awolden
> 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`.

~~~
julie1
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.

------
nikolay
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/](http://gugel.io/ied/)

[1]: [https://ipfs.io/](https://ipfs.io/)

~~~
tlrobinson
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](https://github.com/diasdavid/registry-mirror)

~~~
nikolay
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!

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

~~~
tapsboy
kik module could have been called kik-messenger

Else even [http://www.kik.de/](http://www.kik.de/) could claims kik for an API
to it's merchandise

------
swang
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?

~~~
stonemetal
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.

~~~
jlarocco
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_me
Lol that satire flipped bit site even caught it
[http://www.theflippedbit.io/2016/03/23/developer-outraged-
as...](http://www.theflippedbit.io/2016/03/23/developer-outraged-asked-remove-
whatsapp-package-npm/)

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

~~~
wolfgke
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?

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

~~~
cyphar
> 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.

------
tlrobinson
Also:
[https://twitter.com/seldo/status/712414400808755200](https://twitter.com/seldo/status/712414400808755200)

~~~
newman314
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...](https://en.wikipedia.org/wiki/Microsoft_Corp._v._Lindows.com,_Inc).

------
diffraction
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://www.trentonian.com/general-news/20140728/pedophile-on-kik-app-
its-well-known-in-our-industry)) ([http://woodtv.com/2015/02/02/sexual-
predator-warns-parents-a...](http://woodtv.com/2015/02/02/sexual-predator-
warns-parents-about-kik-app/))

------
fold_left
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](https://github.com/JamieMason/shrinkpack).

Its not completely there yet, but I think there's something worth exploring
further in this idea.

------
zachrose
So what keeps Kik from going after Github?

[https://github.com/starters/kik](https://github.com/starters/kik)

~~~
hartator
Github has proper lawyers.

------
sjclemmy
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? ;)

------
sbuttgereit
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 :-)

~~~
nirvdrum
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.

~~~
krakensden
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.

~~~
nirvdrum
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?

------
cdubzzz
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](https://twitter.com/izs/status/712510512974716931)

~~~
mstade
That is some serious highfaluting language going on in those tweets. Something
something if you play the game something something...

~~~
cdubzzz
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.

~~~
mstade
You and me both. I wish I could up-vote your comment twice!

------
wtbob
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).

~~~
_pmf_
As done by Maven for a decade.

But hey, Java sucks, move fast and break things, right?

------
taumeson
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?

~~~
Klathmon
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.

~~~
taumeson
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!

~~~
d0m
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.

------
octref
Why don't people just use lodash?

[https://lodash.com/docs#padStart](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.

~~~
progx
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?

~~~
jdd
If there was ever an issue I'd work with npm to come to a resolution that
didn't break 25% of npm.

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

------
cammsaul
There's a PR open to remove "unpublish" from NPM here:

[https://github.com/npm/npm/pull/12017](https://github.com/npm/npm/pull/12017)

~~~
cyphar
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.

------
jahewson
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/pepsi)

[https://www.npmjs.com/package/coke](https://www.npmjs.com/package/coke)

[https://www.npmjs.com/package/kfc](https://www.npmjs.com/package/kfc)

[https://www.npmjs.com/package/virgin](https://www.npmjs.com/package/virgin)

[https://www.npmjs.com/package/sprint](https://www.npmjs.com/package/sprint)

[https://www.npmjs.com/package/nba](https://www.npmjs.com/package/nba)

[https://www.npmjs.com/package/nfl](https://www.npmjs.com/package/nfl)

[https://www.npmjs.com/package/google](https://www.npmjs.com/package/google)

[https://www.npmjs.com/package/yahoo](https://www.npmjs.com/package/yahoo)

[https://www.npmjs.com/package/skype](https://www.npmjs.com/package/skype)

[https://www.npmjs.com/package/word](https://www.npmjs.com/package/word)

[https://www.npmjs.com/package/excel](https://www.npmjs.com/package/excel)

[https://www.npmjs.com/package/unix](https://www.npmjs.com/package/unix)

[https://www.npmjs.com/package/windows](https://www.npmjs.com/package/windows)

[https://www.npmjs.com/package/osx](https://www.npmjs.com/package/osx)

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

~~~
ShaneCurcuru
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_...](https://tsdr.uspto.gov/#caseNumber=86930821&caseType=SERIAL_NO&searchType=statusSearch)

------
erikb
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?

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

~~~
prodigal_erik
The whole point was demonstrating what npmjs.com has reserved the right to do
to any user at any time.

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

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

~~~
zackboe
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/](https://snyk.io/blog/testing-for-unpublished-packages/)

~~~
trumbitta2
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](https://github.com/trumbitta/kik-check)

------
repn001
Not a Package Manager (NPM)

------
pluma
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](https://github.com/pugjs/pug/issues/2184)

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

------
albertfdp
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](https://github.com/albertfdp/did-azer-break-my-stuff)

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

------
zakame
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/](http://www.openjsan.org/)

------
miiiichael
I'm adding this bash script to the conversation.
[https://gist.github.com/mbranch/f77e62d91f46972dcc32](https://gist.github.com/mbranch/f77e62d91f46972dcc32)

It reports on the inclusion of unpublished modules in all package.json files
found in deeper directories.

------
alongtheflow
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...](https://github.com/azer/left-
pad/issues/4#issuecomment-200062925)

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

------
stblack
I read the whole damn thread and nobody, nobody links to the assholes that
deserve to be kik-ed.

------
cdnsteve
More details of the story:
[http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

------
cat-dev-null
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.

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

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

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

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

------
kofejnik
this is why your dependencies should be checked into git

~~~
aidos
Then how can you ever install anything in the first place?

~~~
kasey_junk
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.

~~~
aidos
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.

~~~
kofejnik
this is not a serious burden on git, plus they will rarely change

------
justaaron
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)

~~~
coreyp_1
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.

------
staticelf
We gotta support:
[http://puu.sh/nQOLH/d225ff95d3.png](http://puu.sh/nQOLH/d225ff95d3.png)

:D

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

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

------
wangderland
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...](https://medium.com/@viktorw/how-to-fix-npm-issues-in-your-projects-
after-azer-ko%C3%A7ulu-liberated-his-modules-7368951c2509#.5wiknjg39)

------
kelvin0
The only Kik I knew was the Cola:
[https://p2.liveauctioneers.com/1164/26545/9944497_1_l.jpg](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?)

------
joepie91_
For everybody discussing decentralization of NPM in the comment threads down
below, _please read the following thread_ :
[https://github.com/nodejs/NG/issues/29](https://github.com/nodejs/NG/issues/29)

Much of the thinking work has already been done.

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

~~~
JeremyBanks
You should greatly thank him for highlighting the flaws in your system if this
caused significant issues.

~~~
dclowd9901
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?

------
spriggan3
It's high time people publishing packages on NPM audit their dependencies. I
bet 80% of them are unnecessary.

------
antouank
> 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](https://twitter.com/ag_dubs/status/712669386511949824)

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

~~~
PeCaN
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](https://www.npmjs.com/package/twitter)

~~~
kennywinker
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...

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

------
hartator
Atom.io is not impacted, I think it's a good thing that apm is running on its
own network.

~~~
Dirlewanger
Like trusting Github is much better?

~~~
hartator
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.

------
Coxa
Check your project for these liberated modules using (yay) this module
[https://www.npmjs.com/package/affected](https://www.npmjs.com/package/affected)

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

------
jordanlev
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?

------
trumbitta2
Trying to help with damage control:
[https://news.ycombinator.com/item?id=11346633](https://news.ycombinator.com/item?id=11346633)

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

~~~
BHSPitMonkey
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.

------
tobltobs
What would Stallmann say?

~~~
cyphar
Shoot him an email if you're interested. rms@gnu.org.

------
howareroark
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?

~~~
ricardobeat
Nobody is going to pay anything for a package name when NPM Inc. can just yank
it out of your hands at their discretion.

------
galistoca
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?

~~~
hills
left-pad is used in babel. And a lot of ppl use babel

~~~
galistoca
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

------
gambiting
I have read the post and I still have no idea what NPM is.

~~~
GFK_of_xmaspast
A miserable pile of micro-dependencies, apparently.

------
stevebmark
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?

------
tehwalrus
Sounds like NPM should move to pulling in the code from specific github tags
or something? although I suppose, github is also "private land"...

------
EGreg
I'd like to liberate _your_ modules

The new pickup line

------
Chyzwar
We should just troll them and created packages with kik in name like:

kik-looser iKik only-kik true-kik true-kik2 real-kik

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

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

~~~
lovelearning
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?

~~~
bryanrasmussen
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.

------
studentrunnr
npm will improve after this and that is a net good thing which comes from
this.

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

~~~
gnaritas
> 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.

~~~
MaulingMonkey
> 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/](http://dev.kik.com/)
[https://trademarks.justia.com/858/93/kik-85893307.html](https://trademarks.justia.com/858/93/kik-85893307.html)

Is the point that kik should just give up on their company trademark?

~~~
linksbro
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.

~~~
gariany
+1 also US Trademark != the whole world. NPM should have handle this better!

~~~
detaro
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).

~~~
gnaritas
> 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.

------
turtlekiosk
can i kik it?

RIP Phife Dawg

------
st3v3r
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?

~~~
maze-le
Right now I have serious doubts about the whole npm infrastructure...

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

------
st3v3r
Hopefully NPM will think of this in the future, next time they try something
like this.

~~~
pluma
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.

~~~
LukeB_UK
Care to give a source for that claim?

~~~
pluma
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](https://github.com/nodejs/node/issues/3959)
and
[https://github.com/nodejs/TSC/issues/21](https://github.com/nodejs/TSC/issues/21)
and
[https://github.com/nodejs/NG/issues/26](https://github.com/nodejs/NG/issues/26),
leading up to
[https://github.com/nodejs/NG/issues/29](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).

------
bbcbasic
> 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?

~~~
lerpa
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.

~~~
cyphar
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.

------
zongitsrinzler
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?

~~~
jzs
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.

~~~
zongitsrinzler
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.

~~~
archgoon
Neither did he.

