Towards Licenses Compatibility and Composition in the Web of Data

Abstract

We propose a general framework to attach the licensing terms to the data where the compatibility of the licensing terms concerning the data a ected by a query is veri ed, and, if compatible, the licenses are combined into a composite license. The framework returns the composite license as licensing term about the data resulting from the query.

Introduction

The absence of clarity concerning the licensing terms does not encourage the reuse of the data in the Web of Data [ 3 ]. When consumers query the Web of Data, results from di erent datasets, and thus released under di erent licensing terms, are provided. In this paper, we propose rst to verify the compatibility among the licensing terms associated to a query result, and second, to compose, if compatible, the distinct licensing terms for creating a composite license. The composite license is retuned together with the query result using the standard SPARQL query results XML format by means of the <link>1 element. We adopt Semantic Web languages only, and reuse the Creative Commons (CC) licenses schema [ 1 ] to de ne the anatomy of our licenses. Licenses are composed by models: cc:Permission, cc:Requirement, and cc:Prohibition. Models are composed by elements eli like ShareAlike, Attribution, and many others. We choose CC because it provides a general schema for licenses speci cation, even if there are works which should not be released under the CC licenses [ 5, 3 ]. For addressing this issue and covering a wider range of machine-readable license speci cations, we align the CC vocabulary with the other schemas including licensing terms (Figure 1). We extend and adapt existing proposals for licenses compatibility and composition in the area of service license analysis [ 2 ] to the Web of Data scenario. However, the di erent application scenarios (service composition vs Web of Data) open di erent problems. The compatibility rules we de ne are di erent, and the de nition of the composite license mirrors the same di erences. Truong et al. [ 6 ] address the issue of analyzing data contracts using RDF for the contracts representation. This work concentrates on data contracts and not on data licenses. Krotzsch and Speiser [ 4 ] present a semantic framework for evaluating ShareAlike recursive statements while we address the problem of licenses composition. ? The author acknowledges the support of the DataLift Project ANR-10-CORD-09. 1 http://www.w3.org/TR/rdf-sparql-XMLres/#head omv:hasLicense omv:LicenseModel doap:license gr:License pvroeamgi:sh:alsiLciecnesnesTeeTrympse subPropertyOf cc:license pvroeamgi:sL:iLciecnesnesMeoIdneflormation subClassOf cc:License nie:license vivo:License mo:license meb:License Licenses Compatibility. We de ne a set of compatibility rules assessing the possible compatibility among the elements composing the licenses L, following [ 2 ] for service licenses. First, there are certain elements which are broader in scope of permission than other elements, e.g., Sharing is more permissive than Reproduction [ 1 ]. The subsumption rules2 for cc:Permission elements, and the way they can be combined are shown in Table 1. Table 2.a shows whether an element el1 is compatible with another element el2, i.e., el1 el2, concerning cc:Permission elements3. The rationale is that these elements are compatible if there is a subsumption relation between them.

Subsumption More permissive Less permissive DerivativeW orks Sharing DerivativeW orks Sharing

Distribution Reproduction Distribution Reproduction DerivativeW orks Reproduction DerivativeW orks Reproduction

Sharing Reproduction Sharing Reproduction

DerivativeW orks Distribution DerivativeW orks Distribution

Second, a possible situation in analyzing license compatibility is that one license Li speci es clauses which are not speci ed by the other license Lj , e.g., Li speci es cc:Prohibition and Lj does not specify this clause. Table 2.b shows the compatibility rules for speci ed elements against Unspeci ed elements4. The requirement for speci cation of Attribution does not a ect the compatibility with Unspeci ed (the same holds for Notice, SourceCode, and CopyLeft ). Concerning prohibitions, these elements are not compatible with Unspeci ed, e.g., commercial use is the default setting of the licenses, thus we cannot assume compatibility if commercial use is denied by NonCommercial. For permissions, we follow the \conservative" approach where unspeci cation means a denial of compatibility5. 2 Subsumption means that there is a compatibility if a certain license element eli is more permissive, i.e., it accepts more, than the other license element elj. 3 Rules are expressed under the form of truth tables where elements are evaluated as compatible T , or incompatible F . 4 We interpret unspeci ed elements as \do not care", as in [ 2 ]. 5 Table 2.c shows three exceptions of compatible elements from distinct models.

el1 el2 el1 el2

Sharing DerivativeW orks T Reproduction Distribution T Reproduction DerivativeW orks T Reproduction Sharing T Distribution DerivativeW orks T

Sharing Distribution F

(a) el1 el2 L1 L2 Attribution ShareAlike T el1 ^ el2 Attribution NonCommercial T el1 ^ el2 ShareAlike NonCommercial T el1 ^ el2 (c)

el1 el2

Notice Unspecified Attribution Unspecified ShareAlike Unspecified SourceCode Unspecified

CopyLeft Unspecified

NonCommercial Unspecified HighIncomeNationUse Unspecified

Reproduction Unspecified

Distribution Unspecified DerivativeW orks Unspecified

Sharing Unspecified (b) T T T T T F F F F F F

Let L(C) be the set of licenses associated to the named graphs a ected by the consumer's query, we say that two licenses are compatible if the models in both the licenses are compatible [ 7 ]. The models are compatible if (i) the models are the same, (ii) the models are composed by elements which satisfy the compatibility rules (Table 2.c), and (iii) their elements are compatible. The elements are compatible if (i) the elements are the same, (ii) the elements satisfy the subsumption rules (Table 1), (iii) the elements satisfy the compatibility rules against Unspeci ed (Table 2.b), and (iv) the elements satisfy the compatibility rules (Table 2.a-c). If the licenses are not compatible, then we leave to the data provider to decide the strategy to deal with this situation, e.g., the data is returned together with the more constraining license among L(C).

Licenses Composition. If the licenses are compatible then we compose them such that the resulting composite license Lc ( is the composition relation) satis es the following properties: Lc can be generated only if all the licenses composing it are compatible, and Lc is consistent with the set of licenses used to compose it. The de nition of Lc is achieved through the de nition of (i) rede nition rules to be applied in case a subsumption relation holds (Table 1), (ii) composition rules necessary to maintain the consistency of Lc w.r.t. L(C) (Table 2.c), and (iii) heuristics to compose the elements of each license into Lc. We consider three basic heuristics: OR-composition: 8l 2 Li then l 2 Lc; AND-composition: if 9l 2 L1 ^ : : : ^ Ln then l 2 Lc; Constraining-value: most constraining l 2 L(C) is included in Lc. We leave to the data provider the choice of her best strategy for composing the licenses, e.g., AND-composition typically leads to a shorter and simpler license, while OR-decomposition leads to a more complex license where all the clauses in L(C) are listed. For example, assume we want to analyze two licenses L1 and L2 (Figure 2.a-b). We rst compare the two licenses at the model level. Both licenses contains the model cc:Permission. Even if the two elements are not the same, there is a subsumption relation between them (Table 1). The rst license does not contain the model cc:Prohibition and the :licComposite a cc:License; THE ELEMENTS cc:permits cc:DerivativeWorks; cc:requires cc:ShareAlike; cc:prohibits cc:CommercialUse.

THE MODELS: - Permission - Requirement - Prohibition second license does not contain the model cc:Requirement. However, the two elements cc:ShareAlike and cc:CommercialUse are compatible (Table 2.c). Thus, the two licenses are compatible. Lc is obtained using the more permissive permission, and the OR-composition heuristic. 3

Future challenges

The rst point to be addressed is a legal and social validation of the proposed framework. This means to evaluate, not only quantitatively the performance of the algorithms to retrieve remote licensing statements referenced in the data, but also the legal value of the composite license. We will address an evaluation of the disparate named graphs that might be used in a \typical" query, and their relative proportions that have compatible or incompatible licenses. Finally, we are de ning more complex heuristics like the one looking for the minimal composite license.

References

1. H. Abelson , B. Adida , M. Linksvayer , and N. Yergler . ccREL: The creative commons rights expression language . Technical report , 2008 .

2. G. R. Gangadharan , M. Weiss , V. D'Andrea , and R. Iannella . Service license composition and compatibility analysis . In ICSOC, LNCS 4749 , pages 257 { 269 , 2007 .

3. T. Heath and C. Bizer . Linked Data: Evolving the Web into a Global Data Space . Morgan & Claypool, 2011 .

4. M. Kr otzsch and S. Speiser . Sharealike your data: Self-referential usage policies for the semantic web . In ISWC, LNCS 7031 , pages 354 { 369 , 2011 .

5. P. Miller , R. Styles , and T. Heath . Open data commons, a license for open data . In LDOW , 2008 .

6. H. L. Truong , G. R. Gangadharan , M. Comerio , S. Dustdar , and F. De Paoli. On analyzing and developing data contracts in cloud-based data marketplaces . In APSCC, IEEE , pages 174 { 181 , 2011 .

7. S. Villata and F. Gandon . Licenses compatibility and composition in the Web of Data . In COLD , 2012 .