Support for configurable list of licenses #7920
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| { | ||
| "name": "CC-BY-4.0", | ||
| "uri": "http://creativecommons.org/licenses/by/4.0", | ||
| "shortDescription": "Creative Commons Attribution 4.0 International License.", | ||
| "iconUrl": "https://i.creativecommons.org/l/by/4.0/88x31.png", | ||
| "active": true | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3576,3 +3576,28 @@ Recursively applies the role assignments of the specified Dataverse collection, | |
| GET http://$SERVER/api/admin/dataverse/{dataverse alias}/addRoleAssignmentsToChildren | ||
|
|
||
| Note: setting ``:InheritParentRoleAssignments`` will automatically trigger inheritance of the parent Dataverse collection's role assignments for a newly created Dataverse collection. Hence this API call is intended as a way to update existing child Dataverse collections or to update children after a change in role assignments has been made on a parent Dataverse collection. | ||
|
|
||
|
There was a problem hiding this comment. This is a geneal comment about updates to the guides. We should probably update the "Terms" section in the User Guide from what's currently there: https://guides.dataverse.org/en/5.9/user/dataset-management.html#terms |
||
|
|
||
| Manage Available Standard License Terms | ||
|
There was a problem hiding this comment. We might want to move these outside "admin" so regular API users can learn what licenses are available. There was a problem hiding this comment. Makes sense - for the get licenses call anyway. Probably good if API users can directly tell if custom licenses are allowed too. Is there a precedent for a split API like that where get is open and the change/delete functionality is restricted? (Looking at how to construct the URLs and where to place the code - I know there are some /api/admin/* calls not in the Admin class, but I don't know what best practice is.) There was a problem hiding this comment. Perhaps we should have a new top level That way, any API client could get a list of licenses even without authenticating. But only superusers would be able to add licenses. |
||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| View the list of standard license terms that can be selected for a dataset:: | ||
|
|
||
| curl http://$SERVER/api/admin/licenses | ||
|
|
||
| View the details of the standard license with the database ID specified in ``$ID``:: | ||
|
|
||
| export ID=1 | ||
| curl http://$SERVER/api/admin/licenses/$ID | ||
|
|
||
| Add a new license by posting a JSON file adapted from this example :download:`add-license.json <../_static/api/add-license.json>`. The ``name`` and ``uri`` of the new license must be unique. :: | ||
|
|
||
| curl -X POST -H 'Content-Type: application/json' --data-binary @add-license.json http://$SERVER/api/admin/licenses | ||
|
|
||
| Overwrite the license with the database specified in ``$ID``:: | ||
|
|
||
| curl -X PUT -H 'Content-Type: application/json' --data-binary @edit-license.json http://$SERVER/api/admin/licenses/$ID | ||
|
|
||
| Delete the license with with the database specified in ``$ID``:: | ||
|
|
||
| curl -X DELETE http://$SERVER/api/admin/licenses/$ID | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| { | ||
| "name": "CC-BY-4.0", | ||
| "uri": "http://creativecommons.org/licenses/by/4.0", | ||
| "shortDescription": "Creative Commons Attribution 4.0 International License.", | ||
| "iconUrl": "https://i.creativecommons.org/l/by/4.0/88x31.png", | ||
| "active": false | ||
| } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| { | ||
|
There was a problem hiding this comment. These three are used only for tests? Maybe they should go under /src/test/resources somewhere (suggestions anyone? in the json dir with datasets or a new licenses dir?) There was a problem hiding this comment. I think just adding it to the json dir in /src/test/resources with a descriptive name should be okay There was a problem hiding this comment. @qqmyers on second thought the rest of the tests also use the scripts/api/data/ directory for the tests, it would make more sense to change that as a whole then for all Integration Tests? Changing the directory to /src/test/resources just for the license test wouldn't make a lot of sense I think There was a problem hiding this comment. @scolapasta , @pdurbin - any guidance for where test data should go? It seems like existing test data is not all in one place, so I'm not sure what the recommendation would be for new test data. There was a problem hiding this comment. Under /src/test/resources sounds fine to me. You're right. Test data is a bit spread around. But at least it'll be in good company there. 😄 There was a problem hiding this comment. So I think putting all the test data there makes sense too - (not sure if I commented on all the test files, but I wasn't trying to single this one out.) |
||
| "id": 6, | ||
| "name": "CC-BY-4.0", | ||
| "uri": "http://creativecommons.org/licenses/by/4.0", | ||
| "shortDescription": "Creative Commons Attribution 4.0 International License.", | ||
| "iconUrl": "https://i.creativecommons.org/l/by/4.0/88x31.png", | ||
| "active": true | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| { | ||
| "name": "CC-BY-4.0", | ||
| "uri": "http://creativecommons.org/licenses/by/4.0", | ||
| "shortDescription": "Creative Commons Attribution 4.0 International License.", | ||
| "iconUrl": "https://i.creativecommons.org/l/by/4.0/88x31.png", | ||
| "active": true | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be "CC BY 4.0" (without the hyphens)? That's what it says at https://creativecommons.org/licenses/by/4.0/
Update: I talked to @4tikhonov and he pointed me to https://spdx.org/licenses/ which leads me to believe that "name" should be "identifer" since "CC-BY-4.0" seems to be an identifier.
However, now I'm concerned that we're showing these machine-readable identifiers in the UI. If I saw "MIT-0" in the GUI below I wouldn't know what it means but "MIT No Attribution" is clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the URL is really the primary identifier and the 'name' is intended for display rather than as a second less specific way to identify the license globally. So - I think I agree that the non-hyphenated versions make more sense and we can change those (unless someone else has a concern about that?).
(Note - since these are configured via API, installations that prefer some other user-visible label (or want to have them in another language, etc.), they can still do that. The interoperability is intended to be by URL - if that matches, it's the same license.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no objection to using a URL as a primary identifier but are our URLs aligned with SPDX, for example? It seems like not (CC-BY-4.0 example):
In short, if we're going to use URLs as identifiers it would be nice to see a canonical list of these URLs somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The URLs used now are what Creative Commons has assigned to their licenses. Their page metadata include attributes like
about="http://creativecommons.org/licenses/by/4.0"for example. While SPDX has assigned alternate URLs, I don't think it would be best practice to not follow Creative Commons. Since licenses are configurable, installations could choose to do that if they wanted to though.