A Tool to Define the Compatibility of Licenses as Partial Orders with CaLi
Introduction to Cali
What is a license
Licenses specify precisely the conditions of reuse of resources, i.e., what actions are permitted, obliged and prohibited when using the resource.
Choosing the appropriate license for a combined resource or choosing the appropriate licensed resources for a combination is hard. It involves choosing a license compliant with all the licenses of combined resources as well as analysing the reusability of the resulting resource through the compatibility of its license.
Compatibility and compliance among licenses
We consider that a license lj is compliant with a license li if a resource licensed under li can be licensed under lj without violating li.
If a license lj is compliant with li then we consider that li is compatible with lj and that resources licensed under li are reusable with resources licensed under lj.
In general, if li is compatible with lj then lj is more (or equally) restrictive than li.
We also consider that a license lj is more (or equally) restrictive than a license li if lj allows at most the same permissions and has at least the same prohibitions/obligations than li.
Cali orderings
CaLi (ClAssification of LIcenses), is a model for license orderings that uses restrictiveness relations and constraints among licenses to define compatibility and compliance.
A CaLi model is a tuple ⟨A, LS, CL, C→⟩ that partially orders licenses, such that:
- A is a set of actions (e.g., read, modify, distribute, etc.);
- LS is a restrictiveness lattice of status that defines (i) all possible status (e.g., permissions, obligations, prohibitions, etc.) of an action in a license and (ii) the restrictiveness relation among status denoted by ≤S;
- C→ is a set of compatibility constraints to identify if a restrictiveness relation between two licenses is also a compatibility relation;
- CL is a set of license constraints to identify non-valid licenses.
A simple example
For this simple example, we only consider the actions defined in the ORDL vocabulary.Restrictiveness lattice of status
In the following form, you can define which status you want to consider for the licenses.
You can define the restrictiveness lattice of status below by pressing the shift key and connecting the nodes. A restrictiveness lattice defines the relation between the status. For instance if in the following graph, the edge between Permission and Duty means duties are more restrictive than permissions.
Note: actions not explicitly defined in one of the statuses will be considered automatically in the Undefined status.
License constraints
You can add some license constraints to identify non valid licences. A valid license should respect all the constraints. One constraint can be composed of one or several conditions. If several conditions compose a constraint, they are evaluated as a disjunction.
Compatibility constraints
You can add compatibility constraints between every pair of licences. These constraints define if a restrictiveness relation is a compatibility relation or not.
Only one condition of each constraint have to be respected.
License creation
You can define your own license using the ODRL vocabulary.
Once you defined the licenses, you can order them according to the restrictiveness lattice of status previously defined.
An edge in the graph means the conneted licenses are compatibles. In other words, if License_i and License_j are connected as shown in the figure, it means
the actions of the License_i are compatible with the actions of the License_j.
To be more precise, if you merge a dataset published under License_i with a dataset published
under License_j, you have created a dataset that can be used under License_j.
References
Benjamin Moreau, Patricia Serrano-Alvarado, Matthieu Perrin, Emmanuel Desmontils."Modelling the Compatibility of Licenses." 16th Extended Semantic Web Conference (ESWC2019), Jun 2019, Portorož, Slovenia. https://hal.archives-ouvertes.fr/hal-02069076/document