One of my students wanted to know what a package he installed was doing, but the only direct information he found was a repository with examples which uses the package. The package I am talking about is named mmWave. The maintainer of this package is the same guy who maintains the example repository. A few weeks ago I opened an issue on his example repository to ask him to add repository informations on the package site since his package is
labeled as Open Source.
the source code could be downloaded as zipped file. (Not yet checked)
After I started my issue, he included information of a github repository, but obvious not the actuall package repository. I can just speculate his/her intuition of adding this truly false information.
Before reopening the issue/or making a new one, I wanted to discuss with the forum how to handle the situation.
Note that if you want to see the source code, you can find the source distribution that the project publishes here: https://pypi.org/project/mmWave/#files.
Before my Issue only the website was pinned. Not the other projectlinks were provided.
I truly don’t want to blame the person but the linking to numpy looks like statistic fishing, which mostly makes the repository maintainer not very trustworthy for me.
I absolutely don’t understand why he would not share the original repo link, since the source is already provided as you also mentioned.
I just stumbled about this, because I usually read the Readme first before using a package. Since the GitHub frontpage is the easiest to read for me, I searched for the repo.
It’s possible that even though the prroject is open source (i.e., published on PyPI), the source repository is not on GitHub or not publicly available at all. The author may not have a link to share.
I agree that linking to numpy doesn’t make sense here, but unfortunately PyPI does not have a way to enforce whether these links are accurate or not.
I think your best path forward would be to reiterate your request on the issue and mention that the link to the numpy source repo is confusing.
Looks like the number of stars on the PyPI page and other statistics are taken from NumPy? That could explain why the author does this: they’re apparently trying to borrow another project’s popularity.
One thing we can do to mitigate some of this is show the actual GitHub repository name, in the GitHub section; so that it’s difficult to misrepresent what the project refers to (eg: for getting boosted star ratings etc).
Disclaimer: I myself am not a lawyer, and nothing in the following should be considered legal advice.
It appears the main issue is them listing Numpy as their homepage and project URL, which shows Numpy’s extremely impressive GitHub stats instead of the project’s non-existent ones. It isn’t totally impossible that it is unintentional, but what is clear is the misleading effect it has on viewers.
It is well established in precedent (and internet ethics) that no permission is required to merely link a site, and such is not protected by copyright or trademark law. However, the issue here is that the specific usage and context of the link implies endorsement of mmWave by Numpy, is an inappropriate and unauthorized appropriation of Numpy’s goodwill by mmWave, and can result in substantial consumer confusion as to the relationship between Numpy and mmWave.
Aside from civil action on various claims, as Numpy has registered and has a policy protecting use of their trademark in ways that actively and deliberately mislead users and harm the project, this could invoke that protection as well.
In any case, beyond any PyPI policy to handle cases such as these (which might be beneficial, if this is not an isolated incident), @rgommers might want to take note of this.
I’m a little confused by this. Whether or not the project is FOSS/Open Source is orthogonal to whether it is published on PyPI, as being on PyPI neither requires nor guarantees that project is open source or even not completely commercial/proprietary. The MIT license is stated in the metadata, but the actual license file is not included in the distribution artifact, so the license status is a bit ambigious. However, unfortunately with how things are presently set up, this is not uncommon (and the motivation for our work on PEP 639). However, it doesn’t appear to directly relate to the main issue here.