|
|
|
npm-disputes(7) -- Handling Module Name Disputes
|
|
|
|
================================================
|
|
|
|
|
|
|
|
## SYNOPSIS
|
|
|
|
|
|
|
|
1. Get the author email with `npm owner ls <pkgname>`
|
|
|
|
2. Email the author, CC <support@npmjs.com>
|
|
|
|
3. After a few weeks, if there's no resolution, we'll sort it out.
|
|
|
|
|
|
|
|
Don't squat on package names. Publish code or move out of the way.
|
|
|
|
|
|
|
|
## DESCRIPTION
|
|
|
|
|
|
|
|
There sometimes arise cases where a user publishes a module, and then
|
|
|
|
later, some other user wants to use that name. Here are some common
|
|
|
|
ways that happens (each of these is based on actual events.)
|
|
|
|
|
|
|
|
1. Joe writes a JavaScript module `foo`, which is not node-specific.
|
|
|
|
Joe doesn't use node at all. Bob wants to use `foo` in node, so he
|
|
|
|
wraps it in an npm module. Some time later, Joe starts using node,
|
|
|
|
and wants to take over management of his program.
|
|
|
|
2. Bob writes an npm module `foo`, and publishes it. Perhaps much
|
|
|
|
later, Joe finds a bug in `foo`, and fixes it. He sends a pull
|
|
|
|
request to Bob, but Bob doesn't have the time to deal with it,
|
|
|
|
because he has a new job and a new baby and is focused on his new
|
|
|
|
erlang project, and kind of not involved with node any more. Joe
|
|
|
|
would like to publish a new `foo`, but can't, because the name is
|
|
|
|
taken.
|
|
|
|
3. Bob writes a 10-line flow-control library, and calls it `foo`, and
|
|
|
|
publishes it to the npm registry. Being a simple little thing, it
|
|
|
|
never really has to be updated. Joe works for Foo Inc, the makers
|
|
|
|
of the critically acclaimed and widely-marketed `foo` JavaScript
|
|
|
|
toolkit framework. They publish it to npm as `foojs`, but people are
|
|
|
|
routinely confused when `npm install foo` is some different thing.
|
|
|
|
4. Bob writes a parser for the widely-known `foo` file format, because
|
|
|
|
he needs it for work. Then, he gets a new job, and never updates the
|
|
|
|
prototype. Later on, Joe writes a much more complete `foo` parser,
|
|
|
|
but can't publish, because Bob's `foo` is in the way.
|
|
|
|
|
|
|
|
The validity of Joe's claim in each situation can be debated. However,
|
|
|
|
Joe's appropriate course of action in each case is the same.
|
|
|
|
|
|
|
|
1. `npm owner ls foo`. This will tell Joe the email address of the
|
|
|
|
owner (Bob).
|
|
|
|
2. Joe emails Bob, explaining the situation **as respectfully as
|
|
|
|
possible**, and what he would like to do with the module name. He
|
|
|
|
adds the npm support staff <support@npmjs.com> to the CC list of
|
|
|
|
the email. Mention in the email that Bob can run `npm owner add
|
|
|
|
joe foo` to add Joe as an owner of the `foo` package.
|
|
|
|
3. After a reasonable amount of time, if Bob has not responded, or if
|
|
|
|
Bob and Joe can't come to any sort of resolution, email support
|
|
|
|
<support@npmjs.com> and we'll sort it out. ("Reasonable" is
|
|
|
|
usually at least 4 weeks, but extra time is allowed around common
|
|
|
|
holidays.)
|
|
|
|
|
|
|
|
## REASONING
|
|
|
|
|
|
|
|
In almost every case so far, the parties involved have been able to reach
|
|
|
|
an amicable resolution without any major intervention. Most people
|
|
|
|
really do want to be reasonable, and are probably not even aware that
|
|
|
|
they're in your way.
|
|
|
|
|
|
|
|
Module ecosystems are most vibrant and powerful when they are as
|
|
|
|
self-directed as possible. If an admin one day deletes something you
|
|
|
|
had worked on, then that is going to make most people quite upset,
|
|
|
|
regardless of the justification. When humans solve their problems by
|
|
|
|
talking to other humans with respect, everyone has the chance to end up
|
|
|
|
feeling good about the interaction.
|
|
|
|
|
|
|
|
## EXCEPTIONS
|
|
|
|
|
|
|
|
Some things are not allowed, and will be removed without discussion if
|
|
|
|
they are brought to the attention of the npm registry admins, including
|
|
|
|
but not limited to:
|
|
|
|
|
|
|
|
1. Malware (that is, a package designed to exploit or harm the machine on
|
|
|
|
which it is installed).
|
|
|
|
2. Violations of copyright or licenses (for example, cloning an
|
|
|
|
MIT-licensed program, and then removing or changing the copyright and
|
|
|
|
license statement).
|
|
|
|
3. Illegal content.
|
|
|
|
4. "Squatting" on a package name that you *plan* to use, but aren't
|
|
|
|
actually using. Sorry, I don't care how great the name is, or how
|
|
|
|
perfect a fit it is for the thing that someday might happen. If
|
|
|
|
someone wants to use it today, and you're just taking up space with
|
|
|
|
an empty tarball, you're going to be evicted.
|
|
|
|
5. Putting empty packages in the registry. Packages must have SOME
|
|
|
|
functionality. It can be silly, but it can't be *nothing*. (See
|
|
|
|
also: squatting.)
|
|
|
|
6. Doing weird things with the registry, like using it as your own
|
|
|
|
personal application database or otherwise putting non-packagey
|
|
|
|
things into it.
|
|
|
|
|
|
|
|
If you see bad behavior like this, please report it right away.
|
|
|
|
|
|
|
|
## SEE ALSO
|
|
|
|
|
|
|
|
* npm-registry(7)
|
|
|
|
* npm-owner(1)
|