Hi Peter,

Bumping this up a bit conceptually.  I do agree that the timing and sophistication of tooling to support SPDX deserves additional discussion.  The comments below speak a bit more to the intent, so hopefully we will get additional discussion on this topic.   

One of the intents of normalization is to move the open source community to more standard licenses with less non-material reorganization of words, single-word changes, etc. 

In prior discussions regarding template licenses like BSD, there has always been an intent to parse out items such as organization names.  Other items, like the BSD tendency to swap copyright “Holder” vs. “Owner” and other small but potentially material items would likely be dealt with by an agreement with our legal representatives and the broader SPDX community regarding what the “standard” license is (or should be), and having other variants be bumped to “non-standard” in a package and being required to list the full text.

The expectation is that by standardizing the licenses that will move people in the direction of using the standard rather than the small variants.  Over time, the requirements for tool sophistication with regards to license identification will be reduced – there would essentially be a requirement for an exact match other than agreed upon template items.  Companies that participate in SPDX or want to take advantage of SPDX will benefit by moving towards the standard.

Our “bail out” has consistently been that if the match is insufficient, the entire license text is listed.  We can get a lot of mileage out of a straightforward approach that starts with exact match minus white space, capitalization etc., and then progressing to removal agreed upon template items, and then optionally progressing to small, agreed upon word changes such as single v plural, British use of Z rather than S, etc.  But we only do this with the full agreement of the legal team and possibly some extension in to the SPDX group and open source community – the approach is conservative, with anomalies kicked out into the full text being required.

The net is that the reasonable alternative to tool sophistication is the progressive standardization of the licenses which should occur over time if we get the adoption that we are aiming for.

That aside, the declared license field (the field where the preparer states their interpretation of the license given the relevant facts) is an opportunity to state the license based on broader interpretations that include a more sophisticated tool, access to a particular resource individual such as the author or open source projects attorneys, etc.

My thought is that we start with a basic approach (exact match minus white space and caps, and grow from there) .  If we do this for the beta, that will give us an opportunity to pilot the approach with “friends and family” and have ongoing discussions in our group regarding the viability of the approach, and make necessary adjustments.   

Tom

Tom Incorvia

tom.incorvia@...

Direct:  (512) 340-1336

Mobile: (408) 499 6850