Now that the technical sub-group has initiated its work i think it would
be worth having a issue tracking system. This would allow us to
reliably track issues with the spec and to make sure nothing falls
through the cracks.

Peter Williams
<http://openlogic.com>
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx

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

From: Kim Weins <kim.weins@...>
Subject: Re: SPDX Agenda/Minutes
To: "dmg" <dmg@...>, "Philip Odence" <podence@...>
Cc: "spdx@..." <spdx@...>
Date: Wednesday, September 8, 2010, 6:05 PM
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 :)



On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence
<podence@...>

wrote:

Per discussion late meeting, agendas will be going

out in bodies of emails

and minutes will go out as links to archive at

spdx.org.

I'll strive to get minutes out a week in advance,

though I'm behind this

time. Here's where they are posted (note that Kate

is still editing, so they

won't be final until tonight) http://www.spdx.org/wiki/minutes-26aug2010
Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am

EDT / 16:00 GMT

Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS

AND WILL BE CHANGING IN THE

FUTURE.
Conference code:  7812589502
Toll-free dial-in number (U.S. and

Canada):  (877) 435-0230

International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of

toll free numbers can be

found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNu

mber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF

Web:
Note, we will be using a different URL for each

meeting for purposes of

taking attendance. When you login please include

your full name and company

name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/

Administrative Agenda

Attendance
Approval of minutes
Outreach and evangelism:

Common Messaging/Presentation ­ PhilO

Industry Venues ­ PhilR

Website ­ PhilO/Martin

Roll Out Plans - KimW/JohnE


Action Items
Note: Drafting related action items are embedded

in

the Wiki. http://www.spdx.org/wiki/spdx/specification

€ PhilO/Martin - Update on participation page

where to join (suggestion was

to put link in text, not just at top, consider "I

want to use the spec, vs.

I want to contribute to the spec" in navigation

section.

€ Kate- Transfer document (.pdf) back to WIKI.
€ PhilO- Update standard presentation with

LinuxCon2010 input

€ Kate- Clean up the sharing analysis to what is

accurate.

€ Kate- Publish the current version number of

the specification in brackets

behind reference
€ Kim/PhilO- Add and element of 'What's in this

for me?" to presentation

€ JeffL (w/Bill/Gary- Update zlib based on new

specification

€ All- Look for new examples to add to site.
€ PhilK- Explore possibility of LF hosting

source for SPDX tools.

€ Gary- Explore other possible hosting options
€ PhilO- Start making minutes available via

link.

€ BillS- Start up RDF sub-group. Solicite

members.

Technical Agenda

SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.


L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)

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

Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic

650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic

OpenLogic, Inc.
Headquarters, Broomfield, Colorado





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

From: Kim Weins <kim.weins@...>
Subject: New proposed field for project that a file came from
To: spdx@...
Date: Wednesday, September 8, 2010, 6:18 PM

I would like to propose a  new field in the file section.  The field would be used to identify the OSS component/package that a file originated from.  This is important since many packages will bundle other packages.  Knowing the license is important, but if you need to do any research on the file, knowing the component is even more important.

I am proposing this would be an Optional field.

5.6 OSS Project  
5.6.1 Purpose: Identify the name of the open source package or project where this file originated.
5.6.2 Intent: By providing the open source package, the reader can better identify the source and use it to do further research if needed.
5.6.3 Cardinality: Optional, single instance
5.6.4 Tag: "Project"
5.6.5 RDF: /RDF/SPDXDoc/Describes/File/Project
5.6.6 Data Format: Freeform text string
5.6.7 Example: Project: jUnit

Kim

Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic

650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic

OpenLogic, Inc.
Headquarters, Broomfield, Colorado

-----Inline Attachment Follows-----

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

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...]
On Behalf Of kate.stewart@...
Sent: Thursday, September 09, 2010 10:14 AM
To: dmg; Philip Odence; Kim Weins
Cc: spdx@...
Subject: Re: SPDX Agenda/Minutes

Hi Kim, Daniel,
Use case I'm worried about is how do we say what MUST be recognized
when all the licenses are on the web. What happens when we don't have
a stable base set of "must recognize" to conform.

If we make everything on the web, then the use case of including in
the spdx file, the full text of ALL licenses discovered (even if they
are ones that have a short form) - will conform to the specification.
Comparisons between analysis of the same package will become
"interesting".

Consider package "1" has licenses A, B, C, D in it. A, B, are on
the web site, C, D aren't. One analysis tool produces a file with
short form of A & B in the spec, C & D included verbatim. Another
analysis tool produces a file with A, B, C, & D included verbatim.
Both can be said to be SPDX 1.0, but if you compare both to each other,
you may not draw the conclusion that they are talking about the same
package.

