Date   

Issue tracking

Peter Williams <peter.williams@...>
 

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>


Re: Issue tracking

Martin Michlmayr
 

The Linux Foundation has a Bugzilla instance that we should be able to
use.

* Peter Williams <peter.williams@...> [2010-09-07 16:25]:

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
--
Martin Michlmayr
Open Source Program Office, Hewlett-Packard


SPDX Agenda/Minutes

Philip Odence
 

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/viewNumber.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.
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


Re: SPDX Agenda/Minutes

dmg
 

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/viewNumber.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



--
--dmg

---
Daniel M. German
http://turingmachine.org


Re: SPDX Agenda/Minutes

Kim Weins
 

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


Re: SPDX Agenda/Minutes

Bruno Cornec <Bruno.Cornec@...>
 

Kim Weins said on Wed, Sep 08, 2010 at 05:05:46PM -0600:

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.
Which in fact solves the point I had during the conf call this week.

If the license is known to spdx, then we can point to a uri/url linked
to spdx.org having it full text. If not, the full text is then embedded,
as long as the license doesn't become official, in which case, it can be
further offloaded from the SPDX file.

Meaning we could have:

File A has Std license: "http://www.spdx.org/license/GPLv2"
File B has Other license embedded "this is the free beer license..."

Thus keeping duplication to a minimum.
Bruno.
--
Open Source & Linux Profession Lead EMEA / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net
http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org


New proposed field for project that a file came from

Kim Weins
 


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





Re: Decouple license list from the spec

Michael J Herzog <mjherzog@...>
 

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


Re: SPDX Agenda/Minutes

kate.stewart@...
 

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


Re: New proposed field for project that a file came from

kate.stewart@...
 

Thanks Kim,

    Will add it into the agenda to discuss tomorrow on the SPEC section.

    If anyone feels strongly about this field, and can't attend the call,  please send email to the list so we have your input.

Thanks, Kate


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

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


Re: New proposed field for project that a file came from

Gary O'Neall
 

I’ll be on the call, but I thought I would throw in my 2 cents in advance of the call.

 

I like and agree with the proposal.  I think it adds a lot of value to the spec.

 

One slight modification/addition.  Having just the name of the OSS package may not be sufficient to uniquely identify the package.  I would propose having a URL which references the OSS project homepage – or – a free text field with the OSS project name.  To make this easier to parse by non-humans, I would suggest having 2 optional fields:

 

5.6 OSS Project (ass proposed)

5.7 OSS Project URL

5.7.1 Purpose: Identify the project home page of the open source package or project where this file originated.
5.7.2 Intent: By providing the URL for the open source package, the reader can uniquely identify the source and use it to do further research if needed.
5.7.3 Cardinality: Optional, single instance
5.7.4 Tag: "ProjectURL"
5.7.5 RDF: /RDF/SPDXDoc/Describes/File/ProjectURL
5.7.6 Data Format: URL
5.7.7 Example: Project: http://www.junit.org

 

Gary

From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of kate.stewart@...
Sent: Wednesday, September 08, 2010 7:20 PM
To: spdx@...; Kim Weins
Subject: Re: New proposed field for project that a file came from

 

Thanks Kim,

    Will add it into the agenda to discuss tomorrow on the SPEC section.

    If anyone feels strongly about this field, and can't attend the call,  please send email to the list so we have your input.

Thanks, Kate

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


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

 


Re: SPDX Agenda/Minutes

Soeren_Rabenstein@...
 

Dear All,

By uncoupling licenses and standard, I see a high risk, that we end up in many different quasi-sub-standards of spdx.

As in the example, what if several users of the license C and D give different license name tags to them, before they eventually get adopted by the license list?

One Spdx file says
1. Standard | License A
2. Standard | License B
3. Custom | License C (attached license text x)
4. Custom | License D (attached license text y)

Another one, describing the same package, says
1. Standard | License A
2. Standard | License B
3. Custom | License 3 (attached license text x)
4. Custom | License 4 (attached license text y)

And another spdx file, describing a DIFFERENT package says
1. Standard | License A
2. Standard | License B
3. Custom | License C (attached license text z)
4. Custom | License D (attached whatever)

Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding).

