The ever-growing number of accessible online resources allows any person to modify, to derive, to combine resources in order to create and share new resources. Overseeing those interactions are licenses that define if and how each resource can be reused. As the author can choose to protect and share the new resource to any extent, the license used can be more or less complex and specific. In particular, contextual constraints in a license can circumscribe the reusability of its covered resource to a specific context such as a given location, during a given timeframe, or in specific media. In addition, the new resource must be protected by a license that complies to the licenses of its source materials, it should also be the least restrictive possible in order to make it as shareable as the author wishes. This makes finding a license which complies to a set of potentially complex licenses a challenging task for an author without legal knowledge. We propose CLiC, an approach that, while taking into account contextual constraints expressed in ODRL, composes the least restrictive license that complies to a given set of potentially complex licenses. The idea is to help authors in reusing resources protected by complex licenses while maximizing the shareability of new resources. This way an author obtains the adequate license for a new resource that complies to the licenses of its source materials, while limiting as little as possible its shareability.
The amount of available online resources motivates authors to take inspiration from, to modify, to derive, and to compose existing resources into new ones. In that context, attaching a license to a new resource is fundamental to control and facilitate reusability. A license specifies how a resource can and cannot be used, i.e., what actions are permitted, obligated and prohibited. The most well-known licenses used with online resources are simple licenses designed to foster an easier reuse of resources. Their simplicity comes from the use of general and clearly defined clauses, allowing the licenses to be applicable in numerous contexts. Examples of such licenses include the Creative Commons’ licenses1 for creative works, or the MIT2 and Apache3 licenses for source code.
However, some cases require resources to be protected by more specific or complex licenses that include contextual constraints. Therefore, in addition to the well-known licenses, a number of other licenses can exist. They, then, vary in terms of their complexity, scope of application, or drafting languages. Online stock image resources, coming from companies such as Shutterstock or Adobe, are an example of resources protected by complex dedicated licenses that describe specific contextual constraints45. Those constraints limit a resource’s reuse to a given context, e.g., a circumscribed timeline, a particular country, specific purpose, a certain number of reuse. Contextual constraints can also include
© 2025 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). specific information such as the legal jurisdiction the licenses must comply with or the court where a case will need to be brought if legal actions were to take place in relation to the covered resource. Contractual by nature, these legal documents should not be overlooked by the resources’ users as legal consequences are attached to their infringement both under contract law and intellectual property law.
When combining multiple source materials into a new resource, an author is tasked with finding a
license that will protect the new resource and be compliant with the sources’ first licenses. The re-user
will have the daunting task to delve into the legal analyses of multiple licenses, perhaps in diferent
languages, in order to pick a license that will accommodate the first ones. Indeed, the overall license
should, at most, have the same permissions (or a coherent intersection of them), and at least the same
obligations and prohibitions than the licenses of the source materials [
Following the idea of maximizing shareability, the author should also pay attention that his/her license for his/her new resource is not too restrictive as it reduces its reusability. This additional constraint will, again, require the author to legally analyse closely licenses options. If the author does not find a suitable license, he/she will be left to draft his/her own licensing terms. In other words, the author will often be required to draft from scratch a contractual document, the license, that will be legally compliant with the initial licenses covering the source materials. In that scenario, the author will have to compose a new license by combining terms from the original ones without introducing errors or loopholes. This will require the author to have a good legal understanding of the first licenses and the ability to translate his/her analysis into another contractual document. From a legal point of view, any mistake will bare serious and actual contractual consequences. Such legal analysis and drafting are often left to Contract or Intellectual Property lawyers when companies need a license, but for a lay individual author, seeking legal advice and writing will not be an option.
Tools could (semi-)automatically do this task. To understand licenses, a tool needs to have the licenses in a machine-readable language. ccREL6 is the language used by Creative Commons to represent their licenses. L4LOD7 is a similar lightweight language. MPEG-218 is an ISO standard that permits the expression of licenses. ODRL9 is a W3C standard made to represent complex types of policies. In this work we rely on the ODRL vocabulary for its capacity to express complex contextual constraints thanks to constraints and refinements. The ODRL vocabulary provides concepts that convey basic legal provision such as permission, duty and prohibition. The vocabulary targets the usage of content or services. A license can be considered as an ODRL Ofer, an ofer is composed of a list of rules and of an assigner, here it is the person licensing the resource. A rule is an abstract representation of a permission, a duty, or a prohibition, which we call status in this work. Each rule concerns one action in a status. As stated, ODRL allows expressing licenses with complex contexts thanks to constraints and refinements . An ODRL constraint allows to restrict a given rule to a specified context. While an ODRL refinement allows to further precise an action in a rule.
Figure 1 shows a graphical representation of three licenses (see in Appendix A their ODRL expression). L1 contains three rules (A, B, and C). Rule A permits the distribution of the target with a constraint (dateTime > 2030) and a refinement of the action Distribution (mediaType on TV and online streaming). Rule B obliges a compensation (payAmount of 1000$). And Rule C prohibits Commercial Use until 2050 in Europe. After 2050, this rule is not applicable and the user has to refer to standard copyright rules. L2 contains also three rules (D, E and F). Roughly speaking, with L2 the target can be distributed until 2050 on TV, online streaming, and movies (rule D). It can also be distributed without time constraint on printed medias as journals and books (rule E). But L2 has a prohibition of distribution on TV before 2040 (rule F).
The license that would protect a new resource combining resources protected by L1 and L2 should
L1
L2 L3 = L1 • L2
Permits Obliges Prohibits
Distribution Compensate Commercial
Use Permits
Distribution Prohibits
Distribution Permits
Distribution Obliges Prohibits
Compensate Commercial
Use Prohibits
Distribution
dateTime > 2030 mediaType ∈ {TV, online streaming} payAmount = 1000$ dateTime ≤ 2050 spatial ⊆ Europe dateTime ≤ 2050 mediaType ∈ {TV, online streaming, movies}
License
Rule status action constraint refinement mediaType ∈ {journals, books}
dateTime ≤ 2040 mediaType ∈ {TV}
2030 < dateTime ≤ 2050 mediaType ∈ {online streaming}
2040 < dateTime ≤ 2050 mediaType ∈ {TV} payAmount = 1000$ dateTime ≤ 2050 spatial ⊆ Europe dateTime ≤ 2040 mediaType: ∈ {TV} (1) contain every prohibition and duty of L1 and L2 (i.e., the prohibitions and duties of L1 and L2 are propagated), and (2) contain the intersection of the permissions of L1 and L2 that are not in contradiction with the propagated prohibitions and duties. If such a license exists, it must be equally or more restrictive than both L1 and L2. In our example, neither L1 nor L2 can be this license. We cannot determine which one is more restrictive because neither fully encompasses the other. Neither contains at least the same prohibitions and obligations as the other, nor does either include at most the same permissions as the other.
We argue that L3 in Figure 1 meets requirements (1) and (2). L3 is the least restrictive license that complies to L1 and L2 because, on the one hand, it includes all the prohibitions and duties propagated by L1 and L2 (and no more) with the minimal constraints and refinements necessary to ensure compliance with both licenses. On the other hand, it retains as many permissions as possible without contradicting the propagated prohibitions and obligations, while keeping constraints and refinements to a minimum. Concretely, L3 includes every duty and prohibition described by L1 and L2. It does not contain the permission E of L2, as there is no permission in L1 which intersects with the constraint and refinement of E. Finally, L3 contains the permissions A of L1 and D of L2 as the permissions A•D’ and A•D". These two rules contain the intersection of the constraints and refinements of A and D, except what is stated as prohibited by F. Other licenses that would comply to L1 and L2 are licenses that are compliant with L3, but with additional constraints and refinements over the permissions than L3, and with more obligations and duties. This license would be more restrictive than L3. Indeed, following this idea, a lot of more restrictive licenses compliant to L1 and L2 may exist.
Obtaining L3 automatically is challenging and still an open problem [
Thus, our problem statement is how to automatically build a license that complies with a set of complex licenses containing constraints and refinements? The challenge is to guarantee that such a license is the least restrictive license equally or more restrictive than the complex licenses it complies to. In this paper we propose CLiC (Complex License Composition), an approach to build a license by composing a set of complex licenses. The main idea of our approach is to order constraints and refinements based on their restrictiveness using a set-based comparison. This approach guarantees that the resulting license is the least restrictive license that can be used to cover a resource combining source materials protected by diferent complex licenses. A implementation of CLiC is available on Git 10.
The rest of the paper is structured as follows. We present existing works in license composition in Section 2. We formally define CLiC in Section 3. We present two use cases in Section 4, one with Creative Commons licenses, and one with the complex licenses of Figure 1. Then we discuss about the limitation and future works surrounding CLiC in Section 5. Finally, Section 6 concludes the paper.
CLiC is an approach to license composition that builds upon but also goes beyond existing work. For
instance the study by Gangadharan et al. [
The work by Mesiti et al. [
The paper by Governatori et al. [
DALICC [
The model CaLi proposed in [
In conclusion, none of the existing works on license composition can compose the license L3 of our
motivating use case. That is why we propose CLiC. As most of the approaches described in this section
[
A complex license is a set of rules. Each rule concerns a status, a specific action, a collection of constraints, and a collection of refinements. Composing two complex licenses therefore devolves into comparing the rules of the original licenses to find the least restrictive set of rules that composes the new license, with the right constraints and refinements. If a new license can be composed from a set of source licenses, our set-based approach for comparing domains assures that the new license integrates every prohibition and duty contained in the source licenses, and that it contains as much permissions as possible, leading to the least restrictive license compliant to an original set of licenses.
In this section we describe CLiC, our approach to compose a set of licenses into a new license. Section 3.1 introduces the formal definitions that allow to compare constraints and refinements in the context of a status and an action. Section 3.2 introduces the algorithm that, based on these definitions, allows to obtain the least restrictive license that is compliant to the licenses it composes. 3.1. Formal comparison of constraints and refinements based on their restrictiveness To compare the rules of diferent licenses, we need to be able to compare the constraints and refinements of diferent rules based on restrictiveness. This section introduces three definitions. Definition 1 formally defines the restrictiveness order over collections of constraints while Definition 2 formally defines the restrictiveness order over collections of refinements. With these definitions we can finally define complex licenses in Definition 3. 12https://en.wikipedia.org/wiki/Join_and_meet
In the following, we formalize a constraint and a collection of constraints as a set of constraints of distinct types, e.g., a temporal constraint and a spatial constraint. Limiting collections to have constraints of distinct types allows for an easier comparison of two collections. In addition, it does not reduce the variety of licenses that can be expressed, because two constraints of a same type can be expressed as a single constraint by utilizing the intersection of their domains, e.g., the two constraints (dateTime < 2050) and (dateTime ≥ 2030) can be joined as (2030 ≤ dateTime < 2050).
After defining collections of constraints, we also formalize the restrictiveness relation between collections in the context of a status.
Constraint. We define a constraint in the context of a given status as a pair (︀ , )︀ where the corresponds to a combination of the Operator and rigthOperand. ifrst element is the type of the constraint and the second element is the domain of the constraint. We name the set of all possible constraints in the status . In ODRL, corresponds to leftOperand and
We define a collection of constraints as a set of constraints, each with a diferent type. We name the list of types present in a collection of constraints. We formally define all the possible collections of constraints as a subset of the powerset of , ℘ (), given a status : = { ∈ ℘ () |∀, ∈ , = =⇒ = } Restrictiveness relation over the set of constraints . We consider that, (i) for the status Prohibition and Duty, given two constraints , context of a same status, ≤ , if ≤ if = ∧ ⊇ ∈
, the former constraint is less restrictive than the latter in the = ∧ ⊆ . And (ii) for the status Permission, . For instance, this allows to establish a restrictiveness relation for the constraints of C and F in Figure 1 as (dateTime ≤ 2040) ≤ ℎ (dateTime ≤ 2050). Restrictiveness relation over the set of collections . From that relation over constraints, we define a restrictiveness relation ≤ over by comparing pairwise the domains of the constraints that have the same type in the context of the same status . The intuition is that for every status, the collection whose constraints are always equally or less restrictive than the constraints of another collection is equally or less restrictive than that other collection.
For ∈ {, ℎ}: ∀, ∈ , ≤ ⇐⇒ ⊆
∧ (∀ ∈ , ∃ ∈ , such that ≤ ) For ∈ { }: ∀, ∈ , ≤ ⇐⇒ ⊇ ∧ (∀ ∈ , ∃ ∈ , such that ≤ ) (1) (2) (3)
For practicality, we also redefine two set operators over collections of constraints: the intersection, and the subtraction. The operators are defined using the equality of the type of the constraints from two collections, and the intersection or subtraction of the constraints’ domains. The intersection, noted as ∩, is the intersections of all the constraints in two collections, defined as follows: for ∩ = { ∈ |∃ ∈ , ∃ ∈ , ︁( = = = , ∈ , ∩ ︁) } .
And the subtraction, noted as − , is a collection where the domains of its constraints have been subtracted by the domains of the constraints of another collection. It is obtained by performing the following operation: for two collections of constraints , ∈ , for every constraint ∈ , if there exists a constraint , ∖ ︁) is one of the constraints of − , ∈ with the same type as , then (︁ otherwise, is one of the constraints of − .
An example of a constraint is (dateTime, {| > 2050}), it limits the dates on which a rule is applied to every dates that comes after the year 2025. And an example of a collection of two constraints is {(dateTime, {| > 2050}) , (spatial, {| ⊆ limits the place targeted by the rule to be within Europe.
Europe})}, in addition of the previous constraint, it
We define a refinement, a collection of refinements, and the restrictiveness relation between collections of refinements in the same way. The diference between constraints and refinements is that a constraint is defined in the context of a status, while a refinement is defined in the context of a status and of an action. That is because a refinement redefines an action to a more specific application.
We define a refinement
in the context of a given status and of a specific action as a pair ︀( , )︀ where the first element is the type of the refinement and the second element denotes the domain of the refinement. We name
ℛ, the set of all possible refinements for the status and action .
We define a collection of refinements as a set of refinements, each with a diferent type. We name the list of types present in a collection of refinements . We formally define all the possible collection of refinements for a given status and a given action as ℰ, : ℰ, = { ∈ ℘ (ℛ,) |∀, ∈ , = =⇒ = } Restrictiveness relation over the set of refinements ℛ,. As with constraints we define the restrictiveness relation between two refinements. On a given action, for the status Prohibition and Duty, for status Permission, ≤ , if = ∧
⊇ two refinements , ∈ ℛ,, then ≤ , if = ∧ ⊆
. For instance, this allows us to . And for the establish a restrictiveness order for the refinements of D and A in Figure 1 by saying that ( ∈ { , , }) ≤ , ( ∈ { , }). Restrictiveness relation over the set of collections ℰ,. From that relation over refinements, we deifne a restrictiveness relation order ≤ , over ℰ, by comparing pairwise the domains of the refinements that have the same type in the context of the same status and action . The intuition is that for every status paired with an action, a first collection where the refinements are always equally or less restrictive than the refinements of a second collection is then equally or less restrictive than that second collection.
For ∈ {, ℎ}: For ∈ { }: ∀, ∈ ℰ,, ≤ , ⇐⇒ ⊆ ∧ ︀( ∀ ∈ , ∃ ∈ , ≤ , )︀ (4) (5) (6) ∀, ∈ ℰ,, ≤ , ⇐⇒ ⊇ ∧ ︀( ∀ ∈ , ∃ ∈ , ≤ , )︀
Additionally, in the same way as for two collections of constraints, we define the intersection of two ℛ,|∃ ∈ , ∃ ∈ , (︁ = = collection of refinements. The intersection is defined as follows: for =
∩ ︁) , ∈ ℰ,, ∩ = { ∈ }. The subtraction, noted − , is obtained by performing the following operation: for two collections of refinements , ∈ ℰ,, for every refinement ∈ , if there exists a refinement ∈ with the same type as , then ︁( ,
∖ ︁) is a refinement of − , otherwise, is a refinement of − . to only concern distribution on TV and in American English.
An example of a refinement on the action distribute is (mediaType, {TV}), which redefines the action to only concern distribution on television. And an example of a collection of refinements on the same action would be {((mediaType, {TV}) , (language, {en-US})}, which redefines the action
With the definition of a collection of constraints and a collection of refinements, it is possible to define a complex licenses as a set of rules. Each rule contains a status and an action, and that rule can be limited by a collection of constraints and a collection of refinements.
Rule. Let be a set of status, be a set of actions, be a set of collections of constraints for a status , and ℰ, be a set of collections of refinements for a status and an action . A rule is a tuple (, , , ) defined on × × × ℰ ,. The collections of constraints and refinements should be understood as a conjunction. That means that all the constraints and refinements present in a rule need to be satisfied, otherwise the rule cannot be exercised. For a rule (, , , ), we name respectively ., ., ., and . each of its element.
Complex license. A license is a set of rules, each defined on × × × ℰ ,. Note that ∅ ∈ and ∅ ∈ ℰ,, meaning that it is possible for a rule in a complex license to have no refinements and no constraints. We denote by the set of rules assigned to the action with the status in the license , e.g., is the list of rules in the license relating to the status and to the action .
For example, the license L1 given in Figure 1 can be expressed as follows: 1 : { (Permission, Distribution, {(dateTime, {| > 2030})}, {(mediaType, {TV, online streaming})}) , (Duty, Compensate, ∅, {(payAmount, {1000$})}) , (Prohibition, Commercial Use, {(dateTime, {| ≤ 2050}) , (spatial, {| ⊆ Europe})}, ∅) } 3.2. An algorithm to compose complex licenses With the ability to compare constraints and refinements in the context of a status and an action, it is possible to compare the rules of a set of complex licenses. By comparing and composing the rules of two complex licenses, we can obtain the least restrictive license that is compliant to that pair. For that, we propose the Algorithm 1.
Algorithm 1 describes the function compose which, from two complex licenses and , returns the least restrictive license compliant to and or an empty set if it is not possible. To achieve that we perform four steps for every action present in or . We have as hypothesis that the licenses and are correct and do not contain any rule preventing re-licensing (e.g., the obligation Share Alike, or the prohibition of Derivative Works).
Step 1. Propagation of Duties and Prohibitions. Line 5 adds every prohibition and duty defined for a specific action in or to the resulting license. This guarantees that the resulting license will be compliant to and in regards to the prohibitions and duties. Additionally, as we keep the constraints and refinements within the prohibitions and duties, we ensure that the resulting license is as not restrictive as possible. Lines 6 to 10 remove from the resulting license every unnecessary prohibition or duty. That is, every prohibition or duty whose constraints and refinements are equally or less restrictive than another prohibition or duty (cf. Definition 1 and 2). This efectively simplifies the resulting license by removing rules that are contained in another rule.
Step 2. Detection of incompatible Duty and Prohibition. Lines 11 to 13 detect if a couple of propagated duty and prohibition makes the composed license incoherent. If that is the case, compose returns an empty set because the licenses are incompatible and a compliant license cannot exist.
Step 3. Addition of the intersection of Permissions. For each pair of permissions, one coming from and one from , the lines 14 to 16 compose a new permission and add it to the resulting license. The created permission concerns the same action as the original pair of permissions, and it contains the intersections of the collections of constraints and of refinements from that original pair. By using the intersection of the collections, we ensure that the created permission will be as not restrictive as possible while still being equally or more restrictive than the original pair.
Step 4. Ensuring coherency of Permissions vis-à-vis the Duties and Prohibitions. Lines 17 to 24 ensure the coherency of the domains of Permissions vis-à-vis the domains of Duties and Prohibitions by removing the values of the domain of each permission that contradicts a prohibition or duty. For that, our approach consists of only keeping subsets of each permission. Lines 18 to 24 keep the subsets of each permission which do not contradict a prohibition or duty, those correspond to the parts of which the collections of refinements or constraints do not intersect with the collections of refinement or constraints of the prohibition or duty. We only add back the parts with non-empty collections. Lines
20 and 21 keeps the subset of the permission that has diferent refinements from the prohibition or duty, without changing its constraint. This corresponds to the collections of refinements of the prohibition or duty subtracted to the collection of refinements of the permission (cf. Definition 2). Then, Lines 22 and 23 keeps the subset of the permission that has the same refinements as the prohibition or duty, but diferent constraints. This corresponds to the intersection of the collections of refinements (cf. Definition 2) and to the collection of constraints of the permission minus the collection of constraints of the prohibition or duty (cf Definition 1). Finally, on Line 24, the subsets of each Permission replace the Permissions of the new license.
This section illustrates our approach with the composition of two pairs of licenses, one simple case and one complex case. The simple use case concerns Creative Commons licenses, which do not contain constraints or refinements. It is developed in Section 4.1. The complex use case is the one shown in Figure 1, it explores most steps of Algorithm 1. It is developed in Section 4.2. 4.1. Use case with Creative Commons licenses A simple example, such as the composition of Creative Commons licenses, helps showcasing the soundness of Algorithm 1. We describe the composition of CC BY13 and CC BY-NC14 whose composition produces CC BY-NC. That is because CC BY-NC is compliant to CC BY.
The expressions of CC BY and CC BY-NC following Definition 3 are shown in Figure 2. The license CC BY permits the five actions Distribution, Reproduction, Sharing, Derivative Works, and Commercial Use. It obliges the actions Notice and Attribution, and it prohibits none. The license CC BY-NC permits the four actions Distribution, Reproduction, Sharing, and Derivative Works. It obliges the actions Notice and Attribution, and it prohibits the action Commercial Use.
When composing licenses with no contextual constraints or refinements, Algorithm 1 keeps every duty and prohibition present in at least one license, and every permission present in both licenses. Step 1 of Algorithm 1 will add to the new license the obligations of Notice and Attribution, originating from the two licenses as well as the prohibition of Commercial Use. Step 3 adds permissions contained in both CC BY and CC BY-NC. Steps 2 and 4 of the algorithm have no impact in this example. The resulting composed license is perfectly equivalent to CC BY-NC. 4.2. Complex use case with constraints and refinements This section explains how CLiC obtains the license L3 of Figure 1 using Algorithm 1. We first describe the licenses L1 and L2 from Figure 1 as complex licenses (cf. Definition 3). The license L1 corresponds to the following complex license. We name the rules of L1 respectively A, B, and C according to Figure 1. 1: { (Permission, Distribution, {(dateTime, {| > 2030})}, {(mediaType, {TV, online streaming})}) , #A (Duty, Compensate, ∅, {(payAmount, {1000$})}) , #B (Prohibition, Commercial Use, {(dateTime, {| ≤ 2050}) , (spatial, {| ⊆ Europe})}, ∅) #C } The license L2 corresponds to the following complex license. We name the rules of L2 D, E, and F. 2: { (Permission, Distribution, {(dateTime, {| ≤ 2050})}, {(mediaType, {TV, online streaming, movies})}) , #D (Permission, Distribution, ∅, {(mediaType, {journal, books})}) , #E (Prohibition, Distribution, {(dateTime, {| ≤ 2040})}, {(mediaType, {TV})}) #F}} 13https://creativecommons.org/licenses/by/4.0/deed.en 14https://creativecommons.org/licenses/by-nc/4.0/deed.en
In the following paragraphs, we compose the complex licenses L1 and L2 following Algorithm 1.
Step 1 adds every duty and prohibition from L1 and L2 into the new license, this leads to the addition of three rules, the duty B and the prohibition C from L1 as well as the prohibition F from L2. As there is no duty or prohibition contained in another prohibition or duty, we keep every rule in the new license.
Step 2 verifies if the composition is possible. It verifies that no pair of rules defined on a same action, one with the status Duty and one with the status Prohibition, have intersecting collections of constraints and refinements. This example has no issue because the rule B is defined on the action Compensate, while the rules C and F are defined on the actions Commercial Use and Distribution.
Step 3 composes rules A and D, and rules A and E, but the latter has no result. On the one hand, the combination of rules A and E does not lead to a new permission as their collections of refinements have no intersection, i.e., ( mediaType, {TV, online streaming}) ∩ (mediaType, {journals, books}) = ∅. On the other hand, the combination of rule A in L1 and rule D in L2 leads to the new rule A•D. This new rule is defined on the status Permission, the action Distribution, and contains the intersection of the collections of both original permissions as its collections of constraints and refinements. Here, the intersection of the collections of constraints is {(dateTime, {| > 2030})} ∩ {(dateTime, {| ≤ 2050})}, which is equal to the collection: {(dateTime, {|2030 < ≤ 2050})}. And the intersection of the collections of refinements is {(mediaType, {TV, online streaming})} ∩ {(mediaType, {TV, online streaming, movies})}, which is equal to the collection {(mediaType, {TV, online streaming})}. Therefore, this step adds (temporally) the rule A•D = (Permission, Distribution, {(dateTime, {|2030 < ≤ 2050})}, {(mediaType, {TV, online streaming})}).
Step 4 ensures that the permissions of the new license do not contradict its prohibitions or duties. Therefore, rule A•D is compared with duty B and prohibitions C and F. The comparison of rule A•D with B and C does not raise any issue as A•D is defined on the action Distribution, B on the action Compensate, and C on the action Commercial Use. The comparison of rules A•D and F is more complex as both are defined on the action Distribution. Therefore, A •D is removed from the new license and two new rules are created, named A•D’ and A•D”. A•D’ and A•D” are versions of A•D with truncated collections of constraints and refinements that prevent the potential contradiction with the prohibition F. Following the formulas of Algorithm 1, the two rules are the following: A•D’ = (Permission, Distribution, {(dateTime, {|2030 < ≤ 2050})}, {(mediaType, {online streaming})}), and A•D” = (Permission, Distribution, {(dateTime, {|2040 < ≤ 2050})}, {(mediaType, {TV})}).
After the four steps, the new license created corresponds to the following complex license, which equals the license L3 in Figure 1.
3: { (Permission, Distribution, {(dateTime, {|2030 < ≤ 2050})}, {(mediaType, {online streaming})}) , #A · D′ (Permission, Distribution, {(dateTime, {|2040 < ≤ 2050})}, {(mediaType, {TV})}) , #A · D′′ (Duty, Compensate, ∅, {(payAmount, {1000$})}) , #B (Prohibition, Commercial Use, {(dateTime, {| ≤ 2050}) , (spatial, {| ⊆ Europe})}, ∅) , #C (Prohibition, Distribution, {(dateTime, {| ≤ 2040})}, {(mediaType, {TV})}) #F }
As described, CLiC will allow for data re-use by providing a way to automatically compose new licenses in order to cover a material derived from diferent sources (see Figure 3, left part). From a lay person’s point of view, such an automatisation of the license’s composition based upon various licenses with complexes constraints that defer from one another will ofer a relief. As the analysis and composition efort is handled by the algorithm, CLiC is an incentive for data-sharing. In this regard, our research ofers promising perspectives for digital rights management in complex data-sharing scenarios.
The next step of such a work will be to translate the machine-readable composed license into natural language (see Figure 3, right part). Indeed, so far the composed license is ofered in a machine-readable format but, in order to reach maximum utility, the license will need to be translated in a natural language in order not to condition its reading and application to the use of complex computer means. In this regards, it seems only logical to convey a contractual document, such as a license destined to human Resource 1 Machliicneen-sreea2dable Resource 2 Machine- readable
license 3 Resource 3 composition
Machine-readable composed license A
Resource combined from resources 1, 2, and 3.
translation
Natural language composed license A
Resource combined from resources 1, 2, and 3.
CLiC – Complex License Composition users, into a language that humans can make sens of. From a legal point of view, this human-readable license will be a prerequisite to demonstrate the license’s existence in the case of a legal action as trying to enforce in court a machine-readable version of the license will prove to be complex and will question its validity. However, this essential task of translation, from machine-readable to natural language can also be computerised as well, using the ODRL vocabulary15. Indeed, the definitions attached to each ODRL concept can be retrieved in order to draft the natural language’s license with the selected constraints. As RDF is structured in triples (subjects predicate object), defining simple phrases from a machine-readable license in RDF is possible. Indeed, it would be possible to define a template in English using the traditional structure of a license, beginning with a preamble, followed by definitions that clarify the terms and actions used. Next, the permissions, prohibitions, and obligations could be outlined, and the template may conclude with the conditions under which the license may be revoked and the legal consequences of non-compliance.
Some limits of such an enterprise have to be acknowledged. Indeed this type of automatic natural language drafting of a license will create a very simple and direct legal document which will be very diferent from what one would have expected from a license. In other words, the "drafting style" will constitute a limit. For instance, if the new composed license prohibits the commercial use of the resource, the drafting might read: "Prohibition: the licensee has the inability to exercise commercial use over the resource" as the definition of a prohibition, under ODRL, is "The inability to exercise an Action over an Asset". Such a drafting is understandable and will be enforced in a court of law. However, some users might want to correct the style and grammar in order to obtain a more human-readable friendly version. Moreover, one might want to adapt the text by translating it into another language such as French or German in order to adapt the license to its domestic context. This translation of the translation is not a legal prerequisite in order to enforce a license but might appear useful in order to disseminate the covered resource as the targeted re-users might better understand the text in her/his native language. Such translation from one natural language to another will not be provided by ODRL as the vocabulary is only published in English. With regards to those various limits, the user will be invited to pay attention to the human-readable document provided for, warning that the license need some improvement and proof-reading.
To facilitate the composed license’s proof-reading, the next step, for the user, could be to use a Large Language Model (LLM). Such tool can easily re-word the composed license to make-it more human-friendly by generating the necessary and appropriate words. Here, again, the limits of this process should be acknowledged. The first will be that depending on the LLM used and its training data, the generated text’s quality will vary a lot. Indeed, if the LLM has mostly been trained on English data, then it will perform better on a license drafted in English than on its translated versions in other languages. Additionally, cautions should be taken when using LLMs to take into account potential risk of harm. For instance, the composed license provided to the LLM should not include any personal data, as those generative AI hardly comply with data protection regulations due to a series of technical limitations that include the memorisation of personal data and their possible unwanted regurgitation. Moreover, the user should monitor the generated content to ensure that no license’s term has been modified and that the added text does not modify the intended meaning of the license. Therefore, human proof-reading and verification remain the essential last step of the process in order to ensure the license’s correctness and, where appropriate and needed, a last review by a legal counsel. Such next steps will raise additional questions outside of the real of license composition such as in terms of the usability and the explainability of a license.
In this work, we propose CLiC, an approach to compose complex licenses that include constraints and refinements, as defined by ODRL. The core idea of our approach is to order constraints and refinements based on their restrictiveness using a set-based comparison. This method ensures that the resulting license is the least restrictive one capable of protecting a resource that combines resources protected by diferent complex licenses. Our contribution includes a set of definitions that formalize our approach, as well as an algorithm to facilitate its implementation.
CLiC aims to simplify and encourage the reuse and publication of licensed resources. It does not intend to provide legal advice but rather to ofer a practical solution for users who may not seek such advice yet wish to combine various resources and generate an appropriate license. CLiC provides a tool that ensures the composed complex license does not infringe upon the licenses of the reused resources. By alleviating the burden of extensive legal analysis and the comparison of multiple licenses, CLiC introduces an innovative perspective as a data-sharing management tool. A future direction of this work is to define a methodology for translating machine-readable licenses into human-readable ones. Such a process could leverage the ODRL vocabulary, LLMs to enhance readability, and human verifications.
During the preparation of this work, the author(s) used ChatGPT to improve grammar and for spelling. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
The three licenses of Figure 1 in ODRL using the Turtle syntax. @ p r e f i x r d f : < h t t p : / / www. w3 . org / 1 9 9 9 / 0 2 / 2 2 − r d f − s y n t a x − ns #> . @ p r e f i x r d f s : < h t t p : / / www. w3 . org / 2 0 0 0 / 0 1 / r d f −schema #> . @ p r e f i x o d r l : < h t t p : / / www. w3 . org / ns / o d r l / 2 / > . @ p r e f i x c c : < h t t p : / / c r e a t i v e c o m m o n s . org / ns #> . @ p r e f i x xsd : < h t t p : / / www. w3 . org / 2 0 0 1 / XMLSchema#> . @ p r e f i x : < h t t p : / / example . com/ > . : L1 a o d r l : O f f e r ; o d r l : p e r m i s s i o n [ r d f s : l a b e l "A" ; a o d r l : P e r m i s s i o n ; o d r l : a c t i o n [ r d f : v a l u e c c : D i s t r i b u t i o n ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " TV " @en " o n l i n e s t r e a m i n g " @en ) ] ] ; o d r l : c o n s t r a i n t [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : g t ; o d r l : r i g h t O p e r a n d " 2 0 3 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ] ] ; o d r l : o b l i g a t i o n [ r d f s : l a b e l " B " ; a o d r l : Duty ; o d r l : a c t i o n [ r d f : v a l u e o d r l : compensate ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : payAmount ; o d r l : o p e r a t o r o d r l : eq ; o d r l : r i g h t O p e r a n d " 1 0 0 0 " ^ ^ xsd : d e c i m a l ; o d r l : u n i t < h t t p s : / / d b p e d i a . org / page / U n i t e d _ S t a t e s _ d o l l a r > ] ] ] ; o d r l : p r o h i b i t i o n [ r d f s : l a b e l " C " ; a o d r l : P r o h i b i t i o n ; o d r l : a c t i o n c c : CommercialUse ; o d r l : c o n s t r a i n t [ a o d r l : L o g i c a l C o n s t r a i n t ; o d r l : and ( [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 5 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e
Listing 2: License L2 expressed with ODRL. : L2 a o d r l : O f f e r ; o d r l : p e r m i s s i o n [ r d f s : l a b e l "D" ; a o d r l : P e r m i s s i o n ; o d r l : a c t i o n [ r d f : v a l u e c c : D i s t r i b u t i o n ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " TV " @en " o n l i n e s t r e a m i n g " @en " movies " @en ) ] ] ; o d r l : c o n s t r a i n t [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 5 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ] ] , [ r d f s : l a b e l " E " ; a o d r l : P e r m i s s i o n ; o d r l : a c t i o n [ r d f : v a l u e o d r l : compensate ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " j o u r n a l s " @en " books " @en ) ] ] ] ; o d r l : p r o h i b i t i o n [ r d f s : l a b e l " F " ; a o d r l : P r o h i b i t i o n ; o d r l : a c t i o n [
r d f : v a l u e c c : D i s t r i b u t i o n ;
o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " TV " @en ) ] ] ; o d r l : c o n s t r a i n t [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 4 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ] : L3 a o d r l : O f f e r ; o d r l : p e r m i s s i o n [ r d f s : l a b e l "A . D ’ " ; a o d r l : P e r m i s s i o n ; o d r l : a c t i o n [ r d f : v a l u e c c : D i s t r i b u t i o n ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " o n l i n e s t r e a m i n g " @en ) ] ] ; o d r l : c o n s t r a i n t [ a o d r l : L o g i c a l C o n s t r a i n t ; o d r l : and ( [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : g t ; o d r l : r i g h t O p e r a n d " 2 0 3 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e
Listing 3: License L3 expressed with ODRL. o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 5 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ] ) ] ] , [ r d f s : l a b e l "A . D ’ ’ " ; a o d r l : P e r m i s s i o n ; o d r l : a c t i o n [ r d f : v a l u e o d r l : compensate ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " TV " @en ) ] ] ; o d r l : c o n s t r a i n t [ a o d r l : L o g i c a l C o n s t r a i n t ; o d r l : and ( [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : g t ; o d r l : r i g h t O p e r a n d " 2 0 4 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 5 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ] ) ] ] ; o d r l : o b l i g a t i o n [ r d f : l a b e l " B " ; a o d r l : Duty ; o d r l : a c t i o n [ r d f : v a l u e o d r l : compensate ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : payAmount ; o d r l : o p e r a t o r o d r l : eq ; o d r l : r i g h t O p e r a n d " 1 0 0 0 " ^ ^ xsd : d e c i m a l ; o d r l : u n i t < h t t p s : / / d b p e d i a . org / page / U n i t e d _ S t a t e s _ d o l l a r > ] ] ] ; o d r l : p r o h i b i t i o n [ r d f s : l a b e l "C" ; a o d r l : P r o h i b i t i o n ; o d r l : a c t i o n c c : CommercialUse ; o d r l : c o n s t r a i n t [ a o d r l : L o g i c a l C o n s t r a i n t ; o d r l : and ( [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 5 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ] , [ r d f s : l a b e l " F " ; a o d r l : P r o h i b i t i o n ; o d r l : a c t i o n [ r d f : v a l u e c c : D i s t r i b u t i o n ; o d r l : r e f i n e m e n t [ o d r l : l e f t O p e r a n d o d r l : mediaType ; o d r l : o p e r a t o r o d r l : isAnyOf ; o d r l : r i g h t O p e r a n d ( " TV " @en ) ] ] ; o d r l : c o n s t r a i n t [ o d r l : l e f t O p e r a n d o d r l : dateTime ; o d r l : o p e r a t o r o d r l : l t e q ; o d r l : r i g h t O p e r a n d " 2 0 4 0 − 1 2 − 3 1 " ^ ^ xsd : d a t e ]