policies

Security & Privacy

Explore on GitHub Read Hacker News discussions

7Distinct people

7Mentions

0Explicit recommenders

69GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2015-10-31 22:54:43 UTC to 2020-05-09 14:16:29 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	5	5
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1

What Hacker News says

5 sources

laughinghan·Mar 30, 2016

This concern is indeed not addressed in the text I cited. However, though my English reading comprehension isn't precisely the best either, I'm pretty sure this concern wasn't brought up in your comment that I was replying to when citing that text. I don't see this concern addressed in their Package Name Disputes document at all: https://www.npmjs.com/policies/disputes Perhaps they'd be delighted if you brought it up in the public forum they linked to at the end of the blogpost? https://github.com/npm/policies/issues/44

In Changes to Npm's unpublish policy

kibwen·Mar 29, 2016

Responding to your edit: the OP mentions that lawyers were indeed involved in drafting these terms: "These lines are the result of a clarification that we asked our lawyer to make for the purposes of making this policy as understandable as possible. You can see that in this PR." The linked PR is https://github.com/npm/policies/pull/43/

In Changes to Npm's unpublish policy

spdustin·Mar 29, 2016

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: 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 irrevocab

Read the rest

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

In Changes to Npm's unpublish policy

joeyespo·Mar 29, 2016

It appears that by publishing, you accept their terms in allowing them to distribute the package [1]. They also say they won't run the code directly (although they may analyze it), which might sidestep certain license issues. My guess is that it's no different than posting it on your own website and having the Internet Archive back it up. (IANAL. Just doing my best to interpret their policy.) [1]: https://github.com/npm/policies/pull/43/files

In Changes to Npm's unpublish policy

tlrobinson·Mar 29, 2016

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

Read the rest

o 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 2. GitHub issue with additional discussion here: https://github.com/npm/policies/issues/44

In Changes to Npm's unpublish policy