Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rufuspollock opened this issue Dec 3, 2012 · 14 comments
Assignees

Comments

@rufuspollock
Copy link
Member

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
Copy link
Contributor

mlinksva commented Jun 4, 2013

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

@mlinksva mlinksva closed this as completed Jun 4, 2013
@rufuspollock rufuspollock reopened this Jun 14, 2013
@rufuspollock
Copy link
Member Author

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

@rufuspollock
Copy link
Member Author

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

@rufuspollock
Copy link
Member Author

Much of relevant discussion on this is in #27

@rufuspollock
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

@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
Copy link
Member Author

updated description with current proposal as to what happens

@Stephen-Gates
Copy link
Contributor

Stephen-Gates commented Jul 17, 2017

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:

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

@rufuspollock
Copy link
Member Author

@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
Copy link
Contributor

Ok I'll look into it over the weekend

@Stephen-Gates
Copy link
Contributor

Stephen-Gates commented Nov 9, 2017

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

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
Copy link
Contributor

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants