[_puk]

Presumably, if the original author had changed the licence and pushed to npm prior to change of ownership then npm wouldn't have been able to do this?

Sounds like we could start seeing npm specific releases with different licences to the github repo (or npm specific branches with different licencing)

Obviously npm could re-publish the non npm specific code, but that would be more manual than a simple revert of an unpublish.

[kelnos]

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.

[pygy_]

Even if Azer had relicensed the code, NPM had a copy of the code released under the original one, which can't be revoked.

[_puk]

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

[lmm]

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.