Changes to Npm's unpublish policy - <AUTHOR> http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy <comment><USER2> 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?

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

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

<comment><USER4> Namespacing costs $7/mo/dev... for a string and a slash.

<comment><AUTHOR> Not for public ones. Those are free. If you want them to be private, then you pay the money.

</comment></comment></comment></comment></comment><comment><USER5> 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?

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

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

</comment></comment></comment><comment><USER8> > 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)

<comment><USER9> Time to start committing dependencies to your VCS.

<comment><USER8>
        $ 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))

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

<comment><USER8> 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)

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

<comment><USER12> Yes, if you only write JS for Chrome and Node, not sure how many JS devs fall into that bracket!

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> 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.

<comment><USER14> 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)

<comment><USER15> 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).

<comment><USER16> 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)

<comment><USER14> Thanks, the company actually eventually went with that. Our attempt was a few years back, before that was available/known to us.

</comment></comment></comment></comment></comment><comment><USER17> > 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.)

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

<comment><AUTHOR> 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.'

</comment></comment></comment><comment><USER18> "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.

</comment><comment><USER19> 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.

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

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

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

<comment><USER19> >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?

</comment></comment></comment></comment></comment><comment><USER21> 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.

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

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

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

</comment></comment></comment></comment><comment><USER25> 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.

<comment><USER26> > 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)

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

<comment><USER27> 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)

<comment><USER25> 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).

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

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

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

<comment><USER25> >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)

<comment><USER24> > 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)

<comment><USER25> [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.

<comment><USER24> > > [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.

<comment><USER25> >> 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)

<comment><USER24> > 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?

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

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> 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.

<comment><USER29> This is the first solution in this thread that sounds fair.

</comment></comment><comment><USER30> 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)

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

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

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

</comment></comment></comment></comment><comment><USER6>
      > 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.

</comment><comment> 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?

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

</comment></comment><comment><USER33> 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.

<comment><AUTHOR> [https://docs.npmjs.com/misc/scope](https://docs.npmjs.com/misc/scope)

<comment><USER34> Scopes are not mandatory when they should be.

</comment></comment></comment><comment><USER35> 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?

<comment><USER36> 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?

</comment></comment><comment><USER37> 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.

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

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

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

</comment></comment></comment></comment><comment><USER39> What exactly would they do if I sent them a DMCA takedown notice as soon as I requested that my package be unpublished?

<comment><USER6> 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).)

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

</comment></comment></comment><comment><USER40> >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.

<comment><AUTHOR> The next few sentences directly acknowledge that they built a system that let this happen.

</comment></comment><comment><USER41> 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.

<comment><USER13> 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?

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

</comment></comment></comment><comment><USER42> What happens if a package is depended on but contains pirated things?

</comment><comment><USER43> 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?

<comment><USER44> There are examples within the very article on which you are commenting. I'd start there.

<comment><USER17> from article:

\- bugs

\- contained secrets (accidental publish)

\- embarrassment

\- open-source fatigue

</comment></comment></comment><comment><USER45> 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...

</comment><comment><USER46> 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.

</comment><comment><USER47> Won't be the last scandal, the JavaScript ecosystem is worrying.

</comment><comment><USER48> > 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.

</comment><comment><USER49> So with the new rules, the easiest course of action is to abandon the published packages and fork new versions to a different repository.

</comment><comment><USER29> Thats laughable. I don't see myself publishing code on NPM for which i magically lose my rights when i decide to move on.

</comment><comment><USER50> 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

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

</comment></comment><comment><USER5> 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)

</comment><comment><USER52> 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.

<comment><USER53> 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?

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

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

</comment></comment></comment></comment><comment><USER54> 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?

<comment><USER6> The OP addresses this:

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

<comment><USER55> what happens if someone writes a script to publish then unpublish every dictionary word?

</comment></comment></comment><comment><USER56> You will be assimilated. Your biological and technological distinctiveness will be added to our own.

</comment><comment><USER57> 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.

<comment><USER25> 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?

<comment><USER58> Why is this getting downvoted? As I read it as well, NPM went against their own code of conduct.

</comment></comment></comment><comment><USER59> >>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.</comment>


Explain xkcd : It's cause you're dumb - <AUTHOR> http://www.explainxkcd.com/

<comment><USER2> Here's what's going on with the Banach-Tarski paradox:

