Means to specify database license #414

merkys · 2022-06-02T11:35:16Z

Fixes #102. After discussions with @rartino in #102 I became convinced that for now a single license for all the data in a database should be sufficient. Should there be parts of database belonging under a different license, they should either be described in database-wide license document, or moved to a separate "sibling" database under a different license.

sauliusg

The stanza says "all data", but shouldn't we include also "all metadata"?
I was slightly inclined to have a possibility to specify license per record, but I agree that this wold be unnecessary complication for now. We can always upgrade if there is a genuine need.

I would approve the PR if/when the question about metadata is resolved.

merkys · 2022-06-02T11:49:15Z

The stanza says "all data", but shouldn't we include also "all metadata"? I was slightly inclined to have a possibility to specify license per record, but I agree that this wold be unnecessary complication for now. We can always upgrade if there is a genuine need.

I would approve the PR if/when the question about metadata is resolved.

@sauliusg I have added this in 3a678c3.

merkys · 2022-06-02T12:19:47Z

This is an important change (please note MUST level of inclusion), thus I would like to make sure that providers-consortium members check it out and let us know should there be a problem with conforming to it.

…enses`.

merkys · 2022-06-03T08:30:09Z

I have updated the PR to reflect workshop discussions: license_is_compatible_with_cc_by_4_0 has been replaced by compatible_licenses list of SPDX identifiers. The new property is OPTIONAL.

blokhin · 2022-06-03T12:31:35Z

For the case of the MPDS, we might have multiple licenses for the different sections of our data: CC BY 4.0, commercial/proprietary, per-vendor custom license, etc. We currently use per-entry custom field _mpds_data_license, which I would feel strong to recommend as a standard data_license / entry_license field.

merkys · 2022-06-06T13:03:59Z

For the case of the MPDS, we might have multiple licenses for the different sections of our data: CC BY 4.0, commercial/proprietary, per-vendor custom license, etc. We currently use per-entry custom field _mpds_data_license, which I would feel strong to recommend as a standard data_license / entry_license field.

This is a scenario quite closely fitting my reasoning which I have presented in #102 in my discussions with @rartino. If MPDS uses per-entry custom field, why not promote it to the standard? But this probably could be introduced in a follow-up PR in order not to block the current one.

According to this PR, MPDS licensing situation could be solved in two ways:

Separate databases (one per each license);
Specify all licenses and their governed domains in the top-level license file.

@blokhin Is any of these solutions suitable for MPDS? If so, maybe per-entry licensing could wait for the follow-up PR?

rartino

Some input on the overall design.

optimade.rst

rartino · 2022-06-07T08:34:54Z

@blokhin Even with your licensing situation, I hope that you do not have anything against merging this PR that allows linking a database-wide license text, where you can clarify the maybe not so simple licensing situation in MPDS? At the same time, perhaps we can continue the discussion of separate licenses for individual entries in #102? I'll copy your comment there to continue that discussion.

JPBergsma · 2022-06-13T09:22:11Z

optimade.rst

+  - **license**: A `JSON API links object <http://jsonapi.org/format/1.0/#document-links>`__ giving a pointer to a license covering all the data and metadata provided under this database.
+    If the license is included in the `SPDX License List <https://spdx.org/licenses/>`__, then the URL MUST point to SPDX-hosted license fulltext, i.e., it MUST start with :field-val:`https://spdx.org/licenses/`, but MUST NOT include the terminating :field-val:`.html`.


There may be more databases besides MPDS that use a per entry licencing system. So I think it would be good to specify that in that case, the link should point to a document describing how to find the licence for each entry. Otherwise someone may fill in a null value here, because there is no server wide licence.

I would suggest resolving this by explicitly stating that there is no default value/interpretation of null for these licensing properties. In case no pointers are provided in license (or *_licenses), this means no rights are granted for the client (as is with the source code). I do not want to entangle too much logic around this PR - there is a field for provider to put a link to their license/policies, and it is up to a provider to describe their license/policies in it.

Also, with the latest edits, the text for license says that the text it points to may express "(or licensing options if there are multiple)", which I think is the appropriate level of clarification about this.

But maybe we need to explicitly state what missing/null value for license means too?

Sure, it does not hurt to clarify for both the fields that null/missing means "no license". But, I suppose, in particular available_licenses present, and license missing should still be interpretable.

rartino · 2022-06-17T07:14:46Z

