All Javascript developers might have used npm at some point in their lifetime. npm is the default package manager for node.js. For those who don’t ...
For further actions, you may consider blocking this person and/or reporting abuse
I don' think that's the real issue here. The problem is that the whole javascript eco system is built and used in such a way that someone can break the internet by removing a 12 line package from a website. The reasons why he did that are irrelevant.
This has nothing to do with Copyright, which isn't applicable at all. And it's not "illegal" to not remove something with a name conflict on the Internet. Trademark law is a civil matter, and there are a lot of complexities to what extent a company is protected. I think NPM should have waited for a letter from a lawyer and given the author a chance to legally respond. The whole "don't want to get lawyers involved ha ha! so please take away someone else's work" shouldn't really fly. It probably would have ended with the same result, but at least there would be a proper process around it.
Exactly. I'll add my perspectieve as a root comment.
It's a shame this nonsense is the first comment on here. We get that you were in the same situation as kik and you won you so you think you were right. You weren't, and neither was kik. You don't magically get to use your name everywhere because you are a company. Might does not make right.
And yet you are insisting that the company that has trademarked kik in one country can ignore all trademark/copyright laws in the rest of the world, just because they are in another country ...
As far as I understand, Fernando, he used the name Kik without knowing there was a company in US that registered the name. Actually, there are a lot of companies called Kik in the world !! That kind of short names are pursued by companies, and they registered it. This patenting existing names is quite a issue, worldwide. Azer is Turkish, that Kik is US (there are a Austrian, a German one, etc), Internet is international. Consider that a lot of names of packages are probably the name of some company on the world. And if a much bigger company with more lawyers wants the name Kik for another package, NPM will reassign them the name? We can be changing names of packets just because a company decided to adopt a name, it would be a never-ending mess. So, for me, declining such kind of request was the logical step to take, and fulfilling it was a failure from NPM. Maybe they had no option due to the laws of the country they are in, which shows that this is a problem to be solved: in laws and/or software structure.
And I understand perfectly the feelings of the developer: so many people working for OpenSource make the base of what is programming today, and if a company comes with a request, the choice of the developer is disregarded, undone, and even twice.
But well, yes, the point of this article is how code is build and related.
Thats a false implication. He did understand copyright, the kik lawyers tried to conflate patents, trademarks, and copyrights. His kik package predated the kik company and therefore his claim to the copyright for his filename was legitimate. Npm further broke the law itself by republishing his package without consent as it had been previously litigated that "open-source" does not mean free or free use. The material still belongs to the owner and can only be used or published as licensed. In this case as part of another module and not as a package itself.
Software and human relationships and emotions are intrinsically tied in a forever loop.
Regardless of who may have been right or wrong in this case, it demonstrates the delicate nature of this complicated thing we've built.
This has nothing to do with copyright law. In your case your code is copyrighted so someone who is not the owner put it on pypy. But in kik case there was no copyright law broken. The issue was a trademark and he didn't lose a lawsuit but npm sided with the company which was wrong. It was wrong because you allowed to use the same name for non-related thing. For example in Germany if you say kik to anyone, no one would think about chat program from kik.com but they would think about kik.de (so 2 different companies use exactly the same name).
I wonder if Indonesia government will sue us for using name Java or Java Script , since Java is the name of their island... #eh..
Holy s**t man, stop with this trademark nonsense. It's clear you understand little to nothing about trademark law and it's intricacies. Please argue from a perspective that you understand. Reading your comments is painful. One moment "I am not a lawyer" but then you continue to argue as if you are.
I've always been a bit confused about this. I know it is only 11 lines, but... the idea that everyone should write those 11 lines instead of importing left-pad seems like the exact wrong lesson to learn here.
I am sure if we look hard enough we can find plenty of other 10-15 line functions that solve common problems. Do we believe that all "experienced" JS programmers should write their own versions of these? What about inexperienced programmers? Should we let them write 40-line versions?
It seemed to me that left-pad did precisely what we want open-source software packages to do: solve common problems so that the rest of us don't have to re-invent the wheel. The fact that it is "only 11 lines" is irrelevant. If it were 50 lines, and still broke the internet, would we all just have said "¯\_(ツ)_/¯ nothing we could have done differently here at all!"?
Exactly this. I remember when this happened a bunch of people went on to "lament" the downgrade of today's developers - because they didn't want to do this stupid function. Apparently being able to
left-padmakes one a "true developer".Obviously dependencies are bad, which means the real question here is why such a trivial function is not in the standard library in the first place.
Let give some background for myself to help you get context. I've developed as hobby before internet and then I did .NET C# for a long time sometime until 2010. I was mostly involved with enterprise software.
Personally, I would feel ashamed to publish such a package. It feels incomplete and even I started this with bigger dreams, most probably it will never receive a 1.0 version. I would rather gist/block my amazing code for inspiration rather than doing this. I'm writing this to help you connect with the perspectieve that is driven from my background. I hope this help you give context for the following.
The concept of package repositories is amazing. But, for my background, to add a package dependency, the package needs to offer something substantial. I don't think that there is any gain here when 10line code packages that don't even have a major verion are linked everywhere. It is a very volatile situation.
When a package is delivered as binary, then a small referenced package is of a lesser problem because the deliverable includes the compiled code. For example in .NET, the only potential problem is that if 2 different packages have the same dependency then 2 dlls with the same name lead to problems at runtime. But, outside of the compiled world, there is the concept of builing everything which multiplies the potential problems of this approach. Because, if my package needs to be built, then my dependency and its dependencies need to be built as well. Everytime I try to work with node and use a tool, it's like it never works out of the box. Errors and warning over wring 0.0 packages etc. If you think about it, easy workaround suggested everywhere is to override the version restrictions like
bundle exe. It makes you wonder what is the point? Yes, the desciplined shops will not do this, but from all my circle, developer and especially junior ones are more and more copy/pasting from a proposed solution and if it works, then its in without evaluation. Yes there are code reviews etc but lets be honest here about how effective these are when the code is not evaluated by the whole planet. :)Call me concervative but when a package is small, I prefer the copy of it's code in a designated location with a clear mention for future maintanence but there is control. I'm glad that there is open source and I can get insight and inspiration but adding non major dependencies is already a problem in my approach, yet alone when the dependency is 10 lines. It's not worthwhile. I can always revisit this and chose the code when it is mature. But this is a nice plan that goes all to the garbage when a nice big package has dependencies to 10line of code non major versioned releases.
I believe that the current mess (not only in javascript) with non major packages is because of what I mention in the top of me being ashamed to publish a 10line package. I'm sure I'm not the only person who has this mental blocker but still wants to share. Like "viral" the outcome of the usage could be very far from my original expectations and planning.
IMO it's not a matter of how many lines of code the package is, but a matter of how well tested it's in the CI pipelines. When you see in the repo that the authors have added tests that make you happy, you may use it. If the only tests are a linter then it's time to look for a different package. The power of open source is that in fact, you can see these things and not put your trust in some entity.
But the situation in the original anecdote completely bypasses any question of testing. Because you can test a package all day long, but the core question is: What do you do if that package... disappears???
That is also part of my point. Every package is a dependency and a potential problem. You need to weight the benefits against the risks.
If for every package you need to check quality, license and lifetime then maybe the overhead is to big. If the organisation has actual oss policies, then it can get out of control. What if the package changes license?
There is a reason that in ESCROW agreement, all dependencies are included.
Agreed. This is also why many companies have started using solutions like Artifactory.
leftpad had a real influence on my approach to software development.
This post left me with some real food for thought that taught me to take a more deliberate approach with some of my choices in software.
davidhaney.io/npm-left-pad-have-we...
And the whole thing just helped me confirm that this whole industry is, in fact, kind of just a bunch of stuff tied together as best as possible. Any system can fail and we have to be able to deal with this as best we can on average. We'll never have a perfect flawless ecosystem.
I understand your point of dependencies. Check out @tinyhttp. Its built as an alternative/clone to Express completely using TypeScript as first class citizen but with the least number of dependencies. I think such projects should be really encouraged.
Secondly, Lawsuits etc can be really messy. Open Source should shy away from those. NPM did a pretty bad job there.
In the end, the
kikpackage is empty on npm: npmjs.com/package/kikAnd they published their package under
@kikinteractive/kik
npmjs.com/package/@kikinteractive/kikVery interesting read! Packages are fun and I use them a lot, but that’s why in larger applications I try to push out as many dependencies as possible.
Actually no! If npm allowed him to register the name and if npm had no such copyright checks in place then the user is not at all wrong here. He came, he saw that the name he wanted was available and he used it. He was turkish, I bet he had no idea that such a company even existed and furthermore seeing that the company didn't even use the reassigned name to publish a package simply implies that they wanted the name just to feel good about owning it. Kik should have been sued in a class action suite just to cause these turn of events.
This is why I try to host as much of the code I need as possible.
crates.io is just good, you can't pull down a package once it is published.