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 :)

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of Michael J Herzog
Sent: Thursday, September 09, 2010 7:22 AM
To: Kim Weins
Cc: spdx@...
Subject: Re: Decouple license list from the spec

+2 for decoupling the spec from the licenses. We need to be able to
update
the spec and the license list on different cycles. We should also
anticipate
that many orgs may want to keep a local copy of the SPDX license list.

Regards, Michael

Michael J. Herzog
+1 650 380 0680 | mjherzog_at_nexB.com
nexB [Open by Design] http://www.nexb.com

CONFIDENTIALITY NOTICE: This e-mail (including attachments) may
contain information that is proprietary or confidential. If you are

the intended recipient or a person responsible for its delivery to the
intended recipient, do not copy or distribute it. Please permanently
delete the e-mail and any attachments, and notify us immediately at
(650) 380-0680.


On 9/8/2010 4:05 PM, Kim Weins wrote:

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

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 :)

_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx