Multiple licences feature proposal

[vicding-mi]

Multiple licences feature proposal

Summary

In the out-of-box Dataverse, when specifying the terms of use for a dataset you can only choose between applying the CC0 waiver or specifying custom terms. We propose to present the user with a list of standard licenses which replaces the Waiver radio button. CC0 and "custom license" will be in this list automatically. The other licences can be configured through a new API endpoint.

Motivation

There are many other licenses than CC0 that are commonly used by depositors, for example CC-BY in several variants, In Dataverse depositors can only apply those terms by copy-pasting them into the "custom" terms field. This is not user friendly.

Description of the changes

User interface

The following screenshots show the current interface and the proposed interface.

Current interface

View mode

1. With 'Yes, apply CC0 - "Public Domain Dedication"'

2. With 'No, do not apply CC0 - "Public Domain Dedication"'

Edit mode

3. With 'Yes, apply CC0 - "Public Domain Dedication"'

4. With 'No, do not apply CC0 - "Public Domain Dedication"'
   

Proposed interface

View mode

Edit mode

1. With CC0 or other standard license selected
   

2. With "Custom Terms" selected
   

API

Configuration

Installing the list of available licenses is achieved by calling a new API endpoint:

curl http://localhost:8080/api/admin/licenses/load -H "Content-type: text/tab-separated-values" -X POST --upload-file /tmp/licenses.tsv

This uploads a configuration file that specifies the licenses that should appear in the dropdown box. This TSV file has the following columns:

licenseUri	a unique identifier for the license (dropdown list value)
licenseDisplayName	the string to be displayed in the user interface (dropdown list text)
licenseDescription	a short description of the license to be displayed below the dropdown list

There are two reserved items in the list, CC0 and "Custom Terms" which cannot be specified in the TSV file. They will always be present.

Metadata exports

(Native) JSON

Current output

When getting the JSON for a dataset the information about license currently looks like this:

For CC01:

{

  "id": 7,

….

  "license": "CC0",

  "termsOfUse": "CC0 Waiver",

…

  "termsOfAccess": "You need to request for access.",

}

For custom:

{

  "id": 7,

….

  "license": "NONE",

…

  "termsOfAccess": "You need to request for access.",

}

Proposed output

The current JSON will be extended with one field 'licenseURI'. The existing fields will be filled as follows:

license	display name of the selected license
termsOfUser	description of the selected license

For CC01:

{

  "id": 7,

….

  "license": "CC0", 

  "termsOfUse": "CC0 Waiver",

…

  "termsOfAccess": "You need to request for access.",

}

For other standard license (i.e CC-BY):

{

  "id": 7,

….

** "licenseURI": "https://creativecommons.org/licenses/by/4.0/legalcode"**,

  "license": "CC-BY",

...

  "termsOfAccess": "You need to request for access.",

}

For custom license:

{

  "id": 7,

….

** "licenseURI": "https://uro_to_custom_license.com/"**,

  "license": "NONE",

  “termsOfUse”: “User input terms of use”

...

  "termsOfAccess": "You need to request for access.",

}

Formats based on native JSON

The following formats seem to be based on the native JSON so the transformation will not have to be changed: Dublin Core, DataCite, DDI, DDI Codebook HTML.

OAI-ORE, JSON-LD, OpenAIRE

These formats currently contain a license URI for CC0. This URI will need to be filled in correctly for the other licenses as well.

Migration

To support this functionality one extra table is required to store the list of licenses. Probably this table can be created automatically on deployment of the new Dataverse version that contains this new feature. This would mean that no migration scripts are necessary to activate this feature.

[4tikhonov]

@djbrooke, @pdurbin, @qqmyers, this functionality seems to be quite useful for all Dataverse community partners, not only for DANS.

[poikilotherm]

Hi @vicding-mi,

thanks for opening this issue. Looks like you put some thoughts into this.

Let me bring to your attention that this issue is likely a duplicate of #1753, but maybe people like @djbrooke decide it's time for a fresh start since #1753 is a bit dated. The most limiting factor seems to be the availabilty of resources from the UI/UX team @TaniaSchlatter

Also #5899 is related here, some thoughts spend over there, too.

Personally, I'd be more than happy to work along with you on this, as this is a blocker for my research software depositing work ahead.

[poikilotherm]

Reposting from #1753 (comment), I would encourage the use of SPDX for licenses.

See https://github.com/spdx/license-list-data for a curated, normalized and machine-actionable source.

[vicding-mi]

@poikilotherm many thanks for pointing out ticket #1753 , we read through it before created the ticket. There are lots of information and ideas in the original ticket, it might be useful to have a fresh start and more focused feature ticket.

We would like to have feedback from the community, any suggestions and ideas will be welcome, and at the same time keep the feature 'simple and straight forward'. ;)

[jggautier]

I've always thought a blocker for this feature (and similar requests in other GitHub issues) was the DataTags work being done at IQSS. Would it be helpful to figure out if and how that work affects proposals like this one?

[djbrooke]

Thanks @vicding-mi for the detailed proposal and @poikilotherm for the linkage. I may close and consolidate some issues as suggested. I appreciate the link to SPDX!

@jggautier I don't think DataTags is a blocker here, but it's been hard to prioritize this specific licensing workflow because the DataTags work will require us to revisit pretty much the entire workflow around depositing data into Dataverse, and it would be easier to handle this at that time instead of a one-off.

Let me discuss with some folks on this side, including the design team, and I can come back with some more information.