Require license_url, add attribution fields

[antrim]

license_url is an optional field in system_information.json (added in PR #49). This new pull request would make a backwards-compatibility breaking change to define license_url as mandatory. The outcome of the discussion related to versioning (issue #15) would define how such a change would be treated and incorporated into the spec.

This proposal would:

• Make feed_license a mandatory field.
• Add statement that a license_url being present but empty means the feed is released without a license (public domain).
• Add fields for attribution to the GBFS, partially borrowed from this GTFS-Attributions proposal.
• Add a limited inventory of licenses to the GBFS wiki, with implications of each.

[yocontra]

Can we use SPDX license IDs? This is what most OSS tools have converged around, and I think it makes sense here as well.

[antrim]

@contra : Makes good sense. I'll revise the PR.

[antrim]

I've revised the PR:

• Added license_id. This is a string that refers to the SPDX identifier.
• license_url and license_id are both conditionally required. Only one should be provided. If a standard license then feed publishers should specify license_id; if custom, then license_url.

Since the introduced requirement makes the change backwards-compatibility breaking, then this would need to be part of a MAJOR version. (see #188)

What this PR does NOT currently do:

• Make any recommendation with regard to particular licenses or custom vs. standard licenses. I was tempted to include a recommendation to use a standard license, but thought better of writing that sort of practice recommendation into the specification, at least before there is a more thorough research and stakeholder interview process.
• Allow SPDX License Expressions. This would allow multiple standard licenses to be applied or a standard license to be applied with modifications. I figured this would just add complexity now, and could be added later if necessary. LMK if that's wrong and this would be used immediately.

[antrim]

I hereby call a vote on this proposal. Because of the US Thanksgiving holiday, I propose we extend by 1 day. Voting will be open for 8 full days, until 11:59PM UTC on Tuesday, Dec 3.

Please vote for or against the proposal to add a data license, and include the organization for which you are voting in your comment.

[barbeau]

@antrim I know in some states (including Florida) Thursday and Friday are both considered holidays:
https://www.dms.myflorida.com/workforce_operations/human_resource_management/for_state_personnel_system_hr_practitioners/state_holidays

...so I'd suggest giving two additional days to account for this.

[antrim]

Following @barbeau 's suggestion, I'd like to extend the voting period until 11:59PM UTC on Dec 6 to accommodate the USA Thanksgiving holiday.

Please vote, and note if you can commit to implementing this proposal.

[yocontra]

+1 from Stae

[madupras]

+1 from PBSC

[quicklywilliam]

+1 Ride Report

[evansiroky]

+1 from IBI Group

[antrim]

Voting has closed and this changed has been passed. Four votes were in favor:

• IBI Group (Developer of OpenTripPlanner, GBFS consumer)
• Stae (Vendor)
• PBSC (Vendor / GBFS producer)
• Ride Report (GBFS consumer)

@MobilityData is refining how we'll implement the versioning scheme (#188). We'll merge this once we arrive at a sensible release process (see #163).

[antrim]

Merged - branch deleted.

[heidiguenin]

We'd love to make this an official part of the spec, but first we need to see this change being implemented. Could you comment here if your organization has implemented this? [Sorry to those of you fabulously active community members who will see this message over and over again today!]

@evansiroky @quicklywilliam @madupras @contra Others?

[madupras]

We still have multiple months before tackling this change at PBSC. It's in our "GBFS version 2" internal project which is planned for the Q3/Q4 2020.