Merge https://github.com/okfn/licenses with this repo ...

[rufuspollock]

Update. April 2015

• We probably aren't going to actually merge licenses repo itself.
• What we do want to do is merge the API / UI from licenses repo / licenses.opendefinition.org to here
  • though even here there is an argument to leave stuff in licenses and migrate web stuff to gh-pages
• licenses repo will then slim down to being data only

TODO: work out what we to migrate here and what not

Original proposal

Source https://github.com/okfn/licenses

Merge process:

• licenses => api/1/
• bin/ => scripts/
• js + index.html => api/

[mlinksva]

I'm not sure the utility of this. licenses.opendefinition.org and opendefinition.org are served by different technologies (? and wordpress). Seems fine to have separate repos modulo any bigger reorg. Closing for now, would be part of bigger reorg open in #5

[rufuspollock]

At AC call we agreed to proceed with this. Basic approach in description above.

[rufuspollock]

I wonder whether we want to deploy at api.opendefinition.org given that existing site will remain on wordpress for forseeable future ...

[rufuspollock]

Much of relevant discussion on this is in #27

[rufuspollock]

Moving thread here from #27 (comment)

@mlinksva so I think we probably do want to get rid of the html stuff at licenses.opendefinition.org and if we do have the API we may as well have it here (even if we submodule in ...)

So, next steps:

• Strip down licenses repo to be bare bones
  • Do we still include all the jsonp stuff? Seems like we should to keep it simple but we then either won't have jsonp support here (not the end of the world) or would have to fake it here which seems a bit of a PITA (but not the end of the world). @mlinksva thoughts?
• Submodule it here somewhere nice e.g. api/v1/... or something
  • Beauty here is we can submodule the same repo at different revisions multiple times to do versioning :-)
• Redirect licenses

Questions:

• Do we still want the nice "home page" for the API
• Do we still want the nice license listing?

The proposed API

opendefinition.org/api/v1/{license-id}.json
# groups stuff
# this is one option
opendefinition.org/api/v1/all.json
# alternative is to follow existing practice on licenses.opendefinition.org
opendefinition.org/api/v1/groups/all.json

[mlinksva]

Is there any need for jsonp? If not, scrap.

What is the point of json files by group? Seems that any client can fetch all.json and filter on whatever properties they wish to. Another alternative is

/api/v1/license/{license-id}.json
/api/vi/all.json

I don't know if there's any need for a HTML frontend. Currently licenses.opendefinition.org serves as documentation and a kind of quasi-chooser. Desired? Or maybe people should be looking at opendefinition.org/licenses as the ... one place to look. No strong opinion.

[rufuspollock]

@mlinksva

• jsonp - it means browser clients can load. I don't know use / need so i guess we scrap for present based on KISS
• Re groups: guess we could drop though certainly getting all in one is sort of useful ... (or alternatively being all to find a list of all the other files).

[rufuspollock]

updated description with current proposal as to what happens

[Stephen-Gates]

Can I suggest a simple solution to provide a machine-readable list of open licences and urls as this issue seems stalled...

Publish the licences as a CSV by OKI on datahub.io. If it's published as a CSV, then an API is generated.

In fact, unmaintained versions are:

• published as JSON on datahub.io
• and also on GitHub https://github.com/okfn/licenses

@rufuspollock @mlinksva
So if I fixed this, what's the true data source and preferred destination? Would you like me to proceed?

[rufuspollock]

@Stephen-Gates basically yes! The main thing to complete actually right now is okfn/licenses#45 - let's get the licenses repo fixed and then we can publish straight into datahub.io as you suggest.

[Stephen-Gates]

Ok I'll look into it over the weekend

[Stephen-Gates]

So we now have an up-to-date licenses.csv and datapackage.json being checked by goodtables.

To nudge this work (and the related issue) along, here's my suggestion...

Open Licenses Service

• becomes an exemplar data package:
  • licenses.csv (continuously validated)
  • datapackage.json (follows versioning pattern)
  • readme.md
• contains scripts to:
  • keep licenses.csv up-to-date
  • convert licenses.csv to multiple formats (json, jsonp, rdf) and into groups if required to avoid breaking changes
  • publish the data package to datahub.io
• has a githhub readme focused on using the data
• full set of community files to assist with contributions
• all other content removed

Open Definition site

• Licence approval process is updated to reflect that licenses.csv is updated as a result of the review process
• Filtered views of licenses.csv are shown on :
  • Recommended conformant licenses
  • Other conformant licenses
  • Non-conformant Licenses

This would result in some loss of information e.g. the BY, SA and Comments columns in the existing tables. This may result in adding columns to licences.csv.

Licences.csv changes

Consider changes to licenses.csv to:

• Add BY, SA and Comments columns from the existing tables in Open Definition.
• Add icon attribute to licenses #5
• Add uri to licenses #6
• define the family field, and the similar licenses #54
• Add a description for each field in the datapackage.json schema #64

but be careful to communicate, or avoid, breaking changes.

Next Steps

• determine what changes are required to support presenting filtered views of licenses.csv on the Open Definition site (consider data package views)
• make those changes
• update the Open Definition site
• consider the remaining suggestions

Thoughts?

[mlinksva]

I'd rather have the data package derived from:

1. SPDX (this is where the most concentrated effort to curate info about licenses is, a shame to not leverage that)
2. Open Definition (adding individual license records as Jekyll collection there would be one way to do it; I feel that we need to uplevel documentation around approval and making a CSV canonical would go opposite direction)
3. Wikidata

Derived probably means a script to collect info from those sources and shove into a CSV or whatever data packages want.

That said feel free to proceed as I don't know when I'll get around to fleshing out above.

[rufuspollock]

@mlinksva @Stephen-Gates this sounds good - i'm happy for Stephen to proceed with Mike's guidance.