New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Self-Contained NuGet Packages - License #4628

Closed
maartenba opened this Issue Feb 16, 2017 · 53 comments

Comments

@maartenba
Contributor

maartenba commented Feb 16, 2017

Right now, every package can link to a license by providing the licenseUrl property in the metadata. This is awesome, but also not-so-awesome. Allow me to explain my line of thinking.

Every package owner can attach a license to every version of their package. So far, so good, as it allows switching license between versions. So far, so good.

Now imagine utilizing a NuGet package. For impact, let's take Newtonsoft.Json, a very popular OSS package with a permissive license. One day, the author decides to update the HTML contents at the referred license URL. That's... problematic!

Which license applies? The one I read (and agreed with) at package install time? Or the current one that is now displayed on the license URL?

There is no way to figure out the license changed between install and consuming the package, no way to prove it was permissive at time of first install.

Please consider enforcing embedding license info into the package, as the package itself is considered immutable.

@xavierdecoster

This comment has been minimized.

Member

xavierdecoster commented Feb 16, 2017

I totally agree we should do something about this! A package version's license should be immutable.

Tagging @rrelyea @DoRonMotter

@cmatskas

This comment has been minimized.

cmatskas commented Feb 16, 2017

My +1

@vbfox

This comment has been minimized.

vbfox commented Feb 16, 2017

Also if licenses are embeeded, please allow authors to simply specify one of the standard OSS licenses ( https://opensource.org/licenses ) instead of a full text.

It'll make blacklisting / whitelisting license a lot simplier and would provide a way to display nicely the package license in the nuget.org UI without guesses in such cases.

@ryanbnl

This comment has been minimized.

ryanbnl commented Feb 16, 2017

@vbfox good idea; imho that should be extended so that you can, for example, filter on named licenses. named only being available when you select one of the standard licenses (all other being custom).

@reiz

This comment has been minimized.

reiz commented Feb 16, 2017

I totally agree. The license name should be mandatory and immutable! On Maven Central (Java) that is the case since years, because of reasons. For license names I would suggest to take the SPDX identifiers, that's a standard for OSS licenses. See here: https://spdx.org/licenses/.

By the way, I'm working on the open source project VersionEye and we did already a lot of work for recognising SPDX identifiers from license URLs provided in Nuget packages.

@maartenba

This comment has been minimized.

Contributor

maartenba commented Feb 16, 2017

@reiz We do a similar thing in MyGet. It helps, but ideally license info on a package should be immutable.

@reiz

This comment has been minimized.

reiz commented Feb 16, 2017

@maartenba Absolutely. The license name should be mandatory and immutable. That would make our all life much easier :-) MyGet looks like a nice service.

@JimBobSquarePants

This comment has been minimized.

JimBobSquarePants commented Feb 16, 2017

What happens if I want to change my license to something more permissive? Do I have to create a new package? That could seriously affect branding and visibility.

@maartenba

This comment has been minimized.

Contributor

maartenba commented Feb 16, 2017

A new package version in this case, yes.

@hhariri

This comment has been minimized.

hhariri commented Feb 16, 2017

@JimBobSquarePants Even if the license is more permissive, many organisations have restrictions on what type of licenses they can use. Going from a more restrictive to more permissive might still have legal impacts for those using the packages.

@sean-chase

This comment has been minimized.

sean-chase commented Feb 16, 2017

+1

@dylanbeattie

This comment has been minimized.

dylanbeattie commented Feb 16, 2017

+1. The inability to cite and verify the license that was in effect at the time a package was installed is a considerable weakness in the integrity of the NuGet ecosystem.

@markrendle

This comment has been minimized.

markrendle commented Feb 16, 2017

@JimBobSquarePants A new version, not a new package. Going from GPL on 1.x to MIT on 2.x, for example.

@markrendle

This comment has been minimized.

markrendle commented Feb 16, 2017

I don't actually know much about blockchains, but this seems to me to be the sort of thing that could be verified externally with a blockchain, signing and saving something when a package is published.

It could use Project Bletchley.

@ryanbnl

This comment has been minimized.

ryanbnl commented Feb 16, 2017

You don't need a blockchain here because you don't have a distributed trust problem. You have a central authority who can be trusted. They store/serve signed packages with embedded licenses (or links to well known licenses; Universal Resource Identifier style) :)

