New license request: Microsoft Limited Public License (MS-LPL)

[testworksau]

This license has one extra special condition in section 3 as compared to the Microsoft Public License (MS-PL):

(F) Platform Limitation- The licenses granted in sections 2(A) & 2(B) extend only to the software or derivative works that you create that run on a Microsoft Windows operating system product.

Refs:

• https://www.openhub.net/licenses/mslpl
• https://en.wikipedia.org/wiki/Shared_Source_Initiative#Microsoft_Limited_Public_License_(Ms-LPL)
• https://github.com/gabegundy/atlserver/blob/master/License.txt

[swinslow]

Thanks for submitting this @testworksau!

So for requests to add licenses to the SPDX License List, we look at them based on the License Inclusion Principles.

Here's my quick analysis on looking at the principles -- would welcome thoughts / comments from others in the SPDX legal team community:

---

Has the license been approved by the OSI?

All OSI-approved license will be included on the SPDX License List, regardless of other factors

No

Definitive factors

These must all be satisfied to allow inclusion in the license list

Is the submitted license unique, that is, it does not match another license already on the License List as per the matching guidelines?

Yes: As noted in the submission, the "Platform Limitation" restriction is not in Ms-PL or in other licenses currently on the license list.

If a software license, does it apply to source code and not only to executables?

Yes

Does the license have identifiable and stable text, and is not in the midst of drafting?

Yes -- historical license, appears to have been released in October 2006, based on this archive page

Has the license steward, if any, committed to versioning new versions in the future and to not modify it after addition to the list?

Not aware of any such commitment, but also not aware of any changes to the license since the 2006 release

Other factors for inclusion

Roughly in order of descending importance

1. Does the license substantially comply with one of the free/open content definitions?

Approval by the organisation that publishes the definition is not required

No. Due to the "Platform Limitation" restriction, unlikely to satisfy the OSD or the other definitions.

2. Is the license structured to be generally usable by anyone, and not specific to one organisation or project?

Yes -- although "Microsoft" is in the license name, it is structured for anyone to be able to be the licensor.

3. Does the license have substantial use such that it is likely to be encountered (ie. use in many projects, or in one significant project)?

For recently written licenses, definitive plans for it to be used in at least one or a few significant projects may satisfy this

Yes, for historical usage. I'm skeptical about how much it's getting used for new / ongoing projects, but looking at these Google search results on GitHub and particularly this search within the 'microsoftarchive' org on GitHub, I think it's fair to say that it had sufficiently substantial use.

4. Is the license primarily intended to facilitate the free distribution of content with limited restrictions?

Generally yes. The limitation for software / derivative works only being licensed if they run on a Microsoft Windows operating system product is of course a restriction, but that is the only restriction and it does not appear from a cursory reading to prevent free distribution of the licensed content.

5. Does the license steward support this submission, or is at least aware of and not in opposition of it?

Not aware of views either way from Microsoft re: its inclusion on the SPDX License List

Summary of factors / outcome

Comments on the totality of these "other factors" in light of the SPDX License List's overall goals and objectives

I lean slightly in favor of adding this to the license list. Obviously the Platform Restriction is the major strike against it, but given the inclusion principles' intent to permit some "source available but not open source-ish" licenses to be added, I think the evidence of substantial historical use is sufficient to warrant including it here.

[jlovejoy]

@testworksau - do you work for Microsoft? We like to make sure that the license steward (if there is one) is aware of submission, out of courtesy.

[zvr]

I am reluctant about adding it to the main SPDX License List, due to the platform limitation. People have come to expect licenses in the SPDX License List to signify "you may re-use this" (which results in discussions about the CC-NC).
I should point out that there are a significant number of similar licenses with different run-time platform restrictions ("only if software runs on hardware X" or even "only if software runs on hardware that uses memory from manufacturer Y").

On the other hand, this license would be ideal for an entry in the Microsoft license namespace: it's stable, used in different projects, etc. 😉 Provided a steward is found, obviously (and we include namespaces in the 2.3 spec, which I will try).

[swinslow]

@zvr It's a fair point!

Under the new inclusion principles, there are some newer non-open-source licenses that have been added (e.g. Hippocratic-2.1, PolyForm-Noncommercial-1.0.0) but only when there's been a showing of some amount of substantial use. But even in those cases, the restrictions were about who could use the software or for what purposes -- as compared to Ms-LPL, which is a flat prohibit on use outside the permitted technology platform.

If it weren't for the significant amount of past publicly-available source code that appears to be out there under Ms-LPL, I wouldn't be in favor of adding it to the list. I do still lean slightly in favor given the amount of use, but I'm interested in others' thoughts as well given the technology platform restriction.

[testworksau]

Thanks all for your comments.

@jlovejoy I do not work for Microsoft, so will not be a suitable steward.

@zvr I understand where you are coming from; perhaps to add a little bit of context, my organisation is currently going through a much overdue process of ensuring open source software (either source code or compiled binaries) that we use is correctly attributed to their licenses.

We are implementing tooling to ensure that we are compliant with our current and future usage of OSS, and most tools and package managers in this space are recommending SPDX identifiers to be used to allow tools to accurately report / alert / block etc. As an example, here's the Conan documentation for a Conan package license attribute.

People have come to expect licenses in the SPDX License List to signify "you may re-use this"

Given the above context, I'd be interested in hearing more about this statement you made as I feel that the restrictiveness of a given license does not negate the need for a consistent and unique identifier to exist.

I am quite new to this space so please feel free to educate me if my understanding / interpretation of SPDX is incorrect 👍🏼

[swinslow]

Discussed on legal team call 2022-04-14, general agreement with inclusion principles analysis above. @testworksau, one question from the discussion: You mentioned Conan, is this request relating to wanting to use an SPDX ID for one or more packages that are on the Conan package manager?

[ariel11]

@jlovejoy and @swinslow - I work for Microsoft. No objections to the MS-LPL having a SPDX identifier - thanks for the heads up.

[jlovejoy]

@testworksau - would be you be wiling to prepare the files for this? We have a (lengthy) description of the process here: https://github.com/spdx/license-list-XML/blob/master/DOCS/request-new-license.md

The next release will be pushed soon, so if it may take you some time, just let us know and we'll mark this for the next release.

[jlovejoy]

@testworksau - would be you be wiling to prepare the files for this? We have a (lengthy) description of the process here: https://github.com/spdx/license-list-XML/blob/master/DOCS/request-new-license.md

The next release will be pushed soon, so if it may take you some time, just let us know and we'll mark this for the next release.

[swinslow]

No PR submitted yet; I'm going to bump this one to 3.18.

[testworksau]

Discussed on legal team call 2022-04-14, general agreement with inclusion principles analysis above. @testworksau, one question from the discussion: You mentioned Conan, is this request relating to wanting to use an SPDX ID for one or more packages that are on the Conan package manager?

Hi @jlovejoy - sorry I've not responded yet, I've been travelling!

In a sense, yes. The license attribute is part of the recipe that generates Conan packages; we are using Conan in our org, but cannot use public Conan packages as they lack debugging information, so effectively roll our own.

I'll see if I can get a PR together for the new license by the end of the week.

[testworksau]

OK I think that's complete @swinslow 👍🏼