@merkys This seems a bit stalled? To move things forward, if you disagree with my suggestions, but don't have time to debate this, perhaps we can simplify the PR back to just a single "free-form" link without any machine-readable version and add the machine readable version in a separate PR?

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>

merkys · 2022-06-17T14:05:15Z

@merkys This seems a bit stalled? To move things forward, if you disagree with my suggestions, but don't have time to debate this, perhaps we can simplify the PR back to just a single "free-form" link without any machine-readable version and add the machine readable version in a separate PR?

Yes, I wanted to give some more time for opinions like @blokhin's. But sure, if we can agree on a common subset of this PR, I am fine with stepping back. I would like to have licensing sorted out before the next release, one way or another.

blokhin · 2022-06-17T15:01:22Z

I'm okay with the database-wide available_licenses / license fields. But what do you think about the optional per-entry license field?

rartino · 2022-06-17T16:00:37Z

@blokhin

My opinion on the per-entry field is that it is best kept as a database-specific field, because it should always have a database-specific meaning defined in the global license. As soon as we standardize a license field, rather than _mdps_license, it means both servers and clients can try to give it meaning outside of its database-specific definition in the main license info link. And IMO they shouldn't.

rartino

The adjustments I think are needed to address my other point -- i.e., that the link really should be a free link with no requirement to be computer parsed, since available_licenses takes that role.

(I'm happy to hear contradicting opinions on this, though - I really don't mean to "steamroll" this PR, just make sure it is will work in a way that can be handled semi-automatically by my client implementation...)

optimade.rst

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>

rartino

I think it would be great if @sauliusg has a chance to take a look at the present version before we merge it, since I think he has a good handle on the formalities around licensing. I also recall @giovannipizzi having some thoughts/input on this on the workshop.

rartino · 2022-06-29T05:51:10Z

This has sitting approved for a week waiting for further input. In the interest of cleaning up our PRs, I'm going to merge it.

ml-evs · 2022-12-06T21:25:07Z

optimade.rst

+    Inclusion of a license identifier in the list is a commitment of the database that the rights are in place to grant clients access to all the data and metadata according to the terms of either of these licenses (at the choice of the client).
+    If the licensing information provided via the field :field:`license` omits licensing options specified in :field:`available_licenses`, or if it otherwise contradicts them, a client MUST still be allowed to interpret the inclusion of a license in :field:`available_licenses` as a full commitment from the database that the data and metadata is available, without exceptions, under the respective licenses.
+    If the database cannot make that commitment, e.g., if only part of the data is available under a license, the corresponding license identifier MUST NOT appear in :field:`available_licenses` (but, rather, the field :field:`license` is to be used to clarify the licensing situation.)
+    An empty list indicates that none of the SPDX licenses apply for the entirety of the database and that the licensing situation is clarified in human readable form in the field :field:`license`.


Without opening a new issue, I just wanted to clarify something here @merkys (and others). The field license is simply a Links object, so when you say "situtation is clarified in human readable form in the field license", are you referring to the content served at the URL pointed to in license->href, or the meta section of the Links object?

If I remember the discussion correctly, we were indeed referring to the content of the URL to which the licence link points.

It is license->href indeed, worth clarifying.

merkys added 3 commits June 2, 2022 11:54

Introducing license attribute.

8fb2435

SPDX links MUST NOT contain terminating .html.

5864280

Adding license_is_compatible_with_cc_by_4_0.

c14bedd

merkys requested review from rartino, ml-evs, giovannipizzi, gmrigna, JPBergsma and sauliusg June 2, 2022 11:35

sauliusg reviewed Jun 2, 2022

View reviewed changes

"data" -> "data and metadata".

3a678c3

merkys requested a review from sauliusg June 2, 2022 11:49

sauliusg previously approved these changes Jun 2, 2022

View reviewed changes

merkys added 3 commits June 3, 2022 11:03

Merge branch 'develop' into database-license

8e55cef

Replacing license_is_compatible_with_cc_by_4_0 with `compatible_lic…

0688b83

…enses`.

Making compatible_licenses OPTIONAL.

cd7a0db

merkys dismissed sauliusg’s stale review via cd7a0db June 3, 2022 08:19

merkys requested a review from sauliusg June 3, 2022 08:23

Making the text a bit more easy to read.

80556c1

rartino reviewed Jun 6, 2022

View reviewed changes

optimade.rst Outdated Show resolved Hide resolved

optimade.rst Outdated Show resolved Hide resolved

