On Thu, Mar 3, 2011 at 5:31 AM, Tom Incorvia
<tom.incorvia@...> wrote:

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.

I like the goal but i don't see how standardizing a license
normalization algorithm designed to remove non-material variations
advances this goal.

In prior discussions regarding template licenses like BSD, there has always
been an intent to parse out items such as organization names.

I think everyone agrees we need to handle this case.

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.

Having a registry of licenses with standardized text (particularly
good, well formatted, cut-and-pastable text) may increase the use of
those licenses. However, i don't think we can assume that license
variations will ever be reduced to point that users will be able to do
without sophisticated matching. Even it that does happen someday, it
is not the world we live in today.

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.

Maybe. Personally, i doubt we will ever see the day when there are
few license variation than there are now.

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.

If we did this, what would a non-match due to a non-material variation
mean? (Say some "a"s where switched to "an"s.)

Could i, as a human, look at it and decide that it is clearly one of
the standard licenses and so produce an spdx file in when the licenses
in file and concluded licenses both reference the standard license?
Or would i be forced to use a non-standard license (even though is is
clearly one of the standard licenses)?


Peter
openlogic.com