Add Prosperity-3.0.0

[feross]

I'd like to add Prosperity-3.0.0 to the SPDX license list. Here's a PR!

Previously, there was discussion about adding Prosperity-2.0.0 in #805. Since that time, Prosperity-3.0.0 was released. The announcement post is here: https://blog.licensezero.com/2019/12/15/prosperity-3.html

[waldyrious]

The announcement post is here: blog.licensezero.com/2019/12/15/prosperity-3.html

And here's the release notes in the license repo, the list of commits, and a complete diff of the text changes, however useful it may be.

[kemitchell]

@jlovejoy thanks for adding the 3.9 release tag here.

@feross, would you like me to open the PR to add the XML file? I've already got my head around the file format, more or less.

[feross]

@kemitchell Go for it!

[feross]

I assume this PR should be closed then?

[kemitchell]

@feross, my mistake here. I didn't recall that this is a PR. Reopen?

[kemitchell]

So it likes I mistook this for a PR, which led @feross to close it prematurely. We were tagged for 3.9, but got left out due to the mixup.

@jlovejoy, I see you just tagged Accepted. Would it be easiest for me to reopen as a new PR?

[swinslow]

@kemitchell I don't recall this getting accepted (or reviewed) -- guessing that was tagged in error. Has there been an issue filed for reviewing this one? The only thing I'm seeing was a mention of a prior version of this license in the thread that was about one of the Parity versions.

If you or the license steward can file an issue with details about the license, I'll tag it for discussion for the 3.10 release cycle and I'll bring it up during one of the upcoming legal team calls.

One way to create an issue for this with the relevant info is to fill out the form at http://13.57.134.254/app/submit_new_license/ (yes, we need to get an actual domain name set up for this).

[feross]

Re-opened.

[seabass-labrax]

Whilst this license satisfies a number of the technical factors for inclusion, I believe that there are some issues that would prevent it from being a suitable fit for the SPDX license list.

This license clearly does not comply with any of the free or open source definitions listed on the inclusion principles, due to its severe limitations on commercial use.

The 9 example projects given on the license steward's website are not representative of the use of this license: one has been changed to the MIT license, and others are under older versions of the Prosperity license. The largest project listed, Drone, is substantially open source with only 'enterprise' features under the Prosperity license. I did find a number of other projects using the license, but nothing stood out as very significant to me.

Unlike with the Parity license by the same author (which was included on this license list), the restrictions here would prevent prominent software distributions such as Debian or RHEL from being able to include packages available under this license.

It is also worth noting that the license steward seems to also advertise itself as a payment handler for exclusive software licenses; however, it also states that it has shut down "to make way for an evolved system".

In conclusion, I don't feel as if inclusion of this license in SPDX would add any value to the open source ecosystem. What do others here think about its suitability for this list?

[kemitchell]

OSI and FSF approval aren't required for SPDX identification, and haven't been. A few non commercial licenses have already been identified, including Creative Commons'
NonCommercial variants and PolyForm Noncommercial, upon which this version of Prosperity is based.

SPDX users, on the dev side and the user side, routinely identify proprietary code with license identifiers and expressions.

It's a list of license forms. Not a list of endorsements.

[seabass-labrax]

Thanks for the speedy response, Kyle! I've spent some time researching the PolyForm license that you've linked to in comparison to this one.

OSI and FSF approval aren't required for SPDX identification, and haven't been. A few non commercial licenses have already been identified, including Creative Commons' NonCommercial variants and PolyForm Noncommercial, upon which this version of Prosperity is based.

I noticed from your GitHub profile that you are a member of both the Artless Devices (the license steward for Prosperity for others reading this) and PolyForm projects, so I can understand your reasoning for their equivalence here. However, I don't think that similarity to a previously accepted license grants any intrinsic eligibility to the SPDX license list; indeed, proliferation of similar licenses is most often counter-productive in this space.