rartino mentioned this pull request Jun 7, 2022

Data(base) licenses #102

Closed

JPBergsma reviewed Jun 13, 2022

View reviewed changes

Merge branch 'develop' into database-license

4bce691

merkys and others added 2 commits June 17, 2022 16:56

Merge branch 'develop' into database-license

3c1046e

Update optimade.rst

c133959

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>

rartino requested changes Jun 20, 2022

View reviewed changes

optimade.rst Outdated Show resolved Hide resolved

optimade.rst Outdated Show resolved Hide resolved

merkys and others added 2 commits June 20, 2022 11:01

Update optimade.rst

954b0eb

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>

Update optimade.rst

392e1e4

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>

rartino approved these changes Jun 20, 2022

View reviewed changes

merkys requested a review from blokhin June 20, 2022 08:16

blokhin approved these changes Jun 20, 2022

View reviewed changes

rartino merged commit f1e656e into Materials-Consortia:develop Jun 29, 2022

merkys deleted the database-license branch June 29, 2022 06:12

ml-evs mentioned this pull request Jun 29, 2022

Support for specifying database licenses Materials-Consortia/optimade-python-tools#1254

Closed

ml-evs mentioned this pull request Dec 5, 2022

OPTIMADE v1.2 release planning #429

Closed

ml-evs added this to the v1.2 milestone Dec 6, 2022

ml-evs reviewed Dec 6, 2022

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Means to specify database license #414

Means to specify database license #414

merkys commented Jun 2, 2022

sauliusg left a comment

merkys commented Jun 2, 2022

merkys commented Jun 2, 2022

merkys commented Jun 3, 2022

blokhin commented Jun 3, 2022

merkys commented Jun 6, 2022

rartino left a comment

rartino commented Jun 7, 2022 •

edited

Loading

JPBergsma Jun 13, 2022

merkys Jun 20, 2022

rartino Jun 20, 2022

merkys Jun 20, 2022

rartino Jun 20, 2022 •

edited

Loading

rartino commented Jun 17, 2022

merkys commented Jun 17, 2022

blokhin commented Jun 17, 2022

rartino commented Jun 17, 2022 •

edited

Loading

rartino left a comment

rartino left a comment

rartino commented Jun 29, 2022

ml-evs Dec 6, 2022 •

edited

Loading

JPBergsma Dec 6, 2022

merkys Dec 7, 2022

		- license: A `JSON API links object <http://jsonapi.org/format/1.0/#document-links>`__ giving a pointer to a license covering all the data and metadata provided under this database.
		If the license is included in the `SPDX License List <https://spdx.org/licenses/>`__, then the URL MUST point to SPDX-hosted license fulltext, i.e., it MUST start with :field-val:`https://spdx.org/licenses/`, but MUST NOT include the terminating :field-val:`.html`.

Means to specify database license #414

Means to specify database license #414

Conversation

merkys commented Jun 2, 2022

sauliusg left a comment

Choose a reason for hiding this comment

merkys commented Jun 2, 2022

merkys commented Jun 2, 2022

merkys commented Jun 3, 2022

blokhin commented Jun 3, 2022

merkys commented Jun 6, 2022

rartino left a comment

Choose a reason for hiding this comment

rartino commented Jun 7, 2022 • edited Loading

JPBergsma Jun 13, 2022

Choose a reason for hiding this comment

merkys Jun 20, 2022

Choose a reason for hiding this comment

rartino Jun 20, 2022

Choose a reason for hiding this comment

merkys Jun 20, 2022

Choose a reason for hiding this comment

rartino Jun 20, 2022 • edited Loading

Choose a reason for hiding this comment

rartino commented Jun 17, 2022

merkys commented Jun 17, 2022

blokhin commented Jun 17, 2022

rartino commented Jun 17, 2022 • edited Loading

rartino left a comment

Choose a reason for hiding this comment

rartino left a comment

Choose a reason for hiding this comment

rartino commented Jun 29, 2022

ml-evs Dec 6, 2022 • edited Loading

Choose a reason for hiding this comment

JPBergsma Dec 6, 2022

Choose a reason for hiding this comment

merkys Dec 7, 2022

Choose a reason for hiding this comment

rartino commented Jun 7, 2022 •

edited

Loading

rartino Jun 20, 2022 •

edited

Loading

rartino commented Jun 17, 2022 •

edited

Loading

ml-evs Dec 6, 2022 •

edited

Loading