Thanks all for your comments in this thread. I'm not going to try to reply
here to every comment, but wanted to note a few pieces that might be
informative to folks who are less deep in the SPDX license ID weeds.
*Custom license IDs*:
Anyone who wants to use an SPDX-format-compatible license ID for a license
that isn't on the license list is able to do so, via the LicenseRef-
syntax. [1] The characters for the ID are the same as those permitted for
IDs on the SPDX License List: letters, digits, hyphen ("-") and period
("."). [2]
*Making reusable custom license IDs*:
If someone wanted to create a standalone, reusable LicenseRef- ID that
implemented a UUID, or a hash of a license text, I believe they could do so
just by prepending "LicenseRef-" to the UUID or hash. I suspect there are
some automated tools out there that work in this manner. (Of course, it's
not going to be a particularly meaningful ID on its own, but just noting it
since UUIDs were mentioned in the thread.)
The challenge with using LicenseRef-, of course, is in letting people know
which license text corresponds to your custom license ID. There are various
ways to do this without ever talking to anyone at SPDX, including by
creating your own SPDX document that defines it in an "Other License
Information" section, or by following practices such as REUSE. [3]
For an approach that could enable anyone to create more meaningful custom
IDs and share the corresponding license text, we've had discussions several
times over the past 4+ years about creating a formalized "license
namespace" format, built on top of the existing LicenseRef- syntax. This
has repeatedly failed to reach consensus, in my view primarily due to
disagreements about the nuances of what the syntax should look like, and I
don't think there's any appetite to reopen that discussion yet again.
As a result, community members are welcome to establish informal practices
for how they format LicenseRef- IDs within the permitted syntax and how
they share the corresponding license text, such as via REUSE.
*Standards for what goes on the SPDX License List*:
I agree with Richard that the documentation should be clearer about
"vanity" licenses generally being inappropriate for inclusion on the SPDX
License List.
I think there is value in the license list *not* being just a hash of
license IDs to arbitrary text. The work that the SPDX Legal community does
to review and curate licenses, insert markup to group them together where
appropriate, and omit licenses that are not likely to be encountered in
FOSS(-ish) development, seems to be of value to downstream users of the
list. If it isn't, and if downstream users do in fact want a list that is
just a hash of unique IDs to arbitrary text, then anyone is of course free
to implement such a list and to persuade the broader ecosystem to adopt it.
For newly-drafted licenses that are used in only one or a couple of
projects (or sometimes zero projects), I agree with Richard that we often
burn lots of cycles going back and forth with the license author without
real benefit. I'd be in favor of bumping the "substantial use" factor
higher on the License Inclusion Principles list [4]. And perhaps being more
explicit in related documentation about the likelihood that vanity licenses
with little usage, particularly non-FOSS licenses that fall in that
category are highly unlikely to be added to the list. For a change to the
inclusion principles, as Jilayne mentioned earlier I do think that a Change
Proposal [5] is probably the right place to discuss the specifics of what
that would look like.
Submitters of newly-drafted licenses with little-to-no usage do sometimes
mention that they need their license to be added to the SPDX License List
so that their software with their new license can be included in a package
manager. For package managers that use license list IDs as a requirement,
I'd encourage them to consider implementing and permitting LicenseRef- IDs
as well. (Or, if they don't want to permit LicenseRef- IDs, then that
suggests to me that they are in fact finding some value in the curation
that we perform for the License List.)
And of course, to James's point: if a brand new license does see
significant usage in the wild such that it is likely to be encountered in a
broad set of community-developed software projects, then at that point it
may be appropriate to add to the list. But I don't see value in having the
SPDX License List be the first stop for a newly-drafted, non-FOSS license
that is used in someone's personal project, or in having us burn cycles
repeatedly explaining that.
Steve
[1] LicenseRef- syntax: see
https://spdx.github.io/spdx-spec/v2.3/using-SPDX-short-identifiers-in-source-files/
and
https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/
[2] idstring format:
https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
[3] REUSE: https://reuse.software/spec/#license-files
[4] License Inclusion Principles:
https://github.com/spdx/license-list-XML/blob/main/DOCS/license-inclusion-principles.md
[5] Change Proposals: https://github.com/spdx/change-proposal
On Wed, Jan 25, 2023 at 1:14 PM Kyle Mitchell <k...@kemitchell.com> wrote:
> 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
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3316): https://lists.spdx.org/g/Spdx-legal/message/3316
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]
-=-=-=-=-=-=-=-=-=-=-=-
