Policy on requiring links to package source/docs/license?

[gregmac]

I've run across a number of packages over the time I've been using Nuget where there is no license, no documentation, no link to source code, and the project site is a generic top-level site to some company. I don't mean to pick on this particular one, but just as an example: https://www.nuget.org/packages/RealSense.CommandArguments.dll/

I'm filing this to start a discussion and potentially bring up some enhancements to help improve the nuget.org packages feed, as it's getting large and unchecked, I feel this situation will only get worse with time.

I can't find any policy on what is required to publish on nuget.org. At a minimum, it should be necessary to publish a license with all packages, as the default in most (all?) jurisdictions is that with no explicit license, you cannot use code or binaries, period. As such, it seems to me that nuget.org should actually reject publish requests for packages missing licenses.

Another thing that's unclear, is it acceptable to publish non-open code/binary packages on nuget.org?

If not, requiring a link to source code repository should be a minimum requirement. If it is, requiring a link to the place where you can license the code should be required (though perhaps the license link is enough for this).

One way to handle this is to contact the project administrator one-by-one, but this is hugely inefficient, and there's no guarantee the package maintainer will respond or do anything about it anyway. As a casual user that has no intent of using a particular package anyway, seems to be a waste of time. If we had comments it would at least be a low-friction way to call this out, but alas, comments were removed in #55.

So:

• Should licenses be required to publish on nuget.org?
• Is a non-open license allowed?
• Should a link to source code be required?
• Can we state and publish an official policy for this on nuget.org?
• What is the mechanism that should be used for reporting violations of policy?

[csharpfritz]

Great questions, and we are talking about requirements and validation for packages to ensure that the package feed is maintained at a high quality bar. I think these are good items that we should consider for the NuGet.org gallery and welcome discussion on them.

[gregmac]

I just ran across another package where the linked license and project URLs doesn't exist anymore, resparking my interest in this.

So in the interest of moving this forward, personally, I'd suggest:

• licenseUrl field is required (enforced as part of publish action: nuget.org rejects missing licenses)
• License must be OSI-approved.
  • In other words: go publish your binary/commerical packages on a custom nuget feed on your own server
• projectUrl field is required
• The project URL site MUST provide an obvious link to the source code for the package
  • Acceptable: Github/Codeplex/Bitbucket/etc URLs, Pages/sites dedicated to this particular package (or the project this package is a part of)
  • Not acceptable: Personal or company web page (unless it's mainly about the package itself, and has a link directly to the source code), pages requiring registration to get source,

The "report abuse" page on nuget.org would also need to have a couple additional reasons added ("Inappropriate project site link", "Project site down/missing", "Source code link missing", "Non-OSI license").

[marekr]

bump

With C#'s and nugets popularity growing. Its really starting to get silly. There are so many "commercial" packages on nuget now where you have to buy a license but theres no clear mention.

Granted one should be reviewing licenses there should be a system that:

1. Make packages use a pre-selected License type, i.e. MIT, GPL, LGPL, etc. This would display and allow users to understand what they are getting into easily.
2. If commerical is to be allowed. It should be explicitly noted as such as a license type "Commerical". There should be an additional field for license url required..
3. On that note of point 2, "custom" and "other" open-source licenses can be a type as well "Open-Source, Other" with the url to the license required.

[anangaur]

Thanks. Totally makes sense. We have added this to our backlog.

[Mystere]

My personal thoughts on this are that it's fine for commercial apps to use NuGet under the following conditions.

1. There is a link to the license. This might even be some way to extract the license from the NuGet package itself
2. The package is clearly marked as "commercial".
3. There is a link to the site.

It's obviously hard to enforce that these links actually do anything, but maybe the site should crawl the links from time to time to ensure the links are responding and mark them as dead if they are not. (which of course won't catch parking sites, but it's a start). Check that a) there is a dns record for the site, and b) that the site actually responds.

I do NOT think it's necessary to have an OSI-approved license, since any commercial license will obviously not fit that. And there are many custom OS licenses that are perfectly fine free licenses, but not specifically OSI approved (for instance the typical "Use this as you will, don't sue me" license. ie., essentially public domain.

Another important thing is documentation. There should either be documentation in the package, a link to documentation on the project site (this one actually would hit a lot of Microsoft packages that just point to dot.net or asp.net homepage), or a link to source code such as GitHub repo.

There seem to be a lot of packages that are uploaded to Nuget for personal use, and are not intended to be used by the public at large. We should discourage this. It seems like the author is simply trying to avoid paying for their own Nuget server/binary repository. Of course this is hard to enforce, but having the policies in place is a good start. Requiring a modicum of information, such as license, project/documentation site, and a general description would help as well, even though we cannot enforce that these fields contain real or sensical information.

While we're at it, why not add a rating system, with possible review/comments, similar to Visual Studio Gallery (which, by the way, has already addressed issues some of these issues). Number of downloads is a good indicator, but it's not really an indicator of quality (which I understand is highly subjective, but averages out over a large enough sample).

Finally, while I would never suggest that we prune or cull the repository, there should also be a way to add more filtering. For instance, don't show me packages that haven't been updated in x timeframe. Or even filter on some of the new fields we're talking about like license or don't contain documentation.

[markusschaber]

While I'm against banning of commercial packages, I'm all in favour of requiring a license statement. Without any license, the package is practically unusable. And having only a URL pointing to the license is not reliable - the contents behind the URL might change or vanish.

Thus, the licensing information should be contained within the package. There's currently a spec discussed which recommends either SPDX identifiers, or including the license file within the package. See https://github.com/NuGet/Home/wiki/Packaging-License-within-the-nupkg

[AraHaan]

Sorry for late reply but does the website support this expression for license GPL-3.0 for GNU GPL v3 Only?