Skip to content

RFC037: Redefine licenses, add licenses and make them machine readable

Background and rationale

The iSHARE Trust Framework contains the concept of licenses to define what a Service Consumer is allowed to do with received data or the results of a consumed service.

The iSHARE Trust Framework contains the concept of licenses to define what a Service Consumer is allowed to do with received data or the results of a consumed service. The current list of defined licenses contains 9 licenses.

Licenses are mentioned in:

Proposed change

Purpose

Purpose 1 of this RFC is to expand that list to accommodate the following:

  • International scoping (use the data / service output in a specific country only)
  • Industry (business segment) specific scoping (use the data / service output in a specific industry only)
  • Organisation certification scoping (use the data only in in organisations with a specific certification)

Purpose 2 of this RFC is to research options to make the licenses machine readable, for example using ODRL.

Purpose 3 of this RFC is to update and improve the guidance text in the licenses page of the framework, providing a better legal context and explanation on the usage of licenses.

Purpose 4 of this RFC is to evaluate the legal effect of the licenses: as they are build on top of Dutch legislation, are they usable internationally?

Purpose 5 of this RFC is to create more descriptive formats, improving usability and clarity.

Purpose 6 is to clarify how the list of licenses can be extended by data spaces.

Proposed change: considerations

  • Attention should go into version management
  • Align with other relevant initiative and enhance interoperability → iSHARE brings legal coverage and technological implementation should be interoperable → requires machine readability.
  • Align with https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-g/UsageControl/Contract
  • Further enhance the licences list with better legal translations and descriptions, validated by legal experts.
  • Make sure that the licenses are combinable, but ensure that the licences chosen by participants do not conflict.
  • Move away from numerical codes and use more descriptive formats, such as URLs or abbreviations, for the naming of licenses.
  • Interoperability with external licenses such as Creative Commons → ensures legal validity.
  • If a license changes, consumers must evaluate whether to continue processing the data or seek clarification from the data owner. The delegation evidence includes license information, allowing consumers to verify compliance. Additionally: create a more appropriate method and process for maintaining Licenses.

Solution description and principles

Licenses define what a Service Consumer is allowed to do with received data or the results of a consumed service. The scope of the licenses therefore extends beyond the transaction. Licenses are different from conditions, as defined in RFC055, which are evaluated at the time of a transaction, to determine whether or not a service or data can be provided.

Framework description of licenses

The introduction text on the Licenses page will be changed into the following.

Licenses allow an Entitled Party to explicitly specify what a Service Consumer is allowed to do with the consumption of a service or with received data. The licenses are included in [delegation evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence) and are in this way applied to specific authorisations. Since all iSHARE participants have signed the terms of use and agree to underlying scheme rules, participants are legally obliged to comply with the license conditions. In case of any violations, participants can appeal to each other based on the provided licenses.

The licenses presented here serve as a foundational set provided by iSHARE. Data spaces may extend this set with additional licenses, provided they ensure appropriate legal backing for any additions—such as incorporating them into relevant agreements.

iSHARE licenses are categorised in the following categories:
- General
- Country
- Industry
- Certification

Licenses can be combined using logical operators.

For the combination of licenses to be implemented, a logical structure must be allowed in the licenses element of the delegation evidence.

Compared to the current version this text:

  • Focusses on the specific purpose of licenses (compared to conditions)
  • Leaves out the paragraph about change management, since the licenses are considered an integral part of the framework and are therefore already subject of the change management process

Implementation in delegation evidence

To clarify that not only iSHARE licenses can be applied to data transactions, the following changes are foreseen:

  • On the dev portal, delegation endpoint, the sentence "Array which describes which iSHARE licenses apply to this policySet" will be replaced by "Array which describes which licenses apply to this policySet, using logical operators if required"
  • In the framework, in the the description of delegation evidence model the same change.

To be considered and decided is the structure of licenses:

  1. Option 1 (as currently implemented): an array of strings, where the strings contain the license identifiers. Relatively easy for ARs, but more difficult for Service Consumers wishing to automatically parse provided licenses. Also better implementable as metadata in the service implementation by Service Providers. It needs explanation on how to read and translate into the formal license description on the framework.
  2. Option 2: incorporate licenses as structured object. This would result in a better machine readable list of licenses, although harder to create by ARs. Also more unclear how Service Providers can include license information in the service they provide.

Example: a license combination of:

{
  "licenses": [
    {
      "allOf": [
        {
          "type": "license",
          "name": "resharing-with-adhering-parties",
          "url": "https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0"
        },
        {
          "type": "group",
          "allOf": [
            {
              "type": "country",
              "name": "nl",
              "url": "https://licenses.ishare.eu/country/nl"
            },
            {
              "type": "country",
              "name": "be",
              "url": "https://licenses.ishare.eu/country/be"
            }
          ]
        }
      ],
      "anyOf": [
        {
          "type": "industry",
          "name": "5210",
          "url": "https://licenses.ishare.eu/industry/5210"
        },
        {
          "type": "group",
          "anyOf": [
            {
              "type": "industry",
              "name": "5012",
              "url": "https://licenses.ishare.eu/industry/5012"
            },
            {
              "type": "industry",
              "name": "4923",
              "url": "https://licenses.ishare.eu/industry/4923"
            }
          ]
        }
      ]
    }
  ]
}

Must be interpreted as that the outcome of the service or received data can be re-shared with adhering parties only in The Netherlands or Belgium.

  1. Option 3 (as discussed during CAB): a simpler approach to the nested licenses list.
{
  "licenses": [
    {
      "allOf": [
        "https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0",
        {
          "allOf": [
            "https://licenses.ishare.eu/country/nl",
            "https://licenses.ishare.eu/country/be"
          ]
        }
      ],
      "anyOf": [
        "https://licenses.ishare.eu/industry/5210",
        {
          "anyOf": [
            "https://licenses.ishare.eu/industry/5012",
            "https://licenses.ishare.eu/industry/4923"
          ]
        }
      ]
    }
  ]
}

This method has been implemented in the provided OpenAPI spec.

Updated list of licenses

The list included on the page will be updated to this list. This list and the license descriptions have been reviewd by a legal advisor.

This list will be published on a separate domain: https://licenses.ishare.eu.

Machine readable list of licenses

After discussions with the community it was decided that creating and publishing an ODRL version of the licenses should be out of scope from this RFC. The legal basis for the iSHARE licenses is formed by the descriptive text of the licenses in the framework. The ODRL representation will never fully be in line with this.

The community and iSHARE foundation will however work together to produce a non-representative but supporting ODRL docment. Initial work is available here. It shall NOT be part of the framework.

License identifiers

Option 1: use numbers -> this option was considered unfavourable by co-creation participants

To improve universal identification of licenses, including framework versioning, both machine readable and human readable, the following license identifier will be introduced:

https://licenses.ishare.eu/<number>/<version>

Example: https://ishare.eu/0001/v1
Example: https://ishare.eu/0001/v2
Option 2: use descriptive identifiers -> this option was considered favourable by co-creation participants

To improve readability of license identifiers instead of using numbers, the use of descriptive identifiers is possible.

https://licenses.ishare.eu/<identifier>/<version>

Example: https://licenses.ishare.eu/general/resharing-with-adhering-parties/1.0
Example: https://licenses.ishare.eu/general/unrestricted/1.0

Participants of co-creation sessions have indicated that a descriptive identifier is favourable.

Change management

For the management of the list of licenses two options are available:

  1. As part of the change management process of the framework documentation (established process). -> this option was considered favourable by co-creation participants
  2. In a separate process (possibly faster process, but more administrative impact). -> this option was considered unfavourable by co-creation participants, but when required could be implemented in the future

Example use cases

Clarify the RFC by describing example use cases in which the change is used in practice.

Impact on the ecosystem

Worth mentioning is that iSHARE Foundation is working together with the Eclipse Data Space Working group on Data Rights Policies Profile which might in the future impact this topic.

The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role).

Formal role Technical impact Business / legal / functional / operational impact
Service Consumer Possibly* Yes
Service Provider Possibly* Yes
Entitled party No Yes
Authorization Registry Yes No
Identity Provider No No
Identity Broker No No
Data Space Administrator No No
Satellite No No

* If the role wants to use the machine readable form of licenses

Impact iSHARE Foundation (Scheme Owner)

Implementation

Release schedule

This change is scheduled for release 2.2.

Communication

Describe required communication topics and means.

Edited by athishare