William, Sorry to air-drop into this conversation. I've been lurking fairly reliably, but have been too slammed to keep an active voice in all the various places where people are typing.
Is there any kind of summary or similarly short, approachable artifact you could point me to for the current namespacing proposal? For reasons in line with a few of Philippe's comments, I'm interested to see what there is in terms of viability or outreach to the package manager implementers. The primary driver for SPDX identification requests in my nick of the woods has been people trying to put an SPDX identifier in a package manifest where one is required. RubyGems for Ruby. npm for JavaScript. Cargo for Rust. And so on. All of these projects use the license list, and just the license list, as a kind of "library", divorced from SPDX as a whole. npm and Cargo have also taken the expression syntax, or variations of it, but that's it. If the namespace proposal's too complex or esoteric, or too tightly coupled to the XML-file use case of SPDX, I'd fear divergence with the fast-moving packager and utility people, myself probably included. -- Kyle Mitchell, attorney // Oakland // (510) 712 - 0933 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2761): https://lists.spdx.org/g/Spdx-legal/message/2761 Mute This Topic: https://lists.spdx.org/mt/71910791/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
