My initial response is, as always, that classifying and contesting the attributes of individual licenses largely misses the point. Indeed I wrote this to the European Commission in a recent submission a month back (¶ 51):
The debate on the best choice of data license or set of licenses rarely looks at the question of legal interoperability — meaning can material under one licence be mixed with material under another license and republished. Rather, the merits of individual classes of license are debated and then the merits of individual licenses. This same discussion takes place within our [energy systems analysis] community too. But this approach tackles the problem from the wrong end.
That said, the terms‑of‑use of each particular license are highly material — in relation to what users may do and how that material might be legitimately combined and distributed with material under other forms of public license.
To return to the question posed by @SimonPoole of whether the CC‑BY‑4.0 license can or should be considered copyleft. On first glance, the CC‑BY‑4.0 and CC‑BY‑SA‑4.0 licenses are typically regarded as “permissive” and “copyleft” respectively. While noting that that terminology was developed to classify software licensing — and that Creative Commons instead use the loosely related terms “attribution” and “share‑alike”. And in the software domain, copyleft licenses were designed to keep the covered code forever within the software commons — while permissive licenses intentionally allowed the covered code and any local improvements to migrate into proprietary software without the need to additionally reveal and return those improvements. If you wish, that latter action being a form of permitted enclosure, at least obliquely so.
So the broader question is essentially this: does the CC‑BY‑4.0 license force retention in the information commons? And conversely, does this particular license prevent downstream use in proprietary products. And the answers are yes and no, respectively. Some may consider those responses perverse perhaps? But one should also note that software can potentially exist in source and compiled forms and there is clearly no equivalent to binary‑only distribution for content — “binary” used here in the sense of executable files.
Stepping back, I agree with @SimonPoole that §2.a.5.B imposes copyleft‑like obligations in a similar fashion to the way that the GNU public license (GPL) family prohibits additional restrictions. I am going to ask about this clause elsewhere and will report back if I discover anything useful. Also to note that I read this earlier posting carefully and found it particularly instructive.
Regarding specific downstream use‑cases, deeming the CC‑BY‑4.0 to be inbound compatible with United Kingdom government OGL‑UK‑3.0, as that license does, would seem in contradiction of §2.a.5.B. We talked early about choice of law provisions in this regard. And indeed I observed that deemed interoperability could well be in conflict with the respective terms‑of‑use. That said, importing to OGL‑UK‑3.0 is also a use‑case of limited interest to me — but it will be for those working with United Kingdom public sector information. Similar claims of inbound‑compatibility are implied by the Linux Foundation in relation to their recent CDLA‑Permissive‑2.0 license. One certainly wonders how those compatibility assertions could have survived analysis by crown law offices and corporate legal departments.
Also needing examination are the notions of “licensed” and “adapted” material, as defined in CC‑BY‑4.0 under §1.f and §1.a respectively. I guess these notions derive from the free software presumption that every contributor retains their own copyright and the so‑called inbound=outbound precept such that the same license implicitly applies. Chestek (2017) examines these doctrines and argues that they should be abandoned in favor of a joint authorship doctrine. Nor has the inbound=outbound concept ever been tested in court, so its legal status remains uncertain in respect of computer code at least.
Regarding data specifically, the CC‑BY‑4.0 under §4 covers only 96/9/EC databases. Much of the data‑related material passed around in my community are just simple‑minded datasets — ranging from ASCII lists to HDF5 high‑performance storage formats — without the necessary seek functionality to attract database protection. Moreover, my community is starting to toy with semantic web technologies and the interaction between 96/9/EC and those technologies will doubtless be a nightmare.
As an aside, the 96/9/EC database directive is currently under review by the European Commission. My pick that is that database protection within the European Union will be removed in due course, possibly as soon as next year.
To close, my interest in data licensing is to go no more stringent that CC‑BY‑4.0. So the prohibition on significant downstream restrictions in §2.a.5.B is of no direct interest to me or most of my community.
That said, the free software world has been down the track of license proliferation. It would be very sad to see the OKF do likewise — by effectively promoting new licenses that create Open Definition-compliant legal silos because no one sought to fully analyze the wider context. Is that really the world that open data advocates would like to advance?
Finally, my earlier offer to the OKF to draft a position paper still stands. I remain concerned about no‑retreat or terminus licenses being applied to data and, in particular, the approval of new licenses that fall into this camp. Could the OKF respond either way? The ball is in your court!
References
Chestek, Pamela S (2017). “A theory of joint authorship for free and open source software projects”. Colorado Technology Law Journal. 16: 285–326. Open access.