The critical differences between the PolyForm license you linked to and the Prosperity 3.0.0 are the 30-day trial period and the 'contributing back' section. I find these additions problematic, though. Given the lack of clarity as to whether and how the trial period can be continued or reset through transference or modification, this extra clause is of little to no use for software distributions and their users.

As for the 'contributing back' clause, I personally don't see this as an improvement! If a for-profit company made an addition to the licensed software and then put it up for sale under the Apache license, for instance, how would this not be commercial use? Indeed, is that company's license void if the initial author refuses or is unable to, for some reason, receive the modified version?

Thus, even in the wider proprietary distribution context, Prosperity 3.0.0 seems to be at best serving as a replacement for the PolyForm Noncommercial license, and at worst adding uncertainty for software distributions that use SPDX.

Again, thank you for giving some extra background about the license. I'd appreciate some other views on this as well; anyone else fancy chipping in?

[kemitchell]

The SPDX process isn't an open-ended referendum on license quality, or a popularity contest. That's what OSI and the Linux distro licensing committees are for.

There are plenty of licenses on the list I take it you'd dub problematic. There are several arguably permissive licenses that another organization I'm involved in, Blue Oak Council, call out as problematic by ID. The value of SPDX identification is being able to name and recognize welcome as well as unwelcome terms in the wild, for whatever counts as welcome and unwelcome in context.

People are using Prosperity for their work and running into it in code and package repositories. Both licensors and licensees would benefit from an SPDX ID.

[ghuntley]

I use Prosperity in most of my source provided software.

GitHub uses Prosperity as well https://github.com/dependabot/dependabot-core/blob/main/LICENSE

I seek the addition of Prosperity to SPDX as it helps with the generation of a bill of materials. SPDX is meant to be a list of licenses.

[ghuntley]

See also NixOS/nixpkgs#97832.

[drewcrawford]

I also use prosperity for my published software. I also considered the Polyform NC license and specifically chose Prosperity.

I believe the reason Polyform NC entered the discussion is not to compare the licenses in every respect but to address a specific objection around the inclusion principles. Specifically, the draft process considered the question of Polyform NC and whether SPDX wanted to include it. Obviously the end result is that the license was included.

[seabass-labrax]

The SPDX process isn't an open-ended referendum on license quality, or a popularity contest.

@kemitchell, certainly, I agree with you here. Indeed, I may have been rather vague in my previous comment! To clarify, I was referring to the usefulness of a 'prospective' inclusion rather than judging the license on any inherit merit.

If a new version of the GNU GPL were to be published, for example, there would be a strong case for a kind of prospective inclusion, as it's to be expected that such a license would quickly become common in software distributions that use SPDX.

The same would likely not be true of Prosperity 3.0.0, as many of these distributions would be unable to include software under the license. This is either because they do not distribute proprietary packages, because the distribution is a commercial venture itself, or because the lack of clarity in key areas of the license would incur unreasonable risk to the distribution or its users.

To recap with particular regard to the inclusion principles-

1. The license is not free or open source by any of the definitions listed in the principles, which I think weighs strongly against inclusion,

and

3. The usage is currently not (in my opinion) substantial, and for the reasons above I don't think it is likely in the future to rise appreciably in popularity with users of SPDX.

[seabass-labrax]

Welcome to the discussion, @ghuntley, @drewcrawford. It is always good to have more perspectives on these things :)

ghuntley, regarding creating a software bill of materials, I think section 6.1 of the latest SPDX specification has you covered! It describes the process for describing within SPDX documents licenses not included in the SPDX License List.

[kemitchell]

@seabass-labrax, "pure" Linux distributions aren't the only or even the primary use case for the SPDX license list, and no free/open-only disto I'm aware of relies on SPDX to identify only licenses they accept. The standard's also used extensively by mixed distributions, software package repositories, automatic license audit and compliance tools, and corporate compliance departments.

