Better protection for verified packages.

[JimBobSquarePants]

At present there is no protection at all for verified packages other than the blue tick. We need better protection.

I am one of the owners of SixLabors. A registered company made up of OSS developers who have spent the last 3+ years building a cross platform 2D Graphics API for .NET Core. We have reserved our namespace in a vain attempt to protect end users from unsanctioned uploads using our branding on Nuget.

https://www.nuget.org/profiles/sixlabors

This user has uploaded every single one of our pre-release packages, easily bypassing any namespace reservation validation by simply adding their own prefix to our namespace.

https://www.nuget.org/profiles/intheloop

SixLabors.ImageSharp becomes Loop.SixLabors.ImageSharp

They:

• Use our logos
• Point to our Github repository for support
• Have changed version numbers removing any pre-release tags.

This means that there are now potentially dangerous, pre-release packages on Nuget that contain our name and show up in the default search.

I will be reporting them for copyright violation but I have yet to successfully remove a project that violates our copyright from Nuget having previously reported the below listed projects for doing similar (logo, repo-link). The apathetic responses from support have been very disappointing.

https://www.nuget.org/packages/RevStackCore-ImageSharp/
https://www.nuget.org/packages/RevStackCore-ImageSharp.Drawing/

Can we add at least do the following?

• If a verified project want a clone removed, actually do it.
• Add better namespace protection - i.e don't allow it to feature anywhere in an non-validated name.
• Prevent unverified packages linking back to a verified packages repository for logos
• Prevent unverified packages linking back to a verified packages repository for support

[jamiehowarth0]

+1

[peter-dolkens]

I'd go so far as to add a few extra requirements:

• Any package that can be shown to be repackaged, should not be allowed to include unrelated dependencies (e.g. https://www.nuget.org/packages/IonicZip/1.9.1.8)
• Any package that can be shown to be repackaged, should be flagged "Unofficial" in their package title.
• Any package that can be shown to be repackaged, should ideally be forced to use the "Unofficial" root namespace as a matter of policy.

[JimBobSquarePants]

The reporting process needs to change also.

At present all the work has to be done by the verified package owner.

To get a package violating our copyright removed I have to:

• Contact the owner of the offending package by email
• Forward a copy of that email to [email protected]
• Fill in the copyright violation form on Nuget
• Hope for the best.

I strongly believe that the emphasis should be on the accused to prove that they have not violated the copyright of the verified package and that a soft removal should be immediate with a hard removal occurring if the accused cannot prove that they're package does not violate copyright.

We are verified after all?

[peter-dolkens]

@JimBobSquarePants I'd argue that, unless there was an instance of the verified namespace within the package namespace at the very least.

Otherwise you might start issuing takedowns for your competitors.

We don't want this to become another ContentID farce like YouTube, where a few big players spoil out for everyone.

[JimBobSquarePants]

We don't want this to become another ContentID farce like YouTube, where a few big players spoil out for everyone.

@dolkensp Definitely not. And with the aforementioned protection regarding logos and repository links in place it should boil down to namespace violation.

If someone can prove they are not violating copyright. Great! What I want to avoid is the compounding of already stressful situations with policy that does not actively protect the verified user.

[peter-dolkens]

Here's an example where Microsoft's own official package has less downloads than the Unofficial clone...

Scary...

[anangaur]

@dolkensp None of them are official ;) We have had issues where anybody could have used a Microsoft. prefix for packages. We have since then fixed the issue with Prefix ID Reservation but existing packages remain.

[peter-dolkens]

Ahh, good spot! Just goes to show how hard it can be to spot these things!

[JimBobSquarePants]

It's happened again.

https://www.nuget.org/packages/Loop.ImageSharp/1.0.0-beta1003

https://www.nuget.org/packages/Loop.ImageSharp.Drawing/1.0.0-beta0003

[anangaur]

Thanks for reporting this. Can you please report them using the ‘Report’ option on the packages?
This may seem like a redundant step but it is required to take down any package citing copyright or trademark violation. Do select the right option in the drop down.

[JimBobSquarePants]

Already have.

[JonDouglas]

I would encourage people on this thread to look up:

https://www.dmca.com/FAQ/What-is-a-DMCA-Takedown

