Gary O'Neall

@tsteenbe @swinslow I'm thinking this should be moved to 3.0 since it would be a breaking change. Agree?

Just commented on a similar topic in #49: From a tooling perspective, a license expression for a declared license is commonly constructed through machine analysis of discovered licenses and inserting...

> Mostly I want to avoid establishing a practice where e.g. any time an SPDX document creator isn't sure that they are accounting for every byte in a file, that...

@wking I tend to separate out the internal fields used by the legal team in the creating and maintenance of the licenses from the external fields used by tools. The...

@robinagandhi Good point on the possible (miss)interpretation. The definition of the property would be that the license is designated as "Free" by the FSF (see https://www.gnu.org/licenses/license-list.html). @jlovejoy @kestewart Thoughts?

In reviewing https://www.gnu.org/licenses/license-list.html, the FSF specifies "Free and Compatible with GPL", "Free and Incompatible with GPL" and "non-free". Do we need to capture all of these states? If so, do...

> That's good. On this front, I would prefer if *none* of the FSF/OSI material was maintained by the legal team. It should instead be maintained by the FSF and...

+1 on FsfLibre proposal

Completely agree on having an API. I would like to propose an additional approach. If a 3rd party provided a machine readable list or map which allows us to map...

Note that we could add this to the spec, but any updates to the information provided on the SPDX license list HTML pages (https://spdx.org/licenses) would be decided by the legal...