@drewcrawford, @ghuntley, @feross and others want to be able to use the obvious identifier---Prosperity-3.0.0---in their package.json and other package metadata files without warnings. Noncommercial users of tools like licensee should be able to add Prosperity-3.0.0 to their license whitelists, along with CC-BY-NC-4.0 and PolyForm-Noncommercial-1.0.0. Firms and projects that don't approve noncommercial terms should be able to add Prosperity-3.0.0 to their blacklists, so folks running into the license later on don't duplicate effort reviewing and assessing.

These are all valid users of the SPDX license list, and in some cases the expression syntax.

[jlovejoy]

ok, several things to address here:

PROCESS: I think at least a couple of us got confused b/c this came in directly as PR, instead of as an Issue with the usual format that entails. That's ok, we know where we are now.

INCLUSION PRINCIPLES:

• not OSI approved
• seems to be intended to be source available
• stable text, yes
• clearly @kemitchell has demonstrated his ability to version control his licenses
  other factors:

1. license substantially complies with one of the open source definitions - no
2. license structured to be generally usable by anyone - yes
3. substantial use - I'm not really seeing this. I searched Github for "Prosperity Public License" and got about 300 hits and scanned the first 100ish. Most of the hits were to older versions of the license, from license scanning tools or other references like that. For projects that use the 3.0 version, I didn't find a lot:

• @ghuntley projects, as already mentioned
• a couple projects by this person https://github.com/frkl-io/bring/blob/develop/LICENSE
• https://github.com/Massi-X/freepbx-phonemiddleware/blob/fae2d8a5fda1cab606add3de8bdf1698ee65c113/README.md
• https://github.com/zinc-collective/compensated/blob/a961881fb167f066eb82a790561f85a29d3aa9e1/compensated-proxy/compensated-proxy.gemspec (I think?)
• https://github.com/SmartAudioTools/serializejson

4. license is primarily intended for free distribution of content (including, in the case of software, its source code) with limited restrictions, and meets other factors listed here - the main restriction is non-commercial use for no more than 30 days, which I suppose is limited, but as to whether it meets the other factors here, see 3 (always the tough factor)

[jlovejoy]

unrelated to inclusion analysis - @ghuntley - not sure why you thumbs-downed @seabass-labrax comment re: use of LicenseRef- as recognized by SPDX where there is not an SPDX License List identifier. This is correct (I have used it myself in code for a license not on the SPDX License List!) "Proprietary" is not recognized in SPDX. I know, I know, you may be just using the SPDX License List and are not creating a full SPDX document, but that doesn't mean other downstream users won't be. The license fields information in the SPDX are still relevant to use of the SPDX License List, so it'd be nice if you could use the method provided :) (unless/until the relevant license is added to the SPDX License List)

[jlovejoy]

one more comment re: use - it seems like the 2.0 version has the most uptake (I didn't count, but that's the impression I got while flipping through pages of files)
@kemitchell - do you have a take on that?

[ghuntley]

Adding more context to 3. because it's a biggie: https://www.theregister.com/2019/05/23/github_acquires_dependabot_to_automate_open_source_bug_zapping_chucks_money_at_developers/ https://docs.github.com/en/code-security/supply-chain-security/configuring-dependabot-security-updates Finally https://github.com/dependabot/dependabot-core a. Prosperity is a core feature that enabled the founders to create an open community where people could see code and contribute fixes which in return the service helps the contributors/community through the service. b. Prosperity enabled a path for founders for their exit. c. Prosperity enabled the creation of a form of an open community (viewing of source code, people can fix their own issues/contribute them back) that isn't possible under any other license currently. d. Prosperity enables GitHub to continue the original open community recipe, invest into their product features whilst preventing competitors from piggybacking off the investment. What I'm getting at — this is a new class of license, that is pro-community, pro-access to source code, pro-contribution and is financially sustainable. It does not meet the OSD definition but not every license should. Licenses in the category of OSD are financially unsustainable by design.

[jlovejoy]

#1368 has now been opened, so we can re-invigorate the discussion there in relation to the license inclusion guidelines for the SPDX License List and clarify the version 2.0 or 3.0 question and usage.
Note - opinions of business sustainability as related to choice of license are not relevant to inclusion on the SPDX License List :)

On 12/23 call, we remembered we had a analysis for the collection of Polyform licenses (tl;dr - we added some but not all), so we should ensure we are consistent with the decisions there

[kemitchell]

@jlovejoy, why was this closed? #1368 may be unclear or abandoned, but this #960 is unambiguous and ready to merge.

You mentioned the difference of free trial off in #1368. Prosperity 3 isn't a free-trial license. It's a noncommercial license plus a free trial. More permissive than PolyForm Noncommercial.

[ghuntley]

@jlovejoy, why was this closed? #1368 may be unclear or abandoned, but this #960 is unambiguous and ready to merge.

👍

[jlovejoy]

whether it's a PR or an issue - it was for the same license, so the various comments as to the decision were made in one place with a pointer (to here). Please remember, it's not one person making the call and there had already been much discussion (and procrastination) on a decision.

[kemitchell]

Please try to understand how frustrating this is on our end. I've got multiple side messages reading this as underhanded. I don't see it that way, but I see how they do.

I read the note before Christmas last year about discussion moving to #1368. #1368 was opened two years after this PR, for a superseded version of the license, with no follow-up to your question about which version was intended. Still, whatever works. I subscribed to #1368. But no discussion there ensued. Crickets.

A few days ago, I saw a comment summarizing a call I didn't know I should be on, making points I'd been happy to talk through, tagging Not Accepted before I had a chance to respond. This PR got tagged and closed likewise, without further comment.

If calls are mandatory, or discussion will no longer take place in this PR or on GitHub more generally, please let me know. Anyone can reach me at kyle@kemitchell.com anytime.

As for substance, this license apes Blue Oak 1.0.0 in style and a combo of PolyForm Noncommercial and Free Trial in substance. It's a noncommercial software license, plus a built-in free trial for commercial use, which it turns out go together like burgers and fries. It also adds permission for developing contributions back to the project, to make sure that's clearly welcome, even in otherwise commercial context.

Apart from Free Trial, which derives from PolyForm Free Trial, and Contributions Back, which is new, no language here is unknown to the license list. Quick diffs against BlueOak-1.0.0 and PolyForm-Noncommercial-1.0.0 show the family resemblance.

I don't understand the hold-up on the merge, other than as reflecting out-of-process pushback from those who don't like non-comm licenses, wish the inclusion principles excluded them, and regret that SPDX has accepted them. If that's new SPDX policy, please announce it clearly, so especially package manager developers know what process they're incorporating by reference.

[jlovejoy]

In case it wasn't absolutely clear, the main reason for not accepting this license (at this time) is the fact of lack of substantial use, in addition to the other factors as noted regarding the SPDX inclusion guidelines which we endeavor to apply equally to all submitted licenses.

There was nothing that was done out-of-process or without fidelity to the SPDX inclusion guidelines. Unfounded accusations otherwise are not appropriate.

If in the future this license has additional substantial use we would welcome your re-submission of this license.

[kemitchell]

@jlovejoy, the idea that there's a main reason, and that it's now substantial use, wasn't absolutely clear. This is the first we're reading that here on GitHub.

Hence the process question: Are we doing this on GitHub, or is the real deal all on calls, with GitHub just for announcing call decisions?

This #960 has several people linking to substantial projects and mentioning use of the license for their own work. Quick searches on GitHub or libraries.io show more.

Please understand that from our point of view, this feels like the goalposts getting moved again. And it's not clear even where they stand now. What's substantial use?

All this---more than two years---to put an XML file in a GitHub repo. I could add Parity-7.0.0 to the list for npm in thirty seconds. No controversy.

[swinslow]

The basis for evaluating what licenses to add to the SPDX License List are described here: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md

@jlovejoy provided a writeup of her take on applying the principles to this submission in this thread, in May 2021: #960 (comment). Lack of substantial use was described there as of that point in time. Although I wasn't on the team call where this one was more recently discussed, I gather there hasn't been further examples of usage of the 3.0.0 version of the license provided either here or in the issue that was filed subsequently.

