W. Trevor King wrote: > I am against this in license-list-XML, for the same reasons I am > against our current osi-approved type: SPDX should not be a > canonical source of whether *someone else* has approved a license or > not. I'd much rather provide tools for Alice to start with an SDPX > ID and lookup Bob's notes for a given license. More on this in [1]. > > I think the FSF should provide a similar API to expose its > license-categorization information in a structured way. Then we can > include FSF IDs in our license metadata (ideally generated through > automated matching [4]) and/or they can provide SPDX IDs in their > license metadata. User agents could ask the FSF if they consider a > license GPL-compatible, GPL-incompatible, free, non-free, > for-a-viewpoint, etc., etc. [5] in a machine-readable way.
By the bye, one thing I'd find useful, either inside or outside of SPDX, is some notion of correspondence of an FSF-approved license with a counterpart OSI-approved, or SPDX-recognized, license. To illustrate, consider the MIT license. There is no MIT license steward; the de facto standard text (basically for historical reasons) is that on the OSI website, https://opensource.org/licenses/MIT The FSF speaks of a license it calls the X11 license as being a free software license and says that this is sometimes called the MIT license (a label the FSF has long considered confusing or misleading). However, the license pointed to by the FSF is not textually identical to the OSI MIT license and also does not match the SPDX license "MIT", but does match the SPDX license "X11". Today one can't justifiably say that the FSF and the OSI both approve the MIT license as meeting the respective definitional licensing norms of those organizations, even though everyone *knows* that's true. Richard _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