First, in case this wasn't clear from the explanation, you have to carve the pumpkin into some very specific pieces in order to be able to re-assemble them into two pumpkins. In particular, you have to carve them into some pieces that are _non-measurable sets_ , which basically means that the carving is so exotic that it is not possible to define a consistent concept of volume for these pieces. This is sort of the heart of the paradox: you get volume- preserving transformations to disobey preservation of volume by using intermediate steps with undefined volume.

Non-measurable sets are not 100% legit in mathematics. Constructing them relies on the Axiom of Choice. I won't get into the debate about the Axiom of Choice, but suffice it to say that if you reject the Axiom of Choice, then the Banach-Tarski Paradox need not be true, and you can self-consistently reject the BTP if you are OK losing the AOC.

The biblical reference from King Solomon is probably referring to the parable of splitting the baby. Two women came to King Solomon, each claiming to be the true mother of the baby. King Solomon suggested cutting it in half, in order to observe the claimants' reactions. The fake mother was ok with this, and the real mother would rather give up her child than see it killed, . XKCD suggests that King Solomon was actually attempting to use the Banach-Tarski paradox to create two babies.

<comment><USER3> There's a bit more to the subtext than that. The Axiom of Choice sounds quite innocuous: If you have a bunch of sets, you can construct a new set by picking one element out of each of them.

Turns out you can reason your way from that to "I can make any solid 3d object into any other solid 3d object just by cutting and rearranging the parts". (Banach-Tarski is often explained as the ability to turn one sphere into two, which is true, but the full implication is more along the lines of being able to rearrange a pea into the earth.) This is just one of many scary dragons that lurk in set theory.

Historically speaking, Banach-Tarski is _why_ the Axiom of Choice is controversial. The other (I forget, nine?) axioms in ZFC, garner a tepid response--along the lines of, "Hooray, someone axiomatized set theory." But AC remained controversial for a long, long time. I cannot find the quote, but there was a mathematician who refused to accept the Axiom of Choice, and when asked about it, commented, "It is because I do not believe one and one make three." He was referencing Banach-Tarski.

That is the dilemma that has faced mathematicians historically: either reject something so innocuous as the Axiom of Choice or embrace something so nonsensical as the Banach-Tarski paradox. "Controversial" is putting it lightly; that's a hard decision. One still sees textbooks that flag all theorems depending on the axiom of choice, so you can reject them if you want to. I would say the field as a whole has come to embrace AC and accept Banach- Tarski; one of my professors one commented, "If we need the axiom of choice in this proof, we'll use it; why do mathematics with one arm tied behind your back?" I think this reflects the common attitude. But it wasn't an easy choice.

And that's the joke. If the guy didn't want one pumpkin to equal two, he should have gone the other way and rejected AC. It is not unfair to characterize Banach-Tarski as the sorry consequence of something mathematicians really wanted to do -- collateral damage, the lesser evil. One could regret it.

<comment><USER4> To be more specific about what exactly the Axiom of Choice is:

If you have a finite number of sets, you don't need the Axiom of Choice. You can enumerate them and pick out of each.

If you have a rule to choose items, like picking the smallest element in a set of natural numbers, you don't need the Axiom of Choice. There is no choice to be made, you just follow the rule.

The problems come out when you have an infinite number of sets and you pick items arbitrarily. This is what the Axiom of Choice allows you to do. Infinity is dangerous.

<comment><USER3> Actually, I think countably infinite sets of sets are okay, too. It's when you're allowed to choose an arbitrary element from an _uncountably_ infinite number of sets that weird things start happening.

(Not that I can call pedantery given the sheer number of who-cares-about-the- details glosses in my original comment ;)

And I don't know that I'd call infinity dangerous so much as I'd call it sanity-stretchingly _counterintuitive_.

Which makes sense, really. Where would we have developed intuitions for dealing with the infinite?

</comment></comment></comment></comment><comment><USER5> At the end of the post, the author says he doesn't get the King Solomon reference. It's to the story of the king's offering to resolve a dispute about which of two women was the mother of the child by cutting the baby in two. See <http://en.wikipedia.org/wiki/Judgment_of_Solomon>; [http://www.biblegateway.com/passage/?search=1Kings%203:16-28...](http://www.biblegateway.com/passage/?search=1Kings%203:16-28&version=NIV)

</comment><comment><USER6> I thought the first panel was the funniest. "I carved a pumpkin" is true in at least two ways for the character, and untrue in the "This is not a pipe" Rene Magritte way.

