[License-discuss] Machine readable source of OSI approved licenses?

[Joe Murray]

Would it be possible for OSI to make available a machine readable list of
the licenses approved by OSI? The format - a csv, xml or some other file in
a repository, or a REST or some other service from opensource.org - is not
as important as that the content be authoritative. There may be an official
specification for how software licenses should be made available, but I am
not aware of it. http://spdx.org/licenses/ provides a list of licenses but
it too is not designed for automated use (though it might be scrapable).
Ideally, it seems like the recognition of licenses by OSI should produce
some output that could be used by SPDX tools, but this request is a bit
simpler.

Background:
CiviCRM would like the set of licenses in this form in order to ensure that
any extensions that we list on civicrm.org and provide auto-download
services for via civicrm.org are using licenses approved by OSI. However,
the request seems of broader interest. Karl Fogel suggested I pose it to
these two lists.

CiviCRM decided to try to up its game with respect to licensing of its
extensions partly as a result of someone coming across
http://www.zdnet.com/github-improves-open-source-licensing-polices-7000018213/.
While early on most civicrm.org listed extensions were hosted on drupal.org and
thus were guaranteed to have a GPL license, now most of our new listings
are for software on github. CiviCRM would also like to 'assist' extension
developers in actually including an accurate license text file in their
extension by checking it is present in the extension's root directory and
that its text matches what they are listing as the license. I've been asked
to liaise with OSI on the availability of such a machine readable list of
these licenses.

Possible implementation strategy:
If OSI decides it would like to do this, it may be technically as simple as
copying the licenses on opensource.org from one type of node to another,
then doing a bit of cleanup to support some requirements for automated use.
Looking at opensource.org, I see a content type was at some point created
specifically for licenses, though no content has been posted of that type,
and all the licenses are currently created as nodes with content type=page.

In terms of fields for automated use, it would be useful to move the short
title into its own field rather than having it in parentheses at the end of
the long title, and to make a plain text version of licenses suitable for
inclusion as a LICENSE.txt file in source code available in addition to the
current html formatted ones. If the approved licenses on
opensource.orgwere put into suitable content types, they could easily
be made available
as a feed or exported periodically to a file that could be stored in an
authoritative repository.

I am also trying to understand the proper way to handle headers in license
files, particularly for the small number of cases where they make a
difference, eg GPL-3.0 versus GPL-3.0+ (see
http://opensource.org/licenses/gpl-3.0.html#howto, and the differences
between the 'How to Apply These Terms to Your New Programs' sections of
http://spdx.org/licenses/GPL-3.0 and http://spdx.org/licenses/GPL-3.0+).
This seems like something we want to assist developers in getting right by
using reasonable defaults. One possibility we are mulling over is
optionally automating the creation of a LICENSE.txt file using metadata
about the Author, publication date, and license and suggesting that authors
use that file in their repo or request a manual review of their
LICENSE.txt. It would be convenient if suggested header text for licenses
was made available in machine readable form from OSI, including for the
differences between 'version x only' and 'version x or later' headers.

I am willing to volunteer with doing some of the implementation work if a
decision is made to provide this new service.

Joe Murray, PhD
President, JMA Consulting
joe.murray at jmaconsulting.biz
skype JosephPMurray twitter JoeMurray
416.466.1281
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20131218/075090e7/attachment.html>