On the other hand, I do understand the concern over not rev'ing the
spec too often to conform to license changes.

What do people think about the following for 1.0?

There is a base set of licenses, that MUST be recognized and
included as short forms, to conform, and they are captured in Appendix
I of the SPEC, as well as being on the web site. This gives the
potential for creating a spec which is all inclusive - full text of
licenses recognized as short forms, which others on the list have
indicated a need for. We include language in the spec, saying these
are the ones that MUST be recognized, but others on the website CAN be
recognized as well. When there is critical mass of changes to rev
the spec to 2.0; the set that is on the web site at that time, becomes
the MUST be recognized, and additions after that are CAN be recognized.
This avoids the point revision churn for licenses that John's afraid of,
allows an enforcement of a minimum set, and give a path to add new
licenses as they are nominated into the "active set".

Thoughts?

Kate

--- On Wed, 9/8/10, Kim Weins <kim.weins@...> wrote:

From: Kim Weins <kim.weins@...>
Subject: Re: SPDX Agenda/Minutes
To: "dmg" <dmg@...>, "Philip Odence"

<podence@...>

Cc: "spdx@..." <spdx@...>
Date: Wednesday, September 8, 2010, 6:05 PM
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 :)



On Wed, Sep 8, 2010 at 11:24 AM, Philip Odence
<podence@...>

wrote:

Per discussion late meeting, agendas will be going

out in bodies of emails

and minutes will go out as links to archive at

spdx.org.

I'll strive to get minutes out a week in advance,

though I'm behind this

time. Here's where they are posted (note that Kate

is still editing, so they

won't be final until tonight) http://www.spdx.org/wiki/minutes-

26aug2010

Meeting Time: Sept 9, 8am PDT / 10 am CDT / 11am

EDT / 16:00 GMT

Conf call dial-in:
NOTE: THIS NUMBER IS DIFFERENT FROM PAST NUMBERS

AND WILL BE CHANGING IN THE

FUTURE.
Conference code:  7812589502
Toll-free dial-in number (U.S. and

Canada):  (877) 435-0230

International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of

toll free numbers can be

found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/
viewNu

mber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF

Web:
Note, we will be using a different URL for each

meeting for purposes of

taking attendance. When you login please include

your full name and company

name, so I can just copy/pate into minutes. THX.
http://blackducksoftware.na6.acrobat.com/spdx9sept10/

Administrative Agenda

Attendance
Approval of minutes
Outreach and evangelism:

Common Messaging/Presentation ­ PhilO

Industry Venues ­ PhilR

Website ­ PhilO/Martin

Roll Out Plans - KimW/JohnE


Action Items
Note: Drafting related action items are embedded

in

the Wiki. http://www.spdx.org/wiki/spdx/specification

€ PhilO/Martin - Update on participation page

where to join (suggestion was

to put link in text, not just at top, consider "I

want to use the spec, vs.

I want to contribute to the spec" in navigation

section.

€ Kate- Transfer document (.pdf) back to WIKI.
€ PhilO- Update standard presentation with

LinuxCon2010 input

€ Kate- Clean up the sharing analysis to what is

accurate.

€ Kate- Publish the current version number of

the specification in brackets

behind reference
€ Kim/PhilO- Add and element of 'What's in this

for me?" to presentation

€ JeffL (w/Bill/Gary- Update zlib based on new

specification

€ All- Look for new examples to add to site.
€ PhilK- Explore possibility of LF hosting

source for SPDX tools.

€ Gary- Explore other possible hosting options
€ PhilO- Start making minutes available via

link.

€ BillS- Start up RDF sub-group. Solicite

members.

Technical Agenda

SPEC - current status and open areas - Kate
RDF focus group - current status - Bill
Tools - update from Gary, and others.


L. Philip Odence
Vice President of Business Development
Black Duck Software, inc.
265 Winter Street, Waltham, MA 02451
Phone: 781.810.1819, Mobile: 781.258.9502
podence@...
http://www.blackducksoftware.com
http://twitter.com/podence
http://www.linkedin.com/in/podence
http://www.networkworld.com/community/odence (my blog)

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

Kim Weins | Senior Vice President, Marketing
kim.weins@...
Follow me on Twitter @KimAtOpenLogic

650 279 0410 | cell
www.openlogic.com
Follow OpenLogic on Twitter @OpenLogic

OpenLogic, Inc.
Headquarters, Broomfield, Colorado





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

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

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