Hacker News Reader

Comment by sangnoir | Hacker News Reader

Conspicuously missing scenario: Sandra owns the comic drawing package "stickman" and publishes 0.1.0, 0.9.9 and 1.0.0. A few months/years later, Stick Manufacturing Corp [StickMan(tm)] shows up with their Internet of Sticks support package library to go with their registered trademark and want to publish it as "stickman". What happens next? Do they just hand over the package so Stick Corp can publish a new version? Does NPM inc rename Sandra's "stickman" to something else? what happens to Julie's "comic" package that depends on "stickman^0.9.9" when the package is handed over?

View on HN

The real problem is the namespace issue that seriously needs sorting out. com.sandra.stickman would be different to com.stickmanufacturingcorp.stickman

npm is growing hugely. It needs to sort out the domain space issue quickly.

npm literally supports namespaces already https://docs.npmjs.com/misc/scope

And, it's not actually clear that a namespace would have been enough had a lawsuit actually been filed.

scopes are ways of grouping functionally related packages. Not sure that is the same thing.

You may be right about the lawsuit.

By the identity function a package is functionally related it itself and so can be scoped.

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.

Namespacing costs $7/mo/dev... for a string and a slash.

Not for public ones. Those are free. If you want them to be private, then you pay the money.

thought it only figuratively supported namespaces

Literally literally means both nowadays. Language is mutable. Furthermore, I'm using it for emphasis here...

Not just nowadays, it's literally had that meaning for hundreds of years: http://blog.dictionary.com/literally/

do we really need TLDs in namespaces

it's almost as bad as putting HTTP protocol in XML namespaces.

Works ok for java?

And OS X/iOS app identifiers, etc.

Yes, it works ok. But there are plenty of schemes that both work and are sane.

How is TLD namespacing not sane? If you own the domain you own the package(s) in that namespace. It's pretty easy and fairly trustworthy to identify a TLD. When Stickman Co comes along, there's not a fight about the package name and the original package maintainer doesn't get elbowed out of the way.

I'm pretty sure domains have been transferred to their "rightful owner" even more than NPM package names have.

I think TLD is ok, but I like Go's namespacing even better. It uses repos, so you can use both private and public repos. And it's actually where the code "live".

Git repos change way more often than domain or company names do. Moving from code.google.com to github.com, moving a project from a user to an org, transferring across orgs, renaming an org. All of these things have happened to me in a single Golang project. Ironically, the code.google.com -> github move was actually Golang stdlib code itself.

Domain names are transient. They come and go, changing owners throughout their lifetime. Code, on the other hand, lives on.

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.

I've always found it to be a pretty sane scheme. What problems do you have with it?

Coupling it to a TLD is arbitrary. Does Sandra own sandra.com? What if she doesn't have a website at all? It's kind of a silly convention.

You can get a free domain name without a lot of trouble.

no you can't.

at most you can borrow one.

This is uncommon, but in this case you can use your email address or github.io, etc.

