The previous case-insensitive matching was removed in e5f46faa (test
required spdx-ids against data from spdx, 2016-05-25, #418). That
commit was designed [1] to allow case-sensitive matching as discussed
in [2]. But while I'm in favor of case-sensitive keys in spdx_list,
the case-sensitive match breaks script/check-approval which downcases
its argument since it was added in 8e56bb83 (add
script/check-approval, 2016-01-18, #318).
There are more notes on SPDX's plans for case sensitivity in [3], so
we should see a clearer policy there soon. I'm arguing for
case-sensitive *display* with optional case-insensitive matching. I
am optimistic that the SPDX will at least agree not to register short
IDs that only differ by case, which is all we need to make this
case-insensitive match safe here.
[1]: https://github.com/github/choosealicense.com/pull/418#issuecomment-221404630
[2]: https://github.com/benbalter/licensee/issues/72
[3]: https://github.com/spdx/spdx-spec/issues/63
that's where they're likely to be, outside of examples at the end
of long licenses
still want to check as if there are unknown [] fields in first
1000 characters, might be a field that should be filled in, but
wouldn't for lack of correct name
- document criteria for whether a license is hidden
- needed for license spectrum on /licenses OR
- on 'popular' list at https://opensource.org/licenses (some other list could be used in the future)
- adjust license properties and tests accordingly
This gets non-hidden list back close to what it was before #386 and (pending licensee vendoring this change, licensee release, and github.com licensee dependency version bump) some commonly requested licenses (eg #413#449) will reappear in the github.com license drop-down.
and are structured
grant (permissions)
conditioned on (conditions)
with limitations
Permissions coming first combats mistaken but apparently widespread
impression that licenses impose conditions, even such that without
a license, there would be no conditions/work would be in the public
domain.
Requirements->Conditions emphasizes that they are pertinent if one
wants to take advantage of permissions.
Forbiddens->Limitations is more accurate: in most cases licenses
don't give permission to hold licensors liable, in some cases to
use licensors' trademarks or patents, but a licensee does not lose
the permissions granted by the license if the licensee holds licensor
liable, etc. Also emphasizes that there are limitatations on the
license grant, not that the license imposes prohibitions.
The most concise place to see both the rename and reorder is in
_includes/license-overview.html
I did not reorder the appearance of the groups of properties in
license source files (.txt files in _licenses) as those orderings
are not used to render anything on the webiste. Might do so later.
