Changes to Npm's unpublish policy
blog.npmjs.org
blog.npmjs.org
And the current changes don't help with the pissed off developer scenario much. Because a pissed off developer can simply publish broken versions of packages instead of unpublishing them, and still break the world.
Actually my question (I'm parent) is also on the technical level, since I'm pessimistically assuming the lawyers will win everytime.
If Sandra renames her package (voluntarily or not) - will the old versions with contested name resolve correctly stickman v0.99? Or will they be gone forever? Will Stick Corp inherit management of the old versions? Is it a good idea? Who will manage point-release vulnerability upgrade - Sandra or Stick Corp? etc. There are a lot of questions relating to the original quagmire that NPM Inc is not answering.
The goal of Npm should be to insure that any software built using their tools enjoys uninterrupted historical continuity and progress. The technical challenge is as serious as the political complexity--exactly as it should be! Rash and sudden movements (yanking version, letting squatters snap up names) are undesirable because they do not honor the spirit of necessity:
Move only when necessary, and then move decisively, and always fight to ensure the historical continuity of the software. If people are confused, illustrate the precept in your actions and instruct the people!
The reason kik was an issue isn't just that "Kik" is a trademark. It's that "Kik" is a trademark referring to a piece of software.
>Computer software for use with mobile devices, namely, computers, personal digital assistants (PDAs) and mobile phones for downloading, displaying, transmitting, receiving, editing, extracting, encoding, decoding, playing, storing and organizing text, sound, images, audio files and video files
The `kik` package was software that was used with other devices for other purposes.
KIK Interactive hasn't even been able to produce a specific Trademark that the `kik` package would have infringed upon.
npm is growing hugely. It needs to sort out the domain space issue quickly.
And, it's not actually clear that a namespace would have been enough had a lawsuit actually been filed.
You may be right about the lawsuit.
I am not sure if I am being playful or not. I'll edit this post if I figure it out before the hour's grace period is up.
it's almost as bad as putting HTTP protocol in XML namespaces.
If you want namespacing to be tied to Internet domains then I want the right to take over your code after you forget to renew your domain.
at most you can borrow one.
What's the problem?
If not, or if we're going to put whatever we want in there anyway, then why hold to the idea it must correspond to a domain name anyway?
People advocating using a domain as the namespace get the same result, but the package namespace is tied to a domain, you have to have control of that domain, if you lose it, do you lose the namespace?
What if I don't own any domain, people are saying in that instance I should use io.github.myusername, why not just myusername? that way my code isn't tied to a platform I may not use in 5 years time.
I suppose that's it, a namespace is about my code, not about where the code is maintained or an external resource I may or may not keep access to, so don't namespace it in a way that ties it to such.
It was abrupt unpublishing, not our resolution policy, that led to
yesterday’s disruptions.
just saying it twice from the same month doesn't make it less one sided.
○ The dispute resolution policy minimizes disruption.
Transferring ownership of a package’s name doesn’t remove current versions
of the package. Dependents can still retrieve and install it. Nothing breaks.
Had Azer taken no action, Kik would have published a new version of kik and
everyone depending upon Azer’s package could have continued to find it.
It was abrupt unpublishing, not our resolution policy, that led to
yesterday’s disruptions.
My English reading comprehension isn't precisely the best, but I'm pretty sure this concern isn't addressed in the text you cited.
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
Or perhaps they would not. After all, my question is a very natural question to ask, and they don't seem to have given it any thought, as if they were ignoring a particularly big elephant in a small and cramped room. It seems deliberate to me. And, even under the unlikely assumption that it isn't deliberate, it says a lot about npm Inc's lack of empathy for their own users.
In any case, not being a JavaScript programmer myself, let alone an npm user, I can't bring myself to care enough to comment on their GitHub issue.
To make clear a package you published is your intellectual property, you're expected to use the "author" field in package.json; it's also common to mention your name in the README. The versions you published would continue to name you in the "authors" field and in the README, rather than someone else. Perhaps NPM thinks that suffices.
(You might do neither of those things, and the someone else might use your name to publish later versions of the package, or a random person might use your name to publish a completely different package. But these problems not affected by the policies being discussed, nor really have anything to do with NPM seeing as the same thing could happen on GitHub (someone else can publish a repo and attribute you as the author; also, will GitHub make perfectly clear that a repo you publish is your intellectual property, rather than someone else's?).)
My question doesn't apply to GitHub, because GitHub doesn't transfer your repositories to other people unless you tell it to.
It is a natural question, and I have asked it elsewhere in this thread (https://news.ycombinator.com/item?id=11385689). When control of package is handed over to a corp at version >=5.0.0, who exactly is responsible for releasing the bug-fix version 1.8.5? Point-releases are done all the time to fix security/bugs, so either NPM Inc didn't think about that scenario (bad) or decided not to address it (very bad).
it would be very rude to take the name 'stickman' from an author just because some big important webscale global internet of things unicorn multi-national 1000billion users app company has an app with the same name.
why can't they just call it stickman_app and not steal other people's land?
although we should also implement LVT to fix the landgrabbing issue
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?
I don't know off the top of my head if they have anything in their terms of use about the rights to permanently distribute published copies; I only know what the tooling enforces.
"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.
The FSF's view at http://www.gnu.org/licenses/gpl-faq.en.html#GPLOtherThanSoft...:
"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."
(IANAL. Just doing my best to interpret their policy.)
"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/
Really, it should've read "You hereby grant npm, Inc. a worldwide, non-exclusive, royalty-free, sublicenseable and transferable license to use, reproduce, distribute, and display Your Content in connection with the services and web sites owned or operated by npm, Inc., its successors and its affiliates."
I think I'll suggest that in a PR.
> The University of Texas School of Law, Juris Doctor with Honors
> State Bar of California, Attorney MemberHowever, I think that in defining how npm can use posted code, the existing language is substantially more lenient than the suggested language in your final paragraph.
Current text
"...That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services." (emphasis added)
vs
suggested text
"You hereby grant npm, Inc. a worldwide, non-exclusive, royalty-free, __sublicenseable and transferable license to use, reproduce, distribute, and display Your Content in connection with the services and web sites owned or operated by npm, Inc., its successors and its affiliates." (emphasis added).
Your secondary language looks like it further grants npm the right to not only use, but also sell, transfer, and sublicense any code posted to it because the 'in connection with the services and websites...' restriction seems very loose (e.g. why wouldn't selling to support the services be related?). Pretty sure that's not what npm or anyone posting packages to npm wants.
If someone else uploaded your software, then NPM is probably protected by the Safe Harbor provision of the DMCA, provided they comply with takedown requests.
Put another way, the license you ship with your code for usage by end users is not necessarily the entirety of the license NPM is bound by if you use their service. There's nothing really special about this, dual licensing is used all the time.
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
2. GitHub issue with additional discussion here: https://github.com/npm/policies/issues/44
Here's one incredibly horrible solution (hack): publish your own "package" to NPM which depends on the shrinkwrapped versions of your dependencies. Per this policy, they won't delete your dependencies since your NPM package explicitly depends on them.
$ du -h -d0 node_modules
673M node_modules
(I get your point, though. My node_modules is 490M, and that's from a package.json that fits in one screenful on a terminal window.)
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)
That sounds like the missing bit of info.
If that is the primary problem, then the good news is that git actually ought to be able to re-de-dupe that stuff back down; checking it into git may not be as catastrophic as you'd initially think.
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.
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.
Similarly, I had to bail on installing the 'victory' package (React visualisation components) using npm2 more than 600MB into it attempting to pull down its dependencies - I don't know if this is still the case, but every "victory-*" plugin was installing its own copies of Babel 6 and Webpack...
One of our devs added a material design webfont NPM package (IIRC, https://github.com/google/material-design-icons). Something like 40kb worth of font files, but the folder was 100+ MB because it included a PNGs of each icon at every imaginable resolution.
I've seen others with 10+MB CSV files used by the unit tests.
File systems divide the disk into segments, confusingly also called blocks. Only one file may occupy a block. On my Mac, the block size is 4 KB, so a file containing a single byte will still occupy 4 KB on disk. The du utility reports the latter. The Mac Finder reports the former in column view and both in the "Get Info" pane.
Unpacked NPM modules have many, many small files, obviously.
I'm still learning and prototyping my first JS/NPM/React project, but https://github.com/JamieMason/shrinkpack seems to me like it solves _most_ of the issues involved here. It pulls down all the tarballs, and updates the npm-shrinkwrap.json to point to those instead. That way you check in a much smaller "node_shrinkwrap" folder of a few hundred tarballs and 15-20MB, rather than a node_modules folder of 30K files and 150MB and a bunch of platform-specific build outputs.
Still doesn't solve the issue of installing new/updated dependencies that might actually require pulling in something that vanished, but at least once you've done an install and run "shrinkpack", you've got everything you need to rebuild right there.
A binary repository like Nexus or Artifactory is very useful for this.
To fix the npm instability problems, I use Nexus and configure it to proxy (and permanently cache) npmjs, and then use npm shrinkwrap.
I've been programming for closing in on 20 years, and have seen a wide variety of approaches to the dependency management problem over that time, under a number of names. My experience is that locking down the version of every single dependency causes you to push off the pain of changing dependencies for a long time, but the upgrade headache will be far nastier when it happens. There is less overall pain from constantly integrating new versions and fixing breakage as it happens.
I doubt that the node.js community will realize this until they go through something like the series of remote code execution vulnerabilities that Ruby on Rails had a few years back. And then they find that all of their software is vulnerable and they can't get rid of the vulnerability until every library depends recursively on the latest version of everything so that you can get the security fix every place that you need it.
That upgrade will be a series of insane nightmares.
Advantages:
1. Ensures everyone is developing on the exact same versions of every package
2. We have a complete record of correctly working dependencies' versions in the source tree at all times
3. Some random package developer can't introduce a bug in my software by pushing a new buggy version of their package right before I cut a release
Disadvantages:
1. You may not get bug fixes immediately. Solution: do a fresh `npm install` and `npm shrinkwrap` regularly (but not in the middle of testing a release branch, for example)
2. If someone unpublishes a version depend on you have to drop what you're doing and fix your npm-shrinkwrap.json
Also, `npm deprecate` allows package maintainers to deprecate specific versions (e.x. if a vulnerability is found), and you'll get a warning when installing, even if you use shrinkwrap. I'm not sure how common it's usage is though.
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 ), "ipmjs" (distributed package manager https://github.com/ipmjs/ipmjs/ ) and my own work "everythingstays" (scripts that works together with the npm cli [ 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.
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)
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).
There is. The only problem is fetching packages from a central registry (registry.npmjs.org). The rest that comes with the NPM CLI is good stuff.
One way, that I have been exploring is to allow NPM to download from IPFS instead, available over at http://everythingstays.com, and that's just one way it can be solved.
The top-level comment have more tools that you can use (but doesn't seem to have been implemented yet)
As I understand and have implemented vendoring in the past, I have always thought of it as a "no external dependencies" solution. If your data center gets DDOS'd durring deployment, things should just work when the attack subsides (assuming you have access). Fetching packages from xxxx.npmjs.org would be sort of antithetical to that idea. Or am I missing something.
Everythingstays seems like it would do the job mostly, as long as the "fall back to NPM" can be shut off.
https://books.sonatype.com/nexus-book/reference/npm-proxying...
Wow. A big change. It means publishing on NPM is granting an essentially irrevocable license. (Edit: Not that anything is wrong with that.)
(That is, the part about npm being able to keep your package up even if you want to take it down, not the changes to unpublish generally)
If you want to be selective about who can freely distribute your code, then you shouldn't be using a free software license.
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.
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
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
It's good, and worth your hour. TL;DW the six reasons are enumerated at 30:59.
Proxying via a local dependency is a good practice, but that can be set up independently of npm.
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.
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.
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?
The stance was without an agreed upon way of trusting public keys, you don't get any additional protection beyond shasum. Isn't that true?
No, that is not true. It is demonstrably wrong and was demonstrated this week.
https://medium.freecodecamp.com/npm-package-hijacking-from-t...
shasums do nothing to stop package hijacking. An attacker can regenerate a shasum at will. A GPG signature cannot be forged and it will be very clear if a public key is changed.
Specifically, Alice publishes widget-1.0.0, Bob records a dependency on widget ^1.0.0, there's one less barrier to Eve convincing Bob to use her malicious widget-1.0.1. (By contrast if Alice signed widget-1.0.0 and included a public key with it, Bob could check Eve's widget-1.0.1's signature against widget-1.0.0's included public-key and see that they don't match.)
The main problem I see with this is what if Alice loses her key?
If it's from NPM, an attacker who could convince you to download the wrong package could convince you to download the wrong public key, too.
If it's from previous versions of the package, what happens if the author loses the public key, or if package ownership needs to be transferred (another name dispute, or the author abandons their package)? Does NPM force people installing the package to decide whether to accept the new key? If NPM merely warns people installing the package, the situation is again barely better than an NPM-provided shasum.
PGP key servers:
hkps.pool.sks-keyservers.net wwwkeys.pgp.net pgp.mit.edu
There are plenty more. You upload a public key, they relay them around. Read all about it.
You can also attach an email address to the public key. You can send an encrypted email to that address and get an encrypted response back proving that the owner of that address has a copy of the private key. Now you just have to trust that package-signer@npmjs.org or whoever can keep his private key safe. You can even store a private key on a Yubikey device to limit theft of the private key to the theft of a physical token.
Not having gpg signed packages is bad enough. Actively discouraging them and denying that pull request is mind-blowing to me personally. The idea that they are going to invent a better scheme is dangerous. They will screw it up, just like everybody else who ever tried that.
Schneier's Law: Any person can invent a security system so clever that he or she can't imagine a way of breaking it.
The idea that they are going to invent a better scheme is dangerous.
They will screw it up, just like everybody else who ever tried that.
Which is exactly the point that you're missing. "The idea that they are going to invent a better scheme"—by "better scheme" you're thinking more secure, but the only people under the impression that NPM thinks they're going to invent a more secure system are people making the strawman argument you are. The strawman is that NPM's scheme isn't intended to be "better" in the sense of being more secure, it's intended to be better in the sense of improving the community in all the ways that aren't security.
You can send an encrypted email to that address and get an encrypted response
back proving that the owner of that address has a copy of the private key.
[...]
You can even store a private key on a Yubikey device to limit theft of
the private key to the theft of a physical token.
Anyway, good luck with those root exploits. I'm moving now to blacklist npm from our servers and then entire company. We have regulations to comply with. Knowingly allowing gaping security holes like those shipping in npm would be considered negligence and strictly illegal.
I would like to see an immutable package feed.
If 1.0.0 was published and it has a serious bug, publish a new package with the bug fix. Let 1.0.0 alone forever.
The same scenarios would still happen, there just wouldn't be the opportunity to make the subjective call to help more and harm fewer by unpublishing.
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.
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.
In their blog? http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
>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
NPM not only tolerated harassment, but sided with the harasser.
[0] https://medium.com/@mproberts/a-discussion-about-the-breakin...
>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).
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 ).
> Edit2: Wow, hit a nerve here.
> Edit to Steve (rate limited): [...]
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.
> 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".
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
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
[1]: "make a DELIBERATELY offensive or provocative online..." (emphasis added) 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
[3]: "...with the DELIBERATE INTENT of..." (emphasis added) https://en.wikipedia.org/wiki/Internet_troll
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...
I may get to the rest later today.
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
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.
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.
>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]
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?
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.
> So, NPM is charging forward like they did nothing wrong?
It’s our mission to help the community succeed, and by failing to protect the community, we didn’t uphold that mission.
We’re sorry.
NPM was absolutely wrong on the `kik` package, but their prior blog/tumblr post said they did nothing wrong there.
Edit to Steve (rate limited): There were many things wrong with how the `kik` package was handled, but that email thread should have never made it through the process. Per NPM policy, it should have been rejected as soon as the word 'dick' was read (the threats wouldn't even need to be considered then [which, they apparently weren't anyway]).
I also disagree with what happened around kik, but not for the same reasons as you.
They already had a substantial blog post reflecting on that part of the incident, including what they feel worked and didn't: http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
there was 168 Comments before they removed commenting from the Blog.... Of those I counted like 5 that where in support of NPM's action and response.
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.
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...
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.
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.
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.
> 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.
Would this keep kik in the registry instead of forcing the dev to give it up?
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?
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.
https://github.com/azer/left-pad has no license file, and the license in package.json is meaningless. I can interpret it as referring to anything I want with the same acronym.
I agree that the spirit from the author seems to have been to allow this re-publishing, and I don't really think npm did anything wrong by doing so, but that's not generally applicable in the way their new policy is. I think their lawyers should have a serious problem with this new policy.
npm's lawyers were intimately involved in this new policy, so I can assure you they don't have a problem with it.
I would love to hear from a lawyer but I would speculate that it would mean that you would effectively subject yourself to infringement if you published a derived work even if those terms changed after your publication.
> You can change the terms for all versions to be "strictly proprietary."
Unless the license you gave them specifically includes a clause which allows you to retroactively revoke that license. I'm not aware of any major open source license which contains such a clause.
http://law.stackexchange.com/a/837/4947
http://law.stackexchange.com/q/8132/4947
From [3]:
> If GPL or Creative Commons-type licenses are subject to later termination by authors (or their heirs), and this termination power cannot validly be waived, then users of such works must confront the possibility that the licenses may be revoked in the fiture and the works effectively withdrawn from public use, with potentially chaotic results. Although a number of judge-made doctrines may be invoked to restrict termination of a license granted for the benefit of the public, the better course would be for Congress to enact new legislation expressly authorizing authors to make a nonwaiveable, irrevocable dedication of their works, in whole or in part to the use and benefit of the public-a possibility that the Patent Act expressly recognizes, but the Copyright Act presently does not.
[3] http://scholarship.law.uc.edu/cgi/viewcontent.cgi?article=11...
Because that's literally true. You chose to relinquish that control when you published under a free software license.
This isn't limited to NPM. Say you publish an application on GitHub, and Debian decides to add it to their package manager. If you take down your GitHub repo, it'll still be in Debian's repository. If you ask Debian to remove it, they'll likely say no.
If I wanted to create a directory of open source code on the internet I'm free to copy and host that open source code as long I keep the open source license on it. Authors could request it to be taken down, removed etc but under the open source license I'm free to keep it up and ignore them.
If I wanted to create a directory of Starbucks locations I could and starbucks could not take it down either.
If you did publish some code on npm with such a license, their TOS covers npm's ability to distribute that code to end-users, who may or may not be allowed to actually run your code, per the license. But then your issue would be with those users, not npm Inc.
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.
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.
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.
But agreed. Isaacs seems to do quite a few unilateral changes that cause a hell of a lot of disruption.
Nodejitsu ( me ) choose to back NPM over Kiwi starting in 2009. It's all public information if you start crawling through emails.
If you don't want to be bothered by support requests, you can just ignore them - nobody owes anybody anything but what you have mutually agreed to - offer consulting about the problem to them at exorbitant rates (say 10k/hour, which is worth it for large enough businesses with my-hair-is-on-fire problems) or whatever else you want. If you have your own domain you can use a throw-away email address and just drop all email sent to it.
However the open source licence you published under specified that you gave away a non-revocable, permanent license so of course you can't demand others delete files on their systems.
(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).)
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.
By uploading it, I have in fact given them a license, as far as I am able, but that doesn't matter if I never had the rights and they get sued for infringement.
"It wasn't our fault guys, someone else wasn't upholding their implicit obligations to their users!"
Sheesh, grow a spine NPM.
...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) to move toward scoped package names, and then eventually deprecate non-scoped names.
Could anyone comment on what those reasons are / might be?
- bugs
- contained secrets (accidental publish)
- embarrassment
- open-source fatigue
Unpublish should be denied except in the case of compromise. All other changes should be accomplished via point releases.
We haven't removed it, just disabled it apart from a small initial window.
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
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...
I personally prefer the Go solution of just specifying a Git repo.
> I don't think GitHub permanently reserves deleted
> usernames, though I could be wrong
Go doesn't have a package manager to begin with. Go get is certainly not a package manager. Go get a a glorified curl.
"No new packages can be published using the same name and version."
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.
>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?
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.