</comment><comment><USER7> There is also <http://xkcdexplained.com/>

<comment><USER8> XKCD Explained is much better -- because it has the right perspective; it's explaining the comics to people who already understand them, shitting on the author and his idiot audience.

XKCD is a condescending comic whose audience revels in its own perceived superiority, while any self-respecting nerd with a real sense of humor knows that putting a science or technology reference in a cartoon is not a joke in itself.

<comment><USER9> You're very wrong about XKCD. There's a whole slew of un-funny techy strips, "User Friendly" being the canonical example. XKCD by comparison is often hilarious. The fact that it requires inside knowledge and targets a specific audience does not automatically make it unfunny, nor does it make anyone who enjoys it "revel in their superiority".

<comment><USER10> perhaps rogerclark is referring to this comic alone; it indeed seems to offer a technical reference as the sole point of humor, at least in the final frame.

Although I do enjoy frame 3 on its own merits.

<comment><USER9> Grammatically that is clearly not what he meant unless he is not a native English speaker and thus not aware of the finer points of article usage, but I doubt that.

<comment><USER11> Oh my god. Irony is beautiful.

<comment><USER9> I don't think you know what irony means.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I can't say that I've ever needed another website to explain this. If there's something I don't get, a quick visit to Google or Wikipedia usually fills in the rest and people in the comic thread even supply links to the relevant parts rather quickly.

I have to say, though, that I'm surprised by how many people know Banach- Tarski, but who never heard the story about King Solomon threatening to cut the baby in two in order to discern who cared about its life the most (in other words, to find the real mother).

</comment><comment><USER13> I do not understand it. "If you want to be a hipster, you need to read xkcd, and if you do not get it, it is no problem, because we can explain it to you"?

Come to think of it, maybe recent xkcd panels would amuse me more if I did not understand them.

</comment><comment><USER14> From wikipedia: "Unlike most theorems in geometry, this result depends in a critical way on the axiom of choice". By "taking" the AoC the figure ended up making two pumpkins. Not really funny at all, I'm afraid.

</comment><comment><USER15> If you can cut something into infinite pieces and then reassemble it into two of the same object - you obviously have a rounding error where you are "rounding up" each fraction when it should not be!

No?

