Add license information in the GTFS feed

[skalexch]

Describe the problem

Many GTFS feeds are published under licenses that might restrict certain aspects of re-use. The information for these license are often found on the agency websites and can be hard to find. This creates ambiguity for use cases of the GTFS, and might delay their ingestion in trip planners.

Use cases

Adding license information to the GTFS spec allows consumers to easily figure out what they can use the GTFS for, whether they can modify it, re-share it, etc.
For consumers who work with hundreds of GTFS, the operation can even be automatized using the license information in the GTFS.

Proposed solution

Solution 1) Adding fields to feed_info.txt since it can contain non-rider-facing information.

license_spdx_id: The SPDX ID of the GTFS feed license
license_name: The name of the license
license_url: linking to either the website of the license, to SPDX or to a page in the agency website that details the conditions of use of the GTFS.

Solution 2) Adding a file called license_info.txt containing license_spdx_id, license_name and license_url.

A drawback of this 2nd solution is be that license.txt is a popular non-CSV file for software in general.

Additional information

GBFS has license information. In v3, license_url and license_id (SPDX ID) are conditionally forbidden. That can be the case with GTFS by providing a license_id if it exists in the SPDX license list, otherwise prividing a license_url.

[skinkie]

From technical perspective: I would support feed_info.txt
From a legal perspective: Is this information even copyrightable?

[skalexch]

@skinkie in theory, it should be open and public. However, some producers/agencies have limits on what can be done to the data (also to limit their liability as well). Eg: London Transit Commission.

[antrim]

This thread from GTFS-changes may also be useful: https://groups.google.com/g/gtfs-changes/c/iDmt-vjs180/m/wMJI7LHGAQAJ

Complication: I believe some feeds may have different licenses for different data (e.g. alignments/shapes.txt).

[skinkie]

@antrim especially if the shapes.txt is derived from OpenStreetMap...

[skalexch]

@antrim @skinkie could there be a solution where the license_id would only be possible when the whole GTFS feed is under one license?
Otherwise, since we intend to make license_id and license_url mutually forbidden, we can link a detailed license_url that specifies special rules for files like shapes.txt

[mmorang]

Thanks for linking to that old thread, @antrim. I'm glad to see this topic still being discussed. With that said, after that discussion in 2017, I talked to my company's legal team. They said that even if there were machine-readable licensing information in the datasets, we would still have to individually check each one and potentially write a contract with the data provider. For this reason, I decided not to pursue the topic further at that time.

I'd be interested to know how folks who DO harvest datasets from all over the world and use them in commercial apps deal with licensing. And what do your legal experts say? Do they agree with mine?

[derhuerst]

I'd be interested to know how folks who DO harvest datasets from all over the world and use them in commercial apps deal with licensing.

Although it's not commercial, people from the transitous project can provide some insights on this, as they collect and automatically process hundreds of feeds. See also public-transport/transitous#18.

cc @jbruechert

[jbruechert]

We have something very similar to this proposal in our additional metadata.
We also use SPDX identifiers and urls referring to the entire feed. I'm obviously happy about every bit of metadata we don't need to collect ourselves and can be read from GTFS instead.

[derhuerst]

It would be great to also add a license fields to GTFS Realtime, mirroring whatever fields & semantics we decide for GTFS Schedule/Static.