Should SPDX license expressions such as "MIT" be considered invalid, as the resulting NuGet package would have incomplete license information?

[plioi]

Documentation shows the following example for using the new license tag:

<license type="expression">MIT</license>

It also says that the expression, MIT in this case, corresponds with the SPDX License Identifiers.

The SPDX "MIT" Identifier, though, corresponds with a license that has meaningful substitution text: <year> <copyright holders>.

How can there be any legal value in specifying the license tag like this?

Is it wrong to conclude that the licence tag should never be used with some SPDX expressions, since the result is meaningfully incomplete? Is the file="..." alternative the only truly valid way to use the license tag for SPDX identifiers whose corresponding text has substitution text?

[karann-msft]

The license expression is a mechanism for the package author to easily express the licensing terms governing a package they own when using a well-known license like MIT. It is reasonable to assume that the copyright and author are the values coming from the respective metadata fields. There is nothing stopping you from adding license text as a file in the package in addition to using license expression. What you cannot do is use the license property to point to a file and an expression since we cannot validate that the file content and the expression is the same license.

[txwizard]

I came here in the course of working out how to implement the 3-clause BSD license, SPDX licens ID BSD-3-Clause. Reading the problem statement of this issue caused me to wonder whether my NuGet client, version 4.9.4.5839, would fill in the two tokens from my own package. As a test, I converted one small library that undergoes regular maintenance from license URL to an SPDX license ID.

The license appears as expected when I upgrade the package in Visual Studio.

However, the blanks aren't filled in.

The attached archive contains my .csproj, .nuspec, and AssemblyInfo files. Note that there are two of the latter, which the build engine merges at build time, because this library belongs to a package that contains another 9 libraries.

WizardWrx_Common_CSProj_and_NuSpec_20190519_001756.zip

Am I missing something, or does this problem expose the need for a feature request?

[plioi]

@txwizard Given the response above includes the words "It is reasonable to assume... the copyright and author" without irony, we have to conclude that no lawyers were consulted at all, and that the feature is unusable by design. I recommend you just include the full license in your NuGet package, including your substituted values, and discard the feature as unsafe.

[karann-msft]

@plioi, @txwizard - I understand the concern and I will take this as feedback for improving this feature. While we don't have a mechanism to substitute the values in the license today, as I mentioned, you can do both i.e. use a license expression and include the license text as a file. It is in the best interest of the package author to use a license expression since it allows your customers to quickly identify the package's license. The link will continue to point to the well know text for that license per SPDX and is for convenience of the package consumer to understand what are the terms of the license if they are not familiar with it. Including the license text as regular content should cover you legally. Many package authors already put a license.txt in the package root even before this feature existed.

[txwizard]

Ideally, the installer should make the appropriate substitutions. In the meantime, combining the SPDX tag with an embedded text file is an acceptable alternative. BTW, though I am not a lawyer, I don't need a law degree or a license to figure that out.

The fact that this thread exists suggests to me that maybe somebody didn't think it all the way through. Consequently, they missed an opportunity to show their text transformation prowess.

[nkolev92]

@karann-msft

Do you want to keep this issue open? Something still you want to consider/

[zkat]

@chgill-MSFT ping :)

[PathogenDavid]

What you cannot do is use the license property to point to a file and an expression since we cannot validate that the file content and the expression is the same license.

In the same vein, NuGet cannot know if the package's license is even correct in the first place. (I've seen packages listed with the wrong license on NuGet.org before, but that's between me and that package's maintainers not me and NuGet.org.)

---

I think it would be valuable for NuGet to do what GitHub does and try to inform the user of what the license flavor is either to:

• Infer the license type from license type="file" (and maybe populate license type="expression") or
• Verify that the included license actually matches what the developer specified for license type="expression" (and error if there's a mismatch when both are specified.)

According to GitHub, they use Licensee for identifying licenses. It's not a perfect solution (for instance it fails on NuGet.Client since it doesn't include the full license text -- see Roslyn for a working example) and it only works with a small subset of commonly-used licenses.

However, I think this is better than the current state of NuGet today. Right now developers have to choose between a crappy user experience (using license type="file") or the nice experience and only including the license file as a convention (which makes it harder to automatically grab license files for compliance purposes.)

[txwizard]

I propose a simple solution, and offer herewith most of its implementation.

Suppose that the license expression is followed by a parameter list, along the following lines.

• CopyrightYear = 4-digit copyright year
• CopyrightOwner = String containing name of copyright owner

Given these two, the SPDTX URL can have a query string appended to it, and the following short function, which I borrowed recently from a Web page, though I forgot to put a credit into the source code from which I extracted it, can extract the two strings.

    function GetUrlParameter ( psstrKeyName )
    {
        /*
            --------------------------------------------------------------------
            Function Name:  GetUrlParameter

            Function Goal:  Extract a named parameter from a query string.

            Input:          psstrKeyName    = Name of key to extract

            Output:         Value of key named by psstrKeyName, if present,
                            otherwise the empty string

            Source:         Get Query String Parameters with JavaScript
                            https://davidwalsh.name/query-string-javascript

            N. B.:          The original author did something that I see as
                            a code smell by modifying the value of an
                            argument. This works here because JavaScript
                            passes arguments by value. I see chained method
                            calls as a code smell, too, regardless of the
                            fact that they seem to be common practice.
            --------------------------------------------------------------------
        */

        psstrKeyName    = psstrKeyName.replace ( /[\[]/ , '\\[' ).replace ( /[\]]/ , '\\]' );

        var regex       = new RegExp ( '[\\?&]' + psstrKeyName + '=([^&#]*)' );
        var results     = regex.exec ( location.search );

        return results === null ? '' : decodeURIComponent ( results [ 1 ].replace ( /\+/g,  ' ' ) );
    };  // function GetUrlParameter

Two simple, inexpensive (easy to apply, with minimal computational effort, regular expressions could replace the blanks in the SPDX license, and the whole thing could run off an onLoad event function that executes in the client's Web browser.

It's just a thought, and the above JavaScript function is yours to use. Though I put it into a proprietary project, as you can see from the comment, I copied it from somewhere public.

[glopesdev]

Speaking of the BSD-3-Clause, I found it concerning that removing the substitution text implies substantial differences between SPDX/BSD-3-Clause and the text on licenses.nuget.org/BSD-3-Clause.

Compare the reading of clause 3 on the two sites above. Removing the placeholder text renders the sentence completely meaningless, and it might as well not be there at all.

If no effort is going to be made to fill in the placeholders with package metadata, why not just leave the defaults from SPDX, since at least they are more likely to form valid legal sentences?

[aortiz-msft]

@clairernovotny, @chgill-MSFT - Any recommendations?

[bilbothebaggins]

Since 2024 this is - rightfully imho - still open, let me add my 002 after wrestling with this license insanity for a few weeks (lawyers involved):

[[ @karann-msft on Apr 23, 2019 ]] What you cannot do is use the license property to point to a file and an expression since we cannot validate that the file content and the expression is the same license.

As @PathogenDavid already pointed out this is a false conclusion.

Indeed, the current mess wrt. https://learn.microsoft.com/en-us/nuget/reference/nuspec#license could be improved if package authors were able to simply declare a license expression and a license file. That way, a clear indication of the license and the license text itself can unambiguously be declared by the package itself. Validation is optional.