
Changes to Npm's unpublish policy - steveklabnik
http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy
======
sangnoir
Conspicuously missing scenario: Sandra owns the comic drawing package
"stickman" and publishes 0.1.0, 0.9.9 and 1.0.0. A few months/years later,
Stick Manufacturing Corp [StickMan(tm)] shows up with their Internet of Sticks
support package library to go with their registered trademark and want to
publish it as "stickman". What happens next? Do they just hand over the
package so Stick Corp can publish a new version? Does NPM inc rename Sandra's
"stickman" to something else? what happens to Julie's "comic" package that
depends on "stickman^0.9.9" when the package is handed over?

~~~
awjr
The real problem is the namespace issue that seriously needs sorting out.
com.sandra.stickman would be different to com.stickmanufacturingcorp.stickman

npm is growing hugely. It needs to sort out the domain space issue quickly.

~~~
steveklabnik
npm literally supports namespaces already
[https://docs.npmjs.com/misc/scope](https://docs.npmjs.com/misc/scope)

And, it's not actually clear that a namespace would have been enough had a
lawsuit actually been filed.

~~~
deckar01
Namespacing costs $7/mo/dev... for a string and a slash.

~~~
steveklabnik
Not for public ones. Those are free. If you want them to be private, then you
pay the money.

------
spdustin
Does NPM require packages to use a license compatible with their asserting an
irrevocable license to distribute said package? How is this verified?

EDIT BELOW

I see some responses (three as of this writing) that quote their terms, and I
want to clarify: I know what their terms state, but if those terms are
incompatible with the license of the content being distributed, the terms
would not be enforceable, or at the very least, would require mandatory
arbitration (itself a clause hostile to the individuals accepting these terms)
to invalidate.

I guess it boils down to: Did attorneys actually vet these terms and
practices, or are they banking on the collective generosity and "FOSS spirit"
of the community to protect them from litigation?

~~~
kibwen
That's covered by their terms of service, quoted in the OP:

 _" Your Content belongs to you. You decide whether and how to license it. But
at a minimum, you license npm to provide Your Content to users of npm Services
when you share Your Content. That special license allows npm to copy, publish,
and analyze Your Content, and to share its analyses with others."_

Services like this _have_ to account for such rights in their terms of
service, because distribution is a minefield even for properly-licensed
packages. For example, the MIT license covers only "this software and
associated documentation files", which AFAICT means that if you have e.g. a
screenshot in your repo then conceivably you could request a DMCA takedown on
anyone distributing your repo. Likewise GPL doesn't cover anything _but_ code,
not even documentation (you're expected to remember to explicitly use the GNU
Free Documentation License to cover that).

IANAL, so I'd be happy if someone who was would chime in with any corrections.

~~~
ajdlinux
Since when did the GPL not cover non-code artifacts?

The FSF's view at [http://www.gnu.org/licenses/gpl-
faq.en.html#GPLOtherThanSoft...](http://www.gnu.org/licenses/gpl-
faq.en.html#GPLOtherThanSoftware):

"You can apply the GPL to any kind of work, as long as it is clear what
constitutes the “source code” for the work. The GPL defines this as the
preferred form of the work for making changes in it. However, for manuals and
textbooks, or more generally any sort of work that is meant to teach a
subject, we recommend using the GFDL rather than the GPL."

------
tlrobinson
> Because all dependents are satisfied by 1.0.1, support agrees to grant
> Supreet’s request to delete 1.0.0.

There are some good changes here, unfortunately this policy will still break
projects that use "npm shrinkwrap" to lock down specific versions, which IMHO,
anyone who wishes to retain their sanity will do.

When this happens AFAIK there's no foolproof way to "patch" your npm-
shrinkwrap.json with the new version without deleting it and re-running
shrinkwrap, and thus possibly bumping versions of every other package as well.
The usual recommendation seems to be "find and replace" the version in npm-
shrinkwrap.json with a regex, which is fine if the package's dependencies
didn't change but will break if a dependency is added.

I'd love to know if there's a better way.

FWIW, if you think this is a very rare occurrence, it's now happened to me 3
times in last few months, the latest being less than a week after the left-pad
incident [1].

1\. [https://github.com/chalk/ansi-
styles/issues/15](https://github.com/chalk/ansi-styles/issues/15)

2\. GitHub issue with additional discussion here:
[https://github.com/npm/policies/issues/44](https://github.com/npm/policies/issues/44)

~~~
eblanshey
Time to start committing dependencies to your VCS.

~~~
tlrobinson

        $ du -h -d0 node_modules
        673M	node_modules
    

EDIT: Actually it looks like du is reporting double the size, it's really
337.2MB according to OS X Finder (apparently it's using 512 byte blocks on OS
X [https://stackoverflow.com/questions/23599131/why-is-du-
comma...](https://stackoverflow.com/questions/23599131/why-is-du-command-
showing-double-size-when-h-flag-is-sent))

~~~
jerf
So, fully serious and non-sarcastic question since I'm not a node developer,
what is in that 673MB?

~~~
tlrobinson
It's mostly Babel and other build tools:
[https://gist.github.com/tlrobinson/1fba66be86f473ffe76312c32...](https://gist.github.com/tlrobinson/1fba66be86f473ffe76312c32513c301)

With npm every dependency gets it's own tree of dependencies, so there's tons
of duplication.

Also, this is using npm 2. With npm 3 that's approximately cut in half since
it tries to flatten the hierarchy as much as possible, but I haven't switched
to npm 3 yet (seems slower and still somewhat buggy)

~~~
nostrademons
Babel seems to be a terrible offender as far as dependencies go. In my
node_modules, babel-preset-es2015 takes up 200M - as you've noticed, each
individual transformer has its own copy of the core Babel runtime.

And Babel was largely responsible for this whole left-pad fiasco in the first
place: about 2/3 of left-pad downloads were through Babel.

The good news is that Node 6.0 is coming out next month, with V8 5.0, which
supports 93% of ES6 natively. That means that most of the transformers can go
away for server & Chrome code, with the appropriate Babel preset. And the big
remaining ones - modules and async/await - are scheduled for Q2 2016, with
work on modules already underway as of a couple weeks ago. So within a couple
months, we may not need Babel at all anymore.

~~~
nilliams
Yes, if you only write JS for Chrome and Node, not sure how many JS devs fall
into that bracket!

~~~
nostrademons
You also have the option of doing split JS bundles, using different Babel
presets, for different browsers. Eg. for Chrome the only thing you need is
module imports, but for Safari you use a preset that also includes
destructuring, function defaults, etc.

This reduces the attack surface that a rogue Babel dependency has access to -
instead of being able to pwn your server and all browsers, it can only pwn the
browsers that use the particular transform that depends on it. It also can
result in significant byte-size savings in the downloaded bundle.

------
diggan
First of, I love how npm works and the nodejs ecosystem. For me it provides
great value and I'm thankful for all the hard work that node/npm developers
have put into the software that they are building

Secondly, I think, by having a company deciding the fate of the code that we
as developers are depending on, it's not a very good idea. There is a inherit
conflict of interest between the community and the company. We want to have
the code available at all times but the mission of the company is not the
same. They care about being in the center of attention, so other companies can
depend on them and they make cash. That's what being a business does to you.

What I see as the ideal world, is a way to have the best of the software
already written (npm cli) combined with a distributed registry that works
peer-to-peer. Not only does it solve the conflict of interest, but also
scaling, offline access and long-term maintainability.

Many folks are working on getting there now, "gx" (package manager using IPFS
[https://github.com/whyrusleeping/gx](https://github.com/whyrusleeping/gx) ),
"ipmjs" (distributed package manager
[https://github.com/ipmjs/ipmjs/](https://github.com/ipmjs/ipmjs/) ) and my
own work "everythingstays" (scripts that works together with the npm cli [
[http://everythingstays.com/](http://everythingstays.com/) ])

If you're interested in solving the problem in a bigger scale than changing
npm inc's policies, I recommend you to check out the tools linked above.

~~~
gedy
Agreed on second point - one of the first things we looked at when introducing
node.js at our company was setting up a private in-house npm repository,
similar to what many companies due in the Maven ecosystem to both store
private packages and filter/proxy the global repo for outages, problems, etc.

It was rather hard and awkward, and there was no solution or support offered
from npmjs-the-company. Some time after they introduced private (and hosted)
npm repos as a paid offering, but this is still not what a lot of companies
want. While perhaps I'm jumping to conclusions, a free in-house offering does
not seem to be in their business model and therefore the community has
suffered a bit.

(I'm aware of the unofficial projects for this)

~~~
zer00eyz
Vendoring is the concept, and is separate from the underlying mechanics.
Having an "in house" repository is one mechanism, but checking the
dependencies into version control is another one. There just isn't really a
good way to do this in/with NPM, and the top google results seem to actively
discourage pursuing this pattern.

Many other languages (well the ones I use frequently) not only have a
recommendations on vendoring, but also support more than one path to getting
the job done (with trade offs naturally).

~~~
phaas
Sonatype nexus can proxy npmjs. Works ok for our build servers, but in my
setup developers still use npm locally so I don't know if there are any
gotchas using nexus exclusively.

[https://books.sonatype.com/nexus-book/reference/npm-
proxying...](https://books.sonatype.com/nexus-book/reference/npm-proxying-
registries.html)

~~~
gedy
Thanks, the company actually eventually went with that. Our attempt was a few
years back, before that was available/known to us.

------
alanh
> If you contact support, they will check to see if removing that version of
> your package would break any other installs. If so, we will not remove it.
> You’ll either have to transfer ownership of the package or reach out to the
> owners of dependent packages to change their dependency.

Wow. A big change. It means publishing on NPM is granting an essentially
irrevocable license. (Edit: Not that anything is wrong with that.)

~~~
kibwen
Given that they were willing and able to republish left-pad just as it existed
before it was taken down, this was already true in practice, though merely
selectively enforced.

~~~
steveklabnik
That action was described as an exceptional response to exceptional
circumstances, I don't believe it had ever been done before. Which doesn't
change your point, but is a bit different than 'selectively enforced.'

------
saghul
"One of Node.js’ core strengths is the community’s trust in npm’s registry. As
it’s grown, the registry has filled with packages that are more and more
interconnected."

IMHO, at the current state of Node's maturity I'd consider relying on a
private and for-profit organization for package delivery a weakness, not a
strength.

------
danjoc
This really doesn't seem to address the core issues with NPM.

Packages need to be signed with GPG. Full stop. If anyone is running unsigned
executable code blindly, they've already failed. You might as well be running
.exe files emailed to you by a Nigerian prince.

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

Oh. Wow. I'm at a loss for words after finding that... I hope NPM are
seriously rethinking this position. shasums are definitely not a substitute
for validating gpg signatures by any stretch of the imagination.

Anyway, the worries about package removal are misplaced. If production
application builds depend on the central NPM repository, they are set up
incorrectly. Dependencies should be proxied via a local dependency repository
like Sonatype Nexus or Artifactory. It is unprofessional to have builds set up
with dependency directly on a repository not under local control.

If you need to convince someone in charge why you need to do this, I recommend
this presentation:

[https://www.youtube.com/watch?v=pBJafU0p_Nk](https://www.youtube.com/watch?v=pBJafU0p_Nk)

It's good, and worth your hour. TL;DW the six reasons are enumerated at 30:59.

~~~
joeyespo
GPG isn't the holy grail. See [https://caremad.io/2013/07/packaging-signing-
not-holy-grail/](https://caremad.io/2013/07/packaging-signing-not-holy-grail/)

Proxying via a local dependency is a good practice, but that can be set up
independently of npm.

~~~
danjoc
>GPG isn't the holy grail.

I don't believe anyone ever said it was. It's a far better approach than using
shasums for package integrity though.

>Proxying via a local dependency is a good practice, but that can be set up
independently of npm.

That's the point. I see a lot of people hand wringing about removed modules in
the future. It's not NPMs job/obligation to provide the javascript world with
never ending storage, hosting, and bandwidth. Expecting a third party to host
dependencies that make in house apps run is a fool's errand. That strategy
can, will, and just did fail.

~~~
joeyespo
> It's a far better approach than using shasums for package integrity though.

The point of that article is that it isn't. It only adds integrity if you
trust the signer. From the article:

> When attempting to verify a signed file you check the signature against a
> public key. If the signature matches that public key then everything is
> kosher. The question then becomes which public key, and therein lies the
> rub. If you do not have a well defined model of trust then all you’ve done
> is thrown cryptography at a problem in order to give the people involved the
> ability to say that their system has signature verification.

> It's not NPMs job/obligation to provide the javascript world with never
> ending storage, hosting, and bandwidth.

That's true, and a good point that we shouldn't expect it to be this way in
all circumstances. On the other hand, allowing people to rip out packages
without warning makes for a much worse npm experience. Expecting that all JS
developers set up a local proxy for all projects, particularly in a non-
professional setting, is also unrealistic. npm is indeed improving the
situation here (even if they're not solving all possible situations).

Do you think if would help if npm automatically banked packages locally? It's
not quite a company-wide proxy, but it could prevent this from failing on your
local machine without too much setup.

~~~
danjoc
>The point of that article is that it isn't. It only adds integrity if you
trust the signer.

Simply put, that article is wrong. Trust is not a binary. It's greyscale.
While no one ever achieved perfect security, pretty good security is better
than none at all.

I find it amusing that this article is published using https, that the
certificate is from Let's Encrypt, and Let's Encrypt validates CSRs using an
unencrypted side channel (DNS). I mean, what a hypocrite, right? There's a
potentially easy exploit in his system and I doubt any of his readers will
ever contact him in a secure way to verify his key fingerprint. Why doesn't he
now eat his own dog food and just give up and go with http instead of going to
the trouble of renewing a certificate every 90 days? By the logic in his
article, how can I even trust he published any of that stuff?

------
chadly
These seem to be relatively good changes. I still think the reasons they
outline for "unpublishing" (still not a word) are not compelling.

I would like to see an immutable package feed.

~~~
Osiris
So, if you accidentally publish a repo with sensitive information, you
shouldn't be allowed to correct the mistake by removing the version and
uploading a fixed version? That seems like a completely legitimate and
compelling reason to allow unpublishing.

~~~
ufmace
The linked post makes the point that if that repo was published for even a
second, then the info may have, and probably has already been, copied by any
number of people. Might as well leave it up as a reminder to change any of
that info ASAP.

~~~
laughinghan
Sensitive information is not in a binary state of "public" or "private". There
are no meaningful degrees of difficulty of access to "public" information.

Consider doxxing. Regardless of who you think is perpetrating it, we can all
agree it's real and does real harm, right? Sometimes they're from hacking into
people's accounts, but often they're from scouring the _public_ Internet for
information on a person and putting it together, making information that is
technically "public" more accessible.

Even if you change the password you accidentally published, knowing your
expired password tells me about the kind of password you're likely to use next
and for your other services. Having to find someone who was mirroring NPM's
firehose of new packages at just the right time is one more barrier to that.

------
jsprogrammer
So, NPM is charging forward like they did nothing wrong?

Where is the reflection on the kik Dispute Resolution process? How does one
non-NPM user (Bob Stratton and kik Interactive) get to harass an actual NPM
user (with millions of monthly downloads), in violation NPM policy, and still
be taken seriously, let alone succeed in taking package names with literally
(according to transcripts) no discussion from NPM?

Is it OK to start referring to people as pussies in emails to them if they
don't give up their names?

Edit: please downmodders, leave a note about why you are downmodding this.

Edit2: Wow, hit a nerve here.

~~~
petetnt
> Where is the reflection on the kik Dispute Resolution process?

In their blog? [http://blog.npmjs.org/post/141577284765/kik-left-pad-and-
npm](http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm)

~~~
jsprogrammer
That's not much of a reflection:

>We stand by our package name dispute resolution policy, and the decision to
which it led us.

There is no discussion of the transcripts, or the violations of the NPM Code
of Conduct[0] that occurred during the takeover.

A very popular community member was _harassed_ and NPM took part in it. I
haven't seen this issue addressed by any NPM representative.

>Harassing other users of the Service is never tolerated, whether via public
or private media.

>Harassment includes, but is not limited to: ... _inappropriate use of nudity,
sexual images, and /or sexually explicit language in public spaces; threats of
physical or non-physical harm;_

[0]
[https://www.npmjs.com/policies/conduct](https://www.npmjs.com/policies/conduct)

NPM not only tolerated harassment, but sided with the harasser.

~~~
alainv
Harassed? Really? The undisputed transcript[0] doesn't really support that
view, in my opinion.

[0] [https://medium.com/@mproberts/a-discussion-about-the-
breakin...](https://medium.com/@mproberts/a-discussion-about-the-breaking-of-
the-internet-3d4d2a83aa4d)

~~~
jsprogrammer
NPM supplied the definition of harassment. The problem is Bob's second email:

> _We don’t mean to be a dick about it, but_ it’s a registered Trademark in
> most countries around the world and if you actually release an open source
> project called kik, _our trademark lawyers are going to be banging on your
> door and taking down your accounts and stuff like that_ — and we’d have no
> choice but to do all that because you have to enforce trademarks or you lose
> them.

Bob was using inappropriate vulgarities and further threatened non-physical
harm against Azer's "accounts" (and other "stuff like that"), in addition to
threatening to send people to Azer's physical location ("stalking",
"following", and, "deliberate intimidation" are also considered harassment
under the Code of Conduct).

~~~
laughinghan
I may be stepping into hot water here, but I agree with grandparent and NPM
that it wasn't harassment.

Consider the following situation, which I hope we can all agree wouldn't be
bad behavior (on the threatener's part), but would be "harassment" by the same
argument you're using here:

Alice writes proprietary code for a living. Monsanto somehow (she has
difficulty proving it was illegal) obtains her (non-open-source) code and
publishes it as open source on NPM under their own name. Alice asks Monsanto
to take it down, threatening to sue them. She also asks NPM to take it down,
who complies.

Should NPM have sided with Monsanto because Alice sent them an email that
contained a threat? No, she had a legal right to make that threat!

In the email exchange between Bob and Azer, the vulgarity was referring to Bob
himself, not Azer, and the threats were ones Bob had a legal right to make—a
legal obligation, even, in some sense ("you have to enforce trademarks or you
lose them" is universal in intellectual property jurisdictions, at least
according to Wikipedia:
[https://en.wikipedia.org/wiki/Trademark#Maintaining_rights](https://en.wikipedia.org/wiki/Trademark#Maintaining_rights)
).

    
    
        > Edit2: Wow, hit a nerve here.
    
        > Edit to Steve (rate limited): [...]
    

Hmmm, whose nerve was hit? I hate corporations as much as the next indie open
source developer, but they're not the bad guy in every corporation vs open
source developer story. Sometimes the open source developer legitimately
infringed on a right that people in the corporation worked hard to earn.

~~~
jsprogrammer
>Should NPM have sided with Monsanto because Alice sent them an email that
contained a threat?

NPM should side with the first to register until told to do so by a court. NPM
just sides with whatever Trademark sends them emails containing threats?

The NPM Code of Conduct also states,

>There is never a good reason to be rude over package name disputes.

Why is Bob informing Azer that he and kik Interactive are dicks?

>Any spamming, trolling, flaming, baiting, or other attention-stealing
behavior is not welcome, and will not be tolerated.

About 8 minutes and 10 minutes after Azer asks Bob to stop email him, Bob
fires back two more unsolicited emails. kik has already decided that _they don
't even want the `kik` package name_, so, Bob is even trolling at this point
(just wants to squat a package name). On top of all that, Bob _never even
responds to Azer 's response to Bob's offer of compensation_. Bait-and-switch
much, Bob?

>Hmmm, whose nerve was hit?

HN won't publish the downmod feed, so I don't know, but the post shot to -2,
with no responses, pretty quickly.

~~~
laughinghan
> > Should NPM have sided with Monsanto because Alice sent them an email that
> contained a threat?

> NPM should side with the first to register until told to do so by a court.

Even if they believe doing so will cause more confusion among npm users than
the alternative?

> NPM just sides with whatever Trademark sends them emails containing threats?

What leads you to believe that the threats are the cause for them siding with
Kik? They've stated in multiple places they sided with kik because they
believe it would reduce confusion, and they present reasons for that belief,
and also explicitly stated that the legal issues weren't "pertinent". I've
seen no compelling case that they're lying or presenting those reasons in bad
faith.

You didn't address my point that sending a threat isn't harassment if it's a
reasonable threat to send, like threatening a lawsuit to protect your legal
right.

> Why is Bob informing Azer that he and kik Interactive are dicks?

I'm worried this will sound condescending but hopefully you'll appreciate
that's not my intention, I'm just not good enough at explaining things to
figure out a better way to word this. Bob isn't informing Azer he's a dick.
"We don't mean to be a dick, but" is a casual phrasing of "Hi, it's not our
intention to cause you pain, but we have to do this thing you're not going to
like". Someone who's writing is about to not be very nice, but they're not
being disrespectful.

By contrast, "you’re actually being a dick. so, fuck you" is unequivocally
disrespectful.

> About 8 minutes and 10 minutes after Azer asks Bob to stop email him, Bob
> fires back two more unsolicited emails.

I believe that Bob only sent one email to Azer, the other was to NPM support
not Azer, but regardless, this would be analogous to, in my allegory, Monsanto
asking Alice to stop emailing them, and Alice sending one (or two) more email
trying to reason with them. Would Alice's additional emails be spamming and
harassment?

> Bob is even trolling at this point

I've never heard a definition of trolling that didn't involve some level of
malice. Is your read that Bob is actively trying to fuck up Azer's open source
project? (You're right that Bob implies Kik ultimately ended up squatting the
package name, but you really think that's out of spite? Bob is the one saying
he doesn't mean to be a dick, not the one saying "fuck you" and summarily
unpublishing hundreds of node packages.)

> Bob never even responds to Azer's response to Bob's offer of compensation.

Seemed obvious to all 3 parties that Azer's offer was not a serious one,
Azer's blogpost specifically uses the language "After I refused them".

~~~
jsprogrammer
>Even if they believe doing so will cause more confusion among npm users than
the alternative?

Yes. Transferring names causes tons of havoc, as witnessed. Further, no one
was confused by this package name, nor are people confused with other package
names that may contain Trademarked names with code unrelated to the Trademark.

>What leads you to believe that the threats are the cause for them siding with
Kik?

People close to NPM keep making this argument. Others have reported that some
of those claims actually turned out to be lies.

>You didn't address my point that sending a threat isn't harassment if it's a
reasonable threat to send, like threatening a lawsuit to protect your legal
right.

You didn't address many of my points, so I think skipping around is fair game.
The problem with your point is that the threat is not reasonable. Bob couldn't
even give a concrete Trademark registration that the package violated (because
one doesn't exist). You're telling me that a court will have no problem with
agents sending threats of "our trademark lawyers are going to be banging on
your door and taking down your accounts and stuff like that"?

>Bob isn't informing Azer he's a dick. "We don't mean to be a dick, but" is a
casual phrasing of "Hi, it's not our intention to cause you pain, but we have
to do this thing you're not going to like".

You're right, he is informing Azer that he and kik Interactive are about to
"be a dick about it"[0]. There is just no way to spin this as being compliant
with the Code of Conduct. None. It uses an inappropriate word, and the meaning
of the phrase sets the user up as someone who violates the Code ("non-
friendly", "rude", "unsafe", "unwelcoming", "confusing", "non-respectful",
etc).

>I believe that Bob only sent one email to Azer, the other was to NPM support
not Azer,

Per NPM policy, Bob was required to CC Azer on emails to them. Azer indicates
that he was CC'd on multiple emails from Bob to NPM, so it is highly likely
that Azer received the email sent ~8 minutes after Azer asked Bob to stop
emailing him (and then Bob sent another email 2 minutes later).

> but regardless, this would be analogous to, in my allegory, Monsanto asking
> Alice to stop emailing them, and Alice sending one (or two) more email
> trying to reason with them. Would Alice's additional emails be spamming and
> harassment?

In your hypothetical? It would appear so.

>I've never heard a definition of trolling that didn't involve some level of
malice.

You and Bob have already admitted to malice (here comes, "We don't mean to be
a dick about it, but", again). I don't think malice is actually required to be
considered trolling though. kik Interactive _doesn 't even want_ (and isn't
even now using) the package, yet it is trying to acquire it. Why is Bob
spamming again (six separate emails in under three hours, three of which
received no replies)?

>Seemed obvious to all 3 parties that Azer's offer was not a serious one,
Azer's blogpost specifically uses the language "After I refused them".

I've read Azer's blogpost and "after I refused them" undoubtedly refers to his
first, entirely reasonable response, "Sorry, I'm building an open source
project with that name.". Bob escalated the situation from there.

>"fuck you"

How is this not a casual phrasing?

Bob: troll, spammer, baiter, flamer ("Azer seems to be acting pretty poorly."
[hilarious by the way]), dick, harasser

NPM: Sure Bob, have this package. Azer, good luck with your refactor!

[0]
[http://www.urbandictionary.com/define.php?term=being+a+dick](http://www.urbandictionary.com/define.php?term=being+a+dick)

~~~
laughinghan
> Transferring names causes tons of havoc, as witnessed.

What if they believe not transferring the name will cause more havoc?

> > What leads you to believe that the threats are the cause for them siding
> with Kik?

> People close to NPM keep making this argument. Others have reported that
> some of those claims actually turned out to be lies.

I'd love to hear more about that, but I hope you'll forgive me for distrusting
your memory seeing as you seem to have misremembered Bob saying he doesn't
mean to be a dick as Bob calling Azer a pussy [0].

I assume you've already seen the various places on their blog and on Twitter
than NPM has said that the threats _weren 't_ the cause for them siding with
Kik. I'm happy to produce them if you haven't.

> You didn't address many of my points, so I think skipping around is fair
> game.

I certainly tried my darnedest to, which point did I not address?

> The problem with your point is that the threat is not reasonable. Bob
> couldn't even give a concrete Trademark registration that the package
> violated (because one doesn't exist).

In my allegory, would Alice's threat only have been reasonable if she had
produced a "concrete" copyright registration?

> You're telling me that a court will have no problem with agents sending
> threats of "our trademark lawyers are going to be banging on your door and
> taking down your accounts and stuff like that"?

Yes, I am. I've never heard of a court having a problem with use of
metaphorical language when threatening lawsuits, legitimate or otherwise.

> There is just no way to spin this as being compliant with the Code of
> Conduct. None.

This isn't an argument, it's just asserting I'm wrong. The Alice vs Monsanto
allegory in my initial reply to you directly addressed this.

> it is highly likely that Azer received the email sent ~8 minutes after

I'll concede this point, hopefully it's clear that it's irrelevant to the
larger point I'm making.

> > Would Alice's additional emails be spamming and harassment?

> In your hypothetical? It would appear so.

Just so we're clear, you're saying that if someone fucks you over illegally,
and you email them asking them to stop, and they ask you not to email them
again, you trying one more time to reason with them as well as CC-ing them
when you escalate the situation is spamming and harassment of the people
fucking you over?

> You and Bob have already admitted to malice (here comes, "We don't mean to
> be a dick about it, but", again).

I acknowledged that Bob in fact did say "We don't mean to be a dick about it,
but", and suggested that it could be paraphrased to include "Hi, it's not our
intention to cause you pain...". When did I "admit" to malice? I was
specifically trying to explain why "We don't mean to be a dick about it, but"
is _not_ malice.

> I don't think malice is actually required to be considered trolling though.

Do you actually want to debate this point? [1] [2] [3]

> kik Interactive doesn't even want (and isn't even now using) the package

They went through a lot of trouble to get it, what leads you to believe they
don't want it? At the very least they explicitly say they want it to avoid
confusion for people expecting a package by them.

> Why is Bob spamming again?

That's actually a great question for you. Why do you think Bob is spamming, if
not his stated reason (avoiding confusion from people expecting the 'kik'
package to be by Kik, the software company with almost as many users as the
population of the US)? Do you think Bob woke up that morning, looked himself
in the mirror and decided his goal for the day was pissing off Azer?

> "after I refused them" undoubtedly refers to his first, entirely reasonable
> response, "Sorry, I'm building an open source project with that name."

You're right. Re-examing the timeline, "We’re not getting anywhere with this"
is clearly a response to "Azer's response to Bob's offer of compensation".

> > "fuck you"

> How is this not a casual phrasing?

It is casual phrasing, but it's also disrespectful. By contrast, "We don't
meant to be a dick" is acknowledging that the recipient is probably not going
to like what they have to do.

> "Azer seems to be acting pretty poorly." [hilarious by the way]

"fuck you" and "bunch of corporate dicks" aren't exactly shining gems of
discourse.

[0]: "Is it OK to start referring to people as pussies in emails to them if
they don't give up their names?"
[https://news.ycombinator.com/item?id=11383607](https://news.ycombinator.com/item?id=11383607)

[1]: "make a DELIBERATELY offensive or provocative online..." (emphasis added)
[https://www.google.com/search?q=trolling](https://www.google.com/search?q=trolling)

[2]: "Being a prick on the internet BECAUSE YOU CAN. ..." (emphasis added)
[http://www.urbandictionary.com/define.php?term=trolling](http://www.urbandictionary.com/define.php?term=trolling)

[3]: "...with the DELIBERATE INTENT of..." (emphasis added)
[https://en.wikipedia.org/wiki/Internet_troll](https://en.wikipedia.org/wiki/Internet_troll)

~~~
jsprogrammer
[https://news.ycombinator.com/item?id=11341285](https://news.ycombinator.com/item?id=11341285)

Your claim of misremembering is vacuous. I never claimed Bob called Azer a
pussy.

>Just so we're clear, you're saying that if someone fucks you over illegally,

Just so we are clear, I never said that. If you believe otherwise, you'll need
to produce a quote. Your hypothetical is baseless as kik was not "fucked over
illegally". kik can't produce a Trademark. Azer didn't even know who kik was.

> In fact, once Azer had made it clear that he wasn’t going to change the
> name, we decided to use a different name for an upcoming package we are
> going to publish to NPM. We did hope that Azer would change his mind, but we
> were proceeding under a different package name even when we were told we
> could have the name Kik. [https://medium.com/@mproberts/a-discussion-about-
> the-breakin...](https://medium.com/@mproberts/a-discussion-about-the-
> breaking-of-the-internet-3d4d2a83aa4d#.hz69bhd5q)

I may get to the rest later today.

~~~
laughinghan
>
> [https://news.ycombinator.com/item?id=11341285](https://news.ycombinator.com/item?id=11341285)

What is this? Is this supposed to be a point you made that I didn't respond
to? This doesn't appear to be a thread I participated in, this appears to be a
distant cousin at best to any exchange I'm part of.

> Your claim of misremembering is vacuous. I never claimed Bob called Azer a
> pussy.

It's strongly implied by:

> How does one non-NPM user [...] get to harass an actual NPM user [...], in
> violation NPM policy [...]? Is it OK to start referring to people as pussies
> in emails to them if they don't give up their names?

[https://news.ycombinator.com/item?id=11383607](https://news.ycombinator.com/item?id=11383607)

Was that just a non-sequitor?

> Just so we are clear, I never said that. [...] Your hypothetical is baseless
> as kik was not...
    
    
        > Would Alice's additional emails be spamming and harassment?
        In your hypothetical? It would appear so.
    

I thought it was pretty clear "your hypothetical" referred to my Alice vs
Monsanto allegory, not kik.

But I really don't care what you didn't say. I'm trying to understand what you
ARE saying. I'm trying to understand your notion of harassment. If someone
illegally fucks you over, and you email them asking them to stop, and they ask
you not to email them again (about them fucking you over), is it harassment to
try one last time to reason with them, and CC them when escalating the
situation?

> If you believe otherwise, you'll need to produce a quote.

While I very much appreciate that you're engaging with me, I'm under no
impression that you're obligated to do anything. I hope you realize that goes
both ways.

> kik can't produce a Trademark.

What leads you to believe this? Because they haven't yet? Neither NPM nor Azer
asked them to, why would they?

> once Azer had made it clear that he wasn’t going to change the name, we
> decided to use a different name for an upcoming package we are going to
> publish to NPM. We did hope that Azer would change his mind, but we were
> proceeding under a different package name even when we were told we could
> have the name Kik.

I'm not sure why you're quoting this, it doesn't say they don't want it, it
says they're not using it for the package they're going to publish. No one is
disputing that fact. Their stated reason for wanting the package name still
applies, namely, avoiding confusion for people who install 'kik' expecting a
package by them.

~~~
jsprogrammer
>> People close to NPM keep making this argument. Others have reported that
some of those claims actually turned out to be lies.

>I'd love to hear more about that, but I hope you'll forgive me for
distrusting your memory seeing as you seem to have misremembered Bob saying he
doesn't mean to be a dick as Bob calling Azer a pussy [0].

The thread I linked to was in response to the above ^. There (in the link) is
more about it. I believe the claims were made on Twitter and the Tweets have
likely since been deleted.

>> Your claim of misremembering is vacuous. I never claimed Bob called Azer a
pussy.

>It's strongly implied by:

>> How does one non-NPM user [...] get to harass an actual NPM user [...], in
violation NPM policy [...]? Is it OK to start referring to people as pussies
in emails to them if they don't give up their names?

>Was that just a non-sequitor?

No, it is not a non-sequitor. The problem is with Bob's language. The language
violates the Code of Conduct, but was tolerated by NPM. If NPM tolerates that
language, they should also tolerate the word 'pussy', or a derivative, being
used, however, my guess would be that NPM would backpedal on their tolerance
if a Dispute ever arose containing that word.

>But I really don't care what you didn't say. I'm trying to understand what
you ARE saying. I'm trying to understand your notion of harassment. If someone
illegally fucks you over, and you email them asking them to stop, and they ask
you not to email them again (about them fucking you over), is it harassment to
try one last time to reason with them, and CC them when escalating the
situation?

My notion of harassment isn't really pertinent. Further, we are talking about
a synthetic hypothetical (where it is already accepted that "someone [is
illegally fucking you over]" [honestly not sure what this means]), which makes
the discussion rather moot.

Bob never _tried_ to reason with Azer. When Azer finally responded to Bob
about "is there something we could do for you in compensation", Bob never
responded, but kept whining to NPM.

Bob was completely disingenuous the entire time. Note his second email to Azer
after Azer asked to not be e-mailed again:

> I don’t know why you think that makes us a dick.

Bob can't even comprehend his own text. Bob literally opened his second email
with:

>We don’t mean to be a dick about it, but

Then Azer called him out for being a Dick and Bob has no idea _why_ Azer could
possibly think him and kik Interactive are dicks? The guy is a top troll.

> kik can't produce a Trademark.

>What leads you to believe this? Because they haven't yet? Neither NPM nor
Azer asked them to, why would they?

That _and_ I have looked up all Trademarks for "kik" and none of them would
apply in this situation. If Azer was "fucking kik over illegally", Bob would
be able to prove it beyond a shadow of doubt by showing the specific Trademark
that he claims is being infringed. It's trivial, yet he didn't do it. Why
would that be?

>I'm not sure why you're quoting this, it doesn't say they don't want it, it
says they're not using it for the package they're going to publish. No one is
disputing that fact. Their stated reason for wanting the package name still
applies, namely, avoiding confusion for people who install 'kik' expecting a
package by them.

Unfortunately this contradicts Bob's first email:

> _Azer: We’re reaching out to you as we’d very much like to use our name
> “kik” for an important package that we are going to release soon._
> Unfortunately, your use of kik (and kik-starter) mean that we can’t and our
> users will be confused and/or unable to find our package.

And Mike Roberts' side:

> In fact, once Azer had made it clear that he wasn’t going to change the
> name, _we decided to use a different name for an upcoming package we are
> going to publish to NPM. We did hope that Azer would change his mind, but we
> were proceeding under a different package name even when we were told we
> could have the name Kik._

Edit: From the previous post (sorry, but I actually don't want to debate every
fine point of this story, at least not on HN [terrible interface]):

>They went through a lot of trouble to get it, what leads you to believe they
don't want it? At the very least they explicitly say they want it to avoid
confusion for people expecting a package by them.

The _fact_ that the package remains unused by kik Interactive. [0]

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

~~~
laughinghan
> The thread I linked to was in response to the above ^. There (in the link)
> is more about it. I believe the claims were made on Twitter and the Tweets
> have likely since been deleted.

Okay then.

> If NPM tolerates that language, they should also tolerate the word 'pussy',
> or a derivative, being used

What? Your argument seems to be "if NPM tolerates this one word, they should
also tolerate this other word." Why?

Even if they were equivalent in offensiveness, the way you used the word and
the way Bob used the word was fundamentally different. Calling someone a pussy
is aggressive. It's understood to be an insult. Telling someone that you don't
mean to be a dick is not insulting them. "Fuck" is arguably a worse word than
either of these, but there are plenty of ways to use it that no one would call
harassment. "I fucked up", for example.

> My notion of harassment isn't really pertinent.

I meant your interpretation of NPM's definition of harassment. Has it been
unclear that that's been the core point of disagreement for our entire
conversation?

> "someone [is illegally fucking you over]" [honestly not sure what this
> means]

I was very specific in the original statement. Someone is publishing your
proprietary code under their name.

> which makes the discussion rather moot.

It's not moot, my point logically follows from it.

> Bob never tried to reason with Azer.

You seem to believe Azer has some kind of fundamental right to this name in
the NPM package namespace. What could Bob have said that, in your view,
_would_ have counted as "trying to reason with" Azer?

> Bob was completely disingenuous the entire time.

See, when I think that, that's when I try to reconsider my take on a
situation. I can't believe Bob woke up that morning, looked himself in the eye
and decided to fuck over Azer. I think Bob was trying to release his open
source project with his own company's name, was annoyed by Azer's curt
response to his first request, and sent a pushy followup email.

> That and I have looked up all Trademarks for "kik" and none of them would
> apply in this situation.

I'm sure you have, jsprogrammer LLP.

> It's trivial, yet he didn't do it. Why would that be?

How about because no one asked him to? Because no one cares?

> Unfortunately this contradicts Bob's first email

Huh? It's perfectly consistent with "once Azer had made it clear that he
wasn’t going to change the name, we decided to use a different name". Is there
something about the timeline we're not agreeing on

First, Kik wants to publish a package, they ask for the name 'kik' from Azer
to minimize confusion. Then, Azer gives them the middle finger, Kik switches
names so releasing their package won't be blocked on seeing how this thing
with Azer shakes out, but continues pursuing the name 'kik' to minimize
confusion. Finally, NPM transfers the name to Kik, but they don't bother
switching back their package's name.

Is that not their undisputed account of what happened?

~~~
jsprogrammer
You aren't reading me right. The problem is not the _way_ in which the word
was used, but the fact that the word was used at all. The Code of Conduct
forbids it.

Further, the problem is not that Bob "d[id]n't mean to be a dick about it"; it
is that _despite_ Bob's _well-meaning intention to not be a dick_ , he
immediately reversed course with his next word, "but". So, Bob informs Azer
that he doesn't mean to be a dick, then double slaps him with full-on dick-
mode.

Like I said, a top troll.

------
roadbeats
this blog post says; no matter you're happy with or not, we'll keep profiting
from your open source work.

What community should ask NPM is; if a developer decide to delete his stuff
from NPM, keep the versions to not break other people's work, but do not show
it on npmjs.com with advertise as you do right now at npmjs.com/left-pad.

~~~
herbst
This is the first solution in this thread that sounds fair.

------
pfooti
This seems like a reasonable approach. It does bracket some of the larger
issues that the left-pad debacle foregrounded (dispute resolution and the
potential of malicious devs to release dangerous code), but it is a good step
forward. Restricting unpublish will prevent some major catastrophes in the
future.

The issue of a malicious user publishing an incremented version with bad code
still stands (as a patch semver release on a package that's not 0.X), but
that's not particular to npm. It's just part of the trust ecosystem.

The issue of conflict resolution is a thornier one. The medium post by the
people at kik [0] paints Azer in a slightly less flattering light. His actions
aren't precisely sympathetic, especially since the people at kik and npm both
attempted to amicably resolve the problem (and Kik has a legit beef here).
Conflict resolution is hard to programmatically / procedurally resolve, and in
the case of a limited namespace (more people should use scopes, I guess)
there's a real issue when you're releasing a package with the same name as
something with registered trademarks in the same domain. Argue with trademark
law if you want, and the use-it-or-lose-it features it has, but don't get mad
at npm and Isaacs for following the lawyer's lead, especially with Azer's
general attitude throughout the exchange.

0: [https://medium.com/@mproberts/a-discussion-about-the-
breakin...](https://medium.com/@mproberts/a-discussion-about-the-breaking-of-
the-internet-3d4d2a83aa4d)

~~~
catnaroek
> attempted to amicably resolve the problem

I'm not sure I'd use the term “amicably” to describe kik's emails. Was it
really necessary to use the phrase “banging on your door”? It's perfectly
possible to threaten legal action (it's their right) without, in their own
words, “being a dick” about it. They could've phrased it like this: “We'd like
to settle this dispute amicably, rather than pursue legal action, but we will
defend our trademark.” Or something like that. Dunno, IANAL.

While Azer's knee-jerk reaction didn't help matters, I can't bring myself to
blame him, because I know I would've reacted the same way, if not worse.

~~~
pfooti
Yah, the problem is (IMO at least) inherent in trademark law. If Azer actually
created an OSS package (or publicized kik broadly), the lawyers would be
pretty much _compelled_ to start banging on his door. If they failed to do so,
Kik the corporation would lose their rights to that trademark.

So yeah, I agree - the phrasing wasn't super great. But it wasn't actually a
threat in itself, just a statement about lawyers being compelled to do what
they have to do. An actual threat - hitting with a C&D letter before reaching
out - would have been much more aggressive.

~~~
catnaroek
> But it wasn't actually a threat in itself

It's a threat no matter how you slice it. You could get arrested if you bang
on your neighbor's door without a good reason.

------
kibwen

      > If you contact support, they will check to see if 
      > removing that version of your package would break any 
      > other installs. If so, we will not remove it.
    

This leaves open a window where a package with legitimately no dependents
could gain a dependent between the author contacting npm and the review being
conducted. You could likely prevent this scenario by immediately bumping the
version number and uploading again so that requests for the most recent
version of your package don't grab the version that you wish to unpublish
(assuming that it's trivial to rectify whatever caused you to want to
unpublish the prior version in the first place), but if an npm employee is
capable of checking if an unpublish could "break any other installs" then
couldn't this review process be automated? Alternatively, if npm supported
something like crates.io's "yank" operation then a package author could opt to
prevent packages from newly depending on the version in question without
needing to first tag and upload a more recent version, and also without
breaking anyone's code in case someone's already become reliant on it.

------
chris-at
This addresses unpublishing but what happens to (dubious/real) trademark
claims under this new policy?

Would this keep kik in the registry instead of forcing the dev to give it up?

~~~
levemi
npm has already says that they acted right in removing kik and that they would
keep old versions of kik around as they were. So the dev would be forced to
give it up and old versions would remain in npm.

------
apocalyptic0n3
Concerning multiple packages with the same name, is there any reason npm does
not use namespaces like some other dependency/package managers do, like
Composer? So "kik/kik" and "azer/kik" could coexist, minus legal issues of
course.

~~~
steveklabnik
[https://docs.npmjs.com/misc/scope](https://docs.npmjs.com/misc/scope)

~~~
spriggan3
Scopes are not mandatory when they should be.

------
mixedCase
Um... was vendoring deleted packages for those packages that depend on the
former too obvious?

E.g.: 1) left-pad package (containing versions 1.0, 1.2 and 1.5) is being
deleted by its author 2) Package X depends on left-pad 1.0 and package Y on
left-pad 1.5 3) Packages $PREFIX-left-pad version 1.0 and 1.5 are created from
copies of left-pad and X and Y dependencies updated to point to it. (PREFIX
being vendor, old, deprecated, or whatever you want) 4) Original package is
deleted (with version 1.2 no longer being available in the registry anywhere),
and name will remain unavailable for either a) Forever b) # amount of months
with potential adopters being able to express their desire of adoption.

Ta-da?

~~~
yati
What about a local "internal/secret" package with a dep on left-pad v1.5?
Redownloading all the deps (say, on a new box) will fail for left-pad 1.5, and
someone has to go and change the dep manually to $PREFIX-left-pad?

------
_Marak_
So wait...if I decided I want to remove my work from the internet and become a
recluse, I'll have to get permission from Isaacs?

What if I just don't want to be bothered anymore by developers looking for
support on my projects?

NPM jumped the shark a year or so ago. A package manager shouldn't be a
ventured capital funded business. We are all going to suffer from Isaac's
leadership on NPM.

~~~
gkoberger
So wait...if I depend on a package but the developer randomly wants to remove
his work from the Internet and become a recluse, my entire site breaks?

What if I just don't want to be bothered anymore by having to rewrite entire
modules I depended on?

NPM jumped the shark a year or so ago. A package manager vitally depended on
should be forced to work for free. We are all going to suffer from Isaac's
leadership on NPM.

~~~
_Marak_
If you are depending on another persons package and haven't bothered to lock
in a version or bundle the version into your application, your site is not
your site.

If you want to depend on other's peoples work without taking care to insulate
yourself, you'll have to deal with it. Why is it none of my applications were
affected by `left-pad` this week? Good question.

NPM had plenty of chances for realistic ( non-venture capital based ) funding.
They took too much cash and hired too many people. Now everything is starting
to fall apart.

~~~
gkoberger
So, if you're okay with me locking a package myself... why can't NPM just do
the locking for me? That's what's happening with this new change.

After all, I'm not a developer because I like administrative work – I want to
build stuff, and NPM takes the hassle out of this.

------
LamaOfRuin
What exactly would they do if I sent them a DMCA takedown notice as soon as I
requested that my package be unpublished?

~~~
kibwen
They could respond by linking you to their terms of service, which explicitly
gives them the right to distribute anything that you upload.

(You might be able to get around this by pretending that someone _else_
uploaded code that you authored without your permission, implying that they
never possessed the right to upload the code in the first place. This is
probably illegal, but false DMCA takedowns happen all the time e.g. on Youtube
and I've never actually heard of anyone being prosecuted for it
(unfortunately).)

~~~
LamaOfRuin
Parenthetical is my point exactly. In practice, this would require them going
to court themselves, which I don't expect them to do.

There are also many legitimate and well intentioned possibilities that could
lead copyrighted, unlicensed code onto NPM in which case they would have no
right, regardless of their ToS, to redistributed it.

I don't like the law, but it is what it is, and I wouldn't expect NPM to
actually back up their new official policy if push came to shove, because as
soon as they try to they lose safe harbor.

------
Sir_Substance
>A byproduct of being so interdependent is that a single actor can wreak
significant havoc across the ecosystem.

"It wasn't our fault guys, someone _else_ wasn't upholding their implicit
obligations to their users!"

Sheesh, grow a spine NPM.

~~~
steveklabnik
The next few sentences directly acknowledge that they built a system that let
this happen.

------
gmisra
As pointed out elsewhere, npm also already supports scoped namespaces:
[https://docs.npmjs.com/misc/scope](https://docs.npmjs.com/misc/scope)

...and has for almost a year:

> (As of 2015-04-19, the public npm registry does support scoped packages)

The right path forward probably involves encouraging major packages (e.g.
[https://www.npmjs.com/browse/depended](https://www.npmjs.com/browse/depended))
to move toward scoped package names, and then eventually deprecate non-scoped
names.

~~~
diggan
If npm have supported scoped namespaces for a long time, why take ownership
from Kik instead of suggesting the company behind Kik to create
CompanyName/Kik?

~~~
kibwen
Because Kik might have argued that _any_ package named "kik" in any npm
namespace could have been infringing on their trademark. Namespaces alone
aren't the solution to this problem.

------
abritishguy
What happens if a package is depended on but contains pirated things?

------
dantillberg
From the article: "we’ve seen a lot of discussion about why unpublish exists
at all. Similar discussions happen within npm, Inc. There are important and
legitmate reasons for the feature, so we have no intention of removing it..."

Could anyone comment on what those reasons are / might be?

~~~
phairoh
There are examples within the very article on which you are commenting. I'd
start there.

~~~
alanh
from article:

\- bugs

\- contained secrets (accidental publish)

\- embarrassment

\- open-source fatigue

------
adnanh
Couldn't they all solve this fuss with namespacing packages to the users, like
Github for example. In that case kik/kik and azer/kik would be two different
packages, and everyone would be happy. This policy is not a solution to the
real problem IMO...

------
sneak
Unpublishing 1.0.0 after 1.0.1 ships is stupid. Not all consumers are in npm.
Many of us like to use specific versions.

Unpublish should be denied except in the case of compromise. All other changes
should be accomplished via point releases.

------
partycoder
Won't be the last scandal, the JavaScript ecosystem is worrying.

------
smegel
> we have no intention of removing it...if the version is older than 24 hours,
> then the unpublish will fail

We haven't removed it, just disabled it apart from a small initial window.

------
smoyer
So with the new rules, the easiest course of action is to abandon the
published packages and fork new versions to a different repository.

------
herbst
Thats laughable. I don't see myself publishing code on NPM for which i
magically lose my rights when i decide to move on.

------
TheHolyLancer
This is completely bullshit

a community than is supposed to be ran on maturity and sharing is now being
governed with an iron fist.

if kik wanted that name, they should have offered honey first, not vague
threats of lawers

if npm wanted to arbitrate, they need to be neutral and not be for either side
(IE don't say you need to pay 1M for the pleasure, but don't just hand them
the name).

the guy was an ass, but kik started it all off by being an ass

~~~
btilly
The problem is that trademark law pushes kik to be asses here. If you're not
seen to defend your trademark publicly, you can lose it. So lawyers are
constantly looking for trademark violations. And when lawyers find them, they
usually start with legal threats.

------
spdustin
I grow more and more confused about this. Here are some quotes from their
terms of use, taken verbatim from [https://docs.npmjs.com/policies/open-
source-terms](https://docs.npmjs.com/policies/open-source-terms):

Some language was changed recently - the diff for the current version of their
open source policy is online [0].

> Nothing in this Agreement gives npm any ownership rights in intellectual
> property that you share with npm Services, such as your Account information
> or any Packages you share with npm Services (Your Content).

Makes sense. Your code is your code.

> Your Content belongs to you. You decide whether and how to license it. But
> at a minimum, you license npm to provide Your Content to users of npm
> Services when you share Your Content. That special license allows npm to
> copy, publish, and analyze Your Content, and to share its analyses with
> others.

This doesn't specify irrevocable, nor clarify how that license could be
revoked by the content owner.

> When Your Content is removed from the Website or the Public Registry,
> whether by you or npm, npm's special license ends when the last copy
> disappears from npm's backups, caches, and other systems.

This seems deceitful. What exactly does "when the last copy disappears" mean?
Seems to me that "perpetual backups" would effectively make their "special
license" perpetual. Speaking of "special license", they really need to have an
attorney write this up.

> Other licenses, such as open source licenses, may continue after Your
> Content is removed. Those licenses may give others, or npm itself, the right
> to share Your Content with npm Services again.

Fair enough, and implies that if my license doesn't give them that right, that
unpublishing the code should revoke their "special license".

> Either you or npm may terminate this Agreement at any time with notice to
> the other...The following provisions survive termination of this Agreement:
> "Your Content", "Feedback", "Indemnity", "Disclaimers", "Limits on
> Liability", and "General Terms"

So ... I can terminate the agreement, but that doesn't actually terminate
anything?

Don't get me wrong, I feel that npm serves an important function in the
community, but as this drama continues to unfold, I find myself trusting them
less and less.

[0]:
[https://github.com/npm/policies/commit/140ed66e2169e248674fe...](https://github.com/npm/policies/commit/140ed66e2169e248674fe16e920ba9a052c8a337#diff-1c802f7fe1aa289dbc553c49af4801e3)

------
tombert
Much as I like Npm, I do kind of have to wonder if all this stuff is a
consequence of having a centralized package manager.

I personally prefer the Go solution of just specifying a Git repo.

~~~
comex
Then you're just shifting the responsibility of preventing squatting from NPM
to GitHub or whoever hosts the Git repo in question. (I don't think GitHub
permanently reserves deleted usernames, though I could be wrong.) And if
squatting does occur, there is nothing like npm's previous guarantee that
replacement packages have a different version number. How is that better?

~~~
kibwen

      > I don't think GitHub permanently reserves deleted 
      > usernames, though I could be wrong
    

This doesn't actually matter, because Github allows you to rewrite your repo's
history at will. Even if Github prevented you from deleting the repo itself,
an irate maintainer looking to "liberate" their code could just delete the
entire history of the repo and force-push to achieve the same effect.

~~~
comex
Yeah, I was being overly security minded and thinking only about the threat of
someone taking the name and replacing the package with a malicious one, not
the breakage caused by the package disappearing in the first place. In the
former case, if the maintainer deletes their GitHub account, it matters
whether someone else could register the same name. But of course you're right
that Git repos are far more vulnerable to the latter too, unless you fork.

------
cwmoo740
Can I write an npm script to look at all my other npm scripts and unpublish
and republish them every 23 hours and 59 minutes?

~~~
kibwen
The OP addresses this:

 _" No new packages can be published using the same name and version."_

~~~
dates
what happens if someone writes a script to publish then unpublish every
dictionary word?

------
geekamongus
You will be assimilated. Your biological and technological distinctiveness
will be added to our own.

------
Furincer
The team at NPM deserves a lot of respect for how they have handled this, and
the speed at which they've responded to the community's demand. Bashing them
for doing this is an unreasonable double standard.

First, they provide a free amazing tool and service for the community.

Second, they didn't have the wherewithal to fight a legal battle over a naming
issue for one of their users. So they complied, and the community got upset.

Third, they apologized and took actions to conform to the community's
requests. No groveling, no excuses.

Fourth, and now people are bashing them for the opposite extreme? This is
ridiculous.

The NPM team deserves a lot of respect and praise, not loud mouthing from a
bunch of users who don't even donate to support the service.

~~~
jsprogrammer
Your facts are wrong. NPM claims there was no legal threat, they made the
transfer on their own volition. Where is the NPM apology? The blog post I saw
directly regarding the `kik` package essentially says they did everything
right and would do it again.

>We stand by our package name dispute resolution policy, and the decision to
which it led us.

NPM's decision went against their Code of Conduct. Why should that be
respected, let alone praised?

~~~
aioprisan
Why is this getting downvoted? As I read it as well, NPM went against their
own code of conduct.

------
the_ancient
>>Please post comments and questions here. We’ve moved to a Github issue for
improved moderation.

No you removed comments because you did not like the comments you were
getting... You understand that your policies are almost universally opposed by
the nodejs development community, and you are attempting to control the
conversation in order to prevent a mass exodus from npm as the default package
manager for node, which I believe should happen.

The NodeJS Package management should be maintained and run by the Node
Foundation, or other non-profit group/committee, not NPM Inc.

