I've added custom licenses now, as well as a link to the Open Definition site

Wow, clever approach. Thanks for fitting it within the pattern established by the undocumented javascript architecture! Took me a few minutes to figure out how the hidden fields were working. It dawned on me that this could also be a lot simpler if we didn't need to store the license_name of custom licenses: we could have a licenses.yml file in the _data/ directory that would populate the <select> box (using name as the label and url as the value), and the "Other" option would allow you to pop in your own custom url. This would allow a single field in the schema file. It looks like data.json only uses the license URL but datapackage.json recommends a label (type) field as well. What do you think?

FWIW, use decided to use a license URL for the data.json standard because that was the best model that we could devise that was a) simple b) extensible and c) non-prescriptive. (At least, as I recall. It's been a few years.) You may well decide that you'd like to be prescriptive, or that you prefer something more complicated—we were trying to establish a government standard, so our requirements were rather different than yours need be. :)

Hey @pezholio just wanted to check in on this. I'd love to include this in v1.0.0 and I appreciate that you put the work in. With the javascript refactor there are a few merge conflicts but I can try to resolve those. The bigger question was the one I asked above -- would it be acceptable to only store the license URL? Or is the license name necessary as well? (Particularly for "other" licenses)

Yep, I've got some time scheduled in this coming week to do some work on this, so will get cracking on this tomorrow. I like the idea of only storing the URL, but you're right that this might cause issues when people choose the 'other' option. That said, we might want to do away with the other option and assume that if people want to add extra licenses, they can do this via the yaml. What do you think?

Also, a further improvement down the line might be to let people manage this yaml file (and other similar files) via a GUI.

I've rebased this branch against the gh-pages branch and taken into account your comments. Now, we have a _data/licenses.yml file. We fetch the list of licenses from this file for the data entry form, and only store the url. We then use the URL as a key to display both License name and URL on the data view page.

I've now added a section to the /admin page that lists the licenses and allows a user to edit / add / delete licenses as they see fit without having to edit the yaml.

I had to hack around with the liquid markup of the text form include, as it seemed like it wanted an object to populate the form label, so I've added a default fallback.

There's also a hidden field in the licenses list that makes sure Not applicable is always available and always the last item in the list of licenses.

Any feedback, please let me know!

This looks great @pezholio! Really top job. Thanks for rebasing and again fitting it into the new architecture -- hope you found this one a little easier.

I've made a couple tiny alterations:

• Show currently selected license on dataset form (a minor typo was preventing it)
• Remove form/hidden.html (doesn't appear to be used anymore)
• Use field_name, label, and placeholder from schema file on form/license.html (easier to customize)

Merging now. Thanks again for your contribution!

Awesome, glad you like. I'll be keeping an eye out for any contributions I can make in the future 👍