It's more common than not to not have a domain. Most programmers I know don't have a personal domain they own, and not all code is written for work (most open-source code isn't, in particular).

So put your open-source code on github and use something like <githubUserName>.github.io. And if it's for work you use your work groupId. If it's personal but not public, who cares what groupId you use? Just pick something.

What's the problem?

And when you move your code off github or change your username, are you supposed to change the package name too?

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?

I have a bunch of domains, but none of them feel appropriate to use for this. So I might get one just do that I can have a proper package name. Now I have to keep that domain forever. I don't see how this is any different than namespacing by my home address.

It feels to me like it's tying your code to something ephemeral. If you're going to do that you may as well make it something uniquely ephemeral. Github, Docker Hub, Packagist et al use usernames for this, it works nicely, packages are namespaced in the form username/packagename.

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.

NO!

Dots are allowed in the package name, so there's nothing stopping someone from having a package named "com.sandra.stickman", if they are really inclined to do that.

You're missing the point. Being intentionally obtuse adds nothing.

That's why it's best not to force people to namespace with backwards website addresses.

If I was being obtuse then it was unintentional. It was a real suggestion. If people really want reverse TLD names then they should do it, and if the community likes it, it will catch on. FYI there are already some package names out there with ".com" on the end.

Their previous post does specifically address this, in its own bolded bullet-point:

    ○ 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.

http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

Do old versions of the package remain under ownership of the original author? Let's assume I publish a package “foo”, and the name is later transferred to someone else. Will npm make it perfectly clear that the versions I published are my intellectual property, rather than that someone else's?

My English reading comprehension isn't precisely the best, but I'm pretty sure this concern isn't addressed in the text you cited.

This concern is indeed not addressed in the text I cited. However, though my English reading comprehension isn't precisely the best either, I'm pretty sure this concern wasn't brought up in your comment that I was replying to when citing that text.

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

> Perhaps they'd be delighted if you brought it up

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.

Honestly I don't think it's as natural a question as you think it is (I haven't noticed anyone else bring it up on HN or in that GitHub Issue), and I don't think it's hard to answer, either.

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?).)

> 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.

My comparison with GitHub was only referring to the problems of people not attributing themselves in their own repos/packages, later owners of a repo/package misattributing later work to earlier owners of the repo/package, and random repos/packages you have nothing to do with claiming you're their author.

> Honestly I don't think it's as natural a question as you think it is (I haven't noticed anyone else bring it up on HN or in that GitHub Issue)

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).

"We've made lots of changes to make things better going forward. What's that? No, of course the changes don't address what actually caused all the issues everybody is talking about."

    It was abrupt unpublishing, not our resolution policy, that led to
    yesterday’s disruptions.

http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm

Proximate cause, maybe.

that's still the one sided argument the commenter above you highlighted.

just saying it twice from the same month doesn't make it less one sided.

Maybe I don't know what you mean by "above you", but, what? The arguments above me I've seen are "missing scenario: ..." and "they didn't address what actually caused all the issues". Which is a one-sided argument is identical to mine?

I don't personally think that npm can tell you what would happen, because this form of situation really relies on the exact details of what's going on. Especially since trademark is about confusion, the specifics really count. Your "stickman" case might be a "no", but a "microsoft" package might be a "yes". Or not. It depends.

However this case matters because it closely resembles what got a developer pissed off enough at npm to unpublish hundreds of modules.

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.

Yeah, if I was King of npm, I would have made shrinkwrap mandatory from day 1.

This is why setting version numbers in your dependencies is important.

This is literally the situation that began all these events.

Sure. But the parent seems to be asking for a general example of what would happen in such a dispute; unlike the rules for unpublish, they require human judgment, and so you can't actually give a single answer here.

> But the parent seems to be asking for a general example of what would happen in such a dispute

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.

Yeah, sounds like you should ask in that linked thread. Assuming the lawyers win, it's not clear to me either.

This is exactly what politically empowered people and lawyers are good at figuring out. Let the law and motivated individuals sort it out in institutions that society has designated. What we are seeing now are the consequences of conflicting unilateral actions.

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!

What happens next is Sandra throws her toys out of the pram and gives the middle finger to 'the (stick)man'.

we should have a first come first serve policy unless stated otherwise.

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

IANAL, but StickMan(tm) probably won't be able to claim a trademark on StickMan in the context of software. Trademarks generally require being the first to use a name within a specific market. See the assorted Apple Computer vs. Apple Records suits that happened once Apple Computer entered the music business. It was perfectly kosher for there to be "Apple Records" and "Apple Computer", but once "Apple Computer" started selling music, they were violating Apple Records' trademark.

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.

replace stickman with Kik and the problem still exists.

"Kik" is not just a trademark referring to a piece of software. It refers to a very specific type of software. KIK Interactive, Inc. has described it in many words, but they are all somewhat similar to:

>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.

Reply on news.ycombinator.com