Therefore my opinion is to include in V.1.0 as many licenses as possible.
Target should not be: include 80% of the licenses in Red-Hat;
Target should rather be: include 100% of the licenses we know of.
Why would it hurt us to include more licenses in the standard upfront?

Once we have done this, there should not be so many revisions due to additional licenses.
How many new FOSS licenses are established per year? I do not think it is too much nowadays.

The only thing that may happen frequently is that someone adds a single special clause to a well known license.
For these cases I would like to propose again to include a system to capture such slight variations by referring to the original version and describe the changes only.

E.g. The newer ECos-License (http://ecos.sourceware.org/license-overview.html) does not need to be an own license in the standard.
The license describer could rather look like

DeclaredLicense = GPLv2
LicenseVariation = yes
VariationContents =
++ As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.
++ However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License.
++ This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License.

... or something the like.


Kind regards

Soeren Rabenstein

____________________________________________________________
 
ASUSTeK COMPUTER INC.
 
Soeren Rabenstein, LL.M.
Legal Affairs Center - Legal Compliance Dept.
15, Li-Te Rd., Taipei 112, Taiwan
Tel.: (+886) 2 2894 3447 Ext.2372
Fax.: (+886) 2 2890 7674
soeren_rabenstein@...
____________________________________________________________

-----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
=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================


Re: SPDX Agenda/Minutes

dmg
 

hi Soeren

On Thu, Sep 9, 2010 at 2:05 AM, <Soeren_Rabenstein@...> wrote:
Dear All,

By uncoupling licenses and standard, I see a high risk, that we end up in many different quasi-sub-standards of spdx.

As in the example, what if several users of the license C and D give different license name tags to them, before they eventually get adopted by the license list?

One Spdx file says
1. Standard      | License A
2. Standard      | License B
3. Custom        | License C (attached license text x)
4. Custom        | License D (attached license text y)

Another one, describing the same package, says
1. Standard      | License A
2. Standard      | License B
3. Custom        | License 3 (attached license text x)
4. Custom        | License 4 (attached license text y)

And another spdx file, describing a DIFFERENT package says
1. Standard      | License A
2. Standard      | License B
3. Custom        | License C (attached license text z)
4. Custom        | License D (attached whatever)
I think for a version 1 this is a very acceptable outcome. The package
is described in a very simple way. We know it has 4 licenses, they are
all extracted
and placed in a well defined "blurb". All a person (or more likely a
tool) needs to do is parse the 4 blurbs. That is addresses one of the
major problems of
Ninka and Fossology want to address: to find the license.

Sure the files will work on their own. But if I eventually want to update them all to the newest standard, I will end up in either a lot of mismatches, or in a lot of manual work; i.e. the very two things spdx shall avoid (in my understanding).
The way I'd solve t is by allowing two types of license descriptor:

1. A text blurb that embeds the license (simple and straightforward)
2. A meta-license descriptor.

A meta license descriptor is a URI (any URI, not only spdx, but spdx
ones would be assumed to be widely known). The URI would indicate
information such as: type of license (reference or inclusion), any
variable parameters that need to be identified,
any potential variability (such as known variations in spelling or punctuation).

So we end with two standards:

1. Describing the licensing of the package (where a license is a URI
described by the license spec, it does not list _any_ specific
license)
2. The one describing the licenses form (which describes the forms
that licenses take).

This way the standards do not change when a new license is added.

Finally, SPDX will publish a list of (accepted|approved|blessed|loved)
licenses, including their URI. But others will be allowed to published
their own URIs for licenses. This could be standard #3.

The license describer could rather look like

DeclaredLicense = GPLv2
LicenseVariation = yes
VariationContents =
++ As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.
++ However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License.
++ This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License.
This is not a variant of the license, it is a different license. IMO,
variants really the same license but have different text (diff would
yield different results, I.e. British vs American spelling).
Variants are usually by inclusion.


--dmg


Re: SPDX Agenda/Minutes

Philip Odence
 

I have a thought that may help resolve.

In section 2 specify, in addition to the spec version, a license list version. So, to be compliant, an SPDX file MUST (Kate's emphasis) recognize all of the licenses in the license version list. In Kim's example, the SPDX file could be rev'ed to the new version of the list. So the 1/1/11 version of the file would be compatible with SPDX V1.0/License List V1.0 and the 3/1/11 would be compatible with SPDX V1.0/License List V1.1.

If someone was looking at two descriptions of the same package and there was a difference in the licenses, first thing they could do is check to see if both files used the same license list version.



On Sep 8, 2010, at 10:14 PM, <kate.stewart@...> <kate.stewart@...> wrote:

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




Re: Decouple license list from the spec

Soeren_Rabenstein@...
 

Dear all

I perfectly understand the concerns. But I would like to emphasize that
imho one of the benefits of spdx for the industry is to have unequivocal
names/indicator for licenses.
Now if there are let's say five new licenses, the names of which are
Amazing Public License,
American Public License,
Amateur Public License,
Amoral Public License, and
Amusing Public License.

...and all of them get tagged "AmPL" in the name tag by someone, then I
will certainly end up with misunderstandings and confusion,
notwithstanding the fact that the text of the different AmPLs are
embedded in the file.

For me the idea of unequivocal "declared license" tags has a lot of
beauty, as this way compliance can be streamlined and partly
automatized, as I can trigger a certain process for a given license tag
appearing in the spdx. If I still need to legally review each spdx,
because many of the applicable license texts are embedded there, I lose
some of the benefits that spdx can have in daily industrial application.

Best regards
Soeren

-----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
not
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
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 :)
_______________________________________________
Spdx mailing list
Spdx@...
https://fossbazaar.org/mailman/listinfo/spdx
=====================================================================================================================================
This email and any attachments to it contain confidential information and are intended solely for the use of the individual to whom it
is addressed.If you are not the intended recipient or receive it accidentally, please immediately notify the sender by e-mail and delete
the message and any attachments from your computer system, and destroy all hard copies. If any, please be advised that any unauthorized
disclosure, copying, distribution or any action taken or omitted in reliance on this, is illegal and prohibited. Furthermore, any views
or opinions expressed are solely those of the author and do not represent those of ASUSTeK. Thank you for your cooperation.
=====================================================================================================================================


Re: New proposed field for project that a file came from

Peter Williams <peter.williams@...>
 

On 9/8/10 11:58 PM, Gary O'Neall wrote:
One slight modification/addition. Having just the name of the OSS
package may not be sufficient to uniquely identify the package. I would
propose having a URL which references the OSS project homepage – or – a
free text field with the OSS project name. To make this easier to parse
by non-humans, I would suggest having 2 optional fields:
Rather than having two optional fields, perhaps we should have one optional field whose value is a doap:Project[1]. the DOAP[2] project has produced a great model of project information and we can easily leverage the subset of it that is useful to SPDX.

This would allow tools to embed as much or as little project information into the SPDX file as desired. It would also allow the utilization of existing data sources when they exist and doing so is desirable to participants of the data exchange.

5.6 Origin
5.6.1 Purpose: Identify the project where this file originated.
5.6.2 Intent: By providing data regarding the project where this file originated 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: "origin"
5.6.5 RDF: /RDF/SPDXDoc/Describes/File/origin
5.6.6 Data Format: doap:Project
5.6.7 Example:
Origin: Project: name: JUnit
homepage: http://www.junit.org

Peter
<http://openlogic.com>

[1]: http://en.wikipedia.org/wiki/Description_of_a_Project
[2]: http://trac.usefulinc.com/doap


5.6 OSS Project (ass proposed)

5.7 OSS Project URL

5.7.1 Purpose: Identify the project home page of the open source package
or project where this file originated.
5.7.2 Intent: By providing the URL for the open source package, the
reader can uniquely identify the source and use it to do further
research if needed.
5.7.3 Cardinality: Optional, single instance
5.7.4 Tag: "ProjectURL"
5.7.5 RDF: /RDF/SPDXDoc/Describes/File/ProjectURL
5.7.6 Data Format: URL
5.7.7 Example: Project: http://www.junit.org

Gary

*From:* spdx-bounces@... [mailto:spdx-bounces@...]
*On Behalf Of *kate.stewart@...
*Sent:* Wednesday, September 08, 2010 7:20 PM
*To:* spdx@...; Kim Weins
*Subject:* Re: New proposed field for project that a file came from

Thanks Kim,

Will add it into the agenda to discuss tomorrow on the SPEC section.

If anyone feels strongly about this field, and can't attend the call,
please send email to the list so we have your input.

Thanks, Kate

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


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@... </mc/compose?to=Spdx@...>
https://fossbazaar.org/mailman/listinfo/spdx



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


DOAP / SPDX collaboration

Bill Schineller
 

Hello Edd (DOAP project owner),

The SPDX (http://spdx.org) working group is involved in defining a
standard format for communicating the components, licenses and copyrights
associated with a software package. A number of our members including
myself are very familiar with RDF and DOAP. For the same reasons you picked
RDF XML and leveraged FOAF, we likewise picked RDF XML and realize our
vocabulary can reference DOAP. Currently, the SPDX effort is in the process
of translating the specification from wiki format into an OWL format. (Our
site does not yet reflect very well our choice of RDF XML as the machine
readable format...)

SPDX is focused on a deep analysis (on a per file level) of the licenses
used within an spdx:Package. As such SPDX is a specialist community and
actually does have the desire to own identifiers for licenses, and create
RDF descriptions of the licenses. (You stated this is out of scope of DOAP
http://www.ibm.com/developerworks/xml/library/x-osproj3/)

An spdx:Package is really any tarball of analyzed source code. Although
there is some (considerable?) overlap between concepts in SPDX and DOAP, we
believe the focus of SPDX is sufficiently narrow that it makes sense to keep
it separate from DOAP (i.e. not suggest we introduce new concepts into
DOAP). Rather, reference DOAP as appropriate.

For example, in some cases, an spdx:Package is equivalent to a
http://usefulinc.com/ns/doap#file-release

And in some cases, perhaps one might assert that
spdx:File spdx:origin doap:Project

(e.g. a specific file foo.java came from
http://usefulinc.com/software/gnome-bluetooth )

Also, we're experimenting with collaborating on the development of our
ontology using a free online tool knoodl.com (Note: we have no affiliation
with knoodl.com)
In order to facilitate developing our ontology to reference DOAP, it may
be useful to have the DOAP ontology loaded onto knoodl. I took the liberty
of uploading doap.rdf into knoodl.com being sure to reference you and your
site; it lives at
http://knoodl.com/ui/groups/DOAP/vocab/DOAP(trunk,19)

We would welcome you to join the SPDX group (self register for the mailing
list at spdx.org). We would value your advice and collaboration.

Thanks,
Bill


Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


SPDX RDF Sub-group Mtg 2

Bill Schineller
 

Colleagues,
Those interested in participating in the RDF track, please reconvene next
Tuesday.
Among other hot topics, we'd like to take a closer look at the ontology,
which for collaborative review purposes has been loaded at free online tool

http://knoodl.com/ui/groups/SPDX/vocab/SPDX(dev-only)


SPDX RDF Sub-group Mtg 2
Tuesday Sept 7, 11AM eastern time

Toll-free dial-in number (U.S. and Canada): (877) 435-0230
International dial-in number: (253) 336-6732
Conference code: 7833942033

URL to join meeting:
http://blackducksoftware.na6.acrobat.com/r41859185/


Bill Schineller
Knowledge Base Manager
Black Duck Software Inc.
T: +1.781.810.1829
F: +1.781.891.5145
E: bschineller@...
http://www.blackducksoftware.com


SPDX Rollout - slides from call yesterday

Kim Weins
 

Hi everyone,

Attached are the slides John Ellis and I put together to start to organize the tasks needed for the rollout of SPDX.  We are going to be asking for help — from you or others in your organization.  

Please check out the slides, including the Appendix, and see where you might be willing & able to provide some help from your organization.  I will be reaching out in the coming weeks to see who is interested.

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





MInutes from Sept 9 call

Philip Odence
 


International colleagues,
While I am thinking of it, most countries shift from daylight time to regular time a few weeks before the US does on Nov 7. We'll keep running the regular meetings at 11 New York time, so please adjust accordingly. Sorry for the complication.

Phil


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

61 - 80 of 1598