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 (#3315): https://lists.spdx.org/g/Spdx-legal/message/3315 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] -=-=-=-=-=-=-=-=-=-=-=-
