Could this be a working group?

On 12/19/2013 10:03 AM, Simon Phipps wrote:
This sounds useful and I'd support the idea if a group were willing to make it happen. I suggest a staged implementation with the "Popular Licenses" being made available first and the others set up to return a placeholder message or error.


On Thu, Dec 19, 2013 at 2:07 AM, Joe Murray <joe.mur...@jmaconsulting.biz <mailto:joe.mur...@jmaconsulting.biz>> wrote:

    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 <http://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
    <http://civicrm.org/> and provide auto-download services for via
    civicrm.org <http://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 <http://civicrm.org/> listed
    extensions were hosted on drupal.org <http://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
    <http://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 <http://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.org
    <http://opensource.org> were 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.mur...@jmaconsulting.biz <mailto:joe.mur...@jmaconsulting.biz>
    skype JosephPMurray twitter JoeMurray
    416.466.1281 <tel:416.466.1281>

    _______________________________________________
    Infrastructure mailing list
    infrastruct...@opensource.org <mailto:infrastruct...@opensource.org>
    http://projects.opensource.org/cgi-bin/mailman/listinfo/infrastructure




--
*Simon Phipps* http://webmink.com <http://webmink.com/>
/*Meshed Insights Ltd* /
/Office:/ +1 (415) 683-7660 /or/ +44 (238) 098 7027
/Mobile/:  +44 774 776 2816/
/



_______________________________________________
Infrastructure mailing list
infrastruct...@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/infrastructure

--
    ||    |      |  ||||    ||    ||    |  ||||    |||    | |||
Patrick Masson
General Manager, Director & Secretary to the Board
Open Source Initiative
855 El Camino Real, Ste 13A, #270
Palo Alto, CA 94301
United States
Skype: massonpj
sip: osi-mas...@ekiga.net
Ph: (970) 4MASSON
Em: mass...@opensource.org <mailto:mas...@opensource.org>
Ws: www.opensource.org <http://www.opensource.org>
_______________________________________________
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Reply via email to