xenial (7) npm-disputes.7.gz

NAME

       npm-disputes - 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 help 7 registry

       •   npm help owner

                                                  December 2015                                  NPM-DISPUTES(7)