Recently, on _npm_ a developer was "asked" to change a name of his repo, because of trademark issues.
Details can be found here:
My questions about composer/packagist would be:
@schmunk42 any project locking its dependencies would not be affected at all by such removal, making the effect of a removal much less breaking than in npm). contrary to a npm schrinkwrap file, the composer.lock file contains the full package metadata, meaning that an install from lock does not read anything from Packagist.
A composer update would of course be impacted by the removal of packages.
I'm not sure there is such a policy yet.
In my opinion NPM screwed up severely. They should have maintained as policy that package names are just an arbitrary combination of characters, are distributed on a first-come-first-serve basis, and can thus never be subject to reverse trademark claims unless willful abuse is incredibly obvious.
From their blog:
Entirely on this basis, we concluded that the package name “kik” ought to be maintained by Kik, and informed both parties.
I can't find any reasoning behind this (rather moronic) decision in their dispute resolution rules.
As Packagist is physically located in Europe instead of the US, and both operated and owned by a EU citizen, the legal power of ridiculous lawyers is also severely limited of course. NPM is pretty screwed there by being incorporated in the land of festering lawsuits.
If you read about it in details, the removal of the kik package wasn't really an issue. It's only an issue in that it triggered the maintainer to go full rogue communist and delete all his package to punish the imperialist npm corporate lackeys (I am paraphrasing but only slightly exaggerating his words). One of his packages was the infamous left-pad, which then caused the apocalypse.
I would definitely not delete a left-pad-style package without trying to work out a good solution because it's in nobody's interest. If someone has a ghost package that is completely unused and is blocking some company's namespace though, I probably would boot it if the original author can't be reached.
The fact that we have vendor namespaces though alleviates this issue largely, because people aren't competing as much for simple and common names like they are with npm.
If someone has a ghost package that is completely unused and is blocking some company's namespace though, I probably would boot it if the original author can't be reached.
But that makes sense as it implies 'squatting', intentional or not. In Kik's case they were just claiming the name for the hell of it as far as I can see - the original package had nothing to do with them and outdated their JS activity. That's bad luck for Kik, time to claim kik-app or something.
Thank you all for the feedback so far.
As Packagist is physically located in Europe instead of the US, and both operated and owned by a EU citizen, the legal power of ridiculous lawyers is also severely limited of course. NPM is pretty screwed there by being incorporated in the land of festering lawsuits.
A very important point, IMHO. And good to hear that this is the case.
The fact that we have vendor namespaces though alleviates this issue largely, because people aren't competing as much for simple and common names like they are with npm.
Maybe an addition to this ... I saw a package once, which was registered under an existing namespace, but was not created by the company/developers who used the namespace before, like I could create a package famous-framework/security-package and point it to github.com/i-am-a-hacker/you-ve-been-pwnd. This does not affect existing installations and it still needs some manual work for a developer to run into trouble, but still something which should be thought about, I think.
There's no reservation of vendor namespaces at the moment, right? Maybe this is something to discuss.
No there isn't, and I won't expend the time to implement this.. It's
easy enough to do by publishing a dummy package to a namespace if you
really care about it. That blocks the namespace for others, and it's
good enough IMO.
@Seldaek Great! I has been at least two years, since I saw that. Must have been implemented in the meantime :)
I've just double checked this and it works like you mentioned. That's absolutely fine for me.
Just for the record, here's the error you get :)

Very good work, guys! :+1: