OGD-2.0 in its current form can be used to define the license of the datasets it describes. However, the standard does not mention the license of the metadata itself (e.g. an XML-dump of an OGD-2.0 description of a catalogue) at all. Since OGD-2.0 is all about exchanging metadata, this topic should be covered.
For example, if I import OGD-2.0 metadata into CKAN, then that metadata will be available via CKAN's API under the Open Database License. Quoting CKAN's dataset creation form:
The data license you select above only applies to the contents of any resource files that you add to this dataset. By submitting this form, you agree to release the metadata values that you enter into the form under the Open Database License.
Of course the same issue arises with other forms of automatic or manual distribution of the metadata.
Obviously we cannot force users of OGD-2.0 to license their OGD-2.0 metadata under a certain license. However, we can require this from users who want to be officially compatible with the standard ("KONFORM" according to section 1.4). Instead of picking one license we could also require these users to choose one of our approved licenses (and to document their choice). In the latter case, that information should be stored directly in the OGD-2.0 metadata, so that it is available to automatic tools.
For example, assume I'm the maintainer of a data portal that harvests datasets via OGD-2.0 from multiple other portals. Then I will need to document the license(s) of the metadata that I'm making available via my portal. For example, my API documentation could contain something like the following:
The metadata available via this API contains information from multiple sources and is licensed as follows:
Metadata provided by the Kingdom of Farfaraway is licensed under the Open Royal Metadata license.
Metadata provided by Gotham City is licensed under the Bruce Wayne Open Justice license.
...
It is clear that offering users a choice for the license of their metadata leads to major headaches (are the licenses of different portals that I harvest from compatible? How do I attribute each piece of metadata with the appropriate licensing information, etc.).
I therefore strongly suggest to force all conforming users to license their OGD-2.0 metadata under a single, prescribed license.
Comments
+1. Wäre also ein Attribut des "Catalogues". It would be a catalogue attribute
I agree with this issue, but not completely with the proposed solution.
The appropriate DCAT property is dct:license for class dcat:Catalog:
This links to the license document under which the catalog is made available and not the datasets. Even if the license of the catalog applies to all of its datasets and distributions, it should be replicated on each distribution.
https://www.w3.org/TR/vocab-dcat/#Property:catalog_license
I do not think that it is good to mix technical conformance criteria with legal conformance criteria.
Each catalog can have its own metadata license.
Thanks for mentioning dcat:Catalog's dct:license. We have to make sure that there is no confusion regarding ODG-2.0's Katalog.lizenzID (which is an optional attribute for speciyfing the default license of Element).
You're probably correct that adding legal constraints to a technical standard is problematic. Nevertheless I still see the problem of clearly communicating the license of harvested metadata to end users of the various end points (web sites, APIs, dumps, ...): Although OGD-2.0 groups datasets (Elements) in catalogues, that grouping is often not used in portal databases, which usually store just the datasets (e.g. CKAN). That means that I need to store the metadata license (in addition to the data license) for each individual dataset so that I can display it later on. Of course that's completely feasible, just something to keep in mind.
In my opinion the most important point is that OGD-2.0 should clearly communicate the differences between the licenses of data and metadata and should offer a way to define each of them.
Thank you very much for this point of license of GovData metadata itself.
Our point of view is the following:
In our current solution DCAT-AP.de we do not yet address the topic.
Metadata as such, seeing it as the former EDV meaning of table names and entities of a datastructure of a database to our knowledge cannot be protected and licensed – as such – according to the German copyright law (see §69a “Gegenstand des Schutzes” “[...] Schnittstellen zugrundeliegenden Ideen und Grundsätze, sind nicht geschützt. in https://www.gesetze-im-internet.de/urhg/BJNR012730965.html)
This might be the reason we do not have this requirement of expressing license for the metadata itself in our GovData community. At the same time we see ISA adms (https://joinup.ec.europa.eu/asset/adms/home ) and other ISA created metadata vocabulary being published under the ISA open metadata licence.
This license is hosted by an official body, translations into MS languages exist and it sounds like an appropriate match for the metadata instance data on open data sets that was suggested here to be licensed by default by kind of a single prescribed license for all data being that is “transported” with DCAT-AP.de.
We will discuss this issue and whether this is a future GovData requirement to be addressed in one of the next meetings of our steering committee (Fachgruppensitzung).