We discussed substantial use's relevance as a factor in 2020 at #925 when the updated license inclusion principles were being put together. That thread includes discussion (and at least my own views) on the ways that, in analyzing the "Other Factors" from the inclusion principles, (i) a higher degree of real-world usage is required to be demonstrated for non-FOSS licenses; and (ii) we haven't see a meaningful way to come up with a strict "use in the wild means exactly X projects must be using the license" definition.

Regarding process:

• We try to work in GitHub Issues (not PRs) as much as possible. Generally we look at Issues for evaluating whether to add a requested new license; and then the PR is created if/when it is approved to be added.
• We have a limited number of volunteers who regularly participate in analyzing submissions under the license inclusion principles within the GitHub Issue threads.
• Because of that, parts of the biweekly calls end up being a chance to go through a few of the pending Issues and try to reach consensus among participants.
• If there are more volunteers who participate in discussions within the GitHub Issue threads between calls, then we can do more work that way. None of us are paid for this, so we're all participating the best as we can!

On that last point, I'd ask if we could please all work to presume good faith in our participation on these issues. There will of course be disagreements on outcomes, but at least speaking for myself I'm endeavoring to presume that everyone involved is acting in good faith towards SPDX's goals and purposes.

As @jlovejoy indicated, if this license has relevant additional substantial use then we would welcome your re-submission of this license, and we will re-evaluate it under the license inclusion principles.

[kemitchell]

@swinslow can you confirm?:

• Apart from "substantial use", there are no remaining blockers under the inclusion principles for this license.

• There isn't any further guidance on what counts as "substantial".

[jeffwidman]

👋 Hi from the Dependabot team.

I was trying to use the SPDX identifier for the Prosperity license that we use, and stumbled across this thread. I find it surprising the license wasn't accepted, at least for the 2.0.0 variant (which I realize probably requires a separate issue/PR than the 3.0.0 variant).

We'd happily start using the SPDX identifier, but until then we're stuck with some hacks:

• Add license to image and gemspec dependabot/dependabot-core#4317
• https://github.com/dependabot/dependabot-core/actions/runs/3049309247/jobs/4915246993#step:6:175
• https://github.com/dependabot/dependabot-core/pull/5716/files#r971615111

We've had discussions about changing to a more popular license, but currently for our use case the Prosperity license is the best fit.

[donmccurdy]

Hi – another open source maintainer here! I'd like use Prosperity-3.0.0 for appropriate projects, preferably without tripping alarms in the npm infrastructure.

Because the blocker appears to be an unspecified threshold of "substantial use", here's some context. Open source packages I personally build and maintain are downloaded from the NPM repository >3 million times per month. Nearly all of these are under permissive licenses like MIT or Apache-2.0, of course, but I have reasons for needing more restrictive licenses in certain packages.

The number of licenses suitable for supporting independent developers is diminishingly small. If it would not be a dramatic technical or procedural burden on the SPDX maintainers to make a few such licenses machine-readable with SPDX, I hope you'll reconsider adding Prosperity Public License 3.0.0 to the registry.

[ghuntley]

Adding my vote for this to be reconsidered.

[jlovejoy]

if you want to request a license be added to the SPDX License List, please follow the process as described here: https://github.com/spdx/license-list-XML/blob/main/DOCS/request-new-license.md
Keep in mind, since this license was already considered at length, you will need to consider how it objectively meets the inclusion principles (now, e.g., what has changed to justify re-consideration)

commenting on closed issues, is not likely to be easily seen :)

[toastal]

I wanted to follow the Handling License Info guide for some software I’m writing as it is concise & easy for other folks to understand the identifiers, however, Prosperity is missing so I can’t technically use SPDX-License-Identifier: Prosperity-3.0.0 as there is no mapping to a license in the the SPDX XML. I can still mark it with Nix’s license scheme, but the identifier in the code I cannot do.