Did they? Most open source licenses aren't revokable - you don't have to stop distributing the code just because the author asks you to stop. That seems especially true in this case, considering the author chose[1] to license left-pad under the WTFPL[2]. I'd say re-publishing the package counts as NPM doing "whatever the f* they want" with the code.
You can't retroactively change license. Sure, the author could push a new version with a new license, but the old versions would still be governed by the old license.
Yeah, I appreciate that, but if this becomes a general concern that npm can grant ownership to whoever it deems acceptable (even to the point of republishing existing versions), then could we start seeing e.g. WTFPL with npm exceptions style licence fragmentation.
The source could still be readily available to anyone to republish as they see fit, but only as a different name / version.
Not condoning it, just thinking that the original author surely has the right to do this if they plan ahead (judging by the npm backlash that has been building over a single entity holding all the keys some may be starting to think this way).
All open source licenses allow the licensee to republish your code - that's part of the definition. It's not going to trigger license fragmentation because any exceptions will make it not open source.
If you want to enforce that other people use different names for their forks, the usual way to do this is with trademarks - this is what e.g. mozilla and redhat do. Npm should respect your trademarks, and if someone else publishes a project under your trademarked name you can make npm take it down... which is exactly what originally happened here.
If you delete a module, the name becomes free. Someone else grabbed it and publishing code he has a license to redistribute under it. NPM is "only" fudging with the version number, the author gave the module away.
I can't agree. The author licensed the code under WTFPL, meaning he directly authorized anyone to do whatever with it in pretty much the most explicit and unambiguous terms possible.
Writing a 15 line function shouldn't grant someone the right to break an entire language ecosystem
I think the real issue though here is technical - does npm really allow mutation of published assets like this? That's a shitty situation that can only lead to unreliable builds
Pray tell, what is the minimum size that should be required before permitting a dependency? Constant-time string compare is only 5 lines or so, should we cutpaste security critical functions too? "We ran your code on $new_arch and discovered a timing attack." "It's not my fault!@# The professionally maintained and reviewed implementation was too small to depend on!@#!"
> First, you should never have a dependency for 15 lines.
If those 15 lines are called throughout your codebase, you should do what? Re-write the 15 lines and stuff them into a lib that you maintain? And everyone else should do this, too?
If a library is widely useful, it's widely useful regardless of how many LOC it contains.
Yes. With dependency you are giving up control and in return you save time in not having to implement the dependency. If the LoC is small you get practically nothing in return and so the only reason to do it is ideological.
Many times it is even faster to write a trivial "module" yourself than even discover it on npm, let alone reading and verifying it. Hell, NPM 3.x is so slow that it's literally faster to write any 1 liner "module" than it is just to install it.
"Reuse" is just a means to an end, it doesn't make sense to do it only for its own sake.
[1] https://github.com/azer/left-pad/blob/master/package.json
[2] http://www.wtfpl.net/txt/copying/