Consider merging this repo with opendefinition repo

[rufuspollock]

See proposal at: okfn/opendefinition#7

Consider pros / cons (cf e.g. as a potential "con" okfn/opendefinition#27)

@enyst interested in your thoughts here ...

[enyst]

I worked a bit to get ready a branch with license texts. Please see: https://github.com/enyst/licenses-db/tree/okfn

My intention has been to make it available for inclusion as a submodule and/or used from any projects. Similar to the linked issue 27.

I think I see as more useful a repo targeted to licenses. It could include licenses in different formats (/licenses/something). If wanted, it could include the main service (/whatever_for_scripts). I think could also include OD content from okfn/opendefinition, which is the only actually different info existing in /okfn/opendefinition, apart from licenses. (there's only three more texts and translations, if I see this correctly)

I'm not sure about including and keeping up with the approval process in the repo structure itself. The opendefinition repo splits licenses per stage 'inreview'/'conformant' and eventually 'non-conformant' in the repo structure.

• the target of the information 'inreview' is not really dev contributors, is it? It's readers of the site/mailing lists. But the site doesn't seem handled by this repo.
• 'in review' is an attribute, not structure of the repo, conceptually... It seems to me it conflates different responsibilities.
• in a previous experience with a similar attempt to keep moving files in folders due to an approval process of sorts, keeping up with the process is not so easy/obvious especially since mailing lists are the venue.. If it works for OKFN, it's cool, just not sure about the potential use of the licenses content by other projects, because they may be affected by moves back and forth...
• this repo may store some licenses without regard to approvals (but to compliance alone), such as the pending Unlicense. They're well known and compliant, but never approved for various reasons. Personally, I would support their storage in the licenses repo, when there are good reasons to. However, a strict repo structure based on approvals seems too rigid then.

IMO the "core" idea of a repo should be licenses data/content, for use by other projects. A service making them available through an API if wanted. The base definition content and work on it seems to belong to it too, but that's about it... I'm having trouble visualizing too many workflows conflated in the same project.

A few initial thoughts for a merge...

• approved/not-approved/rejected[non-conformant] are license metadata
• in-review is not a directory; could be an attribute if needed by a client such as opendefinition.org site; I'd rather make a group in the code to begin with...
• I support the storage of texts. Granted there are other services offering it. (Could use licensedb for text and build only specific APIs in okfn; unclear to me if enough for okfn because the goals seem quite similar not identical, i.e. my intention is to not submit to licensedb certain non-reusable and problematic licenses that have been approved by OSI. Can't use opensource.org since it doesn't provide text yet. And I don't know if I trust others to exist long enough, maybe someone who knows them better than me could tell.)
• I don't understand if opendefinition.org site has anything to do with the repo or is it wanted to. So I'm having trouble visualizing that.

[rufuspollock]

@enyst all good thoughts.

My sense at the moment is we get this repo sorted and leave any merge. My sense is that opendefinition is more of a repo for having an issue tracker and for recording version of licenses for discussion and review and this repo is the "authoratative source" of approved licenses etc.

You've asked a bunch of other good questions - e.g. relation of opendefinition to this repo some of which merit their own issue. To answer that specific one this repo powers licenses.opendefinition.org (via github pages) but is not directly used by opendefinition.org (which is wordpress powered)

[rufuspollock]

@enyst btw feel it would be good to get you commit rights on this repo - would that be good?

[enyst]

Sure, I can use it.

[rufuspollock]

WONTFIX. closing as wontfix based on discussion above. May need new issues for some of specific suggestions from @enyst