Date 1 - 3 of 3
Providing access to FSF license metadata
W. Trevor King
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 ofI agree, and think the best way to maintain that sort of information
is with automated SPDX license matching . 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. ):
$ curl -s https://api.opensource.org/licenses/ | jq '[. | .id]'
Then for each reviewed license, they provide a way to get the
metadata. For example :
$ curl -s https://api.opensource.org/license/AAL | jq .
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 .
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
The FSF speaks of a license it calls the X11 license as being a freeThey also list the Expat license as free and GPL-compatible , and
it matches the SPDX MIT . 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:Right. I'm not calling for “never document this anywhere”. I'mOn Fri, Oct 13, 2017 at 10:20:33AM -0700, Gary O'Neall wrote:This is not really a for or against issue :)There is a request by the FSF and approved by the legal team toI am against this in license-list-XML, for the same reasons I am
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 ) 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 verySupporting 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
if there is some improved way to get to the same end point (ofI've been trying to provide some of that work ;).
This sounds like a nice idea… but we have to work with what we haveBut 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.
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
W. Trevor King wrote:
They also list the Expat license as free and GPL-compatible , andAh right - so not as interesting an example as others I was thinking
of. I've been thinking about this because there's been some interest
among the FSF and OSI in seeing where exactly the lists of
FSF-recognized-as-free and OSI-approved licenses disagree.
It's an accident of history that the Expat license text, rather than
the X11 license text, is what came to be known as the MIT license, I
toggle quoted message Show quoted text
-----Original Message-----Added an issue to the SPDX tools to generate the isOsiApproved flag based on the OSI provided API: https://github.com/spdx/tools/issues/111
|1 - 3 of 3|