Feature Request/Idea: Standardize standard license configuration

[philippconzett]

Overview of the Feature Request
With version 5.10, the long-awaited multiple-license support was released (see release notes). Thanks to all contributors!
To better support interoperability between Dataverse installations and beyond Dataverse installations, I'd like to suggest standardizing the way standard license configuration is managed using multiple-license support as follows:

1. Standardized licenses are provided as authoritative JSON files stored in the IQSS/dataverse GitHub repositories or the GDCC GitHub repository.
2. The section Adding Licenses in the Dataverse Installation Guide links to GitHub folder containing the JSON files.
3. We agree on the source and content of the elements in the JSON files. Here are some suggestions and possible issues to discuss:

• Source: Whenever possible, we use the information provided in the SPDX License List and the license webpage provided by the license issuer.
  JSON elements:
• name: Field Identifier in the SPDX License List, but without hyphens, e.g., Artistic-2.0 > Artistic 2.0
• uri: 1) License URI provided by the license issuer; 2) if (1) is not available, SPDX URI for the license
• shortDescription: Field Full name in the SPDX License List. Question 1: Do we need to add "License" or "Dedication", as is currently done in the JSON files provided in the Dataverse Installation Guide? Question 2: Do we need to add a full stop at the end of the shortDescription element, as is currently done in the JSON files provided in the Dataverse Installation Guide?
• iconUrl: As provided by license issuer

4. We agree on which standard licenses to provide as JSON files in the GitHub repository. To start with, I suggest we concentrate on the following ones:

• Creative Commons Zero 1.0
• All Creative Commons Attribution (BY) licenses 4.0 and later
• Open Data Commons Open Database License v1.0
• Open Data Commons Attribution License v1.0
• All licenses in the SPDX License List that are FSF Free/Libre and OSI Approved, starting with licenses included in Open Science Framework (OSF):

Content:

• CC0 1.0 Universal
• CC-BY Attribution 4.0 International

Code - Permissive:

• MIT License
• Apache License 2.0
• BSD 2-Clause "Simplified" License
• BSD 3-Clause "New"/"Revises" License

Code - Copyleft:

• GNU General Public License (GPL) 3.0
• GNU General Public License (GPL) 2.0

Code - Other:

• Artistic License 2.0
• Eclipse Public License 1.0
• GNU Lesser General Public License (LGPL) 3.0
• GNU Lesser General Public License (LGPL) 2.1
• Mozilla Public License 2.0

Following the suggested guidelines above, I have created a Google spreadsheet containing the necessary information to create JSON files, and I created those files by running a bash file. All these documents are available in this Google folder (you might need to log in to access it).

At a later stage, this could of course be automated by retrieving information directly from SPDX and license issuers, possibly via a controlled vocabulary hosted on SKOSMOS.

What kind of user is the feature intended for?
The suggested feature is primarily intended for Sysadmins who need to install licenses on their Dataverse installation.

What inspired the request?
The implementation of multiple license support released in v5.10.

What existing behavior do you want changed?
The different Dataverse installations adding the same standard license with (slightly) different license information.

Any brand new behavior do you want to add to Dataverse?
No, thanks.

Any related open or closed issues to this feature request?
Multiple licences feature proposal #7440

[qqmyers]

FWIW:

• Files for the CC licenses are already included in v5.10. They do not follow your SPDX advice above as SPDX uses URLs that redirect to their site rather than the CC URLs as defined by CC. My guess is that this is also the case for other licenses and we should probably figure out a best practice for that.
• Another thing to pay attention to is that SPDX doesn't mark things as obsolete, e.g. https://spdx.org/licenses/CC-PDDC.html doesn't give any indication that the license is deprecated as https://creativecommons.org/licenses/publicdomain/ does (unless you manually click through from SPDX).
• We currently use http:// URLs for the CC licenses. At one time I think there was a best practice to use http for identifiers regardless of whether access would be https or not. On the CC site, they seem to have a mix, and they do redirect http -> https so both work for access. However, since our database currently has the full URL string, http and https prefixes currently mean the URLs don't match. So - another place where we could/should have a best practice and/or we should change the code to accept either.

[philippconzett]

Thanks for your comments, @qqmyers. Just a short reply to your first bullet point. I think the way you have done this in v5.10 is already in line with my suggestion; cf.

uri: 1) License URI provided by the license issuer; 2) if (1) is not available, SPDX URI for the license

I think we only should use the SPDX URI when there is no (authoritative) URI provided by the license issuer.

[poikilotherm]

Thank you @philippconzett starting this discussion. This is related to proper future software support (important for our project HERMES), so I'm taking the liberty to join it.

As 5.10 included the first iteration of multi license support, I think we should be very careful when taking the next steps.

Some context about interoperability:
RO-Crate 1.1 uses this JSON-LD schema.org based representation of a license:

{
  "@id": "https://creativecommons.org/licenses/by/4.0/",
  "@type": "CreativeWork",
  "name": "CC BY 4.0",
  "description": "Creative Commons Attribution 4.0 International License"
}

@qqmyers removed the generation of this JSON-LD part from the code and replaced it with the URL only (which is perfectly valid schema.org syntax). The RO-Crate description field is our shortDescription, RO-Crate name stays name, etc. (We might even use our iconUrl for schema.org/RO-Crate thumbnailUrl)

@qqmyers: looking at https://github.com/spdx/license-list-data/blob/master/json/licenses.json, there are licenses marked as deprecated - maybe we need to open an issue at https://github.com/spdx/license-list-XML and talk to them about PDDC being deprecated by upstream (there isn't an issue for this yet).

• Using the SPDX licenseId field, removing the hyphens to create our/schema.org name field looks fine.
• Using the SPDX name field to create our shortDescription / schema.org description sounds fine, too. I would not customize this within the data model to be more consistent in UI and exporting places.
• Looks like the SPDX seeAlso field for a license may provide a good candidate for our uri. Using the SPDX reference without the .html as fallback sounds good. I see this SPDX ID URL is used in RO-Crate, too. (See this examples dataset)
• WRT to http vs https: maybe we should change the API code to avoid doubled entries and make the service bean accept both for searches etc. IMHO we should be ready to serve mixed styles, too.

(Future: IMHO it would be great to have a summary in our UI, so people don't need to look at license texts. Maybe grabbing the quick summaries from https://tldrlegal.com helps?)

[philippconzett]

Thanks for your feedback, @poikilotherm! I wasn't aware that RO-Crate already had addressed this issue. My main concern was just that to make sure that standard licenses are described in the same way across Dataverse installations.

[philippconzett]

When I mentioned that my suggestion was meant to improve interoperability between Dataverse installations and beyond Dataverse installations, I first of all had in mind that license information from Dataverse installations should be made harvestable in a way that complies with recommendations. I'm not sure about the status of RO-Crate, but a standard that is already implemented and widely used is the DataCite Metadata Schema. The current version of this schema, v.4.4 (cf. https://schema.datacite.org/meta/kernel-4.4/), says the following about license information:

ID	DataCite-Property	Occ	Definition	Allowed values, examples, other constraints
16	Rights	0-n	Any rights information for this resource. The property may be repeated to record complex rights characteristics.	Free text *** Provide a rights management statement for the resource or reference a service providing such information. Include embargo information if applicable. Use the complete title of a license and include version information if applicable. May be used for software licenses. Examples: Creative Commons Attribution; 3.0 Germany License; Apache License, Version 2.02
16.a	rightsURI	0-1	The URI of the license.	Example: https://creativecommons.org/licenses/by/3.0/de/
16.b	rightsIdentifier	0-1	A short, standardized version of the license name.	Example: CC-BY-3.0. A list of identifiers for commonly-used licenses may be found here: (https://spdx.org/licenses/).
16.c	rightsIdentifierScheme	0-1	The name of the scheme.	Example: SPDX
16.d	schemeURI	0-1	The URI of the rightsIdentifierScheme.	Example: https://spdx.org/licenses/

As the license identifier, DataCite requires "a short, standardized version of the license name", and they suggest to use the SPDX identifier.

Based on the DataCite recommendations, I've updated the Google spreadsheet (see tab "English v.0.2") and the JSON files for the standard licenses I suggest we should provide on GitHub; see this Google folder.

As far as I can see, none of the standard licenses I suggest we should provide on GitHub are obsolete, so this shouldn't be a show stopper. Also pinging @janvanmansum for feedback.

[philippconzett]

Here are two JSON examples created following the suggested workflow above:

{
  "rightsName": "CC0 1.0",
  "rightsURI": "https://creativecommons.org/publicdomain/zero/1.0/",
  "rightsIdentifier": "CC0-1.0",
  "rightsIdentifierScheme": "SPDX",
  "schemeURI": "https://spdx.org/licenses/",
  "rightsShortDescription": "Creative Commons Zero v1.0 Universal.",
  "rightsIconUrl": "https://licensebuttons.net/p/zero/1.0/88x31.png",
  "rightsActive": true
}

{
  "rightsName": "CC BY 4.0",
  "rightsURI": "https://creativecommons.org/licenses/by/4.0/",
  "rightsIdentifier": "CC-BY-4.0",
  "rightsIdentifierScheme": "SPDX",
  "schemeURI": "https://spdx.org/licenses/",
  "rightsShortDescription": "Creative Commons Attribution 4.0 International.",
  "rightsIconUrl": "https://licensebuttons.net/l/by/4.0/88x31.png",
  "rightsActive": true
}

@qqmyers @pdurbin I guess we might have to change back some of the field names, in order to this not messing up your current setup, e.g., rightsName >> name?

I don't know what needs to be done to discuss this further, but I'd be happy to contribute as suggested above. For example, if you create a suitable place on GitHub, I could create and upload the JSON files, once we've agreed on how they should look like. Thanks!

[pdurbin]

I don't know what needs to be done to discuss this further

@philippconzett I'm not sure either. Perhaps we can try to make the problem more concrete with a scenario and a screenshot.

Imagine a future where you're harvesting datasets from another Dataverse installation with slightly different names. Also imagine that there's a search facet called "License" that makes these differences obvious at a glance:

Once the data is in a facet like this, it's obvious that there's a problem, that counts of the same license should be combined.