<comment><USER16> [https://secure.wikimedia.org/wikipedia/en/wiki/Banach%E2%80%...](https://secure.wikimedia.org/wikipedia/en/wiki/Banach%E2%80%93Tarski_paradox)

It works because, if you assume the axiom of choice, you can postulate "pathological" sets that don't have a mathematically well-defined volume. You can use this to backdoor volume changes, by cutting something with well- defined volume into a buncha pieces without a well-defined volume, then reassembling this into something with a different volume than the original.

You can't get around this trick by redefining what it means to measure something: If you pick any reasonable definition, it must admit the Banach- Tarski paradox. [https://secure.wikimedia.org/wikipedia/en/wiki/Non- measurabl...](https://secure.wikimedia.org/wikipedia/en/wiki/Non- measurable_set)

These pathological sets are too weird to exist in physical reality.</comment></comment>


Ask HN: Tech journalist asks, What prompted this fuss over patents? - <AUTHOR>

Hello HN Community,
I am a dogged Hacker News browser, a startup founder, and a contributing editorialist at a small Chicago-based tech news blog, Tech.li. I've noticed, over the past two to three months, that intellectual property matters (particularly software patents) are a "trending topic", if you will, on HN.
If I were more adroit with code, I'd us the HN Search API to get all the instances of the words "patent" "software patent" "patent troll" and "intellectual property", and come up with a nice graph showing, as of late, a precipitous increase in these words' occurrence on HN. I invite someone to undertake this little project. (I can do all of the data, I just need the data.)
But, I'm not here to suggest an interesting data visualization project.
I come to the community asking a couple of very simple questions.
First, what precipitated all of this attention to software patents, and intellectual property in general? Granted, I've been living under a rock for the past few months (startups tend to do that, even for people on the "business side"). It could be that I missed the big event which prompted this debate.
My second question has two parts: Why is the US government so recalcitrant when it comes to changing an obviously broken intellectual property system, especially as it relates to science and technology? And, other than writing vitriolic blog posts and inveighing against the USPTO and so-called "patent trolls", is there anything else we–innovators, technologists, hackers, artists, and what have you–can do to change things?
A third question goes out to those in the HN community who hold patents, whether hardware, software, or (as is often the case) vaporware. Why did you patent your thing? Was it on the suggestion of a lawyer, your investors? Did you file a patent application without any advice, just because you wanted to? I'm curious.
Anyways, just a few questions. It'll be interesting to see how the discussion unfolds.
Best, Jason <comment><USER2> Software patents have been a topic of interest on HN for as long as I've been reading it. The recent surge of interest started with Oracle suing Google over Davlik but really took off when Lodsys went after Jesus phone developers. Microsoft's pursuit of license fees from Android hardware manufacturer's threw fuel on the fire by proving that only the evil patent their work. Google getting outbid on the Nortel suite and their subsequent claims that implied they only pursued the portfolio for the benefit of OSS kept it alive.

On a meta level, the patent issue is so interesting because it creates such internal contradictions for the libertarians who comprise a significant fraction of vocal HN'ers. On the one hand, patents as the something belonging to the creative individual to dispose of as they see fit certainly resonates with the general philosophy of many people inclined toward libertarianism. However, the mechanism for granting patents is solely in the purvue of the government and must therefore be assumed to be part of a flawed process which harms business according to standard dogma.

In many ways the current drama unfolds according to one of the subtexts of HN - Silicon Valley v the Rest of the World. It's those plucky Silicon Valley startups like Google and Apple [sarcasm] who are suffering at the foreign hands of Nortel and Microsoft, e.g. nobody talks about Intel's and HP's patent portfolios.

</comment><comment><USER3> These are not simple questions. If you are a journalist, follow the money. I personally suspect that the offensive use of patents, both by "trolls" such as Lodsys and large players such as Microsoft, has stepped on enough toes to cause certain vested interests to start a broad-spectrum fight against other vested interests. One usual result of those kinds of fights is manipulation of the public sphere, also known as "press relations".

<http://www.paulgraham.com/submarine.html>

</comment><comment><USER4> I'll take on your first question. In large part for me, the implications of software patents are becoming an increasingly clear obstacle to individual developers. We're not talking patents for incredibly complex processes and lawsuits aimed at specific, large companies. Instead, we're facing lawsuits over (arguably) trivial/common features of an app. These can have a very direct negative impact to the individuals that frequent HN.</comment>


PureVPN facing legal issues? - <AUTHOR>

Recent mail from PureVPN. I hope it goes well for them, but watch out...
Dear customer,
I'm sorry to inform you that due to an incident we had to close your account permanently. We are no longer able to run an anonymization service due to legal issues we are facing.
We had to handover all customer's information to the authorities unfortunately. They might contact you if they need any details about the case they are working on. The following information was handed over: your name, billing address and phone number provided during purchase and any documents we had on file (for example scan of your ID or driver's license if you have provided these to our billing department).
We are also sorry we are not able to refund you, however if you wish your money back, please open a dispute on PayPal or file a chargeback with your credit card company. This is the only way we can refund you as our bank account is frozen during this investigation. We recommend you to do this as soon as possible as we can't guarantee all customers will get their money back.
We apologize once more this had to happen.
Yours sincerely, Uzair Gadit PureVPN founder <comment><USER2> Hi Guys!

Thank you for your support here on ycombinator!

Yes it was a fake email sent to PureVPN Customers. However, our VPN service is functioning 100% fine and there is no interruption whatsoever.

While we are further investigating the actual cause. Please check out our blog for further clarifications and updates:

[http://www.purevpn.com/blog/fake-email-to-clients- update-1/](http://www.purevpn.com/blog/fake-email-to-clients-update-1/)

We are also keeping our customers updated every minute through our Twitter channel. Please follow us on twitter @purevpn for further updates.

Thank you everyone!

PureVPN Team!

<comment><AUTHOR> Good to hear you are not closing down! :)

</comment></comment><comment><USER3> They are claiming, over their twitter account, that the email was faked:

[https://twitter.com/purevpn/status/386700121053736963](https://twitter.com/purevpn/status/386700121053736963)

<comment> workhere-io _Guys, email tht u received is a fake. v r NOT closing down nor hav ANY legal issue of ANY sort._

Wow. I seriously would not pay any money to a company that communicates like that.

<comment><USER4> So, compromised instead... Seems I am not the only one thinking this.

[https://mobile.twitter.com/TeamAndIRC/status/386703066285633...](https://mobile.twitter.com/TeamAndIRC/status/386703066285633537)

Especially if only account owners have been mailed (which I am not, BTW). And what is up with the unprofessional response on twitter: V r ?

</comment></comment></comment><comment><USER5> From a naive reading of their privacy policy [0] it seems they also keep a history of sites visited, and make this available to third parties. That doesn't sound like "anonymizing your locality" except to your local ISP, and only if your local ISP or government never asks PureVPN for the info.

[0][http://www.purevpn.com/privacy-policy.php](http://www.purevpn.com/privacy- policy.php)

<comment><USER6> I have said this time and time again, the only way to be properly safe when using a VPN is if the supplier can guarantee that NO logs at all are saved - of course, no one can guarantee that without showing you the system.

Setting up your own private fully encrypted (Harddrive) OpenVPN is quite easy and the only "secure" alternative.

<comment><USER7> >> Setting up your own private fully encrypted (Harddrive) OpenVPN is quite easy and the only "secure" alternative.

You are misunderstanding the reason people use these services. They use it to stay anonymous because many people use it and it is harder to distinguish what traffic belongs to what user.

If you setup your own vpn server, encrypted or not, it defeats that purpose because one could just listen on the other end.</comment></comment></comment>


Awesome-live-reloading – A collection of live reloading tools and libraries - <AUTHOR> https://github.com/hasura/awesome-live-reloading <comment><USER2> I'm surprised not to see generic tools on this list which make use of event- based file system notifications such as dnotify and inotify. See [https://github.com/rvoicilas/inotify- tools/wiki](https://github.com/rvoicilas/inotify-tools/wiki) or inotifywait ([https://superuser.com/a/959040](https://superuser.com/a/959040)) for examples.

I know this particular API (inotify) is specific to Linux (there might be similiar APIs on other OS). But it is awesome for all kind of build systems, for instance latex documents.

<comment><USER3> Oh I love inotify-wait. So many times I'll start trying to be clever, then delete the whole thing and replace it with inotify-wait

</comment></comment><comment><USER4> The origin of this list was when we were creating documentation for live- reloading code you write on your computer, and syncing those files to your cloud dev/staging environment directly. We then realised that there was no central repo of "live-reloading" tools for different languages/frameworks.

There's a slew of new tools coming out that are making this trend popular (skaffold, ksync, hasura). Some of which need your framework to have live- reloading and some don't.

I'm wondering what the HN community thinks about this general trend of pushing this write/test loop to a hosted dev environment. I think it's a response to increased complexity of bring up a full "microservices" environment on your local machine.

<comment><USER5> I've actually been using a fully hosted dev environment for about a year and a half now for my side projects and it works really well. I started by using Cloud9, then after I had some difficulties with the switch to AWS Cloud9, I spun up a $5/mo Digital Ocean droplet with my entire dev system on it. I use vim and tmux to replicate the classic IDE feel of paned windows. I keep a very minimal tmux config and vimrc so it's super-compatible across machines.

DO does cheap backups for me so in case I hose something I can quickly restore, my code is on GitHub so it can be pulled back down, and I can get to it from basically any machine I own with nothing installed locally. Just the ability to SSH is all I need. I've connected from a Chromebook and an iPad/iPhone variously to do small bug fixes and quick push to production while I was away. I can get away with a cheaper/older dev machine because my local specs don't matter. If my tests are going to run long... who cares? It's not running on my machine, so I can close the lid and walk away if I need to, and it will keep running.

</comment></comment><comment><USER6> [https://github.com/johnno1962/injectionforxcode](https://github.com/johnno1962/injectionforxcode) for IOS apps. I'd submit a pull request but i'm lazy.

</comment><comment><USER7> Unless we are dealing with a list just strictly for frontend development(webpack/sass/etc), I'm kinda confused about the list. What about servers and daemons that perform "hot-reload" for you? And fsevents / inotify are the way to go, otherwise you will deal with 1~10+ seconds reloads, which can be miserable at times.

</comment><comment><USER8> Or just use Clojure and get live coding for free. Its far more powerful than hot reloading.

<comment><AUTHOR> Haha. Do you think live coding is cool enough a feature to move to a particular language?

<comment><USER9> Yes, it's easily one of the most compelling language "features" (in quotes because its something more fundamental than that) you can have.

Unfortunately, management almost never sees it that way.

</comment></comment></comment><comment><USER10> I was expecting single stage presses, neck dies, powder dribblers, and Sierra load manuals, live. Disappointed.

<comment><USER11> I feel your pain</comment></comment>


Drinking Your Way Up the Ladder - <AUTHOR> http://www.zevgroup.com/socialdrinking.html

<comment><USER2> This is pretty interesting in light of my hosting Hacker and Founders in Silicon Valley and San Fran (Meetup on thursday if you're interested <http://hackersandfounders.com> ).

We've tried a lot of different formats: coffee shop, lectures and presentations. None of them work for us quite as well as going to a bar and chatting. We've thought a lot about this over the past two years.

People instinctively understand that when they go to a bar, they are there to relax and have a good time. A lot of times, people are really stressed out from a long day at work, and would like to have a drink, unwind and chat. People don't tend to unwind in a coffee shop or a restaurant. While I've certainly enjoyed the lobby chat at conferences I've been to, but bar talk with the geeks at hackers and founders tends to be a lot better imho.

I'd also say, that the best business relationships that I've developed have involved social alcohol. I grew up in a teetotaler household, and I've made a point of learning how to drink socially and responsibly. Frankly, it requires practice. I think it's actually a pretty valuable social skill to have in the startup world.

Final point. We've pretty much standardized on having alcohol at every Hackers and Founders Silicon Valley, and I have yet to see a single person get drunk, or concern me that they were going to be unsafe while driving.

</comment><comment><USER3> It's amazing the effect a first drinking session make for a new employee. Countless times I've seen the difference after that 'first night out' for new staff - the next day they really are much more accepted into the team, and much less 'the new guy'.

If you've recently started somewhere, and feeling a little disconnected from the rest of the team, get down the pub or bar with them and you will definitely notice the difference the next day. It's also true to say the heavier the session the more the bonding.

<comment><USER4> A bonding session doesn't have to involve drinking. It's merely a cultural custom. Drinking has a lot of potentially unhealthy side-effects and while I don't think anyone should drastically change their behavior as a result of one simple study, it's worth taking a step back to look at the role alcohol plays in your life and whether its benefits are really worth the drawbacks.

<comment><USER5> So have a couple club sodas and lime. As long as you're tolerant of how the people with a little bit of a buzz going are acting, you shouldn't feel particularly excluded. If people do make a big fuss about it, you should probably find drinking buddies with more interesting things to talk about. :-)

<comment><USER4> That's one answer for some people. Regardless, it's missing the point that this study isn't saying "stop going out with friends for drinks!" It's an examination of social customs and their effects. That I can order a Shirley Temple with a straight face while others drink straight Jameson is largely irrelevant.

Yes, there benefits of going out for drinks. Those haven't been disputed, that I can see.

</comment></comment></comment></comment><comment><USER6> What a fantastic way to extinguish through overanalysis any joy that might have been had from the simple pleasure going for a quick drink after work. I realise that drinking cultures might vary enormously but I just don't recognise the fraught environment that is being presented here; I have never seen anyone put under pressure for not drinking, and "White wine won't mix with the whiskey crowd"? Really? I like to go out with work colleagues on occasion. I find that if you are going to spend eight hours a day with some people it helps to get to know them personally a little bit, and this in turn eases the working relationship. This doesn't have to be achieved by going to the pub; that's just a social norm. In some cultures a convivial gathering might mean drinking sweet tea and smoking a hookah, but in mine it involves booze.

<comment><USER4> It's not overanalysis. The fact that drinking and losing sleep is physically unhealthy, along with the fact that there's widespread social pressure to partake, means that the question is worth exploring. You don't have to agree with the answer, but your dismissive and defensive attitude is exactly why a study like this is worthwhile.

If you aren't someone who prefers not to drink, you probably don't really understand where the pressure comes from.

Every single time you go out with new people, people make comments on your lack of drinking. Either the fact that you ordered a 7-up or that it's been 3 hours and you still haven't finished your first beer. Plus the bar itself is designed to sell alcohol, so there's inherent pressure just by being there.

My primary career (IT) doesn't involve a lot of people going out drinking on a regular basis. But I sing for fun, and in that field people are constantly out late, and yes there is pressure to drink. EVERYONE who goes out drinks more than me, and even people I've known for a year or more still make comments. And lately I've had to skip the drinking night because I have to be up at 6:30 AM the next morning for a meeting. I feel much better physically and mentally but I'm socially out of touch.

Plus, there's the matter of being at the bar when your regular bedtime passes and your melatonin starts kicking in. All the drinkers don't even notice and sit around yammering for another hour or four while you sit there yawning.

<comment><USER7> "If you aren't someone who prefers not to drink, you probably don't really understand where the pressure comes from."

Some of us who do choose to drink at times also choose _not_ to drink on certain occasions - e.g. weeknight w/ workout or yoga at 0630. There's definite social pressure to drink at a "drinking establishment" but I don't recall anyone ever wedging my jaws open and funneling beer down my throat.

Hold your own frame and never let your reality be dominated by the throwaway comments of others.

If you want to use a decoy, get a 1/2 cranberry / 1/2 soda with a wedge of lime. Looks like a "real" drink.

<comment><USER4> _I don't recall anyone ever wedging my jaws open and funneling beer down my throat._

That's really why I made the post. Just to explain that this study fully understands that most people do not have beer forced down their throats and instead examined broader trends. My point was to show that there is a whole spectrum between not feeling any pressure and being threatened at gunpoint.

</comment></comment></comment></comment><comment><USER8> It seems that socializing over alcohol is the lowest common denominator for after work activities. Personally I would rather socialize over a nice meal or go play some multiplayer games or plan an outing to an airsoft field. But after work, in a metro area, the bars are plenty and accessible.

I wish someone taught me the strategy of socializing over drinks. As an introvert, I avoided these kind of events and really didn't get anywhere in terms of progressing through the corporate ranks. Realizing that I needed to change me behavior, I started joining these events. It really is a good opportunity to grease the bureaucratic wheels found in corporation to get things done during the work day. It's a teachable skill.

Now my work day really doesn't end when I leave the office. It's "business beers" in the evenings.

</comment><comment><USER9> I'm a practising Mormon and so don't drink but often hang-out after work with others. My career has been progressing very well in my opinion and not drinking hasn't had an effect as far as I can tell.

I think that being it is being sociable with others that helps you move up rather than specifically drinking.

<comment><USER10> I have to agree - although I've done the business drinking thing myself, a very little, I think most of the pressure is people wanting you to validate what they know is stupid behavior. If you laugh with them and make it clear you don't care that they're killing their own brain cells, most of them won't hold it against you. Self-deprecating humor is best.

</comment></comment><comment><USER11> The point that surprised me the most was the study about lower salaries for non-drinkers (-12.8% for men and -25.5% for women). While the study is from 1988 I'm curious how much has changed in the meantime. Although I'm in doubt that the sole reason for this discrepancy is the willingness to drink.

Maybe you earn more in the investigated industries if you are an outgoing "people person". And maybe you are more likely to drink if you are outgoing. It's the old causation/correlation thing. But still interesting.

<comment><USER12> I am REALLY suspicious of statistics like that. Are we including people too young to drink (21 in the US) who will be on much lower pay anyway? Let's see it as "people in industry X in city Y age Z" and I bet it's not so much.

</comment></comment><comment><USER13> The pub is part of our interview process. Before taking anyone on we take them to lunch and they meet everyone in the office they will work with. It's an opportunity to meet people and see how well they get on. When we get back we have a discussion about the candidate and whether or not we should hire them, if they don't fit in, no hire.

I appreciate it's an unfair test and that only the dumbest candidates wouldn't realise that this is part of the interview process but being outside of the office, having an opportunity to talk with the people that you'll work with gives the candidate as much of a view of whether or not they want to work with us as the other way around.

<comment><USER14> What about interviewees who don't drink (for personal or religious reasons)?

<comment><USER15> Presumably if they go along to the pub, have a soft drink, and get along with everyone, they pass the test.

</comment></comment></comment><comment><USER16> If the mangers can't stand working with someone their going to favour another person who they like to work with and fits their mood and culture. Even if the other person is a better candidate for the position, we don't work in a bubble, the relationships between people are going to play a part.

There would be workplaces which work the other way, where people abstaining from alcoholic fueled after work events look more favourable.

</comment><comment><USER17> Correlation does not equal causation.

</comment><comment><USER18> There is no ladder.

</comment><comment><USER19> It seems like this applies to people who want to ascend to upper-management in large companies, where drinking the right drinks and playing the right sports matters.

On the other hand, I know a lot of small businesses that have been hit _very_ badly by a partner or early employee with drinking, gambling, or other character issues. They tend to be much less into the alcoholism. Social drinking's one thing, but the "3-martini lunch" is ridiculous. Software isn't like _Mad Men_.</comment>