Re: SPDX should take a stronger stance against vanity/promotional licenses

J Lovejoy

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.
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.)


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 over the past several months, it seems to me that you get a significant number of license submissions like this latest one:

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.


Join { to automatically receive all group messages.