Honestly, I think the answer (given the existing system) should be “Hey, well, if somebody else registers the name first, tough shit.”
I agree. I wonder how pypi handles this kind of thing.
This part was especially troubling:
This incident did not arise because of intellectual property law.
We’re aware that Kik and Azer discussed the legal issues surrounding the “Kik” trademark,
but that wasn’t pertinent. Our decision relied on our dispute resolution policy. It was solely
an editorial choice, made in the best interests of the vast majority of npm’s users.
So, as a business (npm is apparently a business!), they had no current legal requirement to take that name away from someone? There was no report of maliciousness, nor wrongdoing? Just some emails from a company with “he was mean/rude” (when they threatened him with lawyers) and “We really don’t want to involve lawyers and are trying to be reasonable, but…”?
Wow.
Regarding Joyent, I almost feel bad for them. Seems like their main gaff (debatable I guess) was betting so hard on node. They took over management of node and then that weird community hostile fork thing happened, and now this. I wouldn’t blame them for backing away from the whole thing slowly.
What is it about javascript that seems to encourage a clownshoes shitshow? Is it prototype inheritance? ;)
For what it’s worth, Joyent is no longer in the driver’s seat. Node is in a foundation now, so many other people and companies have at least as much control and influence.
At Joyent, we’re back to focusing on being a great place to run (and debug) Node workloads, and having a large body of Node software. We offer support and counsel where we can, but we’re not in charge any more.
The whole situation is depressing to watch, since I’ve been an early adopter of node and have really enjoyed developing with it for the past 6 years.
Node is really a great runtime, and the majority of the community are friendly and helpful. I disagree that the whole ecosystem ‘a clowncar’. I do think there are those in control with too much power and are also immature, which is a terrible combination. I definitely don’t enjoy watching node be destroyed in such a manner.
npm needs safeguards to keep anyone from causing so much disruption. If these had been in place yesterday, this post-mortem wouldn’t be necessary.
[..]
We will make it harder to un-publish a version of a package if doing so would break other packages.
I’d be pretty cheesed if I wanted to yank code and I was prevented from doing so. I can see it from both sides:
it’s OSS code and (license permitting) anyone can do anything they want with it. NPM included.
I published it, I can damn well unpublish it.
I suppose it comes down to NPM’s policy. If you want to unpublish your code, don’t publish it to NPM and yank the repo instead.
I just don’t remember having many similar issues in the Maven/RubyGem world. Though occasionally someone would accidentally publish a different version to the same version number (Maven) and you’d be left scratching your head over why Jenkins builds work, your build works, but your team member’s doesn’t.
There really isn’t a question here. If the project’s license allows it (and any FOSS license will), then any package system is within their legal rights to keep live any previously published project versions. If someone wants to retain the right to remove the project from such a system, then they need a license that says so.
Unmentioned (unless I missed it) is why on earth npm would expect Kik, the company, to publish a package named kik that had anything whatsoever to do with Azer’s already-published kik package. So how the policy is helping anyone with kik in their package list escapes me.
I think what they mean is that people relying on Azer’s “kik 0.0.3” would not be disrupted, as the new owners would be required by the system to publish at an incompatible version, (let’s say “1.0.0”). So users of the previous package could continue to work with the code same as before.
Honestly, this post made npm’s position sound worse to me, not better.
Yikes.
Honestly, I think the answer (given the existing system) should be “Hey, well, if somebody else registers the name first, tough shit.”
It’s kinda funny to me that now NPM suddenly cares about misleading or garbage package names.
The entire Node ecosystem is a clowncar, and it’ll be enjoyable watching Joyent and NPM crash it into a fucking wall.
I agree. I wonder how pypi handles this kind of thing.
This part was especially troubling:
So, as a business (npm is apparently a business!), they had no current legal requirement to take that name away from someone? There was no report of maliciousness, nor wrongdoing? Just some emails from a company with “he was mean/rude” (when they threatened him with lawyers) and “We really don’t want to involve lawyers and are trying to be reasonable, but…”?
Wow.
Regarding Joyent, I almost feel bad for them. Seems like their main gaff (debatable I guess) was betting so hard on node. They took over management of node and then that weird community hostile fork thing happened, and now this. I wouldn’t blame them for backing away from the whole thing slowly.
What is it about javascript that seems to encourage a clownshoes shitshow? Is it prototype inheritance? ;)
For what it’s worth, Joyent is no longer in the driver’s seat. Node is in a foundation now, so many other people and companies have at least as much control and influence.
At Joyent, we’re back to focusing on being a great place to run (and debug) Node workloads, and having a large body of Node software. We offer support and counsel where we can, but we’re not in charge any more.
After a second’s thought, yep, I suppose that’s true.
It’ll probably just be npm’s fault then. :)
The whole situation is depressing to watch, since I’ve been an early adopter of node and have really enjoyed developing with it for the past 6 years.
Node is really a great runtime, and the majority of the community are friendly and helpful. I disagree that the whole ecosystem ‘a clowncar’. I do think there are those in control with too much power and are also immature, which is a terrible combination. I definitely don’t enjoy watching node be destroyed in such a manner.
I’d be pretty cheesed if I wanted to yank code and I was prevented from doing so. I can see it from both sides:
I suppose it comes down to NPM’s policy. If you want to unpublish your code, don’t publish it to NPM and yank the repo instead.
I just don’t remember having many similar issues in the Maven/RubyGem world. Though occasionally someone would accidentally publish a different version to the same version number (Maven) and you’d be left scratching your head over why Jenkins builds work, your build works, but your team member’s doesn’t.
There really isn’t a question here. If the project’s license allows it (and any FOSS license will), then any package system is within their legal rights to keep live any previously published project versions. If someone wants to retain the right to remove the project from such a system, then they need a license that says so.
Unmentioned (unless I missed it) is why on earth npm would expect Kik, the company, to publish a package named kik that had anything whatsoever to do with Azer’s already-published kik package. So how the policy is helping anyone with kik in their package list escapes me.
I think what they mean is that people relying on Azer’s “kik 0.0.3” would not be disrupted, as the new owners would be required by the system to publish at an incompatible version, (let’s say “1.0.0”). So users of the previous package could continue to work with the code same as before.