BTW I suggest googling blockchain, the technology is interesting bit it has become such a hand wavey marketing term. You don't hear the really good technical people talking about it, just the loudmouthed snake-oil salespeople.

In an ironic twist it'll probably turn out that you know more than the people often presenting about the subject (to non technical people) ;)

@JimBobSquarePants

This comment has been minimized.

JimBobSquarePants commented Feb 17, 2017

@maartenba @hhariri @markrendle My bad, misread. Agree with issue.

@reiz

This comment has been minimized.

reiz commented Feb 20, 2017

@JimBobSquarePants A license is always bound to a specific version of a package. Licenses can change from version to version. That's why it's important to track & document licenses in your dependencies automatically. There are different tools out there for this problem. Tools like BlackDuck, WhiteSource and VersionEye. I'm working on the last one, which is completely open source under MIT license.

@tthiery

This comment has been minimized.

tthiery commented Nov 20, 2017

@rrelyea Some context from my side helping for triage:

  • When analyzing Cordova Apps with its 1000s of NPM (sub)dependencies, standardized SPDX license identifiers inside of the NPM packages helped us to release software using whitelisting/blacklisting. Consider cases like "(MIT OR GPL-2.0)". Without this field, we would need literally weeks to analyze them.
  • License-less and unclear licensed (NPM) packages (e.g. not SPDX compliant statements like "BSD" vs. "BSD-3-Clause" or "MIT*") take serious analysis after identifying them.
  • Micro packages are becoming more and more popular (.NET Core / netstandard). The number of packages will probably grow as well.
  • Do not be late with this topic. During analysis mentioned above, old dependencies with unclear licenses got updated later (during the profesionalization of JavaScript) in newer versions. The old packages are in an unclear state.

I am recommending to enforce a license abbreviation with explicit additional options to "see text embedded in package" or "I hate licensing and do not do it". The first one lawyers need to check and the later can be sorted out automatically. Help with analyzers during the pack phase to ensure that the license is at least clarified.

@anangaur anangaur self-assigned this Jan 5, 2018

@gregmac

This comment has been minimized.

gregmac commented Mar 4, 2018

There's a related issue on the gallery project about license policy (which maybe should be here, or partly merged with this issue).

The main part of it is to be clear about commercially-licensed packages, and ensure there's a clear license link defined -- or simply ban them altogether from nuget.org.

The other part about requiring a project link is partly related to this, and if there's any policy change happening as a result of this ticket that would probably be a good change to go along with it, from a package maintainers point of view.

@karann-msft

This comment has been minimized.

Contributor

karann-msft commented Jul 31, 2018

@tthiery

This comment has been minimized.

tthiery commented Aug 1, 2018

Thanks for the spec. Everything I hoped for is in it :).
Regards license scanning: I think your new/old friends at GitHub did the same. Maybe connect to them.

@ferventcoder

This comment has been minimized.

ferventcoder commented Aug 1, 2018

For embedded binaries, we've required a LICENSE file and VERIFICATION file since 2015ish for Chocolatey Community Repository. Good to see this come into NuGet proper. 👍

@agr

This comment has been minimized.

agr commented Aug 7, 2018

I am reading the spec, and the impression I am getting that using SPDX expression and using custom license packaged with a file are mutually exclusive options. Is it expected that users wouldn't be able to do something like "GPL-3.0-only OR MySuperCustomLicense"? Does anyone want to do that?

@tthiery

This comment has been minimized.

tthiery commented Oct 16, 2018

@karann-msft can you elaborate on the csproj strategy of it. Will there be a explicit property in it or do we need to fallback to create a custom nuspec?

@karann-msft

This comment has been minimized.

Contributor

karann-msft commented Nov 1, 2018

@karann-msft

This comment has been minimized.

Contributor

karann-msft commented Nov 1, 2018

@tthiery

This comment has been minimized.

tthiery commented Nov 1, 2018

Awesome. Just a warning: There is a spdx license name called Unlicense which is a real license. A keyword Unlicensed is very close to that.

@karann-msft

This comment has been minimized.

Contributor

karann-msft commented Nov 1, 2018

@tthiery thanks for the heads-up....what would you use instead of "unlicensed"?

@tthiery

This comment has been minimized.

tthiery commented Nov 1, 2018

Maybe NonSpecified?