This is the official and legal mechanism to order a takedown of content in violation.

The cases get harder every year given more OSS forks of projects happen and more packages are uploaded to NuGet for various reasons. (Removal of functionality, addition of functionality, new maintainer, community fork, etc)

Today that process is to report a package and go through a DMCA takedown through the Report a Package button on any NuGet package's details page.

[kzu]

Are there any (legal, registration) steps where one might copyright a name/namespace so this process is more expedient? i.e. how do I make sure no packages can use Moq in their name unless they are prefixed with Moq.Contrib which is the only prefix reservation I left out for folks to actually extend it?

[JonDouglas]

@kzu Talk to a lawyer who specializes in OSS/software U.S. copyright law specifically 17 U.S.C. 512(f). See https://www.nuget.org/policies/Terms for "Contracting Entity, Choice of Law, Jurisdiction" if needed.

Like everything legal, there is due process and nothing is expedient. I am sorry, but that's the nature of DMCA takedown.

[migueldeicaza]

This is not a copyright issue, you would need to use a trademark for this.

This is what is going on with Rust and happened before with Mozilla and Red Hat.

[migueldeicaza]

That said, regardless of the legal instruments that might be explored, I think that Nuget would benefit from just having their own rules that address this particular set of problems for a narrower set of issues.

One downside is that such a policy would need to consider various scenarios like:

• The maintainer vanishes or is unresponsive and you have security holes to deal with.
• It would make forks of existing projects too burdensome or expensive
• The fork would still happen, just not be as discoverable here.

And so on

[dansiegel]

@JonDouglas while I appreciate that certain legal mechanisms may exist this doesn't address the root issue that we have, which is that NuGet should actually be proactively protecting verified authors. I think there are a number of things that can be done to help NuGet automate flagging packages for human review.

For example if the package name includes part of a verified publisher name such as the case Loop.ImageSharp... it would make sense to automatically flag the package for review which could then

• Scan the assemblies between the verified ImageSharp packages and the suspected package. It may simply be some plugin that adds functionality and is harmless, but it could be fork that should require some validation like the original publisher abandoned the project.
• Prevent the package from being published when it links back to a verified publisher's repo but wasn't published from the verified publisher
• Scan the GitHub source (if available) to determine if it's just a fork... again this should require some hoops to jump through to show the original project was abandoned

[JonDouglas]

Let's take a step back to understand the challenges and state of things.

1. There is no such thing as a verified package. A package ID prefix reservation protects your identity by reserving the land associated with the ID. I'm curious what people are referring to when they say "verified".
2. There is nothing stopping a person from forking/cloning a permissive licensed project and uploading a package to the central registry.
3. There is a policy that can be found here: https://www.nuget.org/policies/Terms. Specifically "Your Content remains Your Content and you are responsible for it."

Now that brings us to the challenges today I'm seeing.

1. Authors want better protection for their critical ecosystem projects with a recognizable name.
2. Authors want faster registry action from impersonation of their derived work.
3. Authors want automation of content review to assist them through DMCA(i.e. 1. & 2. ).

As Miguel points out, the legal protection is a trademark. That allows you to DMCA packages that remotely mention the recognizable name(this happens in other ecosystems too). Otherwise it is up to you to prove you own the copyright to then DMCA the derived packages that violate the terms of your license or copyright law. I am not a lawyer, that is why I suggest speaking to one for further clarity. If you do, please provide some insight into this thread. But that's my understanding after 3 years doing this.

NuGet today has no concept of YouTube's "Content ID" nor a ledger of key ecosystem projects and their maintenance status. I tried to propose an idea for the latter two years ago which was a complete and utter failure.

The challenges I'm trying to understand here is similar to what @peter-dolkens brought up awhile ago. Where is the balance between "free redistribution" and "anticompetitive behavior"? Secondly, if there were a human review, it would not make sense for NuGet to review these as they would be allowed by terms. It would make sense that the content copyright holder review these cases and follow the DMCA process to legally take them down.

This is less so a technical problem in my eyes. This is more a social and legal problem. NuGet is merely the intermediate/supplier. There is a great amount of power and responsibility because of this. I don't have the answer to this problem and I haven't seen any other package manager find a solution yet either. I'm sure there are ways forward to make this better for everyone.