I also agree that we should decouple spec from licenses. We need a way to
add licenses without having to rev the spec. Otherwise we will get lots of
spec revisions or very few license updates.

I know there has been some concern that if the list of licenses is not
"fixed" with the spec version, you won't know what list of licenses you need
to be able to "understand" when you get an SPDX file based on a particular
version of the spec. I'd like to dig into this use case more, since it seems
to me that any tooling or even manual review processes can be designed to
just pull the latest and greatest version of licenses from the website.

The only issue is that you may get an SPDX file that has something marked as
an "Other" license that is now in the standard license repo. That
shouldn't really be a problem, since all the "Other" licenses will have full
license text in the SPDX file.

Here's an example:

Company A creates SPDX on 1/1/2011 using latest set of standard licenses at
that point. They identify:
File A has Standard License A
File B has Standard License B
File C has Other License C
File D has Other License D

On 2/1/2011, License C is added to standard license repo

Company B reviews SPDX on 3/1/2011
All of the info is still valid -- since License C and D are in the SPDX
file. Company B could choose to update the SPDX file as:
File A has Standard License A
File B has Standard License B
File C now has STANDARD License C
File D has Other License D


Am I missing something here?

Kim


On Wed 9/8/10 12:48 PM, "dmg"<dmg@...> wrote:

From the minutes:

Our implicit path had tied a fixed license list of licenses to the
spec rev, but JohnE put forth an impassioned argument as to why they
should be decouples...

I throw my support behind JohnE proposal. It addresses many of the
issues I have discussed before.

--dmg

(hopefully I can make wake up in time for the meeting, but it is tough
to only have 5 hrs of sleep :)