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.)
Thanks,
Jilayne
On 1/24/23 5:07 PM, Ria Schalnat (HPE) wrote:
+1 to Richard!
-----Original Message-----
From:Spdx-legal@lists.spdx.org <Spdx-legal@lists.spdx.org> On Behalf Of
Richard Fontana
Sent: Tuesday, January 24, 2023 3:30 PM
To: SPDX-legal<spdx-legal@lists.spdx.org>
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3309): https://lists.spdx.org/g/Spdx-legal/message/3309
Mute This Topic: https://lists.spdx.org/mt/96510436/21656
Group Owner: spdx-legal+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