Edit: from previous None to NonSpecified. None could be misinterpreted that the package is not licensed at all (which mean different things in different regions I guess).

@agr

This comment has been minimized.

agr commented Nov 7, 2018

npm uses UNLICENSED, I don't think we should introduce yet another special case. License expressions are case sensitive, so UNLICENSED will always be in upper case and Unlicense will always be in Pascal case, so it would be more difficult to have them mixed up.

@pombredanne

This comment has been minimized.

pombredanne commented Nov 13, 2018

The use of "UNLICENSED" by npm is a rather confusing choice IMHO. The SPDX way is simpler and clearer: NONE or NO-ASSERTION. If you adopt SPDX expressions that would make the most sense (disclosures: I am involved in SPDX and I also maintain the scancode-toolkit which is a license scanner so every choices you make here is something that eventually I will have to write code to support whatever new and unique ways you have to express licenses. I also maintain a comprehensive license expression parser)

@pombredanne

This comment has been minimized.

pombredanne commented Nov 13, 2018

The spec at https://github.com/NuGet/Home/wiki/Packaging-License-within-the-nupkg#project-properties references old and deprecated license ids such as https://spdx.org/licenses/GPL-2.0-with-bison-exception.html which would be best avoided IMHO

@karann-msft

This comment has been minimized.

Contributor

karann-msft commented Nov 13, 2018

@pombredanne we plan to not allow deprecated licenses and as a matter of fact, the client will warn on pack and nuget.org will block publishing a package if you use a deprecated license. (excuse the poor choice for an example in the spec)

@rrelyea rrelyea modified the milestones: Backlog, 4.9 Nov 20, 2018

@rrelyea rrelyea changed the title from Package trust - Licenses to Self-Contained NuGet Packages - License Nov 20, 2018

@rrelyea rrelyea added Epic and removed Type:Feature labels Nov 20, 2018

@rrelyea rrelyea closed this Nov 20, 2018

@rrelyea

This comment has been minimized.

Contributor

rrelyea commented Nov 20, 2018

Shipped in NuGet release 4.9
(which ships in VS 2017 15.9 and .NET SDK 2.1.500 and .NET SDK 2.2.100)

@pombredanne

This comment has been minimized.

pombredanne commented Nov 20, 2018

@ karann-msft

we plan to not allow deprecated licenses and as a matter of fact, the client will warn on pack and nuget.org will block publishing a package if you use a deprecated license. (excuse the poor choice for an example in the spec)

Good... but a reminder that deprecation is a moving target as each new version of the SPDX license list may come with new deprecations.

@pombredanne

This comment has been minimized.

pombredanne commented Nov 20, 2018

@karann-msft commented on Sep 7 ...

@dabutvin - if you are using a well-known license, you don't need to put a file. You can just provide the license identifier.

Actually if you do not include the license text of most open source license in a package you are creating a non-compliant package as most license texts should be included as a condition of the license. Using only a well known license identifier is not enough and not a substitute for the text in most cases and it certainly lack clarity always. You need that and the text.

For example, take a simple license such as the MIT: including the full text is pretty much the only condition of the license.... so if you do not include it with a binary nuget package, then you are making your downstream users life miserable by shipping a nuget that is immediately non-compliant and eventually not licensed once downloaded.
User redistributing this package will also need in this case to review in details the package and re-include (and re-package as a new nuget ??) the missing upstream license texts to become compliant if they redistribute this..

So excluding texts is a sure way to create a jolly chain mess if you want my 2 cents.

@markusschaber

This comment has been minimized.

markusschaber commented Nov 21, 2018

As far as I can see, Debian distributes common licenses in usr/share/common-licenses to avoid duplications of license texts. I'm not sure how they manage to do it in detail, but Debian legal is well known for their "attention to detail"...

@pombredanne

This comment has been minimized.

pombredanne commented Nov 26, 2018

@markusschaber indeed. And Debian does this only for a very few licenses that allow such practice... not for MIT licenses for instance. Furthermore, Nuget is not a distro, so you cannot assume that there is some base present

vbfox added a commit to vbfox/docs that referenced this issue Dec 4, 2018

Add license properties to csproj documentation
Part of the text is from the equivalent tag in [nuspec documentation](https://docs.microsoft.com/en-us/nuget/reference/nuspec#license)

NuGet change is NuGet/Home#4628 released in SDK 2.1.500
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment