On Tue, Jan 24, 2023 at 10:56 PM J Lovejoy <opensou...@jilayne.com> 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@lists.spdx.org <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> <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 (#3311): https://lists.spdx.org/g/Spdx-legal/message/3311 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] -=-=-=-=-=-=-=-=-=-=-=-
