Property to tag public domain-compatible sources

[quincylvania]

Hi folks! Over at OpenStreetMap US we've recently started piloting our Public Domain Map tool. PDMap is an interim database based on the OSM tech stack, but with a more permissive license. It allows groups that are limited to public domain-licensed data, such as US government agencies, to setup open mapping tasks via the OSM US Tasking Manager. Once data is mapped and validated, it will become available as an OSM data source.

Public Domain Map uses a fork of the iD editor that relies on 100% public domain-compatible data sources. We'd love to integrate the editor-layer-index and simply filter out any non-PD sources, but there's currently no machine-readable property indicating PD compatibility. I propose adding a property such as this:

"pd_compatible": {
    "description": "Whether data derived from this source is compatible with a public-domain-equivalent license",
    "type": "boolean"
}

Existing consumers can simply ignore this flag. Note that the imagery itself needn't be in the public domain so long as the license indicates compatibility for derived data.

[simonpoole]

Hi Quincy

We used to have a license field that likely could be reinstated that contained a superset of the information.

[quincylvania]

Oh neat, I thought I remembered a license field. I see it corresponded to the SPDX license codes and was removed in e84572e3bc019944d762e80a7b63ae049b53d0ab due to lack of use.

I'm not certain that restoring this exact approach is the way forward. I think it's pretty common for sources to use nonstandard licenses, or for them to grant exceptions to open data projects beyond the stated license. But even if each source had a correct SPDX code, it would still leave it up to each consumer to parse permissions, which sounds laborious and error-prone.

Maybe we could restore the license field but generate the pd_compatible flag from a list of compatible licenses, unless pd_compatible is already set explicitly?

[pnorman]

27 discussed this, and resulted in the decision that the index is specific to OSM editors, and not suitable for use by other projects.

[tordans]

In case the topic of "which attributes does ELI have about license info" get some activity, lets also have look into a possible field to describe the required changeset.source-tag. I ran into this again and again, eg https://github.com/osmlab/editor-layer-index/pull/933#issuecomment-994571440.

---

However, to solve this issue more quickly, it might be easier to setup a processing separate repo that has an allowlist of ELI-IDs that are compatible, pulls and filters ELI entries and redistributes it for use in this iD Fork…

[andrewharvey]

We could have fields:

1. license SPDX license of original data/map (perhaps supporting some extensions like USGOV-PD for US Government works in the public domain)
2. explicit_permission Relying on explicit permission specific to OSM beyond the license, eg. work CC-BY but due to this not being compatible with OSM, an explicit waiver was provided. This could be a boolean or a URL to the waiver (I feel the current permission_osm values explict, implict and no are too vague)
3. license_url Useful where custom license terms apply and there is no SPDX code. It could also specify the URL to the license but not that useful when a standard license applies. (currently in the schema)

Therefore any works specific to OSM only would have either explicit_permission set to true or a URL value.

[cicku]

The complexity introduced is why it was abandoned before.

[simonpoole]

Not really complex or that much work given that we need to determine the licence in any case. What it probably would need is a bit more guidance than was previously provided.

1. license SPDX license of original data/map (perhaps supporting some extensions like USGOV-PD for US Government works in the public domain)

One of things IIRC I suggested was a simple "commercial" as a catch all for non open licences.

[quincylvania]

However, to solve this issue more quickly, it might be easier to setup a processing separate repo that has an allowlist of ELI-IDs that are compatible, pulls and filters ELI entries and redistributes it for use in this iD Fork…

Yes, we'd probably end up doing this for Public Domain Map if the data isn't added to ELI. It doesn't matter to me. But by adding it to ELI, other projects could benefit.