On Tue, Jan 24, 2023 at 10:56 PM J Lovejoy <opensource@...> wrote:

Thanks for this write-up, Richard.

Having spent an exorbitant amount of my time over the years of my involvement in SPDX trying to politely say "no" to licenses for the reasons you describe below, I cannot begin to express how much I would welcome a way to make that easier and quicker.

(That is not to say that we should not be polite! I take a lot of joy in the congeniality of the SPDX-legal community - it's a big part of what keeps me around :)

This reminds me that I think I had submitted a PR when we were working on our "documentation release" to swap factors #2 and #3, as it seemed like the substantial use factor should be higher up the list. I think we may have even discussed this on a call. But changing the inclusion guidelines (even ordering) is a big deal and Steve reminded me that is more apt for a formal Change Proposal or its own discussion.

https://github.com/spdx/license-list-XML/blob/main/DOCS/license-inclusion-principles.md
Looking again now at how the factors are organized - we could probably do a bit better on the "ordering" and grouping than simply swapping 2 and 3. Some of the "definitive" factors aren't really factors. For example, A and D are more of threshold questions; and B is more of a policy that we always have had, but never wrote down anywhere. E is important, but not sure it's definitive (it's also a bit of a warning). Anyway, if someone wants to put some more "definitive" suggestions on paper (the Change Proposal format would be useful here, I think) that would be great. (I would, but I'm up to my ears in other things, so I won't get to it for a bit.)

D had always bothered me a little, but mostly in the context of historically preserved licenses. The BSD, CMU and MIT license families have undergone a fair amount of copying with errors and mutation. Some of the errors and mutations are harmless, while others deserve their own license (and some are downright weird and/or require understanding the context of the changes rather than just the plain language of the change).

I've also struggled with the right way to codify these things. Richard has been fighting the good fight with the whack-a-mole-esque task of finding all the variants that survived in packages long enough to worm their way into Debian. I believe that FreeBSD has dozens of such variations that I've not even begun to sort through. I'd like to hope that if I ever did, and a good way to bucket the ones with significant differences were found, that they could be included, even though they are in some ways similar to vanity licenses, though without the full-blown fanfare some of the others have. They are historically persisting licenses from a by-gone era when license standardization hadn't happened... I see that in 'other factors' the wide-spread use of factor 3. Given the scope of the problem, I'm not at all sure how best to solve it.

I hope that any tightening of the stable texts and other guidelines designed to sweep away many vanity licenses won't sweep these historical artifacts up as well. I broadly support limiting vanity licenses because they cause nothing but grief, on the average, and rarely wind up with something good and useful that pushes the state of the art. They just add to the churn and chores of license compliance w/o offering the authors using them any better protection than other licenses, nor eased compliance burdens since they are off the 'paved path' of old standards like BSD, GPL, MIT, Apache, etc.

Warner

 

Thanks,
Jilayne

On 1/24/23 5:07 PM, Ria Schalnat (HPE) wrote:

+1 to Richard!

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Richard Fontana
Sent: Tuesday, January 24, 2023 3:30 PM
To: SPDX-legal <spdx-legal@...>
Subject: SPDX should take a stronger stance against vanity/promotional licenses

As I've been following the issue queue for github.com/spdx/license-list-XML/issues over the past several months, it seems to me that you get a significant number of license submissions like this latest one:
https://github.com/spdx/license-list-XML/issues/1790

The pattern is, someone has drafted their own license, it either isn't being used at all in the real world or it is being used for a few insignificant projects of the license author. In some cases the license seems to be connected to some contemplated commercial activity of the license submitter. Presumably SPDX license list inclusion is seen as a way of legitimizing or popularizing the novel license. I am quite familiar with this sort of phenomenon from my past involvement with the OSI, where the nature of the OSI process as it was historically defined seemed to unintentionally result in many license submissions of this sort.

When I look at the SPDX license inclusion guidelines, I am concerned that this sort of behavior is not sufficiently discouraged. The guidelines say "The license has actual, substantial use such that it is likely to be encountered. Substantial use may be demonstrated via use in many projects, or in one or a few significant projects. For new licenses, there are definitive plans for the license to be used in one or a few significant projects."
But this is not one of the "definitive" factors and it is the third of a list of non-definitive factors that are given "roughly in order of importance". Someone might understandably conclude that "substantial use" isn't too important to SPDX.

My main criticism of the SPDX license list from years ago was that it was not representative of the makeup of the FOSS project world that I was seeing in Linux distribution packages and other software I encountered in my work. I have been engaged in trying to get the SPDX license list to more accurately reflect the state of widely-used FOSS today and it is frustrating to see repeated examples of vanity license submissions. I suggest that the license inclusion principles should be revised to elevate and perhaps strengthen the "substantial use"
requirement and the maintainers of license-list-XML should more actively make clear that such licenses are generally inappropriate for the SPDX license list.

Richard

If the idea is really to hunt down every license lurking in
every potentially popular public package, I can see how
distro adoption's a real big deal. Congrats! I worry about
more work for distro people, but suppose those chasing
completeness goals like this likely have financial support.

On the process front, three ideas:

First, separate processes for "I've got a license and
champion its identification" from "I spotted a license and
think SPDX may not have it already". Create a separate
intake track for the latter, I imagine often distro people.
This would unburden those submitting just to replace
exceptions with IDs someday. They may otherwise have nothing
to say about terms, beyond what the words are and where they
found them. Put their "sightings" in a separate queue and
let people who care take them up for full submission. Those
can be people more invested in process and criteria.

Second, seriously consider requiring only text for
submissions up front, with XML coding if and when the
license moves forward. Grokking the schema and overcoming
validation errors takes time, even for the XML-astute. I see
the benefits for the tech team in the end. I also see
temptation to use the burden as a general brake on
submissions, or as a backhand "do you really care?" test.
But I don't see XML mattering to the identification
question. It becomes worthwhile only once a license gets
voted in. At that point, well versed SPDX people may be more
inclined to do in five what can take new people an hour.

Third, create a new "provisional" license status and
identify licenses awaiting significance there. Essentially
let folks call dibs on IDs. Supplement with a guideline on
to prefer prefixes like `Apache` to collision-prone
initialisms like `APSL`. Publish the list JSON with a
provisional flag, so implementers can then decide whether to
validate provisionals or not, like they choose for
deprecated. Give provisionals a holding period, say a couple
years, then either promote or deprecate. Think Lanham Act
supplemental register for lawyers, merge-behind-feature-flag
for coders.

On a personal note, I hope I can be honest about my
motivation without coming over blunt. I'm not in
license-list-XML helping clear backlog, even though I
maintain several projects using IDs, because I'm not
interested in a process that I _do_ see as passing
judgments, "approving" more than merely identifying. The
very thrust of this e-mail chain is more effectively shooing
away drafters deemed vain and projects deemed insubstantial.
Those are value judgments.

Value judgments make assessments eat more time. They open
them to controversy. They ask more of reviewers, which
contributes to backlog. I wouldn't expect reordering factors
in the factor test to change that.

If SPDX doesn't want to identify new licenses it doesn't
like, or wants to use its adoption as leverage to discourage
new forms, it should come out and say that. Those of us
building with broader needs can fork or superset.

--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933