<!doctype html>
< html >
< title > disputes< / title >
< meta http-equiv = "content-type" value = "text/html;utf-8" >
< link rel = "stylesheet" type = "text/css" href = "../static/style.css" >
< body >
< div id = "wrapper" >
< h1 > < a href = "../doc/disputes.html" > disputes< / a > < / h1 > < p > Handling Module Name Disputes< / p >
< h2 id = "SYNOPSIS" > SYNOPSIS< / h2 >
< ol > < li > Get the author email with < code > npm owner ls < pkgname> < / code > < / li > < li > Email the author, CC < a href = "mailto:i@izs.me" > i@izs.me< / a > .< / li > < li > After a few weeks, if there' s no resolution, we' ll sort it out.< / li > < / ol >
< p > Don' t squat on package names. Publish code or move out of the way.< / p >
< h2 id = "DESCRIPTION" > DESCRIPTION< / h2 >
< p > 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.)< / p >
< ol > < li > Bob writes a JavaScript module < code > foo< / code > , which is not node-specific.
Bob doesn' t use node at all. Joe wants to use < code > foo< / code > in node, so he
wraps it in an npm module. Some time later, Bob starts using node,
and wants to take over management of his program.< / li > < li > Bob writes an npm module < code > foo< / code > , and publishes it. Perhaps much
later, Joe finds a bug in < code > foo< / code > , 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 < code > foo< / code > , but can' t, because the name is
taken.< / li > < li > Bob writes a 10-line flow-control library, and calls it < code > foo< / code > , 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 < code > foo< / code > JavaScript
toolkit framework. They publish it to npm as < code > foojs< / code > , but people are
routinely confused when < code > npm install foo< / code > is some different thing.< / li > < li > Bob writes a parser for the widely-known < code > foo< / code > 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 < code > foo< / code > parser,
but can' t publish, because Bob' s < code > foo< / code > is in the way.< / li > < / ol >
< p > 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.< / p >
< ol > < li > < code > npm owner ls foo< / code > . This will tell Joe the email address of the
owner (Bob).< / li > < li > Joe emails Bob, explaining the situation < strong > as respectfully as possible< / strong > ,
and what he would like to do with the module name. He adds
isaacs < a href = "mailto:i@izs.me" > i@izs.me< / a > to the CC list of the email. Mention in the email
that Bob can run < code > npm owner add joe foo< / code > to add Joe as an owner of
the < code > foo< / code > package.< / li > < li > 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 isaacs
< a href = "mailto:i@izs.me" > i@izs.me< / a > and we' ll sort it out.< / li > < / ol >
< h2 id = "REASONING" > REASONING< / h2 >
< p > 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.< / p >
< p > 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.< / p >
< h2 id = "EXCEPTIONS" > EXCEPTIONS< / h2 >
< p > 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:< / p >
< ol > < li > Malware (that is, a module designed to exploit or harm the machine on
which it is installed)< / li > < li > Violations of copyright or licenses (for example, cloning an
MIT-licensed program, and then removing or changing the copyright and
license statement)< / li > < li > Illegal content.< / li > < li > " Squatting" on a package name that you < em > plan< / em > 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.< / li > < / ol >
< p > If you see bad behavior like this, please report it right away.< / p >
< h2 id = "SEE-ALSO" > SEE ALSO< / h2 >
< ul > < li > < a href = "../doc/registry.html" > registry(1)< / a > < / li > < li > < a href = "../doc/owner.html" > owner(1)< / a > < / li > < / ul >
< / div >
< p id = "footer" > disputes — npm@1.2.15< / p >
< script >
;(function () {
var wrapper = document.getElementById("wrapper")
var els = Array.prototype.slice.call(wrapper.getElementsByTagName("*"), 0)
.filter(function (el) {
return el.parentNode === wrapper
& & el.tagName.match(/H[1-6]/)
& & el.id
})
var l = 2
, toc = document.createElement("ul")
toc.innerHTML = els.map(function (el) {
var i = el.tagName.charAt(1)
, out = ""
while (i > l) {
out += "< ul > "
l ++
}
while (i < l ) {
out += "< / ul > "
l --
}
out += "< li > < a href = '#" + el.id + "' > " +
( el.innerText || el.text || el.innerHTML)
+ "< / a > "
return out
}).join("\n")
toc.id = "toc"
document.body.appendChild(toc)
})()
< / script >
< / body > < / html >
