On Fri, Oct 13, 2017 at 02:30:18PM -0400, Richard Fontana wrote: > 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
I agree, and think the best way to maintain that sort of information is with automated SPDX license matching [1]. Then, everyone with license opinions (the OSI, FSF, etc.) publishes a list of reviewed license IDs (using SPDX IDs or their own custom IDs, e.g. [2]): $ curl -s https://api.opensource.org/licenses/ | jq '[.[] | .id]' [ "AAL", "AFL-3.0", "AGPL-3.0", … ] Then for each reviewed license, they provide a way to get the metadata. For example [3]: $ curl -s https://api.opensource.org/license/AAL | jq . { "id": "AAL", "identifiers": [ { "identifier": "AAL", "scheme": "SPDX" }, … ], … "text": [ { "media_type": "text/html", "title": "HTML", "url": "https://opensource.org/licenses/AAL"; } ] } And the text. The OSI doesn't have a good example of this at the moment; you'd have to scrape the wrapping markup off of [4]. Then you can use regular SPDX matching to determine the SPDX ID for the license in question to determine an objective (and verifiable) match (modulo wiggle room in the SPDX matching definition ;). Individual providers may suggest their own ID mappings (as in the OSI example above, where the OSI asserts their AAL license has the ‘AAL’ SPDX ID), and downstream consumers could either trust those mapping assertions, verify the asserted mapping, or come up with their own mapping. > 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". They also list the Expat license as free and GPL-compatible [5], and it matches the SPDX MIT [6]. So you can say the FSF considers the SPDX MIT free and GPL-compatible. On Fri, Oct 13, 2017 at 01:09:43PM -0600, J Lovejoy wrote: > On Oct 13, 2017, at 12:02 PM, W. Trevor King wrote: > > On Fri, Oct 13, 2017 at 10:20:33AM -0700, Gary O'Neall wrote: > >> There is a request by the FSF and approved by the legal team to > >> add a property to the listed licenses isFsfFree to indicate if a > >> license is identified by the Free Software Foundation as a Free / > >> Libre license. This would be a simple Boolean type. > > > > 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]. > > This is not really a for or against issue :) > > It is something that has been asked for by the SPDX community (David > Wheeler, last person who asked) and discussed as something that > would be nice to have, but we’d need help from the FSF to organize > and maintain. Now that the FSF has asked for this directly, we are > adding it. SPDX is not claiming to be a canonical source here, just > reflect the same info found elsewhere. Given anyone will be able to > submit a pull request, the expectation once the initial work is > done, will be that the FSF will help keep this current if there are > changes. Right. I'm not calling for “never document this anywhere”. I'm calling for only documenting the OSI ID, FSF ID, etc. for each license in license-list-XML and maintaining those mappings with automated tooling. Then downstream resources built from license-list-XML (like license-list-data [7]) can bake in whatever OSI-provided and FSF-provided metadata they want for their consumer's convenience without worrying about maintaining it in license-list-XML. > As for the OSI information - this was decided to be included very > very early on (probably 2010, or 2011 - SPDX License List got going > in fall of 2010, if memory serves) and again as a joint decision > with the OSI. At that time, they did not have the API. Supporting existing users is important, which is why the old fields should stay in license-list-data. But nobody's relying on license-list-XML (yet), so we aren't constrained by backwards compat there. As long as we can recover the old information when compiling license-list-data (and I think we can), I don't see a backwards-compat issue. > if there is some improved way to get to the same end point (of > identifying on the SPDX license list, which licenses have been > OSI-approved), then we can look into that, but I’d think it’d take > some work from both SPDX and OSI to do so. I've been trying to provide some of that work ;). > This sounds like a nice idea… but we have to work with what we have > and FSF does not have such an API… But now they're asking for one. Can't we help them build one, instead of helping them stuff their metadata into our API? It seems like better separation of concerns that way. Cheers, Trevor [1]: https://github.com/spdx/license-list-XML/issues/418 [2]: https://github.com/OpenSourceOrg/api/blob/master/doc/endpoints.md#licenses [3]: https://github.com/OpenSourceOrg/api/blob/master/doc/endpoints.md#licenseid [4]: https://opensource.org/licenses/AAL [5]: https://www.gnu.org/licenses/license-list.html#Expat [6]: https://directory.fsf.org/wiki/License:Expat [7]: https://github.com/spdx/license-list-data -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spdx-tech mailing list Spdx-tech@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-tech
