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

Git repo usable as a submodule for open licenses and json in projects ... #27

Closed
rufuspollock opened this issue Oct 10, 2013 · 15 comments
Closed

Comments

@rufuspollock
Copy link
Member

Good idea from Mike Linksvayer on list

@mlinksva
Copy link
Contributor

This probably means a repository for license texts and a repository for json. Each could be included as needed by projects requiring them, using git submodule or git subtree, as desired.

Suggest license text repository might be a fork of http://git.spdx.org/license-list.git which already has lots of license texts, including many of interest here.

@rufuspollock
Copy link
Member Author

@mlinksva good point - I wonder if we should just use that repo but with our sublist of open definition ones (though we do have an issue of getting stuff upstream if we have new approved licenses).

@mlinksva
Copy link
Contributor

@rgrp I'm all for using the spdx repo, that is forking and treating as upstream. I suspect they'd be interested in at least some of the licenses we'd add. If agreed that's what we're doing, I can get on their list and tell them.

@rufuspollock
Copy link
Member Author

@mlinksva +1 - please go ahead and chat with them :-) To summarize as I'm understanding it:

  • Use spdx repo as authoratative upstream - we perhaps fork and aim to push everything upstream (we may not even need to fork in a perfect world)
  • We probably add (in a separate location e.g. this repo) a "list" json file or similar where we identify licenses from our spdx fork that are included on our site (allows us to add extra metadata like "its for data, its for content etc" without messing with original repo structure

@mlinksva
Copy link
Contributor

Ok, I'll get in touch with them. They keep license metadata in a spreadsheet (also in the repo) for better or worse; we'd almost certainly want a separate license metadata json file anyway.

@rufuspollock
Copy link
Member Author

@mlinksva any update here? Would love to get this moving - I have a use case right now in http://data.okfn.org/ for using a nice json file and/or submodule

@mlinksva
Copy link
Contributor

mlinksva commented Aug 6, 2014

In short no. Commented on frictionlessdata/frictionlessdata.io#55

@rufuspollock
Copy link
Member Author

@mlinksva thanks - do you think this issue is still worth moving on? If so, what are the steps needed to implement - maybe if we break down we can do one by one?

@rufuspollock
Copy link
Member Author

@mlinksva here are some thoughts. I think once we get it sorted it what we want implemented will be pretty simple ...

First pass suggestion as to what to do:

  • licenses-data repo - light-weight (potentially "submodule-able") git repo with "data" about licenses
    • list of licenses with e.g. identifier, "title", some attributes (that could be used to pull out e.g.
    • this would exclude the full-text of the licenses
    • this is very similar to data we
  • licenses text - repo of licenses text
  • API to access above (in particular licenses data)
    • for this i'm inclined to having api.opendefinition.org or opendefinition.org/api
    • either way this could be pretty similar to current licenses.opendefinition.org code but just submodule the other repos

Questions

  • Do we really want licenses-data repo separate from this one?
    • Yes: its simple, one thing for one purpose and easily reusable by others
    • No: useful to have everything here so we track stuff in one way
  • Do we want license-text repo separate from data repo
    • Yes: people just want simple data and want to do submodule (if no need for submodule we could just provide an API to grab this). Also licenses-list already exists and we can use that.
    • No: why keep 'em separate - they go together
  • Do we want license-text repo separate from this repo
    • See first question

This does seem a bit complex. What's the simplest thing possible? My guess would be that it would be:

  • Put everything in this repo
  • Adopt a structure like: /licenses/{license-id}/ and put everything inside here (tbc)
  • Do a bit of work on a simple DB of the licenses and API to complement this

User stories ...

Needs some work i think ;-) ..

As a Developer I want to quickly get a JSON file listing all or the main open-source licenses so that I can use them in my app

  • I want an Icon and simple title for the license as well as the stable identifier
  • I may want to know "family information" so I don't show the user 5 versions of the same basic license

As a Developer I want to quickly get a JSON file listing all or the main open data and open content licenses

As a User I want to get a stable url to a human viewable version of a license

@mlinksva
Copy link
Contributor

I think separate license metadata (json) and texts (the spdx repo) repos would be useful, at least to others.

I don't really have an opinion about location or uses of API; probably more user stories would help. To work forward incrementally, I'd say use /okfn/licenses to develop API, whatever URL it would ideally live at.

@rufuspollock
Copy link
Member Author

@mlinksva sounds good.

@rufuspollock
Copy link
Member Author

Moving discussion on merge / reuse of licenses repo to #7

@rufuspollock
Copy link
Member Author

OK, my view now is that:

  1. We keep license "data" stuff in licenses repo https://github.com/okfn/licenses
  2. If people want to submodule they will use that

Hence, this issue is WONTFIX and we can close. @mlinksva @hlainchb make sense to you?

This is also relevant for merge license repo thread #7

@mlinksva
Copy link
Contributor

Makes sense to me.

@rufuspollock
Copy link
Member Author

WONTFIX

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

2 participants