Controlling the Use of Derived Data

[benedictws]

The rights assignment we're modeling is achieved by an Agreement Policy when the Assigner (the Originator or Provider of the Asset) assigns rights to the Assignee (the Consumer of the Asset). But what happens when that Consumer then turns Provider and assigns new rights?

This can occur in two use cases:

1. Redistribution: when the assignee of the original policy then distributes the resource to other consumers
2. Derivations: when the assignee of the original policy derives a "new work" and then uses and/or distributes the new resource

How does the original assigner continue to influence the distribution and use of these resources? That's certainly a use case we need to support.

ODRL provides the "next policy" duty mechanism to achieve just this. This Duty is specified in the agreement, and obligates the assignee to ensure that any policy they offer to control the re-distributed or derived resource must be compliant with the policy indicated by assigner's "next policy" duty.

[benedictws]

This calls for an example. This Permission from the CME's Category A license allows the derivation of data. But how does it control the use of the derived data?

cme:P2  a                       odrl:Permission ;
        rdfs:label              "Derive real-time data to support automated trading" ;
        odrl:action             odrl:Derive ;
        odrl:duties             cme:D3 , cme:D4 , cme:D6 , cme:D9 .

The trick is in the duty :D9:

cme:D9  a                   odrl:Duty ;
        nl:creditor         <https://permid.org/1-4295899615> ; # CME
        odrl:action         odrl:nextPolicy ;
        odrl:target         cme:U1 .

This duty requires that the output of the derivation be controlled by a new policy, cme:U1. This policy offers a single permission (that allows the derived data to be used (in any way) so long as the use it internal) and a single prohibition that explicitly disallows distribution to third parties.

cme:U1  a                       odrl:Set ;
        rdfs:label              "Internal use of derivations to support automated trading" ;
        odrl:permission         cme:P5 ;
        odrl:prohibition        cme:Pr3 .

So when the assignee of the original agreement comes to create a policy to control the use of their derived data, it must be compliant with the policy cme:U1. Allowing the data to be distributed to third parties would be an obvious violation.

In this way, although the CME does not own the derived data, they can still influence it's use.

[benedictws]

The Deutsche Boerse's non-display license offers three contrasting treatments for index calculations:

db:P6   a                   odrl:Permission ;
        dc:desciption       "Index calculations for automated trading" ;
        odrl:action         md:CalculateIndex ;
        odrl:duty           db:D7 .

db:P7   a                   odrl:Permission ;
        dc:desciption       "Index calculations for benchmarking and distribution" ;
        odrl:action         [    a                 md:CalculateIndex ;
                                 md:derivation     md:Irreversable , md:Non-Substitutive ;
                            ] ;
        odrl:duty           db:D8 .

db:P8   a                   odrl:Permission ;
        dc:desciption       "Index calculations for internal use excluding automated trading" ;
        odrl:action         md:CalculateIndex ;
        odrl:duty           db:D9 .

The key to the differences are in the next-policy duties db:D7, db:D8, and db:D9.

The policy pointed to by db:D7 only allows the indices to be used to support automatic trading. It prohibits onward distribution to third parties.

db:D8 points to a policy that allows the indices to be used for benchmarking and to be distributed to third parties. (What those third-parties can then do with the indices can be specified by a further next-policy duty on this distribution permission.)

While db:D9 points to a policy that allows internal use but excludes automated trading and onward distribution to third parties.

So when the assignee of permissions db:P6, db:P7, or db:P8 writes the policy to control the use of their derived data, they must write it to be consistent with the policy indicated by the next-policy duty. In this way, the original assigner continues to influence the value derived from their source data.

[markabird]

It's interesting, then, that a derived product with inputs from more than one Originator will potentially have multiple influences, and will need to adhere to them all.

[markabird]

Sometimes, further redistribution of source data in a derived product is controlled by the source data's originator requiring that the derived-product creator license/register their derived product with them.

The contractual control passes from general (you may receive my data and use it however you wish as long as you fulfill these general obligations) to specific (you may use may data to create this one specific derived product and in so doing must fulfill these obligations that apply just to that one derived product).