2010/08/11 Minutes

Scuse the lousy formatting. I'm working on it. Phil

Minutes - 2010/08/11 LinuxCon2010 Boston SPDX BOF

Current status:

         - need to focus on goals for next 3 months

         - SPDX.org rollout,  shadows fossbazaar.org for data.

         - mail list transfering to spdx@fossbazaar.org with

          self subscription to mail list now possible, and

          public archives.

         - package-facts@fossbazaar.org now depreciated,

          mail list there will remain private, per original

          commitment.

Web site overview:

         - site design is still evolving, participation welcome.

         - log in to comment on wiki etc.

         - anyone can blog on site, and postings on topic welcome.

         - presentation material available on site for outreach support.

         - AI: Phil/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).

         - AI: Kate to transfer document (.pdf) back to WIKI.

         - AI: Phil update standard presentation with LinuxCon2010 input

         - AI: Kate clean up the sharing analysis to what is accurate

         - AI: Kate publish the current version number of the specification

             in brackets behind reference.

- License Discussion:

         - Look at Fedora's approach as a single page.

          Example license text - canonical form.   

          Good from tooling perspective.  Suck info off the pages.   

          HTML at low technical level is easy.  RDF?

         - see fedoraproject.org/wiki/License- licenses table.

         - Used License Text - uses tag to identify in page

          Fedora provide notes, and canonical text.

         - For SPDX problem is where store templated version?

Minutes - 2010/08/11 LinuxCon2010 Boston SPDX BOF

Current status:

         - need to focus on goals for next 3 months

         - SPDX.org rollout,  shadows fossbazaar.org for data.

         - mail list transfering to spdx@fossbazaar.org with

          self subscription to mail list now possible, and

          public archives.

         - package-facts@fossbazaar.org now depreciated,

          mail list there will remain private, per original

          commitment.

Web site overview:

         - site design is still evolving, participation welcome.

         - log in to comment on wiki etc.

         - anyone can blog on site, and postings on topic welcome.

         - presentation material available on site for outreach support.

         - AI: Phil/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).

         - AI: Kate to transfer document (.pdf) back to WIKI.

         - AI: Phil update standard presentation with LinuxCon2010 input

         - AI: Kate clean up the sharing analysis to what is accurate

         - AI: Kate publish the current version number of the specification

             in brackets behind reference.

- License Discussion:

         - Look at Fedora's approach as a single page.

          Example license text - canonical form.   

          Good from tooling perspective.  Suck info off the pages.   

          HTML at low technical level is easy.  RDF?

         - see fedoraproject.org/wiki/License- licenses table.

         - Used License Text - uses tag to identify in page

          Fedora provide notes, and canonical text.

         - For SPDX problem is where store templated version?

          Suggestion is to use come up with standardized naming

          of the sections, and embed the text of the licence

          "template" version, so it shows up on the "official"

          license page. (example to consider, verify that BSD

          hasn't been modified and do it with a template).

         - Fields to put on each "web license WIKI page"

          - short form name

          - long form name

          - link to formal license

          - notes on license

          - full license text

          - template version

         - Note: need to figure out and document how to add a license

          (ie. When you add a license - 1) create separate page;  

         raw template text, user visible text - here's out how

         embed this text.  etc.)

         - AI: Tom to define a proposal for user front page.

         Decide section names to correspond to spec

         - AI: Group: discuss further following questions:

                  - what does it mean to be "on the list" for a license.

                  - what is it going to take to add and maintain a license.

                  - Consider when english isn't spoken language?

                   (what can be translated, what can't, work into template)

- roll out - operational aspects

         - what do we want to get accomplished?

         - divy out and how get accomplished?

         - Target to have spec at 1.0 in 2010Q4

         - What are building blocks needed?

          Consider: documenting tooling;  training;  how to use.....

         - Strong feeling one shot to get this right, want

          free and comercial tool support available for supply chain.

         - AI:  Kim & John to work on operationalize plan.  

          (including a date can tell supply chain people?    

          GOAL is understand a date to have industry

          changing/financially impacting.   Tie to next LinuxCon??)

          of the sections, and embed the text of the licence

          "template" version, so it shows up on the "official"

          license page. (example to consider, verify that BSD

          hasn't been modified and do it with a template).

         - Fields to put on each "web license WIKI page"

          - short form name

          - long form name

          - link to formal license

          - notes on license

          - full license text

          - template version

         - Note: need to figure out and document how to add a license

          (ie. When you add a license - 1) create separate page;  

         raw template text, user visible text - here's out how

         embed this text.  etc.)

         - AI: Tom to define a proposal for user front page.

         Decide section names to correspond to spec

         - AI: Group: discuss further following questions:

                  - what does it mean to be "on the list" for a license.

                  - what is it going to take to add and maintain a license.

                  - Consider when english isn't spoken language?

                   (what can be translated, what can't, work into template)

- roll out - operational aspects

         - what do we want to get accomplished?

         - divy out and how get accomplished?

         - Target to have spec at 1.0 in 2010Q4

         - What are building blocks needed?

          Consider: documenting tooling;  training;  how to use.....

         - Strong feeling one shot to get this right, want

          free and comercial tool support available for supply chain.

         - AI:  Kim & John to work on operationalize plan.  

          (including a date can tell supply chain people?    

          GOAL is understand a date to have industry

          changing/financially impacting.   Tie to next LinuxCon??)

2010/08/26 Minutes

ADMINISTRATIVE

Agenda

• Attendance - 18
• Approval of minutes from BoF session – Approved.
• New Logistics and Expanding Group
• Outreach and evangelism:
  • Common Messaging/Presentation – Phil O
  • Industry Venues – Phil R
    • LinuxCon Debrief- Phil O
  • Website – Martin M

Logistics

PhilO discussed need for evolving logistics with the group getting larger and including new folks. We're doing away with the "Who just joined?" approach to attendance and will mainly depend on log-ins to Webshare to record attendance. In addition everyone is encouraged to state their name when speaking. There also some discussion (actually it came up towards the end of the meeting) about providing minutes via a link rather than an attached Word doc.

Common Messaging/Presentation

PhilO is updating the presentation to reflect Kate's LinuxCon presentation content.

Industry Venues

PhilO reported on LinuxCon. Jim Zemlin's keynote was all about the new Open Compliance Program, and SPDX was prominently featured. SPDX got some good PR out of it and one article said it was the key to the bigger program. Phil Koltun delivered a more detailed session on the OCP and Kate had one on SPDX. Both were well attended. Finally, we had a Birds of a Feature session.

Website

Kudos to Martin for helping PhilO get the new spdx.org launched in time for LinuxCon. There was some discussion about making it more obvious how one joins both the group and the mailing list; it's better to be redundant in order to be more welcoming. There was also a discussion about getting examples up to date and getting the Wiki going again. We finally got into a discussion about hosting code for tools. Possibilities were: SourceForge, GitHub.

Rollout

PhilO mentioned the JohnE and KimW have been working on a rollout plan, expanding on both out technical efforts and outreach/evangelism efforts. More at the next meeting.

ACTION ITEMS

• 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

• Review mock up from Spot Calloway https://fedoraproject.org/wiki/TomCallaway/SPDX_License_List
• License Short Form Discussion- Kate
• General RDF Discussion

Mock Up

Spot was not in attendance, but we reviewed the mock-up. There was fair agreement that its close to what we are looking for (if not "Spot" on)

Short Form Licenses

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 decoupled: Essentially we'll want the license list to change with more frequency than the spec (months vs. years). A new license can't mean a new spec rev. There was much discussion about how to manage the license list. 

There was fair agreement just as there is a "playground" for working on the spec and a release process to the current rev, there should be a similar arrangement for licenses (though decoupled) and certainly there should be legal review.

There was not complete agreement about the intended scope of the list, but there was agreement that there needed so be some nomination process and that anyone wishing to add a license must be willing to take on the associated work. BobG is willing to be a contributor. A topic of future discussion is how we will come down on the initial V1.0 list of licenses. These issues in contemplated in the rollout framework that we'll be putting forth.

RDF

We reviewed the intent of using RDF and BillS described what's been done with DOAP as a model. Essentially, we're exploring RDF as a reasonable balance between the needs of people being able to view and create SPDX docs, and machines to be able to consume and produce the format.

There was agreement that there is lots of work to be done in this area: defining the syntax, defining web repository of license info, documenting usage, etc. We decided that we need a sub-team to take this on. BillS will coordinate and PeterW, Gary and Kate will participate, as well as others who are interested.

ATTENDANCE

• Michael Herzog, NexB
• Bob Gobeille, FOSSology.org, HP
• Ann Thornton, Freescale
• Martin Michlmayr, HP
• Gary O'Neall, Source Auditor
• Jeff Luszcz, Palamida
• Richard Fontana, Red Hat
• Mark Gisi, Wind River
• Phil Koltun, Linux Foundation
• John Ellis, Motorola
• David Wolfe, Freescale
• Tom Incorvia, Micro Focus
• Kim Weins, Open Logic
• Peter Williams, OpenLogic
• Bill Schineller, Black Duck Software
• Jack Manbeck, TI
• Kate Stewart, Canonical
• Philip Odence, Black Duck Software

2010/09/09 Minutes

ADMINISTRATIVE

Agenda

• Attendance - 19
• Approval of minutes - Pending til next meeting
• Outreach and evangelism:
  • Common Messaging/Presentation – PhilO
  • Industry Venues – PhilR
  • Website – PhilO/MartinM
• Rollout- KimW

Common Messaging/Presentation

PhilO reported that he'd updated the presentation. He's added a slide describing to people why they should participate; he and Kim will update in the context of her OWF presentation.

Industry Venues

PhilO reviewed process for new participatns

Website

PhilO walked through changes implemented to make how to participate more obvious. There are pointers to where to sign up and get on the mailing list from every major tab.

Rollout

Kim described the motivations for, approach to and elements of the rollout that will require work. There's a fair amount to be done, but it is now well framed. There will likely be a different thread of meetings on rollout issues (vs. spec completion) starting after a face to face meeting in mid-November. Some of the areas that need work would benefit from skills from outside the current group, so please think about others in your organization that might help.

Issue Tracking

We agreed that we should implement an issue tracking system for spec issues. We can use Linux Foundations Bugzilla. Peter Williams agreed to drive and administer with help from Marshall.

ACTION ITEMS

• 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. DONE
• Kate- Transfer document (.pdf) back to WIKI. IN PROCESS
• PhilO- Update standard presentation with LinuxCon2010 input DONE
• Kate- Clean up the sharing analysis to what is accurate.  IN PROCESS
• Kate- Publish the current version number of the specification in brackets behind reference DONE
• Kim/PhilO- Add and element of 'What's in this for me?" to presentation  DONE
• JeffL (w/Bill/Gary- Update zlib based on new specification  IN PROCESS
• All- Look for new examples to add to site. IN PROCESS
• PhilK- Explore possibility of LF hosting source for SPDX tools.  DONE. 
• Gary- Explore other possible hosting options. DONE. 
• PhilO- Start making minutes available via link. DONE
• BillS- Start up RDF sub-group. Solicite members.  DONE

New

• KimW- Sent rollout slides to mailing list
• RDF Group- Work out syntax for 5.6/5.7
• Bill S- Add Ed W to the RDF group
• Kate- Track and (when Wiki is back up) implement changes described in Spec section below.
• PeterW- Implement issue tracking system.

TECHNICAL

Agenda

• Spec current status and open areas- Kate
• RDF Focus Group update - Bill
• Tools update - Gary
• Issue Tracking

License Discussion

As there has been a lot of discussion of licenses on the mailing list (decoupling from spec, etc.), we decided to have a separate session dedicated to that discussion. Kate will be hosting on Thurs, Sept 16 at 12:00 EDT (one hour later than our normal.) Invitation and agenda to be sent out early next week.

Specification - Current Draft 20100806

No changes have been implemented since the beta release as we are working through some formatting issues getting the .pdf back into Wiki form.

Additional Fields: 5.6/5.7 We picked up on the discussion from the maillist of adding 5.6/5.7 fields to the file section which would designate the name and URL of the package from which a file is known to come. There was agreement that we should go ahead with this in concept and that the RDF group would work out the syntax.

Revisit 3.3 To deal with the recursive problem (wanting to include the SPDX file in a package but also wanting it to include a SHA-1 for the package) there has been a proposal based off of the SHA-1s of all the other files in the package. Kate is looking for others interested in this, to brainstorm with as to algorithms to generate this new package level checksum.   We got into a discussion of "unique identifier" vs. "validator" and it became clear our nomenclature needs to be cleaned up to indicate that this is a validator and not an identifier. Someone proposed "Package Check Sum" as the name of the field and there was agreement. Kate will clean up the language requested more discussion on the maillist of the technical approach.

Appendices- The RDF group identified the need for an ontology and an XML schema appendix.   Place holders for these will be added to the WIKI.

RDF Group

There was a good kickoff meeting last Thursday. Most of the discussion was about approaches and concerns. Both an ontology and a schema are to be the targeted outputs from this subgroup.  Bill has since found a collaborative ontology site that will be useful in the development. 

Tools & Infrastructure

Linux Foundation has agreed to make the source code revision infrastructure (git based) available to SPDX tools.   There will be a meeting next week between Gary, Ibrahim, Kate to discuss the logistics in more details.   The first project will be Gary's Pretty Printer (which has components that can be reused in other projects).

Request was made on the list for an issue tracker.  Current mechanism is a WIKI, but it was felt something more formal would give us better history.    After group discussion and the willingness of Peter to volunteer to adminster it (thanks Peter!),  we will be looking at setting up a bugzilla system.   Options on where it can be hosted (linux foundation?), will be investigated by Kate.   Goal would be that this could be used for the SPDX tools as well. 

ATTENDANCE

• Gary O'Neall, Source Auditor
• Daniel Germain, U of Victoria
• Marshall Clow, Qualcomm
• Peter Williams, OpenLogic
• Kim Weins, OpenLogic
• Kate Stewart, Canonical
• Ed Warnicke, Cisco
• Ann Thornton, Freescale
• Alan Stern, Cisco
• Phil Robb, HP
• Tom Incorvia, Micro Focus
• Phil Koltun, Linux Foundation
• Mark Gisi, Wind River
• Jeff Luszcz, Palamida
• Pierre Lapointe, NexB
• Esteban Rockett, Motorola
• Philip Odence, Black Duck Software
• Eric Weidner, OpenLogic
• Dave McLoughlin, OpenLogic

2010/09/23 Minutes

DRAFT

ADMINISTRATIVE

Agenda 

• Attendance - 17
• Approval of minutes: Approved Aug 26 and Sept 9
• Outreach and evangelism:
  • Common Messaging/Presentation – PhilO
  • Industry Venues – PhilR
  • Website – PhilO/MartinM
• Roll Out Update - KimW/JohnE (volunteer needs, face to face plan)
• Legal update from LF Member Counsel call- Rockett

Common Messaging/Presentation

PhilO once again expressed openness to any feedback on the standards slides we should all be using to describe SPDX

Industry Venues

PhilR lead a discussion about future events we should be getting on the list. He will be updating. All are encouraged to crowdsource this list.

Website

Website is still developing and PhilO is open to feedback.

Rollout

PhilO summarized the need for a roll out plan. Kim emphasized that we are looking for volunteers from the group and our respective organizations. A face to face meeting will be scheduled for Nov 16/17, with location to be determined based on who is coming.

Legal Update

Rockett summarized a call with Linux Foundation legal group, the Member Counsel. (Kim, Kate, JohnE and PhilO also participated.) The Member Council has been aware of standardization efforts for a couple of year and this call was to provide status. A number of the participants were new to the MC, so it was important to get them up to speed. They encouraged us to provide them with an example.

ACTION ITEMS

• Kate- Transfer document (.pdf) back to WIKI. IN PROCESS; FORMATTING IS A BEAST
• Kim (formerly Kate)- Clean up the sharing analysis to what is accurate.  IN PROCESS
• JeffL (w/Bill/Gary- Update zlib based on new specification  IN PROCESS
• KimW- Sent rollout slides to mailing list DONE
• RDF Group- Work out syntax for 5.6/5.7  IN PROCESS ON RECOMMENDATION
• Bill S- Add Ed W to the RDF group DONE
• Kate- Track and (when Wiki is back up) implement changes described in Spec section below. WAITING FOR WIKI
• PeterW- Implement issue tracking system.  TO BE DISCUSSED.

New 

• Phil R- Update Industry Events.
• Kate- Draft example for LF Member Counsel; include XML and corresponding spreadsheet (or spreadsheet-like) format.

TECHNICAL

Agenda

• Spec update- Kate
• RDF work group update - Bill
• Tools repository - Gary/Kate/Bill
• Licenses: special working session on Friday at 12 CDT

Spec

Formatting difficulties have slowed getting the spec back in the Wiki. That's in process. Kate will add 5.6/5.7.

RDF

Work group is in process defining the ontology. Using knodle site: http://knoodl.com/ui/groups/SPDX/vocab/SPDX(dev-only);jsessionid=16BABC384D81ECF9EC6DC52C93977C3E   

Participating are Bill, Kate, Gary, Peter, Jeff, Ed, Kyle (from Canonical), Pierre. Bruno and Marshall have been monitoring as well. We discussed using DOAP (description of a project) as a way to extend SPDX capability. 

Tools Repository

LF is willing to host Bugzilla (as well as code). No one in the group saw any problem with going ahead. Kate, Bill and Peter are open to input for defining the hierarchy.

License Discussion

We discussed the call (Friday, Sept 24) dedicated to the big picture license discussion. Decoupling versioning from spec versioning, process for including new licenses, list for version 1, etc.

ATTENDANCE

•   Jack Manbeck, Texas Instruments
•   Michael Herzog, nexB
•   Soeren Rabenstein, ASUS
•   Philippe Ombredanne, nexB Inc.
•   Esteban Rockett, Motorola
•   Phil Robb, Hewlett Packard
•   Bill Schineller, Black Duck Software
•   Philip Odence, Black Duck Software
•   Phil Koltun, Linux Foundation
•   Janet Campbell, Eclipse Foundation
•   Pierre Lapointe, nexB
•   Peter Williams, OpenLogic
•   Kim Weins, OpenLogic
•   Gary O'Neall, Source Auditor
•   Mark Gisi, Wind River
•   Ann Thornton, Freescale
•   Kate Stewart, Canonical

2010/10/14 Minutes

DRAFT

MINUTES

ACTION ITEMS

2010/10/21 Minutes

DRAFT

Agenda 

• Attendance - 14
• Approval of minutes:  9/23 were approved on 10/14;   10/14 still need to be entered and reviewed.
• Outreach and evangelism:
  
  • Common Messaging/Presentation – PhilO
    • no update
  • Industry Venues – PhilR
    • no update
  • Website – MartinM
    • website has been running smoothly for while, no missing feature requests recently 
    • SPDX listed in spam databases - working to get spdx removed. 
    • BillS: any issue with posting HTML page?  look to getting subdirectory should be ok
    • ( AI: Bill S to send Martin some examples. )
•  Legal Update - Rockett
  
  •   SPDX file contents license - working on draft with Bradley, under creative commons - make sure last person editing absolves the previous person.  Ideal goal is to work with Creative Commons open source license author.
  • Trademark use policy - Karen & Rockett to work on it.  To be reviewed with SPDX work group,  prior to wider publishing (AI: Rockett to mail out trademark policy draft to SPDX list)
  • Trademark processing in progress - looking for response back early November  (AI: Rockett to query status)
  • Second dedicated LF meeting is still to be scheduled,  SPDX cliff notes version needed for (see action item for Kate below), Rockett to announce date.
  • Some concern to make sure that SPDX is cast at appropriate light with Linux Foundation, and is not oversold.
   
•  Roll Out Update - KimW
  
  •  no changes on roll out - face to face date still pending
  •  key is how many people can participate, will be discussed tomorrow, and Kim to mail out to wider group the plans.  (AI: Kim to announce F2F plans after discussion)
•  Licensing Subgroup Update - Jilayne
  
  • spreadsheet sent out with first list.
  • guidelines created as went along - looking for review and feedback from group.
  • questions came up as looking at it - to be discussed in next licensing meeting.
  • next licensing meeting now scheduled for 11/12 at this time - (AI: Kim to set up invite.)
  • (AI all: please review 6 months mail and contrast against spreadsheet.)
  • Some discussion on headers and decision made to keep the syntax of the text to be language neutral was made.  (ie. C style comments,  Java style, etc. ignored )
  •  For now we'll keep working in spreadsheet, with goal of auto translating it over to the html pages when stabilizes.  (see action for Martin/Bill to look at html pages written directly to WIKI)
• RDF Subgroup Update - Peter
  
  • concensus of how code RDF semantics into spec still in discussion.
  • group is at work on adding additional capabilities to licensing part.
  • 5.6/5.7 issue - one proposal adds 5.6 & 5.7 additional properties (name and URL of project file belongs to) - alternate proposal links to DOAP project that encodes the name and URL.   (AI: Peter will write up formal proposal between  the two proposal, and mail out to list. )
  • (AI: All - Next meeting will be voting on it explicitly, those that can't attend, are urged to post feedback/vote to list.)
• Spec Update - Kate
  
  •  3.3 - changing field from SHA of tarball to XOR of file level SHAs.  (AI: Kate to write up formal proposal for change of field and mail out to the list.
  • (AI: All - please review and if there are technical flaws open discussion on list, if no flaws figured out,  next meeting will vote on it changing).
  • 5.6/5.7 - discussion of mail list threads - clarification of proposals? (see comments under RDF)
  • no other spec field issues known pending at this time.   Any new suggestions/requests/comments,  please post to list, and add entry into appropriate point in WIKI.
  • (AI: Kate add back to SPEC page in WIKI - prefered syntax for adding comments into SPEC)

ACTION ITEMS

• Kate- Transfer document (.pdf) back to WIKI. DONE
• Dave - Clean up the WIKI to only have analysis visible that reflects current spec.  IN PROCESS
• Dave/JeffL - Update zlib based on new specification  IN PROCESS
• Peter - Mail out competing proposals for 5.6/5.7  IN PROCESS
• Kate- Track and (when Wiki is back up) implement changes described in Spec section below. DONE (see above)
• PeterW- Implement issue tracking system.  BLOCKED ON KATE
• Kate - submit ids to Linux Foundation so infrastructure setup can proceed - pending.
• Kate- Draft example for LF Member Counsel; include XML and corresponding spreadsheet (or spreadsheet-like) format. peinding
• Kim - list of questions from Open World Forum to form start of FAQ  - pending - will send mail to list with questions remembered,  request Phillipe O, add comments.
• Phil R - Update Industry Events.
• Kim/Martin - slides from OWF made available.  Now posted on open world - matin to post to SPDX or link. - DONE
• Kate - 10/14 minutes to be added to WIKI for review. - IN PROCESS

New  - See notes in above minutes.

NEXT MEETING

• 2010/01/04 at same time.

ATTENDANCE

•   Tom Incorvia - MicroFocus
•   Michael Herzog, nexB
•   Esteban Rockett, Motorola
•   Bill Schineller, Black Duck Software
•   Phil Koltun, Linux Foundation
•   Janet Campbell, Eclipse Foundation
•   Peter Williams, OpenLogic
•   Kim Weins, OpenLogic
•   Eric W., Open Logic
•   Dave M. Open Logic
•   Jilayne Lovejoy, Open Logic
•   Martin Michlmyer, HP
•   Kate Stewart, Canonical
•   Mark Gisi, Wind River

2010/11/04 Minutes

Minutes

• Attendance - 13
• Approval of minutes:  10/14 and 10/21 minutes approved
• Outreach and evangelism:
  
  • Common Messaging/Presentation – PhilO
    • no update
  • Industry Venues – PhilR
    • no update
  • Website – MartinM
    • Rearranged so that spec under Specification tab can not be edited with the working version being under Participation
    • Dealt with some legacy spam reputation issues with spdx.org.

•  Roll Out Update - KimW/JohnE
  • Face to Face pushed out into Dec/Jan
  • Need more volunteers before scheduling
  • Beta program is most urgent item; John is back in action and focusing on that.
•  Legal Update - Rockett
  • No update.

• Linux Plumbers report live from Cambridge
  • Well received licensing presentation from Mark Gisi and Sven Dummer included good plug for SPDX
  • Interest from Yahoo! in participation
  • BoF discussion on creating SPDX report for the kernal.

Action Items

Note: Drafting related action items are embedded in the Wiki. http://www.spdx.org/wiki/spdx/specification

• Dave - Clean up the WIKI to only have analysis visible that reflects current spec.  ON HOLD FOR MARTIN TO PROVIDE PRIVS; SHOULD BE UNDERWAY

• Dave/JeffL - Update zlib based on new specification  DONE, BUT AWAITING FEEDBACK

• Peter - Mail out competing proposals for 5.6/5.7  DONE

• PeterW- Implement issue tracking system.  BLOCKED ON KATE

• Kate - submit ids to Linux Foundation so infrastructure setup can proceed - PENDING

• Kate- Draft example for LF Member Counsel; include XML and corresponding spreadsheet (or spreadsheet-like) format. PENDING

• Kim - list of questions from Open World Forum to form start of FAQ  - pending - will send mail to list with questions remembered,  request Phillipe O, add comments. DONE

• Phil R - Update Industry Events. IN PROCESS

• Kate - 10/14 minutes to be added to WIKI for review. - DONE

• Bill S - Send Martin some examples of issue posting HTML. DONE

• Rockett- Mail out trademark policy draft to SPDX list. WAITING FOR SIGNOFF BY LF

• Rockett- Query status of trademark application TBD

• Kim- Update of plans for Face to Face  DONE

• Kim- Send out invite for next licensing meeting. DONE. WILL INCLUDE FOLKS FROM DEBIAN.

• All- Review 6 months mail and contrast against licensing group spreadsheet. FOR NEXT LICENSE GRP MEETING

• All- If you can't attend meeting, post feedback/vote to list on 5.6/5.7 proposals. FOR TECH AGENDA NXT MTG.

• Kate- Write up formal proposal on SHA field change and mail to list. IN PROCESS

• All- Review SHA field change proposal for technical flaws; if so, discuss on list. FOR TECH AGENDA NXT MEETING

• Kate- Add back to SPEC page in WIKI preferred syntax for adding comments. TBD

NEXT MEETING

• 2010/11/18 at same time. NOTE EURO/US TIME DIFF WILL BE BACK TO NORMAL.

ATTENDANCE

• Phil Odence, Black Duck
• Tom Incorvia - MicroFocus
• Esteban Rockett, MotorolA
• Peter Williams, OpenLogic
• Kim Weins, OpenLogic
• Dave M. Open Logic
• Jilayne Lovejoy, Open Logic
• Martin Michlmyer, HP
• Kate Stewart, Canonical
• Ann Thompson, Freescale
• Gary  O'Neall, Source Auditor
• Phil Robb, HP
• John Ellis, Motorola
• Marshall Clow, Qualcomm

2010/11/18 Minutes

Attachments: 

SPDX Organizational Structure Slides

2010/12/02 General Meeting Minutes

Administrative

• Attendance - 14
• Minutes from 18 Nov meeting approved

Technical Team Report

• Working through RDF issues to make sure consistent with tagged version.
• Proposals floating around on the technical mailing list.
• Regular meetings on Tuesdays.
• Need more folks to migrate to technical mailing list.

Business Team Report

• Regular meetings are on the schedule. Same day/time as General Meeting on alternate weeks.
• Kim has posted slides overviewing roll out issues with initial ideas. 
• A working draft wiki for FAQs has been started. Looking for as much input at possible. 

Legal Team Report

• Regular meetings will be the day before General Meeting. 
• First scheduled for 15 Dec (and will be longer than normal).
• Invitations going out to general SPDX list, Linux Found Member Counsel list, and Project Harmony
• Items for first meeting:
  • Handing off work from License Team
  • Addressing any questions from LF Member Counsel
  • Setting going-forward agenda for Team
• License Team meeting for 3 Dec is still on.

Cross Functional Issues

• Agenda for this meeting seems to work fine. Meeting schedule may go to 30 mins.
• Need folks to migrate to respective mailing lists. 
  • Current lists, Technical- 8, Business- 6, Legal- 7

Action Items

• Kate- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING
• Kate- Add back to Spec page in wiki preferred syntax for adding comments. PENDING
  • <kes> 20101215 done.  see: http://www.spdx.org/spec/current/,   have also added same commentary to other related WIKI pages.
• MichaelH- Write up and share postion on "reporting" vs. "interpreting. NO UPDATE
• PhilO- Get input on MH position from Legal Team and get resolution.
• GaryO- Post regular meeting times on Tech Team page.
• Rockett- Post regular meeting times on Legal Team page.
• MartinM- Report back on # of people on respective mailing lists.

Attendees

• Kate Stewart, Canonical
• Phil Odence, Black Duck Software
• Bill Schineller, Black Duck Software
• Tom Incorvia, MicroFocus
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Jilayne Lovejoy, OpenLogic
• Dave McLoughlin, OpenLogic
• Phil Koltun, Linux Foundation
• Gary O'Neall, Source Auditor
• Martin Michlmayr, HP
• Ann Thornton, Freescale
• John Ellis, Motorola
• Esteban Rockett, Motorola

2010/12/16 General Meeting Minutes

Administrative

• Attendance - 12
• Minutes from 2 Dec meeting approved

Technical Team Report

• Still going back and forth on grammar and syntax, resolving RDF and tag value
• Various proposals will be circulating
• Next priority is defining a license template

Business Team Report

• Beta program starting up. Aiming to start late Q1 and wrap in late Q2
• Some tooling needs to be in place prior to make it easier to generate syntactically correct RDF as well as to create human readable format. Gary's 'pretty printer' is a good starting point
• Ideally seeking pairs of supply chain partners for beta. Motorola and HP are interested. Maybe Fedora.
• Ping KimW if interested or with ideas

Legal Team Report

• Kicked of regular meetings.
• First Meeting: successfully bridging from licensing sub-team to new Legal Team. Good discussion about handling GPL3 exceptions. Also about rev'ing license list. And what is "required" for valid SPDX
• Much discussion about license list. Conclusion as that we should add a field to SPDX that specifies the version of the license list used to generate the file. The version number for the list will be date based.  

Cross Functional Issues

• Collaboration Summit. April 6-8, San Francisco
  • Will be a compliance track on Thursday morning, the 7th including SPDX presentation
  • Tech Team will meet Thursday afternoon; Business Team, Friday morning
  • Legal Team may meet at Euro event or may try a teleconference
• Need folks to migrate to respective mailing lists. 
  • Current lists, Technical- 10 (up 2), Business- 7 (up 1), Legal- 12 (up 5)

Action Items

• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING
• Kate- Add back to Spec page in wiki preferred syntax for adding comments. DONE
• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. PENDING
• GaryO- Post regular meeting times on Tech Team page. DONE
• Rockett- Post regular meeting times on Legal Team page. PENDING
• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING 

Attendees

• Kate Stewart, Canonical
• Phil Odence, Black Duck Software
• Bill Schineller, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Jilayne Lovejoy, OpenLogic
• Phil Koltun, Linux Foundation
• Gary O'Neall, Source Auditor
• Martin Michlmayr, HP
• Esteban Rockett, Motorola
• Michael Herzog, nexB
• Pierre Lapointe, nexB

2011-08-11 General Meeting Minutes

Attendance: 16+

NOTE: I believe many folks joined whose names I did not capture. Let me know if your name is not here, and I'll be happy to add it.

   
Technical Team Report - Kate

• New draft of spec posted as of 8/10; no field changes, just editorial
• Open issue on data license; need agreement between spec and RDF
• Deadline for feedback by early am 8/15
• Tools updated
• New example available

Business Team Report - Kim

• GA
  
  • Press release shaping up; Kim reviewed list of names to be included
  • JimZ will mention in Keynote, Phil O. & Esteban R. have speaking slot
  • BOF session not yet on website; Thursday, 8/18 at 5:15 pm
  • SPDX booth staffing in progress; John Ellis working schedule; 1 pg handout will be available
• SPDX Website update
  • Don't believe we'll be ready to cutover from sandbox to live site in time for launch
  • Kim will update Home page on live site in prep for launch
  • Kate will ensure spec is up to date on live site
• FAQs
  • Asked all volunteers to get their contributions in by end of day Tuesday

Legal Team Report - Rockett

• Circulated draft of revised trademark & compliance statements
  
  • Deep discussion on this topic resulted in additional proposed changes
  • "Policing" policy concerns raised; recommendation is to follow LF policy of community notification
  • Concerns about requiring attribution/compliance statement inside SPDX file requiring change to spec
  • Decided that no attribution statement will be included in SPDX file at this time; we will revisit post 1.0 GA
  • Rockett has the action item to send final wording to Kate
• Data license discussion
  • Some team members concerned that use of PDDL, even with language about side-agreement re confidentially may affect adoption of spec by those who are working with packages that contain proprietary code
  • Other team members believe that allowing data licenses other than PDDL will affect adoption by open source community
  • Noted that Karen Copenhaver discussed this use with the author of PDDL and we have agreement that this use is compliant with intent of license; current wording provided by Karen C. after review with author
  • Decided that v1.0 will stipulate PDDL as only license for data

Open Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING
• Kim -- share Biz Team proposed process for adding licenses to SPDX list more broadly
• Michael H. -- Posting BOM info

Attendees

• Kirsten Newcomer, Black Duck Software
• Kamak Hassin, Protecode
• Kim Weins, OpenLogic
• Peter Williams, Open Logic
• Gary O'Neall, Source Auditor
• Martin Michlmayr, HP
• Kate Stewart, Canonical
• Jilayne Lovejoy, OpenLogic
• Esteban Rockett, Motorola
• Phil Koltun, Linux Foundation
• Tom Incorvia, Microfocus
• Adam , Cisco
• Mark Gisi, Wind River
• Branden Robinson, Cisco
• Jack Manbeck, TI
• Steve Cropper, Cisco

2011/02/10 General Meeting Minutes

2011/2/10 General Meeting Minutes

Administrative

• Attendance - 13
• Minutes from 27 Jan meeting approved

Technical Team Report

• Gary/Peter created punchlist of key issues that need to be addressed before beta.
  • Finalize RDF/XML
  • Clean up Grammer
  • Mesh spreadsheet license list, on-line list and RDF
• Kate drafted spreadsheet view of SPDX file which Gary is using as basis for translation tools. Will circulate.
• Seem to be on schedule genearlly

Business Team Report

• Beta program
  • Good briefing meeting with 4 candidates. Following up wth two more.
  • Need coordinator volunteers
• Starting to address need for end user content developed (doc, training, etc.).
• Next issue in the queue is defining the process to add a license to the standard list.

Legal Team Report

• Section 5.3 revision is mostly settled. Some final tweaking of field names was the last issue.
• Karen and Rockett are updating LF Member Counsel with the message "it's time" to pay attention and weigh in.
• In process of making recommendations for default license for SPDX data in a file and for SPDX tool licensing.

Cross Functional Issues

• Tech and Biz teams will meet face to face at Linux Collab Summit (Tech pm 4/7, Biz am 4/8)
• Agreed that SPDX general list should not be for extended discussions, which should be directed to respective team lists.

Action Items

• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING
• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. PENDING
• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING
• Kim/Kate- Provide PhilK with paragraph descriptions of Collab Summit sessions by 2/17

Attendees

• Kate Stewart, Canonical
• Phil Odence, Black Duck Software
• Kirsten Newcomer, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Jilayne Lovejoy, OpenLogic
• Phil Koltun, Linux Foundation
• Gary O'Neall, Source Auditor
• Michael Herzog, nexB
• Pierre Lapointe, nexB
• Mark Gisi, Wind River
• Tom Incorvia, Microfocus
• Karen Copenhaver, Linux Foundation

2011/02/24 General Meeting Minutes

 
Administrative Agenda

    Attendance: 9
    Minutes from http://www.spdx.org/wiki/2011210-general-meeting-minutes - approved


Technical Team Report - Kate

Mid March is now target for spreadsheet in draft form, with spec that correlates to spreadsheet.  

• license spreadsheet - hooking up with legal team (Jilayne, Rockett, Soren - needs work)
• templatizing of license and headers - will go with copy of main text directly as backup position, will work with legal team to get guidelines for automated translation to templatized version. 

Business Team Report - Kim

• current focus on nailing down beta sites.  3- trading partner groups committed, handful of other on investigation list
• will have beta coordinator assigned to each trading group;  for facilitation and working with beta partner,  need technical and support help to work through beta coords.  ( content for FAQ, etc. )  
• Will need to do technical training?- Kristen will work on tools
  • AI tech team:  drafts of spreadsheet, and spec by March 17th.  
  • AI tech team: Need Technical Training volunteers
• Face to face meeting at Collab will focus on see where things are with Beta;  talk about roll out - 4 months away.    
• AI: Kim to document - coodinator volunteers associated with beta sites listed.   

Legal Team Report - Rockett

• meeting schedule has shifted meeting from 2/23 to 3/2.  Resume normal bi-weekly on on 3/9.
• finalized section 5.3 - how ones concludes the license.   Last revision from the call documented in Legal team minutes
• license template would like to move from having to copy text as default for templatized version of license
• license list candidates -  please let Jilayne know if there's input before next Wednesday
• Linux Foundation Legal Counsels meeting went smoothly,  no issues raised.
• Jilayne and Rockett - attending European Legal Conference, on panels;   looking for input from prior presentations, and will Kate/Kim prior to meeting.

Other

• IFOSSLR article came out  
• RDF format,  no one is opposed to its inclusion.  Also desire to keep XML as readable as possible, maybe look at HTML 5 as a varient of output.   Need to contact Scott Lehman at HP,  FOSSology.   

Cross Functional Issues – Kate (for Phil)

•     Collaboration Summit  - Phil Kolton, Phil Odence, Kate Stewart, ??
  
  • Tech meeting Thursday afternoon
  • Business meeting Friday, 
  • 1/2 day track on legal related issues Thursday morning
  • anyone needing invite, please work with Phil Kolton,  who else planning to attend?
•     European Legal Conf - Scott Peterson, Rockett, Jilyane, Karen C. 
  
  • who else there,  make sense for separate meeting?
•     OSBC - May
  
  • Kim reported Mark Radcliff will talk there,  may mention SPDX as part of this.
•     OSCON - anything about SPDX?   maybe look at targetting? 
  
  • AI:  Business team to follow up?
•     CFP for Linux Foundation - LinuxCon north america  - getting ready for launch.
  • AI: need to get proposals put together

Action Items

Most of the action items belong with the Teams. So, in addition to statusing, we will dispatch them to the respective teams and will not continue to track in this meeting. Action items for this meeting will be cross functional.

• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING

• Beta collateral - March 17th.   

• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. PENDING

• converged on section 5.3;   so can declare it done,  will make sure that revised 5.3 can resolve with Michael offline.

• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING

•   Business 11 -> 15;   Legal 17->21  ;  Tech 16->20

• Kim/Kate- Provide PhilK with paragraph descriptions of Collab Summit sessions by 2/17  

•    DONE

New Actions:

We need to capture a list of who will be at face to face meeting - each of the work groups to

• AI:  create signup on WIKI,  adverstise in subgroups, and on these minutes/list.

Attendees

• Kirsten Newcomer, Black Duck Software
• Bill Schineller, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Esteban Rockett, Motorola
• Phil Koltun, Linux Foundation
• Kate Stewart, Canonical
• Tom Incorvia, Microfocus
• Martin Michlmayr, HP

2011/03/11 General Meeting Minutes

Administrative Agenda

    Attendance: 11
    Minutes from http://www.spdx.org/wiki/2011224-general-meeting-minutes - acceptance deferred

Technical Team Report - Kate

Still working through RDF issues/model and spreadsheet to resolve naming, and with a focus on:

• licensing substructure; team plans to post a proposal for general review
• templatizing of license and headers to support legal team; guidelines are available on the legal team wiki

Business Team Report 

Kim was traveling. No update from Business Team at this time. 

Legal Team Report - Rockett

• license templatizing: 75% of the way through on proposal for normalization of non-significant variants. Goal is to have proposal ready by March 23rd. 
• granular discussion of metadata is on-going. No conclusions yet. Karen and Rockett will make a proposal; date for proposal TBD.
• Concluded: any tools coming out of the SPDX project will be licensed under Apache 2.0 and SPDX will recommend Apache 2.0 for 3rd party FOSS tools for this project. Gary will update the tools he's writing to use the Apache 2.0 license.  

Cross Functional Issues – Kate (for Phil)

•     Collaboration Summit  - Phil Kolton, Phil Odence, Kate Stewart, ??
  • Agenda has been posted: http://events.linuxfoundation.org/events/collaboration-summit/schedule
    • Tech meeting Thursday afternoon
    • Business meeting Friday, 
    • 1/2 day track on legal related issues Thursday morning
  • anyone planning to attend should request an invite via the Linux Collaboration web site. (see link above)
  • Phil O. will set up wiki page to help us track those planning to attend
•     European Legal Conf - Scott Peterson, Rockett, Jilyane, Karen C. 
  • legal team is planning a panel presentation with spdx description and open session for questions
  • Karen suggested it would be helpful to have beta participants in audience
  • Karen also recommended that the description include broader context about why the SPDX standard is needed  and its goals
  • Consider conference to be a mini-launch of SPDX spec. Karen will work with Kim to get press release announcing beta
•     CFP for Linux Foundation - LinuxCon north america  - getting ready for launch.
  • Phil Koulton to provide deadline info for call for papers

Action Items

Most of the action items belong with the Teams. So, in addition to statusing, we will dispatch them to the respective teams and will not continue to track in this meeting. Action items for this meeting will be cross functional.

• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING

• Beta collateral - March 17th.   

• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. CLOSED

• converged on section 5.3;   Update available in legal team minutes

• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING

•   Business 11 -> 15;   Legal 17->21  ;  Tech 16->20

Phil O. - Capture a list of who will be at face to face meeting - PENDING

• create signup on WIKI for LinuxCollabSummit attendees,  adverstise in subgroups, and on these minutes/list.

Attendees

• Kirsten Newcomer, Black Duck Software
• Bill Schineller, Black Duck Software
• Peter Williams, OpenLogic
• Esteban Rockett, Motorola
• Phil Koltun, Linux Foundation
• Kate Stewart, Canonical
• Tom Incorvia, Microfocus
• Gary O'Neall, Source Auditor
• Jillayne Lovejoy, OpenLogic
• Karen Copenhaver, LF/Choate
• Michael Herzog, NexB

2011/03/24 General Meeting Minutes

Administrative Agenda

    Attendance: 15
    Minutes accepted http://www.spdx.org/wiki/20110224-general-meeting-minutes

 http://www.spdx.org/wiki/20110311-general-meeting-minutes

Technical Team Report - Kate

After a great deal of effort, the team has converged on a consistent set of field names which will by synch'ed with all forms of spec shortly.

There are still a couple of areas of open issues which are dependent on the Legal Team, most having to do with who created the SPDX file.

Kate will be starting up a wiki page with an agenda for the upcoming Face to Face; participants should feel free to provide input.

Business Team Report - Phil

Beta training materials are not complete, but are in motion and should be fine for beta.

In the last meeting there was a lot of discussion about a process for requesting/evaluating/adding new licenses to the standard list. See last Business Team meeting's minutes for details.

Legal Team Report - Rockett

SPDX Tool/Template Licensing- Done, we'll be using Apache 2.0

Metadata Licensing

• Stil active discussion delving in aspects of:
  • Confidentiality
  • Trace ability and change logging
  • Copyright
• Rockett and Kate are having an offline discussion to pull it all together.

Templatizing (defining what insubstantial variants are OK for a match to a standard license)

• Proposal being reviewed within Legal Team
• Ready for presentation to other teams in the next 1-2 months

Cross Functional Issues – Phil

 Collaboration Summit 

• Agenda has been posted: http://events.linuxfoundation.org/events/collaboration-summit/schedule
  • Tech Team meeting Thursday afternoon
  • Business Team meeting Friday, 
  • 1/2 day track on legal related issues Thursday morning
• anyone planning to attend should request an invite via the Linux Collaboration web site. (see link above)
• Please RSVP for Face to Face sessions on Wiki page

Discussion about how to handle "Newbee" question that come in on lists 

• Asking Business Team to take on providing guidelines to other teams and general 
• General feeling that we need a process to
  • Respond in 24 hours
  • Provide answers that are consistent with "party line" but at the same time helpful
  • Ensure that good questions / answers get captured in FAQ

Action Items

Most of the action items belong with the Teams. So, in addition to statusing, we will dispatch them to the respective teams and will not continue to track in this meeting. Action items for this meeting will be cross functional.

• Kate- Beta collateral: Examples in XML and spreadsheet form. PENDING 

• MartinM- Report back on # of people on respective mailing lists. ONGOING

•  
  • spdx: 98
  • spdz-biz: 17
  • spdx-legal: 23
  • spdx-tech: 21

Phil O. - Capture a list of who will be at face to face meeting - DONE

Attendees

• Phil Odence, Black Duck Software
• Kirsten Newcomer, Black Duck Software
• Esteban Rockett, Motorola
• Phil Koltun, Linux Foundation
• Kate Stewart, Canonical
• Tom Incorvia, Microfocus
• Gary O'Neall, Source Auditor
• Jillayne Lovejoy, OpenLogic
• Karen Copenhaver, LF/Choate
• Michael Herzog, NexB
• Pierre Lapointe, NexB
• Kamal Hassin, Protecode
• Jilayne Lovejoy, Open Logic
• Martin Michlmayr, HP
• Bill Schineller, Black Duck Software

2011/04/21 General Meeting Minutes

SPDX General Meeting minutes from 4/21/2011

Attendance: 10

Minutes accepted 

http://www.spdx.org/wiki/20110324-general-meeting-minutes

Technical Team Report - Kate

Team is recovering from specification review held at the Linux Collaboration Summit face-to-face meeting.

An initial revised draft (PDF) incorporating first round of feedback, dated 20110411, is posted here: http://spdx.org/wiki/spdx/specification

Team is working through discrepancies and adding examples for RDF

It's still possible to have the tools complete (alpha quality) by the end of April, or within one week of beta spec being finalized.

Requested feedback from legal team on web page location (URI) for special terms such as UNDETERMINED.

• Previously specified: the URI for these terms points to entries on on the spdx.org/licenses web page
• New proposal: the URL for these terms points to appropriate Terms page on the spdx.org web page. Reasoning: These special terms are used for data fields for License, Copyright, and Project download/homepage URIs. Since the terms are not specific to licenses, it seems more appropriate to post the definitions for these terms on a terminology web page rather than the spdx.org/licenses web page.

Business Team Report - Kim

Coordinators have been identified for the 3 beta pairs. Kick off calls planned for early May (likely 2nd week).

Training materials in progress and will be finalized once beta spec is final.

Three new discussion/action threads were identified at the Linux Collaboration Summit face-to-face

• connect with yocto project and possibly other build tools for potential integration
• outreach to additional open source communities
• review/update SPDX website for ease-of-use by newly members, beta participants and casual users

Legal Team Report - Rockett

2 active discussions continue: metadata licensing and how to handle id'ing author/reviewer

Metadata Licensing: Stil active discussion delving in aspects of:

• Confidentiality
  • when exchanged between two parties
  • when made public (how to avoid copyright issues)

How to handle id'ing authors/reviewers 

• There is value in this data
•  Pedigree data creates concerns 
• Making author/reviewing anonymous creates trust issues

Related: Trying to determine beta approach for audit / revision history

• Change log has been proposed but there are timing and complexity questions
• Working to put together straw man
• Team considers this is not required for beta but would like input from beta participants
• This becomes more important as supply chain expands beyond two

Action Items

Most of the action items belong with the Teams. So, in addition to statusing, we will dispatch them to the respective teams and will not continue to track in this meeting. Action items for this meeting will be cross functional.

• Kate- Beta collateral: Examples in XML and spreadsheet form. PENDING 

• MartinM- Report back on # of people on respective mailing lists. ONGOING

• spdx: 98
• spdz-biz: 17
• spdx-legal: 23
• spdx-tech: 21

Attendees

• Kirsten Newcomer, Black Duck Software
• Esteban Rockett, Motorola
• Kate Stewart, Canonical
• Tom Incorvia, Microfocus
• Gary O'Neall, Source Auditor
• Jillayne Lovejoy, OpenLogic
• Michael Herzog, NexB
• Kamal Hassin, Protecode
• Peter Wiliams, OpenLogic
• Richard Faulk, Black Duck

2011/05/05 General Meeting Minutes

Administrative Agenda

    Attendance: 15
    Minutes accepted 

Technical Team Report - Bill

Good Progress

One specific blocking item/for spec and tools. The issue is has to do with set of terms to describe situation where a concluded license is not named. Team had been working with terms such as: None, No Assertion, Not Analyzed, Blank. They are working on a final proposal but are leaning towards two values one indcating that there has been a conclusion that there is no license and one indicating that there is no conclusion one way or the other.

Team is asking for some ratification from the legal team, but proceeding on the two value path.

Business Team Report - Kim

Beta kickoffs are scheduled.

Final field names are getting merged into the training and tool docs by Kim and Kirsten resepctively. 

Legal Team Report - Rockett

Metadata licensing issue still under discussion

Team is reviewing the need for including change tracking of SPDX docs in the spec. This will not hold up the beta. There was a discussion about how major a requirement this would be, i.e. would it necessarily hold up V1.0 past LinuxCon in August. The general sense from members of the Tech Team (which has been contemplating the issue) was that it would not by itself.

Cross Functional Issues – Phil

Website: A workign group of Kirsten, Pierre and Steve have been reviewing the website for usability. They are recommending the "three big buttons" approach to the home page for folks who are:

• New to SPDX and want to get up to speed
• Familar and looking for official information on the spec and how to use
• Interested in participating in development of the spec

Their other major recommendation was to have drop down menus to give more visibility into the various sections of the website from the home page.

There was lots of spirited discussion and opinions, but general agreement on the direction.

The team will be developing and circulating mockups for subsequent feedback.

Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING

• • spdx: 98
  • spdz-biz: 17
  • spdx-legal: 23
  • spdx-tech: 21

Attendees

• Phil Odence, Black Duck Software
• Kirsten Newcomer, Black Duck Software
• Esteban Rockett, Motorola
• Phil Koltun, Linux Foundation
• Tom Incorvia, Microfocus
• Gary O'Neall, Source Auditor
• Jillayne Lovejoy, OpenLogic
• Michael Herzog, NexB
• Pierre Lapointe, NexB
• Martin Michlmayr, HP
• Bill Schineller, Black Duck Software
• Kim Weins, Open Logic
• Peter Williams, Open Logic
• Mark Gisi, Wind River
• Steve Cropper, Cisco

2011/05/19 General Meeting Minutes

Administrative Agenda

    Attendance: 14
    Minutes accepted 

Technical Team Report - Kate

New version up with RDF vocabulary appendix. Please review

Tools are keeping up. Only one known oustanding issue at this point.

Legal Team Report - Rockett

License State Discussion

• Centers on states for undetermined Discovered licenses: "None" and "No Assertion"
• Several calls
• All seem to be aligned

Going through latest spec versionLicensing of Metadata

• Concluded that an existing license is a little too long but OK for purpose
• Will circle back once more but will likely approve

Business Team Report

Abreviated as Kim was unavailable

Cross Functional Issues – Phil

Brief statuse on website. Team is working on a story board

OSBC report- No formal presentation, but mentioned on a panel with very positive reception

Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING

New

• Kirsten- Notify Kim of need to clean up business section of website.
• MartinM- Get master list of website pages to Kate
• Legal/Biz Teams- Review and update Master Schedule

Attendees

• Phil Odence, Black Duck Software
• Kirsten Newcomer, Black Duck Software
• Esteban Rockett, Motorola
• Phil Koltun, Linux Foundation
• Gary O'Neall, Source Auditor
• Michael Herzog, NexB
• Pierre Lapointe, NexB
• Martin Michlmayr, HP
• Kate Stewart, Canonical
• Bill Schineller, Black Duck Software
• Scott Lamons, HP
• Adam Cohn, Cisco
• Victoria Mah, Cisco
• Brandon Robinson, Cisco

2011/06/02 General Meeting Minutes

Attendance: 13
Minutes for 20110519 approved
    
Technical Team Report - Gary

• Tools: have received good feedback; addressed a few technical issues; available for beta use
• Spec: final polishing has been largely completed; waiting for one more review from legal which is expected by Friday am PT

Business Team Report - Kim

• 3 beta teams are working; target for beta completion & feedback is end of June; request that all teams work toward this date
  
  • HP/WindRiver & OL/Antelink are in progress
  • Kickoff for Motorola/TI still to be scheduled, but there's been activity. Rockett will work with Gary to get kickoff scheduled
• Website refresh subteam has been created. Details on this working group can be found here:
  
  • http://spdx.org/wiki/website-refresh
• GA launch process is next big thing to focus on
  • Planned for LinuxCon in Vancouver
  • Phil O. has a speaking slot
  • Goal include press release and mention in keynote

Legal Team Report - Rockett

• Last scrub on 5/16 spec in progress. Final comments due by Friday am PT time, 6/3
• Recommend Open Data Commons PDDL license for SPDX MetaData (http://www.opendatacommons.org/licenses/pddl/); will send link to broader group for final sign-off
• License templatizing is the next big focus
• Also noted that we'll need a process for adding licenses to SPDX list very soon; Kim says Biz Team has a proposal for a process and she'll plan to share more broadly

Cross Functional Issues – Discussion

• Website update- Steve
  • Sandbox for testing new website structure in place
  • Team plans to create storyboards for 3-4 personas using mind map tools
  • wiki pages for working grou now available http://spdx.org/wiki/website-refresh
• Questions/recommendations for presenting data for binaries and archives such as jar files -- Kim
  • There's been recent email about how to represent data for binaries that are combinations of OSS, 3rd party, and proprietary code in SPDX documents
  • Issue has also come up for OL/Antelink beta partners; OL/Antelink have decided to use compound licensing for jar files when needed; should we recommend the same approach for binaries?
  • There was a lively discussion on this topic with input from Steve Cropper, Kim Weins, Michael Herzog, Kate Stewart
  • Main conclusion: Recommendations for how to handle these use cases need to be added to the draft FAQ
    
    • Draft FAQ is available here: http://spdx.org/wiki/draft-spdx-faq
    • FAQ should address questions about proprietary and 3rd party as well as OSS licenses
    • Kim added a number of topics to the FAQ; need volunteers to provide additional info on these topics
  • A side issue regarding how best to connect package and SPDX document was also discussed
  • The topic of package hierarchy also came up
    
    • Michael H. noted that the SPDX team made a conscious choice not to tackle this for v1 of the specification
    • v1 spec is intended to address lower level or sub-assembly items and a BOM is not yet represented in the spec
    • Recommended that a section on items specifically deferred be added to the FAQ so that new users have visibility into these decisions
    • Michael also volunteered to pull together info on well traveled routes for BOMs that we might want to leverage   

Open Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING
• Kim -- share Biz Team proposed process for adding licenses to SPDX list more broadly
• Michael H. -- provide info on existing BOM standards that should be useful for future consideration
• Legal/Biz Teams- Review and update Master Schedule
• ?? -- volunteers needed to review and update the FAQ: http://spdx.org/wiki/draft-spdx-faq

Closed Action Items

• Kirsten- Notify Kim of need to clean up business section of website.
• MartinM- Get master list of website pages to Kate

Attendees

• Kirsten Newcomer, Black Duck Software
• Kamal Hassin, Protecode
• Kim Weins, OpenLogic
• Esteban Rockett, Motorola
• Gary O'Neall, Source Auditor
• Michael Herzog, NexB
• Martin Michlmayr, HP
• Kate Stewart, Canonical
• Peter Williams, OpenLogic
• Jillayne Lovejoy, OpenLogic
• Brandon Robinson, Cisco
• Steve Cropper, Cisco
• Tom Incorvia, Microfocus

2011/06/16 General Meeting Minutes

Attendance: 11
Minutes for 20110602 approved
    
Technical Team Report - Kate

• Tools: Updating tools as needed
• Spec: Working minor changes to June 5 version of the spec
• Spec: Have had interesting discussions with Cisco about mapping SPDX to their current process. Expect that new fields and possibly new models will come out of this discussion
• Beta feedback: Looking for place to collect/present feedback. Would like to be sure we capture feedback even for items we've resolved. Kim plans to create wiki page.

Business Team Report - Kim

• Beta program:
  
  • HP/WindRiver & OL/Antelink continue to make progress
  • Motorola/TI progress is not yet clear
  • There's been some confusion over license fields at package level. A wiki discussion on this topic can be found here: http://spdx.org/wiki/license-field-discussion
• GA Launch:
  • Continue to work to get ready for launch at LinuxCon NA in mid-August

Legal Team Report - In absentia

• All legal team members are at a separate face-to-face meeting and unable to attend this meeting

Cross Functional Issues – Discussion

• Website update- Kirsten
  • Working on mind-maps for proposed flow; plan to present more generally in next few weeks
  • Logistical question from Kim: should we remove or archive older content?
    
    • Both options are available; deleting won't create orphaned pages
    • Will likely decide on case-by-case basis
• Package License fields - Postponed until next meeting since legal team not present this week

Open Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING
• Kim -- share Biz Team proposed process for adding licenses to SPDX list more broadly
• Michael H. -- provide info on existing BOM standards that should be useful for future consideration
• Legal/Biz Teams- Review and update Master Schedule
• ?? -- volunteers needed to review and update the FAQ: http://spdx.org/wiki/draft-spdx-faq

Attendees

• Kirsten Newcomer, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Bill Schineller, Black Duck Software
• Gary O'Neall, Source Auditor
• Martin Michlmayr, HP
• Kate Stewart, Canonical
• Brandon Robinson, Cisco
• Tom Incorvia, Microfocus
• Phil Koltun, Linux Foundation
• Juergen Weigert, SuSE

2011/1/13 General Meeting Minutes

Administrative

• Attendance - 13
• Minutes from 16 Dec meeting approved

Technical Team Report

• New Infrastructure is up and running
  • Bugzilla is in place. (use will be broad including tracking issues with documentation and the website for example) All are encouraged to set up accounts.
  • GIT repository- Gary's pretty printer and the RDF version are up already. 
• DEP-5 proposal is in draft state. if we want to sync with them in any way, the time is right. They are open, for example to using the same license short names. We'll assess current gaps and then decide how to proceed.
• The spdx-tech mailing list is very active; interested parties are encouraged to join.
• Started on the grammar for the tag version to facilitate the comprehension of it for the RDF/tag form translation.

Business Team Report

• Beta program
  • Progressing
  • 5 organizations are interested. (WindRiver/HP have agreed to work together)
  • Kickoff meeting with participants Feb3 during the normal Biz Team.
• Next big issue to deal with is getting end user content developed (doc, training, etc.).

Legal Team Report

• Task of developing a process for adding new licenses to the license list has been handed off to Biz Team.
• Rockett/Jilayne and Soren working on the license template scheme.
• Team has been discussing how the spec will influence the way in which the content of SPDX docs is licensed. Team is leaning towards MIT/BSD. 

Cross Functional Issues

• Much discussion on the issue of subjectivity v. objectivity with respect to file licenses.
• Example- License A text in header, but author of SPDX doc believes actually License B.
• Several in the discussion were adamant that the stated license in the file needed to be specified.
• Others felt it was important to include the license author's believed correct license.
• Group came to broad agreement on the idea of including fields for both and a comments field to explain discrepancies.
• Discussion to be continued in ad hoc Legal Team meeting tomorrow.

Action Items

• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING
• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. PENDING
• Rockett- Post regular meeting times on Legal Team page.  DONE
• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING
• Jilayne- Add column to license list showing DEP-5 short names for comparison.
•  

Attendees

• Kate Stewart, Canonical
• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Jilayne Lovejoy, OpenLogic
• Phil Koltun, Linux Foundation
• Gary O'Neall, Source Auditor
• Esteban Rockett, Motorola
• Michael Herzog, nexB
• Pierre Lapointe, nexB
• Mark Gisi, Wind River
• Jack Manbeck, TI
• Tom Incorvia, Microfocus

2011/1/27 General Meeting Minutes

Administrative

• Attendance - 9
• Minutes from 13 Jan meeting approved

Technical Team Report

• Met Tuesday with Kate joining from Australia
• Most of the discussion was about new license fields in file section of spec

Business Team Report

• Questions for Tech Team on how the schedule looks. Generally good for end of Q1 completion of what's required for beta, albeit Kate was not here to weigh in.
• Beta program
  • Kickoff meeting with participants Feb3 during the normal Biz Team. Feel free to participate or invite anyone interested.
  • There will be subsequent meetings with partner pairs
  • Should be ready to go in April

Legal Team Report (From PhilO/Jilayne in Rockett's absence)

• Recent focus has been on new fields for file licenses:
  • Concluded License- Based on author's analysis
  • License Information in File- Just what's in the file
  • Also a field for explanation of basis for conclusion
• We will change a handful of license short names for consistency with DEP-5 list

Cross Functional Issues

• PhilO explained new Master Schedule under General Meeting

Action Items

• Kate/Kim- Draft example for LF Member Counsel; include XML and spreadsheet. PENDING
• MichaelH/Rockett- Write up and share postion on "reporting" vs. "interpreting. PENDING
• MartinM- Report back on # of people on respective mailing lists. DONE, BUT LET'S KEEP UPDATING
• Jilayne- Add column to license list showing Deb5 short names for comparison. DONE
•  

Attendees

• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Jilayne Lovejoy, OpenLogic
• Phil Koltun, Linux Foundation
• Gary O'Neall, Source Auditor
• Mark Gisi, Wind River
• Guillaume Rousseau, Antelink
• Bill Schineller, Black Duck Software

2011/12/1 General Meeting Minutes

Attendance: 7

     
Technical Team Report - Kate

• Bugzilla, the final piece of downed infrastracture up, so we are finally fully functional
• Tech team has been meeting regularly thru the outtage. 
• Minutes have been distributed through the mailing list and will be posted
• Shortly a new draft will be available, either "1.1" or "1.0.1"
• EdW is still working on a proposal for handling hierarchy which will be the basis for SPDX 2.0.
• There have been some good recent contributions to the SPDX tools including a new verification tool

Business Team Report - Michael Herzog (in Kim's absence)

• Most of the recent discussion has been on our infrastructure plan in the wake of the outtage.
• No update on new website.

Legal Team Report - Jilayne (in Rockett's absence)

• Data license issue
  • Seems to be resolved to everyone's satisfaction.
  • Rockett drafted a pre-amble to the CC0 license and got support from Eben Moglen.
• Next Steps
  • Templatizing work is resuming in the next Legal Team call.
  • Jilayne is resuming some clean-up on the license list

Cross Functional Issues – Phil

• Infrastructure
  • Discussed the LF's infrastructure issue. Phil's opinion is that the new infrastructure meets our needs
  • In the next couple weeks there will be a meeting with folks from the Linux Foundation in which they will present an overview what's been done, the idea being to make us comfortable.
  • We don't want to group to be overly large, but if anyone is interested in participating, email Phil.

Open Action Items

Attendees

• Phil Odence, Black Duck Software
• Kate Stewart, Canonical
• Jilayne Lovejoy, OpenLogic
• Michael Herzog, nexB
• Pierre Lapointe, nexB
• Adam Cohn, Cisco
• Brandon Robinson, Cisco

2011/12/15 General Meeting Minutes

Attendance: 12

Dec1 Minutes Approved

     
Technical Team Report - Kate

• Hierarchy is the focus; trade off is backward compatibility
• Aiming for August 2.0 with hierarchy being the big change.
• 1.1 targeted for Q1
  • CC0 License and preamble
  • Updated verification algorithm
  • Bug fixes
• Cleanup in process on current website

Business Team Report - Kim

• New Website
  • Sandbox is ready for updating as of next Monday
  • Need voluteers for migrating/adding content to some sections (see SPDX.org for sections that need help); contact Kim
  • Pierre will send out instructions by Monday
• Kim updating list of conferences for next year; looking for presenters to keep spreading the SPDX word
• Anticipating Face to Face Meetings at:
  • Collaboration Summit, April 3-5 in San Francisco
  • LinuxCon NA, Aug 29-31, San Diego

Legal Team Report - Adam/Jilayne (in Rockett's absence)

• License preamble is ready to run by anyone who was uncomfortable (like Fedora folks)
• Still open for tweaks
• Templatizing will commence after the first of the year

Cross Functional Issues – Phil

Open Action Items

Attendees

• Phil Odence, Black Duck Software
• Kate Stewart, Canonical
• Jilayne Lovejoy, OpenLogic
• Michael Herzog, nexB
• Pierre Lapointe, nexB
• Adam Cohn, Cisco
• Brandon Robinson, Cisco
• Gary O'Neall, Source Auditor
• Mark Gisi, Wind River
• Kim Weins, OpenLogic
• Tom Incorvia, MicroFocus
• Kirsten Newcomer, Black Duck Software

2011/6/30 General Meeting Minutes

Attendance: 12
Minutes for 20110616 approved
     
Technical Team Report - Kate

• Tools- some issues have arisen in beta, but are being rapidly resolved
• New spec and tool versions due next week
• FAQs need work- all pls review

Business Team Report - Kim

• Extended biz meeting on July 7 to focus on beta fb and website. All invited
  • Aim is to ID only showstopper items
• GA Launch:
  • Stake in ground for mid-August
  • Press release- to include endorsements
  • Phil has speaking slot, JimZ should mention in Keynote, Table/Booth of some sort

Legal Team Report - Rockett

• Maximizing adoption is the filter for all decisions
• Key current issue: Creator/Reviewer fields
  • Some Member Counsel are concerned about having files wrongly attributed to companies
  • Team is working to understand and address concerns
  • But don't want to casually drop fields that may be valuable to others
• Question about rules for resolving- Concensus is ideal

Cross Functional Issues – Discussion

• Approach to convergence on V1.0
  • Still open legal/biz issues. 
  • Driving for resolution by end of July
  • Identify showstoppers in beta meeting and ID owners to sheppard resolution of each
  • Clean up spec and finaliz by 8/12, prior to 8/17 launch 
• Website
  • Shifted from mockups to mindmap
  • To be presented at meeting on 7th
  • Volunteers needed for sandbox
• BOM formats MichaelH
  • Real BOMs can be very complex with unlimited depth and width
  • Hierarchy is key
  • There are two well-known existing models
    • ERP BOM data model
    • PDX - Product Data Exchange
  • We don't need to deal with today, but need to consider in the future
  • Michael posting

Open Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING
• Kim -- share Biz Team proposed process for adding licenses to SPDX list more broadly
• Michael H. -- Posting BOM info
• Kim- Creating FAQ strucdture and handing out pieces for review, cleanup, additions

Attendees

• Phil Odence, Black Duck Software
• Kirsten Newcomer, Black Duck Software
• Kim Weins, OpenLogic
• Peter Williams, OpenLogic
• Gary O'Neall, Source Auditor
• Martin Michlmayr, HP
• Kate Stewart, Canonical
• Brandon Robinson, Cisco
• Tom Incorvia, Microfocus
• Pierre LaPonte, nexB
• Jilayne Lovejoy, OpenLogic
• Esteban Rockett, Motorola
• Michael Herzog, nexB

2011/7/13 General Meeting Minutes

Attendance: 10
Minutes for 20110630 approved
     
Technical Team Report - Kate

• Added field for version of package
• Legal team is working on fields for data licensing
• Working thru bug list; looks like no big issues
• Tools on track

Business Team Report - Kim

• GA Launch:
  • Press release- to include endorsements
  • Phil has speaking slot, JimZ should mention in Keynote, 1 pg handout, table

Legal Team Report - Rockett

• Working on clearing Creator/Reviewer field issue
• Templatizing has taken back seat; may only provide general guidelines for v1.0 release.
• Adding some explanation to the concluded license field

Cross Functional Issues – Discussion

• LinuxCon
  • Attendance- PhilO, Kate, PhilK, Daniel, Pierre, Kim, Rockett will all attend. 
  • We'll have a table which we will man during breaks with above folks
• Website
  • Pierre/Steve working in Sandbox
  • On track for launch
  • Will open to SPDX list prior to

Open Action Items

• MartinM- Report back on # of people on respective mailing lists. ONGOING
• Kim -- share Biz Team proposed process for adding licenses to SPDX list more broadly
• Michael H. -- Posting BOM info
• Kim- Creating FAQ strucdture and handing out pieces for review, cleanup, additions

Attendees

• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Martin Michlmayr, HP
• Kate Stewart, Canonical
• Pierre LaPonte, nexB
• Jilayne Lovejoy, OpenLogic
• Esteban Rockett, Motorola
• Michael Herzog, nexB
• Bill Schineller, Black Duck Software
• Daniel German, U. of Victoria
• Phil Koltun, Linux Foundation

2012/01/12 General Meeting Minutes

Attendees

• Kim Weins
• Gary O'Neall
• Michael Herzog
• Jilayne Lovejoy
• Mark Gisi
• Brandon Robinson
• Steve Cropper

Legal Update from Jilayne

• Talked about Legal To-Do's
• Legal team is working on templatizing -- they have a  draft of guidelines.  There are some outstanding issues
• Need to get going on the license approval process.  Biz team is owning the process but legal will be participants as well.
• Jilayne and Adam finalized the last edits on the preamble for the data license.  Kim to send to community people for feedback
• Mark Gisi has updated "rationale doc" that explains why we selected data license.  That doc is not yet on website, but Mark to upload

Tech Team Update from Gary

• Work of tech team is focused on the 1.1 spec.
• They did a review of the draft 1.1 spec and there were a few follow up items.
• Plan is to resolve those issues and update the RDF and the tools by the end of Q1.
• 3 new tools are available that
  • Convert between SPDX Tag and RDF format (both ways)
  • Convert from SPDX to HTML
• 1.1 Features are:
  • Updated data license to CC0
  • Fix typos
  • Fix the verification codes
  • Add tracking of suppliers
• Tech team is also starting on the hierarchical/embedded design for 2.0.

 Biz team update from Kim

• Website conversion is almost ready to start
  • Web team had a meeting earlier in the week to review the work that is done
  • Steve Cropper to schedule a web training for next week to show people how to convert content
• Discussed EclipseCon
  • Protecode is taking the lead to organize a BOF
• Discussed Software Supply Chain Summit idea
  • The idea is to have an in person 1 day meeting in Bay Area
  • Target date is Fri April 6, right after Collab Summit
  • Invite people from companies in the software supply chain -- including non-SPDX participants
  • SPDX people could also invite supplychain partners
  • We want to start to socialize and spread SPDX
  • Agenda would need to be developed, but contect would include SPDX Basics, End User talks, License info, tools as well as discussions
  • Steve Cropper said Cisco may be willing to host.  HP may as well.
  • Kim to follow up with LF and let them know.

2012/01/26 SPDX General Meeting Minutes

Attendance: 9
Minutes for 2011/12/15 approved
     
Technical Team Report - Gary

• Much focus on defining approach for 2.0 spec.
• Two key elements: Hierarchy and time element (revisions, supply chain, approvals)
• Progress forward, but some concern that we are not converging rapidly enough
• Key discussion about backwards compatibility and how important it is for 2.0.

Business Team Report - Kim

• New website has been recent focus.
  • There was a training meeting and an email went to voluteers for content migration.
  • Web team is implementing the new menu structure and will then green light volunteers to move content.
  • That will take two weeks, followed by cleanup.
• License List addition process
  • Dusted off notes from previous discussion and concluded it looked pretty good.
  • Kim working with legal team to review
  • Then we need to publish and implement
• Community outreach re: data license
  • Kim reaching out to Gentoo, Fedora, Eclipse
  • Thumbs up from Gentoo; waiting on Fedora and Eclipse
  • Adding Gentoo licenses to license list
• SPDX outreach meeting
  • Silicon Valley, April 6; plans in motion

Legal Team Report - Jilayne

• Preample to data license complete and will be published.
• License List
  • License "Templatizing" is taking a new approach; better described as "license list matching guidelines."
  • Good progress; lots of concensus
  • Discussion about best form or forms in which to publish (CSV, Excel, HTML)

Cross Functional Issues – Phil

• Heads up- Potential for need for modest SPDX funding from participating companies in the future. Probably a when, not if. 

Open Action Items

• Phil- If it looks like 2.0 may have backward compatibility issues, call broad meeting for community input.

Attendees

• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Gary O'Neall, Source Auditor
• Tom Incorvia, Microfocus
• Pierre LaPonte, nexB
• Jilayne Lovejoy, OpenLogic
• Jack Manbeck, TI
• Steve Cropper, Cisco
• Chuck Gaudreau, Protecode

2012/02/09 General Meeting Minutes

Attendance: 10
Minutes for 2011/1/26 approved
     
Technical Team Report - Gary

• 2.0 Spec
  • Great progress on hierarchy issue.
  • Gaining agreement on importance of backward compatibility. Goal is 100%, but some openness to exceptions (which would have to be run by Biz Team and General Meeting)
  • Still concern about tightness of schedule (for August completion) but progress is accelerating.
• 1.1 is very close. Gate is validating the verification algorithm.

Business Team Report - Kim

• Website conversion is underway. Aiming for end of month to flip switch.
• End User Event - April 6 in San Jose (after Collab Summit)
  • Cisco hosting.
  • Aiming for 50-60 people.
  • Idea is to bring in new supply chain partners.
  • Educational agenda.
  • 9-2 or 3pm

Legal Team Report - Jilayne

• License List Guidelines
  • Guidelines for matching now posted on the web.
  • Discussion going on about whether copyright is part of the license.
  • Down to 9-10 issues.
• License List Format
  • Question is in what form is the "golden" list.
  • Excel limiations on characters in field trucate license text for some licenses.
  • Possible solution is include, not text of license, but link to text, in spreadasheet.

Cross Functional Issues – Phil

• Website Management and Hosting
  • Martin M leading team.
  • Need to define requirements first, solution second.
• Collab Summit
  • Straw pole indicatd 10-15 participants from companies represented in this meeting.

Attendees

• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Gary O'Neall, Source Auditor
• Pierre LaPonte, nexB
• Jilayne Lovejoy, OpenLogic
• Martin Michlmayr, HP
• Steve Cropper, Cisco
• Kate Stewart, Canonical
• Mark Gisi, WindRiver
• Michael Herzog, nexB

2012/02/23 General Meeting Minutes

Attendance: 10
Minutes for 2011/2/9 approved
     
Technical Team Report - Kate

• 2.0 Spec
  • 3 proposals on the table under debate
  • Schedule is in flux
  • Team understands backward compaitibility issue.
• 1.1 Spec
  • Needs feedback.
  • Still verifying the new verification algorithm.

Business Team Report - Kim

• Website content is moving, albeit a little behind schedule. Still believes we will flip switch this Q.
• End User Event - April 6, 9-3 in San Jose (after Collab Summit)
  • Agenda in minutes of Biz Team meeting
  • Aiming for 50-60 people.
  • Reaching out to local bar association.
• Collab Summit
  • Looks like we will have a keynote and a presentation in the Legal sessions on Wednesday
  • Kim working on lining up rooms for a tech meeting.

Legal Team Report - Jilayne

• License List
  • Pulled text our of golden spreadsheet due to truncation issue and replaced with links to txt files.
  • All posted on spdx.org including latest matching guidelines
  • Jilayne recruiting volunteers to check txt files (where there have been some translation errors)
• Forum
  • Had some discussion about Forum. Concern that in the past tech legal discussions in public forums scared some people off, so team will act accordingly.

Cross Functional Issues – Phil

Attendees

• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Gary O'Neall, Source Auditor
• Jilayne Lovejoy, OpenLogic
• Kate Stewart, Canonical
• Mark Gisi, WindRiver
• Brandon Robinson, Cisco
• Adam Cohn, Cisco
• Freddy Munoz, Antelink
• Tom Incorvia, Microfocus

2012/03/08 General Meeting Minutes

Attendance: 10
Minutes for 2011/2/23 approved
     
Technical Team Report - Kate

• 2.0 Spec
  • Focusing in 2 proposals for signing, then revisiting how to handle hierarchy
  • Hoping to reach final resolution at Collaboration Summit
• 1.1 Should be final before Collaboration Summit

Business Team Report - Phil (written input from Kim)

• Website conversion goes slow.
• SPDX participation in Collaboration Summit is on track.
• Forum is firming up as well

Legal Team Report - Jilayne

• Behind on updating Legal Section of new website
• License Text review needs volunteers (Phil volunteered...how about you?)
• License List
  • MPL 2.0 is up
  • Issues with "or later" to be reviewed.
  • Planning to hammer out several issues with tech team at Collaboration Summit
  • David Wheeler from a DC think tank wants to push government adoption of the License List
    • Needs a way to specially designate "US Govenment Works"
    • Team needs to resolve if/how we will handle with License List

Cross Functional Issues – Phil

• Martin reports slow progress in charting out the future of the website.

Attendees

• Phil Odence, Black Duck Software
• Kim Weins, OpenLogic
• Pierre LaPonte, nexB
• Jilayne Lovejoy, OpenLogic
• Martin Michlmayr, HP
• Steve Cropper, Cisco
• Kate Stewart, Canonical
• Adam Cohn, Cisco
• Michael Herzog, nexB
• Scott Lamons, HP

2012 Feb 1 - Merged Model Proposal

Below is a class diagram merging Ed Warnicke's proposed SPDX Element model with the 1.0 model.  Definately a work in progress.  Most of the class definitions can be found in the 1.0 spec in the RDF appendix (model) or in Ed's proposal (http://spdx.org/wiki/rough-proposal-hierarchy-signing-and-supply-chain-friendliness-spdx-20).

The goals of this proposal are to:

- Support the use cases for the 1.0 spec

- Support the supply chain use cases

- Support the "hierarchical" or embedded package use cases

- Provide a more abstract model which can simplify the application of SPDX to some of the more complex use cases

This proposal extends the existing proposals by adding an SPDX Element Relationship which describes the type of relationship from one SPDX element to another.

 See the attached document for the mapping between the SPDX 1.0 properties and this proposal.

See the attached document for a proposal on creating RDF references to other Licensable documents which can be verified through checksums.

Attachments: 

proposedmodel.png

mapping_spdx_1.0_to_merged_model.pdf

proposed_mechanism_to_map_external_references_to_spdx_licensable_elements.pdf

2012-Mar-11 SPDX File Aggregation

Status

Draft

Issue

In order to facilitate the delivery of multiple SPDX Data Files (and possiblye SPDX Data Signature Files ) we need some standard way of grouping them together for simple transport and delivery.

Proposal

Modify the spec to state that

1. Archive Format: When multiple SPDX Data Files need to be delivered together as a group, they should be archived in a Zip file format.  
2. Data & Signature File Grouping: When it is desirable to deliver one or more SPDX Data Files together with one or more related SPDX Data Signature files, the naming convention of Proposal-2012-Mar-6 Detached Signed SPDX Files should be followed.
3. File Naming Convention: SPDX Archive files should be named <filename>.spdx.zip.    

Examples

Example 1

$ unzip -l example.spdx.zip 
Archive:  example.spdx.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  03-11-12 20:18   example.spdx
        0  03-11-12 20:18   example.spdx.sign
 --------                   -------
        0                   2 files

Example 2

 
$ unzip -l example2.spdx.zip 
Archive:  example2.spdx.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  03-11-12 20:18   example.spdx
        0  03-11-12 20:18   example.spdx.sign
        0  03-11-12 20:21   example2.spdx
        0  03-11-12 20:21   example2.spdx.sign
 --------                   -------
        0                   4 files

Compatibility

Resulting <filename>.spdx.zip files will not be backward compatible with SPDX 1.0 tooling. However, the SPDX Data Files they contain can be, and can be easily extracted by ubiquitously available tools and libaries are virtually every platform and in virtually every programming language.

2012-Mar-20: Licenses associated with licensor

Status

Draft

Issue

Bug 1000

To correctly fulfill the terms of some licenses you must know who the licensor is. Currently SPDX has no way to represent this in the situation where there are multiple licenses.

Proposal

Modify the spec in the following ways

• Introduce a LicenseDeclaration entity type. Any number of instances of this type of entity would be allowing in an SPDX dataset.

• A LicenseDeclaration entity would have zero or more licensor properties whose values are Agents.

• A LicenseDeclaration entity would have exactly one licensing property whose values is a AnyLicenseInfo.

• A LicenseDeclaration entity would have zero or more declarer properties whose values are Agents.

• Allow the value of the licenseConcluded property to be a LicenseDeclaration in addition to the currently allowed AnyLicenseInfo.

Proposal 2011-12-20: SPDX analysis history tracking

Status

Proposed

Issue

Currently there is no way track relationships between SPDX datasets.

For example, PostgreSQL project is most licensed under an MIT like license but has some code in the contrib directory which is GPL. If i want a PostgreSQL without any GPL obligations i can simply build it without the contrib directory. I can start with publicly available SPDX dataset for PostgreSQL, remove all files in the contrib directory from the dataset and save it as the SPDX dataset for my PostgreSQL w/o GPL project.

If i do this there is no way for someone else to know that my SPDX data is derived from the public PostgreSQL SPDX data. If any issues are found in the public SPDX data they might effect my SPDX data also. Or if someone found problems in my SPDX data it would be useful to track that issue back to the original source and fix it there.

Proposal

Add an optional property to SpdxDocument which would specify another SpdxDocument from which it was derived. The isVersionOf property in the Dublin Core vocabulary is widely used and has the correct semantics.

Example (Turtle RDF)

  <http://example.com/spdx/postgresql-sans-contrib-9.1.2> a :SpdxDocument; 
    dc:isVersionOf <http://postgresql.org/spdx/9.1.2>; :describesPackage ... .

Example (Tag)

 IsVersionOf: http://postgresql.org/spdx/9.1.2 

The addition of this property would allow the history a particular SPDX dataset to be determined by following the isVersionOf properties of each SpdxDocument. Differences between any two SpdxDocuments could be determined by comparing the two dataset.

Compatibility

This change is fully backwards compatible for consumers that ignore properties they do not understand.

Proposal 2012-Mar-05: Inline signed SPDX files

Status

Draft

Issue

Currently there is no way to be sure that an SPDX file has not been modified by a third party after it was produced. See also, issue 980.

Proposal

Modify the spec to state that allow SPDX producers may  cryptographically sign SPDX files using the PGP clear text signature format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers must accept signed SPDX files, but would not be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would not be required to do so.

Example

SPDX file

SPDXVersion: SPDX-1.0
DataLicense: PDDL-1.0
Creator: Person: Peter Williams

Signed SPDX file

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SPDXVersion: SPDX-1.0
DataLicense: PDDL-1.0
Creator: Person: Peter Williams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQEcBAEBAgAGBQJPVZO9AAoJENTSLvN5TFz940UH/j2/dys3uK6VTqnNBi/yQQxQ
sp/+wBhJThQ4qzph2Zy4pmpjX4u9iwuaIvkOigYp/XR8sdJExQSSSxLxgkfPokRG
4dN8YRZyQ3fTVuCz5DPas9B4NCcZTn77nB8Gas4wzyli7Pqu3YKfq81sfIyxnC+G
/LIMidJ6JD9mvcLmgsbz5zDwmEFnafXcgocK0d9Fbhvx6MKPK7dFxdQ9oN1lV9Ej
hED+wpGIQSSdSJBc2udKAxPZHFQxOTHHr8flxC6bzq01xyjm0W2hDDd0jKRN/cqZ
o10Une5wEO/p7UqFDoNh++kLJeODJ2ZKLr4qwrGXODKLDd5F8ZdDB8deuIb/7RM=
=jdOZ
-----END PGP SIGNATURE-----
 

Command sign an SPDX file

$ gpg --clearsign sample.spdx

Advantages

Embedding the signature in the the SPDX file has several advantages. The combination of the data and its signature reduce the possibility that the two will be accidentally separated as the SPDX data is passed from person to person. Such a separation could happen if an SPDX signature file is simply forgotten, or it could happen very easily if the name of an SPDX file ever needs to be changed. Having that data together will also make tooling easier to build because finding the signature data will be less error prone. Embedding the signature prevents large classes of mistakes from occurring and as such removes the need to cope with them.

Compatibility

This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.

Proposal 2012-Mar-06: Detached Signed SPDX Files

Status

Draft

Issue

Currently there is no way to be sure that an SPDX file has not been modified by a third party after it was produced. See also, issue 980.

Proposal

Modify the spec to state that

1. Signing Convention: SPDX producers may  cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  
2. Signature File Naming Convention: The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.
3. Signature File Renaming: Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  
4. Consumption Optional: SPDX consumers may accept or ignore SPDX signature files. 
5. Production Optional: SPDX producers would have the option of signing SPDX files but would not be required to do so.  

Example

SPDX file

 SPDXVersion: SPDX-1.0 DataLicense: PDDL-1.0 Creator: Person: Ed Warnicke 

Signed SPDX file

 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEABECAAYFAk9WSn0ACgkQpqzn7Jq4hlCfYACbBelTUtjOGAYrSBXEODD9Ukpo vuAAn2gLkGsGOntkUTERnISOyOoBJxlT =JxE7 -----END PGP SIGNATURE----- 

Command sign an SPDX file

 $ gpg --armor --output example.spdx.sign --detach-sig example.spdx

Advantages

Detaching the signature in the SPDX file has several advantages.

1. Leverage Existing Tools: It allows underlying tools that are used to process the formats into which SPDX is normally encoded (RDF tools, Tag Tools, XML Tools, etc) to continue to function normally. 
2. Tooling Simplication: It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who *just* wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.
3. Community Standard: It follows the convention already being followed by kernel.org, mavencentral, the apache foundation, and most packagers.

Disadvantages

Detaching the signature in the SPDX file could lead to

1. Misplaced Signatures: Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file
2. Signature Correlation: Separation of the signature file from the SPDX file introduces the need to correlate signature files with SPDX files.

Compatibility

This proposal will produce files that are trivially backwards compatible. Specifically a signed filed will be readable by SPDX-1.0 compliant consumers and any tool capable of reading it's underlying encoding format (RDF, XML, Tag). By making the issue of signing orthogonal, we maintain separation of concerns.

Application which ships with a contrib libraries

1. Title: Application which ships with a contrib libraries
2. Primary Actor: Committer of the open source project containing the contrib library
3. Goal in Context: To include within the distribution of an open source project contributions made by non-project members.  These contributions are by default not built into the resultant binaries (assuming there are build scripts included in the distribution).  There can be no dependency from the main project on the contrib code.  The contrib libraries may contain licenses different from the main open source project.
4. Stakeholders and Interests:
   1. Committers to the open source project:
      1. Isolates the contrib copyrighted artifacts so that any copyleft licenses will not impact the overall licensing of the project (including the project committers copyrighted works).
   2. Contributors to the contrib library:
      1. Allow the contributors to make their contributions available under the license of their choice
   3. Consumers of upstream copyrightable artifacts:
      1. To receive accurate and clear information of licensing of artifacts
      2. To be able to distinguish copyrighted artifacts intended for be build and distributed as part of the project from optional copyrighted artifacts which may or may not be included
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions:
   1. Project has been organized with clear distinctions between the contrib and main project artifacts
   2. Licensing information has been collected for the contrib and main project artifacts
6. Main Success Scenario: Committer provides complete licensing information and an indication of which artifacts are part of the main project and which artifacts are part of a contrib library.  Each contrib library will contain information on licensing.
7. Failed End Condition: Committer does not specify an artifact is part of a contrib library causing confusion on the applicable license for the overall project.
8. Trigger:
   1. Project release
   2. Contrib updates
9. Notes:  This use case is from the perspective of a committer who is assembling/aggregating additional contributed code for further distribution.  The downstream recipient of the package may choose to use one of the contrib items as part of their delivery could alter the licensing for the aggregated work product.  The downstream recipient could also remove the contrib artifacts completely.
10. Example: Postgresql, which ships under a BSD license overall, contains a contrib/ directory that contains GPL licensed code.

Application which ships with development tools

1. Title: Application which ships with development tools
2. Primary Actor: Committer of the open source project containing the contrib library
3. Goal in Context: To include within the distribution of an open source project development tools used to build a deployable executable (or executables) from the open source code.  These development tools would not be included in any resultant executable and may be under a different license than the stated license for the project.
4. Stakeholders and Interests:
   1. Committers to the open source project:
      1. Makes clear which copyrightable artifacts are intended to be used only at development time and is not intended to be distributed with any executables.
   2. Consumers of upstream copyrightable artifacts:
      1. To receive accurate and clear information of licensing of artifacts
      2. To be able to distinguish copyrighted artifacts intended to be build and distributed as part of the project from build tools intended to be used at development time
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts
5. Preconditions:
   1. Project has been organized with clear distinctions between the build tools and other project artifacts
   2. Licensing information has been collected for the build tools and main project artifacts
6. Main Success Scenario: Committer provides complete licensing information and an indication of which artifacts is part of the main project and which artifacts are part of the build tools. Each build tool will contain information on licensing.
7. Failed End Condition: Committer does not specify an artifact is part of the build tools causing confusion on the applicable license for the overall project.
8. Trigger:
   1. Project release
9. Notes: This use case is from the perspective of a committer who is assembling/aggregating additional build tools for further distribution.  Although the intent of the committer for the build tools has been made, the downstream recipient may choose to use the build tools in a different manner (e.g. include some of the source in the main project itself).  The downstream recipient may also replace or remove the build tools.
10. Example: Wireshark, a network analyzer licensed under GPLv2, contains in it's source base piddle, which is GPLv3, but is solely used as a tool for building wireshark, and no part of which goes *into* any of the binary artifacts built out of Wireshark.

Collecting enough information to allow auditor to make recommendations to remove or not a component

1. Title: Collecting enough information to allow auditor to make recommendations to remove or not a component
2. Primary Actor: Auditor of open source code
3. Goal in Context: To provide the consumer of the code audit sufficient information to make changes to the copyrighted materials in order to comply with the consumers policies regarding open source compliance.
4. Stakeholders and Interests:

   1. Consumer of the audit:

      1. Organization which has an interest in the license obligations of the copyrighted materials
      2. Will typically have policies (either formal or informal) on the use of open source
5. Preconditions:
   1. Access to souce code tree by auditor
6. Main Success Scenario:
   1. Source code is analyzed by the auditor and the origin for code and associated license is created
   2. Policy violations are identified to the file (at least) level
   3. Information on the audit is provided in an SPDX file + additional information (e.g. report)
   4. Remediations are made to the source to comply with the policy
   5. Source code is re-analyzed and an SPDX file describing the compliant code is produced
7. Failed End Condition:
8. Trigger:Audit
9. Notes: 
10. Example: Company has a policy not to deploy any GPL code compiled into their proprietary commercial software.  Audit is performed to identify any GPL code and comply with the policy prior to a product release.

Committer annotates source files with SPDX data

1. Title: Committer annotates source files with SPDX data
2. Primary Actor: Committer
3. Goal in Context: To indicate SPDX data for the file in the source code file.
4. Preconditions: 
   1. Committer has decided the license for the file they are committing
5. Stakeholders and Interests: 
   1. Committer: 
      1. To communicate the license information for the file in line with the file.
   2. Upstream maintainers: 
      1. To be able to have the source code be self documenting in a machine and human readable manner with respect to license information.
      2. To communicate the licensing information for their copyrightable artifacts.  
      3. To have their licenses respected
   3. Consumers of upstream source:
      1. To receive accurate and clear information of licensing of upstream source
      2. To be able to comply easily with licenses for upstream source
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
6. Main Success Senario: Source code files contain complete accurate SPDX data sufficient to communicate their licensing information in a way that is both human and machine readable.
7. Failed End Condition: Source code files lack complete accurate SPDX data.
8. Trigger:
   1. Commit of code to an upstream project.
9. Notes: There may be sub-use cases here around the distinction between original authorship of a file and capturing in SPDX existing information about the file, either from existing file headers or from commit logs.

Committers provides SPDX data for a code being committed

1. Title: Committers provides SPDX data for a code being committed
2. Primary Actor: Committer
3. Goal in Context: To include SPDX data for code being committed to an upstream project.
4. Stakeholders and Interests: 
   1. Committer: 
      1. To communicate the licensing information for the code they are committing to the upstream project.
   2. Upstream maintainers: 
      1. To be able to document the license information for the commits they receive
      2. To communicate the licensing information for their copyrightable artifacts.  
      3. To have their licenses respected
   3. Consumers of upstream source:
      1. To receive accurate and clear information of licensing of upstream source
      2. To be able to comply easily with licenses for upstream source
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Committer has decided on licensing information for their commit.
6. Main Success Senario: Committer communicates accurate complete licensing information for their commit in an SPDX data format as part of the commit process.
7. Failed End Condition: Committer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Commit of code to an upstream project.
9. Notes:  

Communicate data beyond what is described in spec

A vendor wants to embed information about a package in its SPDX file that is not representable using standard SPDX fields (and/or classes).

Stakeholders and interests

SPDX producer

The person or organization that is producing the SPDX and wish to extend it with non-standard information.

standard SPDX consumer

A person, organization or tool that can read and process standard SPDX data but is not aware of the non-standard extensions being used by "SPDX producer".

extended SPDX consumer

A person, organization or tool that can read and process the non-standard extensions used by "SPDX producer" as well as standard SPDX data.

Main success scenario

1. SPDX producer analyzes the package for all the standard SPDX data
2. SPDX producer analyzes the package for the list actions they believe are required to comply with the licensing of the package
3. SPDX producer generates an SPDX file which included both the standard SPDX data and the compliance checklist
4. SPDX producer publishes this file on their website as a "SPDX file for package X"
5. 1. An extended SPDX consumer downloads the SPDX file and uses the checklist to ensure they are meeting their licensing obligations
   2. A standard SPDX consumer downloads the SPDX file and uses the standard data as input into their compliance processes

Contributor makes commit subject to existing SPDX data of project

1. Title: Contributor makes commit  subject to existing SPDX data of project
2. Primary Actor: Committer
3. Goal in Context: To indicate the commit is subject to existing SPDX data for the project.
4. Preconditions: 
   1. Committer has decided to accept the licensing for the project
   2. The Upstream Maintainer is providing SPDX data for the project.
5. Stakeholders and Interests: 
   1. Committer: 
      1. To communicate that their commit is licensed in alignment with the SPDX data for the project.
   2. Upstream maintainers: 
      1. To be able to document the license information for the commits they receive
      2. To communicate the licensing information for their copyrightable artifacts.  
      3. To have their licenses respected
   3. Consumers of upstream source:
      1. To receive accurate and clear information of licensing of upstream source
      2. To be able to comply easily with licenses for upstream source
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
6. Main Success Senario: Committer communicates that they are agreeing to the SPDX data for the project applying to their commit.
7. Failed End Condition: Committer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Commit of code to an upstream project.
9. Notes:  

Intermediate packager adds patches to upstream source that provides SPDX data

1. Title: Intermediate packager adds patches to upstream source that provides SPDX data
2. Primary Actor: Intermediate packager (someone building a rpm, deb, etc from upstream source)
3. Goal in Context: To include in the package SPDX data describing the packages licensing information for the package base upon the SPDX data provided by the upstream source in a way that allows the packager to verifiably reference the upstream packagers SPDX data and also to include SPDX data describing the packagers additions (patches) to the project.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Intermediate Packager:
      
      1. To communicate the licensing information for their package
      2. To communicate the licensing information for the packagers additions (patches) to the upstream source.
      3. To communicate the licensing information provided by the upstream maintainer.
      4. To respect the licenses of the upstream maintainer
   3. Consumers of packages:
      1. To receive accurate and clear information of licensing of packages
      2. To receive accurate and clear information of the licensing of the packagers additions (patches) to the upstream source.
      3. To be able to comply easily with licenses for packages
      4. To be able to trust that the package SPDX data is in alignment with the upstream maintainers license assertions.
      5. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream maintainer has provided SPDX data
   2. Package maintainer has selected a license for their additions (patches) to the upstream source
6. Main Success Senario: Packager communicates accurate complete licensing information for their package in an SPDX data format in the package archive.
7. Failed End Condition: Package maintainer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Release of a new package
9. Notes:  

Intermediate packager adds someone else's patches to upstream source that provides SPDX data

1. Title: Intermediate packager adds someone else's patches to upstream source that provides SPDX data
2. Primary Actor: Intermediate packager (someone building a rpm, deb, etc from upstream source)
3. Goal in Context: To include in the package SPDX data describing the packages licensing information for the package base upon the SPDX data provided by the upstream source in a way that allows the packager to verifiably reference the upstream packagers SPDX data and also to include SPDX data describing the additions (patches) to the upstream source that came from a 3rd party.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Intermediate Packager:
      
      1. To communicate the licensing information for their package
      2. To communicate the licensing information for the additions (patches) to the upstream source that came from a 3rd party.
      3. To communicate the licensing information provided by the upstream maintainer.
      4. To respect the licenses of the upstream maintainer
   3. Consumers of packages:
      1. To receive accurate and clear information of licensing of packages
      2. To receive accurate and clear information of the licensing of the additions (patches) to the upstream source that came from a 3rd party.
      3. To be able to comply easily with licenses for packages
      4. To be able to trust that the package SPDX data is in alignment with the upstream maintainers license assertions.
      5. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream maintainer has provided SPDX data
   2. Package maintainer knows the license for the 3rd party additions (patches) to the upstream source
6. Main Success Senario: Packager communicates accurate complete licensing information for their package in an SPDX data format in the package archive.
7. Failed End Condition: Package maintainer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Release of a new package
9. Notes:  

Intermediate packager builds binary package from upstream source that provides SPDX data

1. Title: Intermediate packager builds binary package from upstream source that provides SPDX data
2. Primary Actor: Intermediate packager (someone building a binary rpm, deb, etc from upstream source)
3. Goal in Context: To include in the package SPDX data describing the packages licensing information for the binary package base upon the SPDX data provided by the upstream source in a way that allows the packager to verifiably reference the upstream packagers SPDX data.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Intermediate Packager:
      
      1. To communicate the licensing information for their package
      2. To communicate the licensing information provided by the upstream maintainer.
      3. To respect the licenses of the upstream maintainer
   3. Consumers of packages:
      1. To receive accurate and clear information of licensing of packages
      2. To be able to comply easily with licenses for packages
      3. To be able to trust that the package SPDX data is in alignment with the upstream maintainers license assertions.
      4. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream maintainer has provided SPDX data
6. Main Success Senario: Packager communicates accurate complete licensing information for their package in an SPDX data format in the package archive.
7. Failed End Condition: Package maintainer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Release of a new package
9. Notes:   Upstream may be the root provider of the code, a source package, or some other intermediate party.  At the end of the day it's who you got the code from.

Intermediate packager builds source package from upstream source that provides SPDX data

1. Title: Intermediate packager builds source package from upstream source that provides SPDX data
2. Primary Actor: Intermediate packager (someone building a rpm, deb, etc from upstream source)
3. Goal in Context: To include in the package SPDX data describing the packages licensing information for the package base upon the SPDX data provided by the upstream source in a way that allows the packager to verifiably reference the upstream packagers SPDX data.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Intermediate Packager:
      
      1. To communicate the licensing information for their package
      2. To communicate the licensing information provided by the upstream maintainer.
      3. To respect the licenses of the upstream maintainer
   3. Consumers of packages:
      1. To receive accurate and clear information of licensing of packages
      2. To be able to comply easily with licenses for packages
      3. To be able to trust that the package SPDX data is in alignment with the upstream maintainers license assertions.
      4. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream maintainer has provided SPDX data
6. Main Success Senario: Packager communicates accurate complete licensing information for their package in an SPDX data format in the package archive.
7. Failed End Condition: Package maintainer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Release of a new package
9. Notes:  This is a base case, it is well understood that packagers both add to the upstream source, but also subset it.

Intermediate packager subsetting upstream source that provides SPDX data

1. Title: Intermediate packager subsetting upstream source that provides SPDX data
2. Primary Actor: Intermediate packager (someone building a rpm, deb, etc from upstream source)
3. Goal in Context: To include in the package SPDX data describing the packages licensing information for the package base upon the SPDX data provided by the upstream source in a way that allows the packager to verifiably reference the upstream packagers SPDX data and to make clear that only a subset of the copyrightable artifacts provided by upstream maintainer are included in the copyright artifacts provided in the package.  Examples would include -dev packages that only include headers, packages that do not package contrib/ subdirectories, or otherwise break up what upstream has provided into package shaped pieces.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Intermediate Packager:
      
      1. To communicate the licensing information for their package
      2. To communicate the licensing information provided by the upstream maintainer.
      3. To indicate that they are only passing on copyrightable artifacts based on a subset of the copyrightable artifacts provided by the upstream maintainers.
      4. To respect the licenses of the upstream maintainer
   3. Consumers of packages:
      1. To receive accurate and clear information of licensing of packages
      2. To be able to comply easily with licenses for packages
      3. To be able to trust that the package SPDX data is in alignment with the upstream maintainers license assertions.
      4. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream maintainer has provided SPDX data
   2. Packager understands how they are subsetting the upstream source
6. Main Success Senario: Packager communicates accurate complete licensing information for their package in an SPDX data format in the package archive in such a way that indicates they are only using parts of what is provided in the upstream source.
7. Failed End Condition: Package maintainer communicates inaccurate incomplete licensing information for their package.
8. Trigger:
   1. Release of a new package
9. Notes:  Upstream may be the root provider of the code, a source package, or some other intermediate party.  At the end of the day it's who you got the code from.

License list extension

An organization that does a lot of compliance work is likely to have a license list already which is a superset of the SPDX license list. Such an organization probably will have policies for how to deal with at least some of these licenses. It is important that organizations be able identify the equivalency of these non-SPDX listed license texts/notices.

Stakeholders and interests

Analyzer

A person or organization which produced the SDPX file and maintains their own license list.

Consumer

A person, organization or tool which wants to consume SPDX files produced by one or more analyzer. This entity maintains its own license list and policies for those licenses. This license list partially overlaps with each of the Analyzers' license lists. The Consumer maintains mappings between its list and those of the analyzers from which it receives SPDX files.

Main Scenario

1. Analyzer analyzes a package and finds licenses it recognizes that are not listed on
2. Analyzer passes SPDX data to Consumer
3. For each SPDX listed license Consumer performs appropriate action based on its policy for that license
4. For each non-SPDX listed license Consumer maps from the globally unique id of the license in the Anaylzer's license list to the license in it's list and performs appropriate action based on its policy for that license

Alternate scenario A

1. Analyzer generates SPDX data referencing its license list for non-SPDX listed licenses
2. Later one of the licenses in that SPDX file is added to SPDX license list
3. Consumer detects non-SPDX listed license and maps it to the now SPDX listed license

Alternate scenario B

1. Analyzer analyzes a package and finds licenses it recognizes that are not listed on
2. Analyzer passes SPDX data to Consumer
3. For each SPDX listed license Consumer performs appropriate action based on its policy for that license
4. Consumer encounters license from Analyzers list that it does not have a mapping for
5. Consumer fetches license data from Analyzer's license list and adds that license to its license list

Patch provider provides SPDX data for the patch

1. Title: Patch provider provides SPDX data for the patch
2. Primary Actor: Patch Provider
3. Goal in Context: To indicate the licensing information asSPDX data for the patch.
4. Preconditions: 
   1. Committer has decided on the licensing for the patch
5. Stakeholders and Interests: 
   1. Patch Provider: 
      1. To communicate that the license information for their patch.
      2. To have their licenses respected
   2. Upstream maintainers: 
      1. To be able to document the license information for the patches they receive
      2. To have a paper trail of the licensing information for their project. 
      3. To have their licenses respected
   3. Third party patch appliers (think Yocto):
      1. To be able to know whether or not they have licensing issues when they apply a patch ot upstream.
   4. Consumers of upstream source:
      1. To receive accurate and clear information of licensing of upstream source
      2. To be able to comply easily with licenses for upstream source
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
6. Main Success Senario: Patch supplier communicates the licensing information for their patch.
7. Failed End Condition: Patch supplier doesn't communicates inaccurate incomplete licensing information for their patch.
8. Trigger:
   1. Creation of a patch
9. Notes:  

Patch provider provides SPDX data for the patch indicating it is licensed however the hell its applied

1. Title: Patch provider provides SPDX data for the patch indicating it licensed matching whatever files it applies to.
2. Primary Actor: Patch Provider
3. Goal in Context: To indicate the licensing information as SPDX data for the patch.
4. Preconditions: 
   1. Committer simply wants his patch to have licensing information matching the code it's applied to.
5. Stakeholders and Interests: 
   1. Patch Provider: 
      1. To communicate that the patch should be licensed the same way as the code it applies to.
   2. Upstream maintainers: 
      1. To be able to document the license information for the patches they receive
      2. To have a paper trail of the licensing information for their project. 
      3. To have their licenses respected
   3. Third party patch appliers (think Yocto):
      1. To be able to know whether or not they have licensing issues when they apply a patch to upstream.
   4. Consumers of upstream source:
      1. To receive accurate and clear information of licensing of upstream source
      2. To be able to comply easily with licenses for upstream source
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
6. Main Success Senario: Patch supplier communicates that their patch is licensed matching the licenses of the files it is applied to.
7. Failed End Condition: Patch supplier doesn't communicates inaccurate incomplete licensing information for their patch.
8. Trigger:
   1. Creation of a patch
9. Notes:  This probably involves work with the legal group around an ASLICENSEDAS-1.0 short form, which would involve drafting a license indicating this, and such a license should probably exclude intentional indications of other licenses (say if the patch actually changed license information in the files deliberately).

SPDX 2.0 UseCase: Reference Implementations

1. Title:  Reference Implementations
2. Primary Actor: Member of  reference implementation team
3. Goal in Context: To include with the copyrightable artifacts distributed by the reference implementation SPDX data describing it's licensing information and the type of copyrightable artifacts.  The reference implementation is typically a hardware device (board) that comes in a box with software pre-flashed to demonstrate some functionality, documentation, cables and so forth. There may also be DVDs, CDs, an SD card, etc that could contain host development tools, the software for the pieces running on the flash, additional SDKs, applications (test and/or demonstration), a distribution of some sort and so forth. This can be a very large amount of material and software and this use case could be seen as a superset of the application, SDK, etc use cases. Note: Some artifacts like Makefiles, sample data files and/or other project files (e.g. IDE project files), scripts and so forth may be machine generated and thus not have a copyright or license and other “incidental” project files may not have copyrights as well.
4.  Stakeholders and Interests: 
   1. Reference Implementation Provider: 
      1. To communicate the licensing information for their copyrightable artifacts and the type of artifacts.
      2. To have their licenses respected
      3. To help consumers understand what they are getting.
   2. Consumers of Reference Implementation artifacts:
      1. To receive accurate and clear information of licensing of artifacts
      2. To be able to comply easily with licenses for artifacts
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream has selected licenses for the copyrightable artifacts originating with the project (package, files, etc)
   2. Upstream has indentified license data for other copyrightable artifacts they consume
6. Main Success Scenario: Reference Implementation Provider communicates accurate complete licensing information for their copyrightable artifacts in an SPDX data format.
7. Failed End Condition: Reference Implementation Provider communicates inaccurate incomplete licensing information for their copyrightable artifacts, or does not describe the type of artifact ..
8. Trigger:
   1. Reference implementation release (ship)
   2. Commit time?
   3. Checkout from a repository?
   4. Inclusion of external artifacts into the reference platform
   5. Posting of updated software for a reference implementation

Notes:  This use case can be viewed as a superset of the application, SDK, distribution, Yocto, etc uses cases where many things are aggregated together. There may be a lot of SPDX documents. Software on Reference Implementations are typically updated and could be posted for download from a website or made accessible though a source code control system. (as examples).

SPDX 2.0 UseCase: Upstream maintainer providing SPDX data

Third party produces bill of materials for software package

An organization desires to understand the legal obligations associated with their intended use of a software package. To gain insight the organization requests a third party to audit their entire codebase to determine all rights holders and licenses for every file in the codebase.

Stackholders and Interests

Auditee

The organization in possession of the code that wants to understand the licensing and rights holders of that code.

Auditor

Third party that need to analyze the codebase and inform the auditee of what the licensing is and who the rights holders are.

Main Success Scenario

1. Auditee delivers code to auditor
2. Auditor extracts licensing and copyright information from files
3. Auditor determines the following for every file in code base:
   • Rights holders
   • Licensing terms
   • membership in a package/component which is included in the codebase
4. Auditor provides above data to auditee
5. Legal staff at auditee looks at concluded licensing and right holder and take any necessary actions to comply with the licenses

Upstream maintainer providing SPDX data in SCM

1. Title: Upstream maintainer providing SPDX data in SCM
2. Primary Actor: Member of upstream maintainer team
3. Goal in Context: To include with the copyrightable artifacts distributed by the project SPDX data describing it's licensing information in the SCM (source configuration management system, for example git,cvs,svn).  The goal is to have the SPDX data at any given point in the SCM match the source code at that point in the SCM, so that whenever code is checked out from the SCM, it has SPDX data appropriate to it.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Consumers of upstreams copyrightable artifacts:
      1. To receive accurate and clear information of licensing of artifacts
      2. To be able to comply easily with licenses for artifacts
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream has selected licenses for the copyrightable artifacts originating with the project (package, files, etc)
   2. Upstream has indentified license data for other copyrightable artifacts they consume
6. Main Success Senario: Upstream communicates accurate complete licensing information for their copyrightable artifacts in an SPDX data format in the SCM matching the code present in the SCM at that point.
7. Failed End Condition: Upstream communicates inaccurate incomplete licensing information for their copyrightable artifacts.
8. Trigger:
   1. SCM Commit
9. Notes:  

Upstream maintainer providing SPDX data in source archive

1. Title: Upstream maintainer providing SPDX data in source archive
2. Primary Actor: Member of upstream maintainer team
3. Goal in Context: To include with the copyrightable artifacts distributed by the project SPDX data describing it's licensing information in the archive of its source being distributed.  In particular this may look like an upstream maintainer including SPDX data in their tarball or jar file.
4. Stakeholders and Interests: 
   1. Upstream maintainers: 
      1. To communicate the licensing information for their copyrightable artifacts.  
      2. To have their licenses respected
   2. Consumers of upstreams copyrightable artifacts:
      1. To receive accurate and clear information of licensing of artifacts
      2. To be able to comply easily with licenses for artifacts
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
5. Preconditions: 
   1. Upstream has selected licenses for the copyrightable artifacts originating with the project (package, files, etc)
   2. Upstream has indentified license data for other copyrightable artifacts they consume
6. Main Success Senario: Upstream communicates accurate complete licensing information for their copyrightable artifacts in an SPDX data format in the source archive they provide for a given release.
7. Failed End Condition: Upstream communicates inaccurate incomplete licensing information for their copyrightable artifacts.
8. Trigger:
   1. Release of a new source archive
9. Notes:  

Candidate spdx.owl (Ontology)

Attaching spdxOWL2.txt  (renamed to spdx.txt so I could attach to wiki)

Also attached spdx_notionalBillEditRDF.txt (renamed to spdx.txt so I could attach to wiki)

spdx_notionalBillEditRDF.txt  validates as RDF against http://www.w3.org/RDF/Validator/  and is meant to have one of each 'tag' in the spec, according to the ontology spdxOWL2.txt

Attachments: 

spdxOWL2.txt

RDF file of notional example with one of each tag

OpenLogic SPDX 1.0 beta examples

Here are some examples generated by OpenLogic.  The are comformant to the 1.0 beta version of the spec. 

Notes

The resulting files are well-formed RDF.  However the graph they produce when parsed as RDF is total gibberish. It appears to be impossible to create a document that both matches the current spec and produces a meaningful RDF graph.

The OpenLogic License Analysis system uses SHA-256 to produce checksums of files. We replaced the SHA1 tag with SHA256 to indicate this.

Attachments: 

Apache Commons Beanutils version 1.6 source

Apache Commons Digester version 1.8 source

Apache Commons VFS version 1.0 source

Apache Commons CLI version 1.1 source

Apache Commons Fileupload version 1.2.1 source

Zlib version 1.2.5 source

Zlib version 1.2.3 source

SPDX Use Case 1

Introduction

The following use case is presented to help evaluate the SPDX Proposal, DRAFT 20100308. It presents a typical ecosystem, discusses the flow of a facts file within it and the offers some observations. In a future revision, it will be expanded to map the files and other information to the specific fields in a Package Facts File.  

Background 

In this use case there are six entities each of which plays a different role.  The project, names and names of individuals are fictional but based on a real open source project and ecosystem.

Library A Project

• An individual has created some software he feels is useful to others and decides to license it under an Open Source license. He does that and places it on a web site for download.
• This is a small library and consists of only a handful of source files including other files such as Makefiles, documentation and test data that support building and testing of the library.
• Being a simple project, it does not require much maintenance and therefore is updated infrequently.

The Project

• The Project is an active community and offers a set of Libraries (for implementing a protocol) that can be integrated by someone into their application. They needed some software and found that Library A did exactly what they wanted.
• They have incorporated Library A and their community has developed Library B and a Tool which tests both the libraries. The Library B and Tool consist of more than a handful of files including other non source files which support the project like Makefiles, documentation, scripts, test data, and so forth.

Company A

• Company A consumes Packages from The Project and has included them with software it has developed as part of a larger offering.
• Company A has made changes to the source from The Project.

Company B

• This Company is using what Company A provides to make their own product and adds their own software to it.  
• Company B has made some changes to the source from Company A.

Consumer

• The Consumer is receiving a product from Company B.

Independent Auditor

• The Independent Auditor is performing an analysis of The Project for Company A and Company B.
• The Independent Auditor could also have collected the original Package Facts from Library A and The Project in the process of doing the audits.

[Editorial Note: This Independent Auditor could be a different organization for Company A and B. Also, it is fair to say that this could be two entities? One is an auditing firm and the other a tools vendor. I have combined the two but it can be broken out. ]

Use Case Ecosystem

Library A Project -> The Project  -> Company A -> Company B-> Consumer

Library A                    Library A          Library A’         Library A’

                                    Library B          Library B’          Library B’’

                                    Tool                   Tool

     |                                  |                         ^                          ^

     |                                  |                          |                           |

     ------------------------------------------------------------

                                                   |

                                     Independent Auditor

Flow of the Package Fact Files in the Ecosystem

Library A Project

• Library A creates a package facts file that is downloaded as part of the release.
• Library A is small so the individual maintaining it hand creates the Package Facts before every release.

The files which make up Library A are described in the table below.

Exception 1 – This is part of each BSD license header and reads 

“The license and distribution terms for any publically available 

version or derivative of this code cannot be changed.  i.e. this 

code cannot simply be copied and put under another distribution 

license including the GNU Public License.”

The Project

• The Project has three separate Package Facts files: one for the tool, one for Library A and one for Library B.
• This allows for distribution of the Facts file for each piece (package) or in the case of the full download each piece would have its own.
• The Project has not modified Library A and is happy to pass along Library A’s Package Fact and they do so.
• The Project creates their own Facts file for Library B and the Tool.
• The Project likes to automate things so they have put keywords in their source and can use these to generate the Facts file.

[Editorial note: okay we can question why they did not automate the generation of the facts from Library A but it’s more interesting that they did not and there are likely many scenarios where facts will be re-used].

Library B and the Tool contain the following source files.

Library B Source Files (sampling for illustrative purposes)

Tools Source Files (sampling for illustrative purposes)

Company A

• Company A brought in the source from The Project.
• They use the Package Facts from The Project and an Independent Auditor to help in analyzing The Project so they understand what their obligations are with respect to the licenses (e.g. redistribution of source, attribution, etc).
• Company A has modified both libraries. It updates the existing Package Facts for each. Since Company A does have the same tool as The Project it hand edits the existing Facts files.
• Company A did not modify the tool so they re-convey the existing Package Facts for the tool.

The files which now make up Library A are described in the table below.

The files which now make up Library B Source Files (sampling for illustrative purposes)

Company B

• Company B gets the packages from Company A.
• They use the Package Facts from Company A and an Independent Auditor to help in analyzing the unique instances of the packages to help them understand what their obligations are with respect to the licenses (e.g. redistribution of source, attribution, etc).
• Company B wants to create an attribution document they can ship with their product (since it has binaries). They use information from the Package Facts to do this; as an example, to get the list of copyright holders.

[Editorial Note: Company B was not shown modifying the Facts Files and passing on to the consumer. They certainly could have done that though.]

Analysis and Observations

[Editorial Note: This section of the document is for use in analysis of the use case.]

The flow of the Fact files and who modified them, according to the example above, is shown by the table below.

In some of the observations below, a best practice is recommended. I think it is a good idea for the proposal to contain them (even in a separate document).  Listing best practices will help to clarify expected behavior which can not be captured in the facts fields alone and should help to create fewer variations on a theme.

In this use case, the Package Facts travelled with the Package vs. being centralized in one location.  While the current proposal does not preclude either approach it would seem useful to examine both as each has advantages and disadvantages and may affect the types of fields we need in the proposal. I am thinking the options could be something like: Facts follow a Package, Centralized but the distributor of a Package posts the Facts file for all to see (and comment or possibly update), Centralized but a common entity posts the facts files for all to see (and comment or possibly update). There may be more variations. This is a good area for someone to do an analysis with the pros and cons.

When I asked about the use case one of the responses was how would this information be collected and put into a facts file. It is a fair question but I think the answer would be that one size does not fit all.  Instead I propose we re-focus the question and look at the “facts” that we convey and make sure that we allow for the maximum opportunity to automate the their generation (for example, if it were me I would put some doxygen keywords in the source files and call it a day). Information used for the facts like copyright holders for a file may change frequently for very active projects. Without the opportunity to automate I believe larger projects will die under the weight of this and that the information will not be as accurate due to the number of files, etc that need to be documented.

Should the information in a facts file be taken at face value or does the receiver need to decode the package and double check it?  If you have to re-decode the entire package I am not sure of the value of a facts value (this should help entities receiving the Package to better understand it is licensing). This level of “reliability” is a key point and may not entirely emerge until the standard matures but we should be cognizant of it and make sure that we do not over specify things (i.e. keep it simple). That said it is fair to dig further if something does not seem right. 

What if the facts file from a project is incorrect? This could range from minor typos, to missing file declarations, etc. It is entirely possible that in the course of someone analyzing the files they find some of these things. What should they do at that point? Do they correct it; do they place something in the Independent Audit block? We should specify the behavior or maybe a best practice. The value of this is especially important as we mature the standard so having expectations would be a good thing.

There is currently no way to capture the exception for Library A in the facts file. It is possible it will be listed as a unique license in which case Company A or any of the downstream recipients could have gone to the source file but then I think we are assuming people will get the license field right for the way we intended it to be used. If Library A had listed it as BSD this may not have happened?

Would it be useful to have multiple audit blocks in one facts file? What if The Project had audited the Facts and Company A had audited the facts. It would also be useful to see who made what comments and why at each stage.

It would seem that there could be multiple versions of a Facts File for a particular Package and you could even use Facts files to see a history of the Package (assuming we have a way to track that inside). This seems useful for Company A or Company B when doing the analysis as they can see the original file. For example, if Company A did an independent audit of Library A and the Independent Audit Entity did one as well it would be like getting a second opinion on the package which seems useful.

Are Package Facts only created on a formal release a package? If not, what happens if you access the package through a SCCS like GIT or SVN to get the working tip? Would the facts file be completely up to date?  Maybe we do not need to worry about this, but I will throw it out there anyway. This could also be handled through some sort of best practice.

Company B wants to create a single attribution document for their release. In this example that is somewhat of a trivial exercise. In reality they need to mash 30-40+ packages in a consumer product of any size. If the various fact files they want to mash are under different and potentially incompatible licenses this may hamper their ability to do so.

In large distributions where some projects assemble other open source it seems reasonable that a package facts would follow the packages they bundle like they did in this example of The Project using the one from Library A. The organization pulling in these packages could mash them in some way but it if they do not, do we want to specify any guidelines on how to communicate how many there are, where they are, etc. We may want to document some best practices along with the proposal so they are easily discoverable, etc. 

Sample (partial) SPDX file for Geronimo

Geronimo Sample for SPDX

April 14, 2010

This is a sample of what Geronimo would look like under current spec.  Note that I have not provided all of the data – since it would be very large, but just some samples so we can see how it looks.

IDENTIFICATION

Version: 1.0

UniqueID: 123456789abcdef

Tool: OSSDeepDiscovery

Tool: FOSSology

Manual: OpenLogic

Reviewed by: Jane Doe

Created: 20100315-HH:MM:SS

Issues

• Will likely have used multiple tools as well as manual review to create this list.  Need to have a way to include all of those.
• For “manual”, we may want a company name – not a person’s name
• As packages get passed up the supply chain, it may be modified or added to by multiple people, companies, tools – how do we manage that? 
• Do we want to include the field names – or just the value?
• It’s not 100% clear what “reviewed by” means.  Do we really need it?

OVERVIEW

Formal Name: Geronimo

Package Identifier: geronimo-jetty6-javaee5-2.1.4-bin.tar.gz

Official Source Location: http://geronimo.apache.org/downloads.html

Declared License: Apache-2.0

Licenses Present:

Academic-2.1

Apache-1.1

Apache-2.0

Bouncy Castle 

BSD

BSD (3 clause)

CDDL

CDDL-1.0

CPL-1.0

CDDL or GPL-2.0 with classpath exception

Dojo

JSON

Jtidy

MIT (modern style with sublicense)

Public Domain

Sun Binary Code License for JDK

Sun Community Source License Version 2.3

W3C-Software

Copyright Holder: The Apache Software Foundation

Copyright Holder: The Dojo Foundation

Copyright Date of Package: 2003-2009 (for ASF)

Copyright Date of Package: 2005-2008 (for Dojo)

Issues

• There doesn’t seem to be any information about what open source packages the additional licenses are associated with.  Do we want that?  Many of the additional licenses come from “bundled” packages.  Knowing what package it is can be helpful, but we don’t show that
• Where should actual license text go?
• Copyright holder and Copyright Date can be problematic – since there may be multiple.  What does it mean to have a single one?  Should we list them all here?  Need to align which copyright holders and dates go together. 
• Should we be listing copyright for other bundled packages?
• For non-ASF projects, this will get even more complicated.
• All of the highlighted licenses don’t have a short name in Fedora.  Would we want all of those to be “Other”
• There are a bunch of other notices/copyrights – how should those be handled?

DETAILS

File Name:

assemblies/geronimo-boilerplate-minimal/LICENSES.TXT

assemblies/geronimo-boilerplate-minimal/src/main/underlay/var/config/README.TXT

assemblies/geronimo-jetty6-javaee5/LICENSE.txt

assemblies/geronimo-jetty6-minimal/LICENSE.txt

assemblies/geronimo-tomcat6-javaee5/LICENSE.txt

buildsupport/buildsupport-maven-plugin/LICENSE.txt

buildsupport/geronimo-assembly-archetype/LICENSE.txt

plugins/connector/geronimo-connector-builder/src/test/resources/database.rar

etc….

File Type:  How do we handle this at directory level where there may be multiple types

License: Apache-2.0

Copyrights: Various??? Do we want to list all of them?

File Name:

buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/AbstractCarMojo.java!/java.io.BufferedOutputStream

File Type:  source

License: Sun Binary Code License for JDK

Copyrights: Sun Microsystems

File Name:

buildsupport/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/geronimo/ServerProxy.java!/javax.management.remote.JMXServiceURL

File Type:  source

License: Sun Community Source License Version 2.3

Copyrights: Sun Microsystems

File Name:

buildsupport/car-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/car/CreatePluginListMojo.java!/org.xml.sax.SAXException

File Type:  source

License: Public Domain

Copyrights: ??

File Name:

buildsupport/testsuite-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/testsuite/ResultsSummaryMojo.java!/org.w3c.dom.Document

File Type:  ????

License: W3C

Copyrights: ??

Issues:

• We can have lots of files and directories that are spread all over the project that fall under one license, but are of different types and copyrights.   Do we need different blocks for each of these?  Or can we list multiple files/directories
• Do we really want to list every file here?
• Do we just show exceptions to the Declared license
• Do we need copyrights down to the file level? Or just an aggregated list?
• With license.txt files or copying files, are we applying the license automatically to every file in the directory?  The sub directory?
• The file type is not easy – doesn’t the file name tell us that?  Can we drop that field
• I think we should reorient around licenses – list the licenses and then a set of files associated with them….creating a
•  definitive list of files for a license is not straightforward since you may have a licenses.txt file in a directory
• Where does the actual license text go?

Sample RDF File for Apache Tomcat (section 3)

Attached is an example of an RDF file for Apache Tomcat section 3 only.  Also attached is an example of a DOAP RDF document for the same package.

Attachments: 

Tomcat SPDX RDF Document

Tomcat DOAP RDF Document

Better version of SPDX Tomcat

How to Handle Licenses in SPDX

Handling of Licenses IDs (Short names)

• We have proposed using the Fedora short names
• We have also looked at the Debian naming scheme
• There are a couple of key differences
• Version handling

1. Fedora builds versions into the short name, but it is done in a non-standardized way that seems to vary from license to license, eg

• ASL 1.0  (for Apache 1.0)
• AGPLv1  (for Affero GPL v1)
• CeCill (for both Cecill v1.1 and v2)

2. Debian proposes a standard way – “license name-version”, eg

• GPL-2
• Apache-2

3. Both Fedora and Debian also use standard way to deal with the “and later” version options by using a “+”, eg

• GPL-2+ (debian)
• GPLv2+ (Fedora)

4.    Suggested Solution for SPDX

• I believe we should have a standard way to handle versions for SPDX.  I would suggest going with the Debian approach or something similar.  This would entail slightly modifying the Fedora short names where they do not follow the standard
• I’m not sure if there is some reason why Fedora hasn’t standardized this.

Handling of “standard” exceptions is different

1. Fedora just uses a term that is “with exceptions”  They don’t tell you which exceptions.  The result is that a short name “GPLv3 with exceptions”  is used for both the classpath and font exceptions.  This seems to create ambiguity.
2. Debian proposes naming the common exception – with the following syntax

• GPL-2+ with classpath exception
• GPL-2+ with font exception

3.    Suggested Solution for SPDX

• I believe we should use the Debian approach for common “approved” exceptions such as the 2 mentioned for GPL

Spaces in short name

1. Fedora has spaces in the short names
2. Debian does not  (they do have spaces when they do “with exceptions”

3.    Suggested Solution for SPDX

• I would ask the technical people if this will be problematic having spaces when we want to automatically parse these files. 

Handling of multiple licenses

1. Both Fedora and Debian use “ands” and “ors” when there are multiple licenses associated with a pkg. 

• “and” when you must comply with the terms of all the licenses because parts of the package or file are under difference  licenses
  • artistic-1 and gpl-2
  • “or” when you get to choose a license
    • artistic-1 or gpl-2

2. Both Fedora and Debian address the combining of ors and ands.

•  
  • Use parentheses when needed
  • (artistic-1 or gpl-2) and lgpl=1.1
  • “and” takes precedence
  • GPL-2+ with font exception

3.    Suggested Solution for SPDX

• Follow the same rules

Handling of license variations

1. There are several licenses that have “variations”.  MIT and BSD are examples of this.  These situations are handled differently by Fedora and Debian.
2. Fedora

• For MIT, Fedora treats a bunch of the MIT variations as “functionally equivalent” and uses the short name “MIT” to refer to all of them.  They have a page listing all of the MIT variants and the actual text. https://fedoraproject.org/wiki/Licensing/MIT
• For BSD, Fedora seems to have different short names for each of the variants, eg
  • BSD License (original) = short name “BSD with advertising”
  • BSD License (no advertising) which is a 3 clause version and BSD License (two clause)  both = short name of “BSD”
  • BSD Protection License = short name of “BSD Protection”
  • Academy of Motion Picture Arts and Sciences BSD = “AMPAS BSD”

3. Debian

• For MIT, Debian says that it is “problematic”  and hasn’t addressed it .  They have no short name for MIT yet.
• For BSD, Debian has a short name for BSD, but it’s unclear how the variants are handled

4.    Suggested Solution for SPDX

• This one is a little complicated.  I think for any situation where we have different variants of a license, they should have different short names.  Fedora has done this to some extent, but in some cases (like BSD 2 and 3-clause) they have combined it to use one short name.   This would require us to stray from the short names of Fedora.
• The other question is what do you do with “other” variants that don’t have a unique short name.  Some people use “BSD-like” or terms such as that.  I know some people don’t like that.   It seems that for now the most accurate approach would be either to give a variant it’s own short name, or tag it as an “Other” license.

RDF to Spreadsheet Translator

Attached is the RDFToSpreadsheet tool.  See the tools documentation http://spdx.org/wiki/draft-spdx-tool-doc-beta for information on usage.

Updated - 5/9/2011 to include the latest spec changes related to NONE and NOASSERTION values

Note: This page will be moved to spdx.org/tools once the tool output has been reviewed.

Attachments: 

rdftospreadsheet.zip

SPDX Viewer

Attached is the SPDX Viewer application.  See the tools documentation http://spdx.org/wiki/draft-spdx-tool-doc-beta for information on usage.

Updated - 5/9/2011 to include the latest spec changes related to NONE and NOASSERTION values.

Note: This page will be moved to spdx.org/tools once the tool output has been reviewed.

Attachments: 

spdxviewer.zip

Spreadsheet To RDF Translator

Attached is the SpreadsheetToRDF Tool. See the tools documentation http://spdx.org/wiki/draft-spdx-tool-doc-beta for information on usage.

Updated - 5/9/2011 to include the latest spec changes related to NONE and NOASSERTION values

Note: This page will be moved to spdx.org/tools once the tool output has been reviewed.

Attachments: 

spreadsheettordf.zip

spreadsheettordf-external-lib.zip

Rough proposal for provenance; hierarchy and aggregation; and supply chain friendliness in SPDX 2.0

A desire has been expressed to be able to have SPDX be capable of expressing

1. Provenance (we can know precisely who said what and when about a package)
2. Hiearchy and Aggregation ( package A contains packages B, C, etc)
3. How software flows through a supply chain (upstream to packager, through several intermediate vendors to consumer)

A rough example of this thought is shown in the diagram below, showing how the coreutils package might be represented:

 The simple story behind this diagram is this:

1. The upstream maintainer of coreutils provides an SPDX file which
   1. Provides information for the copyrighted entity that is the package as a whole
   2. Provides embedded information for the copyrighted entity that is each file in the package (same format, just embedded and clearly down hiearchy)
   3. Provides a coreutils.spdx.sig file with the signature for the coreutils.spdx file (so we can authenticate it)
2. This coreutils.spdx file is in the coreutils.tar.gz for the upstream
3. The rpm (or deb) packager creates a coreutils.spdx (distinct from the one for the upstream) in the rpm file which:
   1. Provides information for the copyrighted entity that is the rpm (or deb) package as a whole
   2. Provides embedded information for the copyrighted entity that is each file (such as patch files) contained in the rpm (or deb) package
   3. For the coreutils.tar.gz file (also contained in the rpm or deb package), provides it's SPDX information by *referencing* the coreutils.spdx in the coreutils.tar.gz file.
   4. Optionally provides and Annotation section to 'annotate' some of the information provided by the coreutils upstream.

Diagram for a Concrete proposal (very very rough) for structure (note, notes that say 'Concrete' or 'Referential' are just indicating an 'or' in the doc structure):

Description of diagram

• Top: Simple top level place to start
• SPDXFile: File containing SPDX data
• SPDXElement: The containing element for SPDX data for a given copyrightable work contained in the SPDXFile.  It's SPDXElements all the way down.
• Specifier: Not really a node, sort of a grouper of nodes to indicate those fields which specify the 'thing' the SPDX Element is about
• LicenseData: not really a node, sort of a grouper of nodes to indicate those fields which specify what we know about the 'thing' this SPDX Element is about
• SPDXElements: zero or more additional 'contained' SPDX Elements referring to contained things (like files, or contained tarballs etc).
• Annotations: zero or more annotations indicating additional information about the contained SPDXElements (to handle the case where a contained SPDX Element represents a reference to a another SPDX file that is signed and thus we can't change directly) - Note, we need more thought here.
• Creator (Annotation): Equivalent to SPDX 1.0 Creation Information Creator
• Date (Annotation): Equivalent to SPDX 1.0 Creation Information Created
• Comment (Annotation): Equivalent to SPDX 1.0 Creation Information Creator Comment
• AssertNewLicense (Annotation): Reference to new License Data you wish to assert to override existing SPDX License Data.  Generally used in situations when we have existing License Data from a more primary source but we believe we have reason to believe otherwise.
• Name: Equivalent to SPDX 1.0 Formal Name
• Version: Equivalent to SPDX 1.0 Package Version Information
• Supplier: Equivalent to SPDX 1.0 Package Supplier
• Summary: Equivalent to SPDX 1.0 Package Summary Description
• Description: Equivalent to SPDX 1.0 Package Detailed Description
• URI (in SPDXElement->Specifier): URI of the copyrightable thing being referenced, may point to a file, an archive, a package, etc.
• URICheckSum( in SPDXElement->Specifier): Checksum for the thing URI points to
• CopyrightText: Equivalent to SPDX 1.0 CopyrightText
• LicenseText: Full text of license if LicenseShortForm isn't available
• LicenseShortForm: License short form in lew of license text if available
• SPDXFileURI: If the SPDX Element does not contain it's own concrete license data but references an external SPDX File... the URI of that SPDXFile
• SPDXFileSigURI: If the SPDX Element references an external SPDXFile, the URI of the sig file for that SPDX file
• ACL: I hate the name ACL, but basically it's a way of specifying that you are including or excluding some of the copyrightable bits that are covered by the referenced SPDX File.
• Exclude (in ACL): Used to specify parts of the stuff referenced by the external SPDX file you are not bring in.  So if I am using all of a package, but not foo.c or bar.c.
• ExcludeAll (in ACL): Used to indicate that *none* of the referenced copyrightable items from the SPDX file are used except those explicitely included.
• Include (in ACL): Used after an excludeall to indicate we are only using the specifically included files... say we are just using foobar.c for example.
• SPDXFileSig: Separate file containing the signature for the octets of the SPDXFile 

This can also be visualized with a UMLish diagram:

Mapping SPDX 1.0 Fields to Proposal

Stealing Java's archive URI syntax:

In the java world, they commonly use a URI syntax <archivename>!<filename> to indicate a particular file within an archive, for example foo.tar.gz!bar.c.  I suggest we use this (as there are no other widespread alternatives).

Archiving multiple SPDX files:

It may be desirable to archive together multiple SPDX files so that we have full resolvability for a given package.  In that case, those should be rolled into a specific archive format (say foo.spdx.zip) with the various spdx files, their sig files, and an index file.  The index file should map URIs (as specified the SPDX files) to filenames in the archive (so we can resolve them).

Example:

file://coreutils.tar.gz!coreutils.spdx: file://upstream/coreutils.spdx

file://coreutils.tar.gz!coreutils.spdx.sig file://upstream/coreutils.spdx.sig

Note: We have to also solve the problem here of how to distinguish when two spdx files contain the same URI (say relative to their archives) but they actually need to be resolved to separate files in the rollup, say if both upstream and the rpm (or deb) packager used file://coreutils.spdx 

Attachments: 

spdxdoodle.jpg

spdxdoodle2.jpg

spdxdoodle2.jpg

spdxdoodle2.jpg

spdxuml.jpg

spdxdoodle.jpg

spdxdoodle.jpg

2010-11-16-TechnicalTeamMinutes

2010-11-16 Weekly Technical Team Meeting

Attendees:

Kate Stewart, Bill Schineller, Peter Williams, Gary O'Neall

Topics:

• we now have a mailing list for technical team (thanks Kate)  self-register at http://spdx.org/wiki/spdx/spec-development  (click the 'mailing list here' link http://lists.spdx.org/mailman/listinfo/spdx-tech  )
• Peter reviewed the re-vamped structure of spec.html currently maintained in master branch of his github repo at https://github.com/pezra/spdx-spec    spec.html has directives for the rake task to include contents of section_2,3,4,5  such that one html file is generated with the complete ontology.  Team asked that the generated file also get committed (to lower the barrier of entry for someone wishing to look at the rendered html during development)
• Reviewed Peter's writeup of the composite license proposal at http://spdx.org/wiki/proposal-2010-10-21-4-composite-licensing    Team agreed the "OrLater" concept in the proposal best be split out into a separate proposal.  Bill asked technical question about whether the references to standard spdx licenses should use rdf:resource vs. rdf:Description... rdf:about   Bill asked whether the e.g. DisjunctiveLicenseSet should itself be a subclass of spdx:License; Peter's recommendation was that it be another object in the range of properties which currently have License in their range.
• Mozilla Tri-License usage scenario for composite license.  Proposal shows its usage in Package/Declared and Discovered licenses.  How to avoid repeating for every File object in a) RDF format and b) tag-value format?  Kate noted that if the 'Mozilla Tri-License' is well known to exist in the wild, then it is a good candidate for inclusion in the SPDX license list.  But more generally, team agreed it would be good form if a 'composite license' is encountered to model it once within the NonStandardLicense section of the SPDXDoc with a locally unique id and reference it from other places within the document.
• re: the artifactOf proposal, Kate noted that the tag-value example was unclear.  Peter and Kate discussed a convention...
• Peter raised idea of additional properties between licenses such as 'laterVersionOf'
• Bill asked about use case of SPDX analysis reporting the discovery of a phrase like "This file is licensed under the GPL' - clearly too ambiguous to map to one of the standard SPDX licenses, but perhaps of interest to consumer of an SPDX doc.  With current spec, *could* report such as a NonStandardLicense whenever encountered.  Raised idea (in future rev of spec?) of modeling license 'families' as an additional way to express associations between licenses, and allow reporting such a discovery in a standard way.
•  Time expired on the meeting.

2010-11-30-TechnicalTeamMinutes

SPDX RDF/Technical meeting Minutes 11/30/2010:

Attendees:

Bill Schineller

Gary O'Neall

Peter Williams

Kate Stewart

zLib example discussion:

Discussion on the whether the SPDX Doc is necessary.  Led to a discussion on having the SPDX Doc contain multiple packages which led to a discussion whether we were constraining the model to a flat model.  Decided to table the discussion for version 2.

Discussion on the file being associated to a package - Section 5.5 - need to have a property to associate the file with the package.  Needed to have the RDF parse properly and to have the graph represent the file relationships properly

Discussion on non-standard licenses - should it be within the package or at the SPDX Doc level.

Three possibilities - "describes license" creates a separate license resource not associated with the SPDX doc or package; a property of the SPDX doc; property of the package

Discussed the pro's and cons of different approaches.  Technically, all three approaches are similar in that the non-standard license will only be valid within the specific SPDX doc (and there is only one package per SPDX doc).  Several people felt that the non-standard license should be associated with the analysis - perhaps leading to it being associated with the SPDX doc.

Actions:

Gary to writeup a proposal for hasFile belonging to a package (section 5.5)

Peter to write up the alternatives for the non-standard licenses

Kate to write up a proposal for field to be added for the validation of entire package

2010-12-21 Technical Team Minutes

SPDX Technical Call
12/21/2010

Attendees:
Bill Schineller
Gary O'Neall
Peter Williams
Kate Stewart

Review of previous meetings

RDF to Tag notation - Kate to provide a grammer.  Will include the zlib example in the tag/value format

Key discussion point is how the implicit section boundaries will impact forward compatibility (issue 589)

Review of issues recorded in the issue tracking

Issue 590 - How individual files are referenced:
 - Discussed use cases for having a unique reference to a file
 - Discussed whether we should have a single URL for a file
 - Agreed that in the RDF, there needs to be a single URI (whether created by conventions or auto

generated in rdf/xml)
 - Discussed an approach we feel will have merit where the tag/value format has 2 tags for a file

(package + file) and we have some documented conventions for converting between these 2 tags and the RDF

file URI

 - We can use the example created for the tag notation to solidify the proposal

Discussion on the repository
 - git repositories have been setup - the ontology
 - Master will be the official version of the spec
 - Proposal to have a post-commit rake task create the ontology

Need the appendices added to the git repository

Peter will send out an email on how to pull down the spdx-spec from the git repo

All - review the spdx-spec and document any questions/issues

2011-01-11-TechnicalTeamMinutes

SPDX Technical Call
1/11/2011

Attendees:
Bill Schineller
Gary O'Neall
Peter Williams
Kate Stewart
Ann Thornton

Agenda:
 - Infrastructure status
 - Differentiation a judgment from a fact
 - Model for representing a judgment
 - DEP 5

Infrastructure status:
 - Git up and running for both SPDX spec and pretty printer
 - Bugzilla up and running

Request to integrate SPDX mailing list with Bugzilla
 Some concern about keeping too much of the comments in Bugzilla if replies to email are added to the 
bugs - will pick discussion after we find out if the David can set this up (Peter already sent in the 
request)
 Should have the default cc on the Bugzilla notifications be the SPDX mailing list

Discussion on posting information to the larger SPDX distribution list
 Bill will send meeting announcements to the larger general distribution list

Differentiating judgment from fact
 - discussion (not all details not captured)
 - agree that when something is stated in a file, it is a fact the file contains that statement
 - discussion on whether conclusions from various stated licenses are also facts or judgments
 - different interpretation what the file level license represents - the declared license or the inferred 
license
 - agree file level would distinguish inferred, and detected license
 - add a reason to the inferred license.  Proposal is that this is either an entry from a standardized short set, or else is a free form text field to act as a comment to explain why the inference occured (ie. results of investigations and caveats/justification for inference conclusion).
 - Proposal that the inferred should be a composite license structure.  This proposal should be discussed in the next meeting.

2011-01-18 Technical Team Minutes

Attendees:

Bill Schinelle

Gary O'Neall

Peter Williams

Kate Stewart

Next week - move time to 4:00PM Eastern

- Kate's grammar for the 'tag-value' format / DEB-5

- Gary's slides for tools to be made available

- recap / status of inclusion of new license fields

- Proposal process

Grammar Tag-Value / DEB-5

 - Is there a difference between the grammar embedded and the proposed grammar?

                - Similar.  Purpose of Kate's proposal is to resolve ambiguities.

                - Difference in syntax of the grammar - DEB-5 compatibility would require a different grammar

representation

                - Concern about forward compatibility - ability of a version X parser to understand version X+N documents

                - There is a goal to be compatible with the DEB-5 which would lead more to the DEB-5 based grammar

                - Need a way to map between the RDF and tag value and between tag value and RDF

Gary's slides for tools to be made available

                - Can the pretty printer output tag-value

                                - Concern about not having a formal parser for the tag-value - could lead to bugs if hand-coded emitter for the tag-value

                                - Gary agreed to prototype a tag-value emitter

                - Gary will ping Kate for the current Spreadsheet format

                - For contribution/feedback switch from emailing spdx.org to use bugzilla

                - Mention that in the spec there will be a grammar and an RDF OWL document

recap / status of inclusion of new license fields

                - An asserted license field seems to have achieved consensus

                - Proposal to split the license field into asserted license, "detected" or "seen" license, and a comment field

                - Will continue the proposal process on the spdx-tech mailing list and in bugzilla

2011-01-25 Technical Team Minutes

Minutes 1/25/2011

Attendees:

Bill Schineller
Gary O'Neall
Peter Williams
Kate Stewart

Summary of follow-up items from the call:

• License section - consider renaming non-standard licenses to embedded licenses - has implications on the short form names.  Todo: Kate to follow-up on the proposal. 
• Document and review the algorithm for creating the xor'd sha1's from the file list
• Change the description in the source information field in the package section
• Discuss/decide if the package level asserted license should be optional or mandatory
• Rename "asserted license" to "asserted licensing"
• Future topic- should there be additional optional fields for non-standard licenses?
• Add a comment for the reviewer in the review section
• Reconcile the tag names with the SPDX overview
• consider a more consistent naming convention

Minute details:

Review spdx overview slides sent by Kate - purpose to align on the current status of the spec:
 Section Headers in the spec - Reviewer information has been moved to a separate section at the end
 License section - consider renaming non-standard licenses to embedded licenses - has implications on the short form names.  Todo: Kate to follow-up on the proposal.  Note that embedded is somewhat ambiguous - used for "embedded in the package" as opposed to "embedded in the SPDX file"
 Identification section - Version of SPDX - does it make sense in the RDF spec?  Topic for future discussion.
 Identification section - Method of xor for all file sha's to generate overall checksum - need to publish and review the specific algorithm
 The package file sha is optional in case the spdx file is embedded
 Source information - change description to reflect additional information on the source rather than anomalies (e.g. the download URL is no longer available)
 Package level - agree to add asserted license
  Asserted may include logic (and/or disjunctive/etc)
  Seen licenses would just be a list
  Not clear if asserted license at the package level should be mandatory or optional - future discussion
 Copyright - just a string for release 1 of SPDX
 
 Should there be additional optional tags in the non-standard license?  Topic for a future proposal.
 File - Asserted License -> Asserted Licensing (takes care of possibility of multiple licenses)
 File - Seen license - can be multiple licenses
  Cardinality - does it make sense to have a mandatory field that may contain 0 items  - yes since it confirms that "none were found"
 Reviews - should there be a comment for the reviewer?  Yes - add this as an optional field.

Todo: reconcile the tag names with the spdx overview
Need a better naming convention - add to topic for next week's call - suggestion to invite the individual providing the feedback to the call.

2011-02-01 Technical Team Minutes

Minutes 2/1/2011

Attendees:

Bill Schineller

Gary O'Neall

Peter Williams

Kate Stewart

Marshall Clow

Phil Koltun

Pre-meeting discussion on version management of the specification.  Need to work through the remaining issues to get the git version of the spec in sync.  After that, we can modify the process to automatically push out the defects.

Issues review - please refer to the spreadsheet attached to the minutes.  The legend tab describes the priority definitions.

Changes in the spreadsheet from the original proposed priorities:

                587 and 625 should probably be merged

                617 - leave as priority one since the legal team may require

                Move 640, 643, 646 to P1 - these will affect the spec being in sync

                623 - comment field for author of the SPDX document - move to P1 since this is relatively easy

                Need to add a bug to track the implementation of the xor's for all file hashes to create a unique package signiture

                Reference this new bug in bug 593 - the solution referenced above will solve this bug as well

Bill added rought estimates on the effort for the P1 defects

Gary will update bugzilla with all of the priority information from the meeting

From this point forward, all submitters of bugs should assign a priority based ont he following critera:

                1 - Must be resolved for beta

                2 - Want to resolve for beta, but is a must for the release 1 of the spec (e.g. can be resolved after the start of beta)

                3 - Want for release 1

                4 - Target for a future release of the spec

We should assign all P1's - if you see any bugs you would like to work on, please assign it to yourself

Some discussion on the support for tag values in Beta.  We will raise this question in the call with prospective beta sites on Thursday.

Attachments: 

bugs-2011-02-01-postconcall.xls

2011-02-08 Technical Team Minutes

Minutes 2/8/2011

Attendees:

Bill Schineller

Gary O'Neall

Peter Williams

Kate Stewart

Kirsten Newcomer

Three items were discussed during the meeting:

- Bugzilla ID 644 - cardinality of Package Overview Info is missing

- Bugzilla ID 592 - License repo

- Time for next week’s call

Bugzilla ID 644:

We discussed the implications of nesting in RDF/XML and the impact of any changes to the spec.

During the discussion, it was decided that a diagram representing the domain model would be helpful in resolving this and other issues.

Kate agree to draw up diagram(s) representing the domain model.

Bugzilla ID 592:

We discussed the processes for setting up the license repository.  It was proposed that we use the license spreadsheet to produce RDFA/HTML pages which would populate the repository.

[Note - since the meeting Peter has proposed a modification to the process to retain the formatting of the license text]

Peter agreed to produce an example RDFA/HTML document.

Gary agreed to write a tool which would translate the spreadsheet into the RDFA/HTML documents.

Next week’s call:

Gary will be calling from Hawaii - we agreed to move the call to 1:00 Eastern time to accommodate the time zone differences.

Summary of Actions:

Kate to draw up diagrams representing the domain model

Peter to draft an RDFA template/document for the license

Gary to write a tool to translate from the spreadsheet to RDFA

2011-02-15 Technical Team Minutes

Minutes 2/15/2011

Attendees:

Ann Thorton

Kristin Newcomer

Bill Schineller

Peter Williams

Kate Stewart

Gary O'Neall

Note: Next weeks meeting will be at 1:00 Eastern time

Agenda -

License Repository (bug ID 592) - review Peter's draft rdfa html

Domain model diagram (fromt the discussion on bug ID 644) - review Kate's diagram (postponed due to time)

License Repository:

Review of the web pages:

 - On the summary web page, there are just 2 columns - full name and short form identifier

 - The license detail page would contain the full name, short identifier, other web pages for this license, notes, text, templated version of text, "official header", templated header

 - Template column/field - There was a discussion whether the template text should be a separate field from the text field:

            - Exact format of the abstract license template text TBD

            - Current working guidelines are:

                         - no capitalization

                        - white space condense (single blank represents multiple blanks and tabs)

                        - alternatives denoted as [a|b] for cases of acceptable spelling differences - for instance, british vs american spelling of common word.

                        - [.*] to denote any value is acceptable - for instance, after a copyright statement.

            - Defining the abstract license template format of the license text is out of scope for the technical team, this will come from the legal team.  The technical team will review for technical implement ability.

            - Suggestion that getting FOSSology/Ninka experts to do the review of the the abstract license template syntax, based on what their tools can recognize, and what they do already as part of their matching.   If Open Logic or Black Duck want to contribute information from their recognition algorithms, that would be welcome too. To be discussed in a future meeting once we nail down the format a bit more.

      - legal team agreed that having a separate field for template would be useful (ie. it would be good to have both the official human readable formatted version available on the license detail web page as well as the abstract license template version on the license detail web page.)

            - for now, this template field will default to the same text as the license text

 - no property for for the license name.  In the proposal, dc:title is used for the name – Proposal to for the SPDX spec to include a license name.  Proposal to add this after beta.  To be discussed  

- License ID - should it be generated from the URL or have a separate tag?  [Gary: I think we agreed on it being a property, but I did not confirm this on the call]

 - no property to store the header

 - no property to store abstract license template template

 - no property to store license notes

 - No property to store the other URL’s.  owl:sameas currently used for the other urls in the license, should we add it in the SPDX spec as a separate appendix or in a license specific section.

- Header text (could have multiple headers are in the text).  The data model will support

multiple headers, but we will only use one for now.

- Issues with spreadsheet license text was discussed throughout the call.  There were 2 issues – formatting is lost and some license text is too large for the spreadsheet cell.  A proposal was made to have the spreadsheet license text cell reference a file which would be formatted using HTML tags.

- We also talked about headers, and abstract template versions of the headers.  To keep things sane for beta at least, only a single header will be recognized for each license initially, preferably the official recognized one, if it exists.

Action: Add the missing properties to the spec.  In general, if there is a column in the license spreadsheet from legal, it should be a property in the spec.

Action: Proposal for the license text column to refer (optionally) to a text file which will be included with the license spreadsheet.

2011-02-22 Technical Team Minutes

Minutes 2/22/2011

Attendees:

Kristin Newcomer

Bill Schineller

Peter Williams

Kate Stewart

Gary O'Neall

Marshall Clow

Review of last week’s minutes – minutes updated and will be posted to the wiki.

Review Kate’s UML diagram:

Discussion on the relationship between the SPDX File and the information.  There are basically 2 different conceptual models – one proposed by Kate and a second model where the SPDX Package contains many of the relationships.

A discussion on the impact to the tag/value format and to the RDF format was discussed.  A discussion on the impact to Beta was discussed. 

Actions resulting from the discussion:

-          Obtain information on how the beta customers will use the SPDX spec – will they use the tag/value format or the RDF format?  The current assumption is that the beta customers will use the spreadsheet and will not care what the underlying format is.  A questionnaire has been sent to the beta sites through the business teams.

-          Draft the UML model for the current RDF tools implementation (Gary) – will compare and discuss next week

-          Document the new fields that need to be added to implement Kate’s proposed model (Kate)

2011-03-01 Technical Team Minutes

Minutes 3/1/2011

 Attendees:

Kirsten NewcomerBill SchinellerPeter WilliamsKate StewartGary O'NeallAnn Thorton

Review Peter’s UML diagram:

We're in the process of reviewing 2 different conceptual models with the goal of finalizing on one model for beta.

On 2/22, the team reviewed a model proposed by Kate

At this meeting, the team reviewed a model proposed by Peter. 

 Discussion included: relationships between objects, what abstract classes are necessary, model for licenses. Peter made some real-time modifications to his model during the discussion to address points raised. 

There was some discussion of whether we should allow for names to change after beta, given that the spec will be versioned. I don't believe agreement on this was reached. 

Actions resulting from the discussion:

• (Peter) will send his model to the team, as well as the name of the tool he used to create the model, so that team member can make proposed changes to the model and share them for review. Goal is to finalize the model this week.  [Attached to the minutes]
• Team agreed that we need to finalize names of properties this week as well to better support tool implementation for beta. The team all agreed that the singular form of the name is preferred to plural. (Kate) will work with Rockett to get the definitive list of names from the legal team.
• (Bill) will put out a call to the SPDX mailing list for use cases the team can use to validate the model. 
• (Ann) agreed to collate and document the use cases on the twiki. (Kate) will work with Ann to bring her up to speed on previous use cases discussed. Bill will send a pointer to the twiki location for use cases. 
• (Peter) signed up to provide training on the spec for the beta as soon as the spec is nailed down. The use cases collected by Ann will be useful input for this training.

Attachments: 

domain-model.png

2011-03-08 Technical Team Minutes

Minutes 2/22/2011

Attendees:

Ann Thorton

Kristin Newcomer

Bill Schineller

Peter Williams

Kate Stewart

Gary O'Neall

Agenda:

Compare the models provided by Kate (attached) and the models from the email thread

Review/discuss the SPDX Names spreadsheet provided by Kate (attached)

Model discussion:

There were a lot of similarities between the proposed models.

Two differences in the models were discussed:

1.      Abstract License which subclasses a non-standard license and a standard license vs. a License object with one subclass for standard license.

2.      Representing the license reference text – either as the text in the non-standard license or text in a LicenseInfo object.

For #2 – The scope was discussed as to whether text for licenses not in the standard license list and not in the file itself.  The scenario discussed was if text was found in a file referencing a license which is not in the SPDX standard list of licenses, is there a way to represent the text of the license which is not in the file itself.  This was described as out of scope which raised some concerns.  Kate raised a concern that if this was in scope, there would be issues with the ID.

We agreed that it was confusing to have the name of the referenced license text “Non-Standard License”.  Various names were discussed and we agreed to change name of Non-Standard License to “License Reference”.

Kate to follow-up on updating the diagram based on the discussion.  Once that is done we can revisit the scope question and the need for Abstract License.

Kate provided a spreadsheet that compared the names for the SPDX properties used by RDF/XML, Tag/Value and the spreadsheet.

Peter agreed to fill in the RDF/XML column and update the git repository version of the spec with the resultant names.

Attachments: 

spdx-model-v4.png

spdx-naming-resolution-v4.xls

2011-03-15 Technical Team Minutes

Minutes 3/15/2011

Attendees:

Kristin Newcomer

Bill Schineller

Peter Williams

Kate Stewart

Gary O'Neall

Agenda:

·         Resolve the naming differences based on the spdx-naming-resolution spreadsheet (http://www.spdx.org/wiki/field-names)

·         Resolve the complex licensing model – supporting non-std licenses

·         Discuss ways to represent the RDF entities in the spec (e.g. artifactOf, DisjunctiveLicensingSet)

Spreadsheet:

·         Kate provided a new spreadsheet format with a “proposed” tab to focus in on the remaining items

·         Discussed the SPDX version and agreed that, although a bit redundant in the RDF XML format, we can add a property spdx:specVersion.

·         Creator/created – matched the name in the RDF to the tag (Creator)

·         Need a creator class and possible a comment class to associate the comments with the creator – same general requirements for reviewer – Peter agreed to propose a model

·         Package filename – since this isn’t a relative path, should be a different property, agree to change the name to spdx:packageFileName.

·         URL: couple issues were discussed, conflict of uniqueness with spec “Unknown”, required field, redundancy with SourceInfo.  Peter brought up a good point that if we don’t have URL being the same as the Package resource URI, there is no place to store package resource URI information in the tag value or spreadsheet.  Agreed on property DownloadLocation property.

·         Seen Licenses in All Files – discussed the change in terms and proposals, should update the bug to reflect the renaming

(2:00 continuation of the meeting)

Discussion of the complex licensing model

·         A non-standard license would include text for licenses not in the standard license text and licenses not included in the file or package information.  This would only be applicable for a concluded license.  This resolves the scope issue.

·         An issue was raised where we are losing some information on the structure of a license with this approach.  We also will not be able to include the text of the standard licenses in the SPDX Analysis itself.  We agreed that this issue can be resolved after beta.

·         The proposal of associating text with the AbstractLicensingInfo object (in SPDX-model-v4.png) was discussed.  We agreed to log this is a bug and discuss this after beta.

Back to the discussion on the name:

·         SeenLicense name – legal proposal is LicenseInfoInFile.

·         Concern on consistency on the use of LicenseInfo.

·         Decided to leave concludedLicense alone (prefer LicenseInfo)

·         Synchronized 3.9 (seen licenses) with this terminology – see spreadsheet for final resolution.

·         Note on the spreadsheet – a green cell indicates that this is the preferred terminology for the row.  Other columns may need to be updated to synchronize with this cell.

·         Copyright statement – agreed to change to copyright text to allow a more structured copyright statement in the future

·         NonStandardLicense – changed to LicensingInfo

·         LicenseID – discussed various approaches and issues – agreed to keep a property for LicenseID to map between the RDF/XML and non-RDF/XML formats in a consistent manner.

Agenda for next week:

·         Complete discussion on names

·         Discuss ways to represent the RDF entities in the spec

2011-03-22 Technical Team Minutes

Minutes 3/22/2011

Attendees:

Nicholas Loke

Branden Robinson

Kristin Newcomer

Bill Schineller

Kate Stewart

Gary O'Neall

Agenda:

·         Complete the resolution of the naming differences

·         Discuss ways to represent the RDF entities in the spec (e.g. artifactOf, DisjunctiveLicensingSet)

Spreadsheet:

·         Started with 4.2 licenseID

·         We will color proposed changes in RDF column yellow for Peter’s review

·         Agreed on LicenseID as property last time – propose spdx:licenseID

·         Per file info -> File Information

·         File name – spdx:filename

·         File checksum/sha1/identifies – Agree on the name being fileCheckSum. 

·         To future proof the field, we agreed to make the name generic (not algorithm specific)

·         Create a checksum class with 2 properties, algorithm and value

·         We changed the Package field to be use the same checksum approach

·         For the RDF fields, should we have property names for everywehere we have class names defined in the spreadsheets?  We decided to add a property name followed by “/” then the class name for these fields.

·         Discussed whether the file verification field should also use the same checksum approach.  Decided to keep this as a single field.

·         ArtifactOf – To not loose information, we will add a URI property

·         Some discussion on the different scenarios with ArtifactOf DOAP documents (external DOAP documents and creating internal DOAP resource nodes within the SPDX document).  Agreed to test out some of these scenarios during Beta.

·         Some discussion of the comments – agreed to use the rdfs:comment consistently.

·         Note: Some of the updates to the spreadsheet may not have been captured in the bullets above – see the Spreadsheet version 9 yellow for all updated names.

Agenda for next week:

·         Complete discussion on names – website fields

·         Discuss ways to represent the RDF entities in the spec

2011-03-29 Technical Team Minutes

Minutes 3/29/2011, 3/30/2011

Attendees 3/29/2011:

Nicholas Loke

Branden Robinson

Kristin Newcomer

Bill Schineller

Kate Stewart

Gary O'Neall

Peter Williams

Attendees 3/30/2011:

Jack Manbeck

Bill Schineller

Gary O'Neall

Nicholas Loke

Marshal

Peter Williams

Kate Stewart

Agenda:

·         Review naming spreadsheet updates

·         Discuss ways to represent the RDF entities in the spec

Spreadsheet:

·         Reviewed Creator change name to creationInfo (property) and CreationInfo (Class)

·         Discussion on if we should prepend property names with cardinality of 1 to N with “has” – we will decide after completing the rest of the spreadsheet

·         Format of the spreadsheet RDF column: propertyName/Range (and/or class)

·         Proposal for Beta – remove the CreationInfo class, add back a property for creator – range Agent, add a creatorComment property - string

·         Future – proposal to add changelog class and property to Analysis

·         Todo: Gary to re-align spreadsheet rows

We decided to have a follow-on call on Wednesday, 2:00PM Eastern.  Bill will send out an invite.

Continuation of the call –

·         Agreed to go back to a simple model for creator  (property spdx:creator) and comment – (property spdx:creatorComment).  We discussed whether comment should be spdxcreatorComment or rdfs:comment.  Concluded that the semantics are different enough to create an SPDX specific property.

·         Discussed the use of the Checksum class and alternatives to providing the extensibility (e.g. separate properties for each algorithm and having the algorithm be identified through the subclass of Checksum rather than a property).  Decided on using the checksum class as it allows for additional / different properties based on the algorithm and keeping the algorithm property.

·         Change property name from spdx:packageChecksum to spdx:checksum since it is semantically the same property as the file property – Note: we did not (and probably should)  update the fileChecksum to checksum.

·         Discussed whether we should change the range of the packageVerificationCode to a Checksum class.  We decided to leave it as a literal string for now, although most people on the call thought that we should make this field more extensible.  We will revisit this during and/or after beta.

·         Licensing discussion:

o   We discussed the name and meaning of the “NonStandardLicense”.  Agreed to rename the field [see spreadsheet for resolved name]

o   We discussed whether the RDF model should have the previously named “NonStandardLicense” as a subclass of License.  We will pick up this discussion in our face to face meeting.

o   The LicenseSets (ConjunctiveLicenseSet and DisjunctiveLicenseSet) will both contain LicensingInfo objects.

Note: there will not be a call next Tuesday, we will meet again at the face to face meeting at the Linux Collaboration Summit 

Attachments: 

spdx-naming-resolution-v13.xls

2011-04-07 Technical Team Minutes

Attendees

--------------

Kate Stewart

Peter Williams

Bill Schineller

Gary O'Neall

Phil Odence

Kirsten Newcomer

Mark Gisi

Marshall Clow

Matt Germon

Michael Herzog

Scott Peterson

Jack Manbeck

Philip Koltun

Steve Cropper

Kim Weins

Martin Michlmayr

Guillaume Rousseau

Agenda

-----------

• Review spec 
• Tools overview
•  Licensing model
• Remainder of the bugs
•  Version 2.0 considerations

We reviewed the Specification as a group in order to close on issues and get agreement for the beta/release candidate version of the Specification. 

There was a lot of lively and effective discussion. 

A number of updates were made to the Specification during the meeting. 

Below are the conclusions made during discussion, along with some issues identified for exploration after beta. 

Again, please review and send additions/corrections as needed

Conclusions

-----------------

• Specification number will be set to version 0.8
• Purpose text:
  •  major versions incremented when incompatible changes are made. 
  • minor field will be incremented when backward compatible changes are made. 
  • Concern about the example where sections cause major version revisions.  We’ll leave the example for now.
• Section 2 will be split into two parts and the following sections will be re-numbered
• Section 2 title: SPDX Document 
  • sub-section 2.1 SPDX Specification Version Number
• New Section 3 title:  Creation Information 
  •  sub-sections include remaining fields from original Section 2, as modified during meeting
  • Creator: changed format to be future reference to format and define it to be just a string for version 1
  • Created: updated the definition to be the last update when the analysis was done
• NOTE: Following comments refer to section numbers in place during the meeting
• Add all the rdf properties to the SPDX Document to map the package and analysis
• Add a checksum class to the Specification (referred to in File section)
• Review for terminology consistency
  • license vs. licensing
  • Undetermined vs. Unknown: used to indicate that data was reviewed, but conclusion is not clear
  • Not Analyzed will be used to indicate that data was not looked for
  • None: data was looked for but none found
• Package-level and File-level licensing fields:
  • Proposed 

licensing model that enables representation of disjunctive / conjunctive licensing is adopted. This means license cardinality can be 1. 

•  
  • Affected sections will be updated, including
    • 5.4.1
    • 5.5
•   Some Purpose/Intent text in the related sections needs to be reviewed with legal. Specifically:
  • 3.8.1: "all should be recited"
  • 3.10:  text refers to both author and copyright, but field descriptions are specific to copyright. Intent/Purpose text and fields need to be in agreement
  • 4.1 wording in Intent -- exact words were highlighted in spec during discussion
• Cardinality for Copyright will remain 1 for beta, but will be more than one after beta
• Section 5.2.6: 
  • Need to add definitions for listed types
  • For future version of Specification, consider mime types.
• Section 5.6: Need this same field at the package level
• Fix "SDPX" typo in footer
• Review section (is this Review or Reviewer?)
  • Copy Creator Data format information to Reviewer section
  • Review Comment field: Needs intent text from Rockett
• Appendix I will simply link to SPDX License repository
•  

Graphical version of model will be added to the Specification (appendix?)

Action Items

-----------------

Kate will complete first round of edits to Specification

Gary will make additional edits to the Specification to add RDF/XML examples and update the tools and example spreadsheet

Kate will get input on wording changes from legal where appropriate

Technical team will do a final review; date TBD

Open Issues

------------------

Concerns were raised about the verification mechanism (SHA1) not including the relative filename

Will the OWL document be added to the Specification?

Proposed that version two provide support for more hierarchical use cases (package in a package for example)

Concern about the created date being overly specified for the RDF format

2011-04-12 Technical Team Minutes

Minutes 4/12/2011

Attendees:

Nicholas Loke

Kirsten Newcomer

Peter Williams

Bill Schineller

Kate Stewart

Agenda:

·         Plan for what remains

·         Review spec – create a list of what’s missing

·         Go through all remaining items

Review Spec:

·         Discussion on document format.  Agreed to add RDF XML examples to the sections and move the tag/value example under the tag/value

·         The RDF and tag/value information will be separated out into different appendices.

·         Peter will produce a new set of RDF documentation.   It will be included in the PDF document and the HTML will be posted to spdx.org/rdf/terms.  The documentation will be based on an OWL.  This will be provided by Sunday.

·         Gary will generate examples for the RDF XML from the tools.  This will be done within 2 weeks.

·         Section 3 – concern about having structure to the strings, for the RDF.  Data format for beta will be simple strings.  The tag/value should have a structure.  The RDF format for after beta TBD.

·         Date Format – should we specify the date format?  Agreed to leave the spec as is (was highly discussed a year ago and the current format was the resolution).

·         Should creator comments and  reviewer comments be rdfs:comment?  TBD (Peter – can you include a proposal when you document the RDF)

·         Discussion on the RDF specific subsections – will make consistent once we add the documentation from Peter

·         SourceInfo 4.6.6 should be changed to multi-line

·         LicenseInfo fields – add the new syntax for license sets and mandatory 1

·         Review of license terminology – will handle on the list (I’m not sure I completely captured this item)

·         Section 5 Identifier Assigned -> Identifier

·         Section 5.2 is currently 4.1 – renumber/format issue

·         Review free form text fields (e.g. 5.1.13) for consistency for <text> … </text>.  Would prefer the subsection for data format to be just free form text and the tag example to include the <text> … </text>

·         Possibly add a sentence or two in section 6, add the description for what happens if there is no archive file name for the package (use the package name).

·         6.3.5 lowercase c in checksum

·         ArtifactOf structure does not match well to the RDF format – Peter to propose a solution

·         Reviewer – name string format – same issue with parsing strings in the RDF

·         Inconsistent use of unspecified and unknown licenses – proposal to treat these as standard licenses and include them in Appendix I (and on the spdx.org/licenses website).

·         Diagram – Analyzed file – is it a property of SPDX Doc or a just a property of the package?  Agreed to add a property at the SPDXDoc level for all file and OtherLicensing info.  This will allow for an easy extraction of all file information within an SPDX doc and easy extraction of all OtherLicensing info within a doc.

Plan: Peter will provide the RDF information by Thursday.  We will review on Friday.  This will allow implementation to begin over the weekend.

2011-04-19 Technical Team Minutes

Minutes 4/19/2011

Attendees:

Nicholas Loke

Kirsten Newcomer

Gary O’Neall

Peter Williams

Kate Stewart

Agenda:

·         Definitions doc – review Kirsten’s emails on consistent terminology

·         Resolve differences in spec and html – review email thread on consistency

·         Discuss proposals on verification code algorithms – review email thread from Marshal

Review of the terms “Unknown”, “Undetermined”, and “None”:

Discussion of Undetermined/NotSpecified/NotAnalyzed terminology proposal. Outcome: recommendations made to revise proposal to reflect 4 use cases where license/copyright/url cannot be specified: 

·         1) analyzed and data is insufficient to draw a conclusion 

·         2) analyzed, and conclusion is Not Licensed 

·         3) analyzed, and no data found 

·         4) not analyzed 

·         Revised proposal sent out to list on 04/19

·         Add “NONE” category for concluded license

·         Change “NOTSPECIFIED” to “NONESEEN”

Discussion of cases where no info is available need to be captured affirmatively in RDF license valuesor whether empty value is sufficient

·         Conclusion:  should be affirmative; provide values that specifically address this use case

Discussion of how best to handle special terms: as literals/constants or try to "shoe horn" into license registry

• Noted that these terms can be applied to copyright and URL data, not just license data
• Proposal: use URI that points to definition page on spdx.org but NOT license page
• All will require special case treatment

Review differences between pdf doc and html rdf spec:

·         For licenses, change the application to match rdf html spec on the “NONE” (etc.) being spdx/rdf/terms URI’s.  Peter to update vocabulary with new terms.

·         Spdx:License class – ok as is for beta; revisit after beta

·         CreatorInfo cardinality – go with the pdf cardinality for now and revisit after Beta start

·         Cardinality of licenseInfoFromFile is 1 .. n

·         Cardinality licenseConcluded, … cardinality 1 – if multiple licenses, represented as a conjunctive or disjunctive set

·         Cardinality of licenseInfoInFile is 1..n (semantics similar licenseInfoFromFiles)

·         Describe which properties of DOAP are used in both the pdf and html (name and homepage)

·         Agreed to change licenseID -> licenseId in pdf, html, and app

2011-04-26 Technical Team Minutes

Minutes 4/26/2011

Attendees:

Kirsten Newcomer

Bill Schineller

Brandon Robinson

Gary O’Neall

Peter Williams

Nicholas Loke

Marshall Clow

Agenda:

·         Discuss the email thread on the terms for undetermined/none seen/not analyzed licenses (email thread originated by Peter)

·         Review the verification algorithm (email from Gary)

·         Discuss the relationship between the SPDX Document and the extracted licensing info

None Seen, None, Not Analyzed, Undetermined:

·         Discussed meaning of the terms.

·         Discussed need for 4 terms.

·         Discussed some proposals for different terms (unfortunately, I did not capture the specifics).

·         Did not reach a conclusion on the call, will follow-up on email

·         Kirsten to write-up the definition of the 4 terms

·         Peter to follow-up with a proposal based on Kirsten’s write-up

Analyzed (effort expended)

Not Analyzed

Seen/factual

Concluded

File Verification Algorithm:

·         Reviewed the proposal – consensus on the general approach of generating a sha1 from the filenames + sha1’s of the individual files

·         File path – reference the file name in the document rather than define the filepath in the verification section

·         Check the file name specification to make sure it specifies forward slash “/” as the separator character

·         Sha1 – reference the sha1 in the doc rather than define the format in the verification section

·         Change sorting to start with sha1 followed by file path.  Note that this resolves case sensitive sorting issues with the file name.

·         Change sha1 definition to specify lowercase a-f for the hexadecimal representation

·         What to do with the spdx file itself – proposal is to leave it out of the verification algorithm.  Peter to review and possibly propose other terms.  This will be specific proposal will continue on the email thread.

Extracted Licensing Info at the Doc level

·         Agreed to add a property at the SPDX document to capture all of the extracted licensing infos

·         Proposed property name “hasExtractedLicensingInfo”

·         Range ExtractedLicensingInfo

·         Cardinality 0 or more

·         The URI associated with this property would be the same URI used in licenseInfoFromFile and licenseInfoInFile

·         Peter will update the spec with this information

With the two outstanding items on the spec (terms for unused/none/noneseen licenses and how to treat the spdx fil in the File Verification algorithm), there may be impact on the beta start date.  Depending on the outcome of the email discussions, we will alert the business team to the possible schedule impact on Thursday.

2011-05-04 Technical Team Minutes

Minutes 5/3/2011

Attendees:

Kirsten Newcomer

Bill Schineller

Gary O’Neall

Peter Williams

Nicholas Loke

Marshall Clow

Kate Stewart

Agenda:

Terms – prepare for legal team

Verification – any concern with excluding the spdx file(s) which are being generated or updated?

Push tools for beta?

Re-organizing the web – difficult to find things

Tools:

• Feedback – change “non-standard licenses” tab name, perhaps format spreadsheet
• Should we push the tools to the spdx.org/tools? – Once updated with terms discussion.  By Saturday.  Push to spdx.org/tools
• Kate to review the differences between rdf terms and doc

Overall schedule:

• Close on terms on Wednesday

• Update tools to decision – by Friday (Gary)
• Update spec pdf by Saturday (Kate)
• Update rdf terms with the results of the license terms discussion by Thursday (Peter)
• Tools document update – by Friday morning (Kirsten)
• Start an email thread to confirm the URL’s and upload the documents (Kirsten)
• Update rdf terms to the correct location (Peter to coordinate with Martin)

Re-organizing the web:

• Change link to rdf to be next to the

List of excluded files from hash calculation:

• Create a property which is a list of excluded files
• Property would have 0 or more file paths
• Property of the verification
• Would be a comma separated list of paths in the tag/value
• Spreadsheet would have an additional column
• Peter to update rdf spec by Wednesday morning
• Gary to update the tools
• Kate to update pdf document

License terms:

·         Agree to hold to the proposal (three terms for no-value AMBIGOUS, NONE, NOTANALYZED

·         Discussed revised definition of NOTANALYZED – ok with revising definition to try to address Scott Peterson concern or that the preparer of the SPDX document is not making any assertion regarding the value of this field.

·         Propose new definition of NOTANALYZED:
Indicates that the preparer of the SPDX document made no attempt to
determine the value of this field or that the preparer of the SPDX document is not making any
assertion regarding the value of this field.    

2011-05-10 Technical Team Minutes

Minutes 5/10/2011

Attendees:

Kirsten Newcomer

Bill Schineller

Gary O’Neall

Peter Williams

Nicholas Loke

Branden Robinson

Kate Stewart

Agenda:

URL’s for beta

• URL’s – Reviewed Kirsten’s email on the URL’s.  Agreed with the proposal except the URL for  rdf terms – agreed to leave the rdf terms URL as spdx.org/rdf/terms for beta
• Remove reference to an RDF terms page (spec should be sufficient)
• Examples – stay under spec/examples
• Templates: Agreed to have the spreadsheet just under the tools directory (we don’t currently need a separate template area)

Review of open priority 1and 2 bugs

• None blocking beta.
• License text – we believe this is not an issue for beta
• License repository – Gary to send an updated set of files to Martin
• Moving tools to the tools web page – Gary to move files today
• Rename git repository to tools – Peter will rename to “tools”
• Tag/Value example – Either Kate or Peter will produce
• Examples – Agree that the examples should all pass the validation
  • Copy the spreadsheet example from the tool
  • Peter will regenerate some of the prior examples with the current spec
• Verification algorithm – need to make sure it is in the spec.  We could also add a Wiki page just for the algorithm.

2011-05-17 Technical Team Minutes

2011-05-24 Technical Team Minutes

Minutes 5/24/2011
Attendees:
Kate Stewart
Kirsten Newcomer
Bill Schineller
Gary O’Neall
Peter Williams
Marshall Clow
Branden Robinson
Steve Cropper
 

Agenda:

• Report on General team meeting
• Beta readiness and ArtifactOf URI proposal
• Specification and Technical web page review/cleanup

Report on General team meeting -- Kate

• Various edit passes completed on Spec
• Waiting for feedback from additional members of legal team
• Kate will continue to consolidate edits and requests that edits be saved either in Open Office or .doc format for Word (Word '97-2004) to ensure edits are not lost
• OSI is going to adopt same short form names as SPDX

Beta readiness

• Tools -- Gary
  • tools are ready except for one item (see below)
  • would like some volunteers to test
  • need closure on ArtifactOf URI proposal
    • CONCLUDED:
    • If there is a known location for a doap:Project document on the web, RDF will use this as the resource URI (i.e. a named node); this will be the value for ArtifactOf URI in the tag/value format
    • If there is no known location for a DOAP document on the web, RDF may represent as an anonymous node; in the tag/value format, ArtifactOfURI will have the value ‘UNKNOWN’
    • RDF may generate a URI named node for the doap:Project even if document is not on the web, so that single node may be referenced in the RDF graph.
    • If translating from tag/value format to RDF format, translator may choose to generate a single URI any referenced doap:Project having name and homepage pair are the same
    • Comments: this would make the RDF graph neater, but adds work to translator
• Technical Doc -- Kirsten
  • Technical training PPT needs updating due to some terminology change
  • Kirsten to send suggested updates to Kim
• There was also some general discussion about having a way to inline contents of a package. Topic was raised by Brandon Robinson.
  
  • Brandon stated that this has been raised by some of their supply chain
  • Kate mentioned that there are technical issues with embedding pkg contents
  • Group agreed that this is not required (or even requested) for beta

Web page review and cleanup -- all

• SPDX Whitepaper referenced on both the Home page and the Specification page needs updating.
  • Owners: Phil Odence and Kim Weins.
  • Kate will provide a technical review after update.
• http://spdx.org/licenses/ <http://spdx.org/licenses/>
  • Title needs to be changed to "SPDX License List"
  • Text needs to be modified to read: "This following is a list of all liceneses currently registered with SPDX as of <date>."
  • Owners: Martin M. and Gary (?)
• http://spdx.org/rdf/terms <http://spdx.org/rdf/terms>
  • Contents are up to date
• http://spdx.org/spec/guidelines <http://spdx.org/spec/guidelines>
  • Currently empty. Assumption is that this will be populated during beta.
  • Owner: Kim Weins (?)
• http://spdx.org/spec/examples <http://spdx.org/spec/examples>
  • There was some discussion about the best way to organize the information on this page. No final conclusions reached. Proposals included
    • Provide a separate page for each type of example
    • Keep current examples all on one page (fewer clicks)
    • Provide an archive folder for older examples
    • Currently, older examples are hidden
  • Requested that the sub-team reviewing SPDX website organization create a working group page for itself to make it easier for others to follow progress and provide feedback
  • Owner: Kirsten

As always, please send additions or corrections.

2011-06-07 Technical Team Minutes

Minutes 6/7/2011

Attendees:

• Bill Schineller
• Kate Stewart
• Nicholas Loke
• Steve Crawford
• Peter Williams
• Gary O’Neall

Agenda:

• Review current spec published 6/6/2011

Review

• Language updated from the legal team
• Request review from Kirsten for the legal language
• Still some review comments in the Legal team, so there may be some additional changes
• Request for technical team to review and send Kate a document version under change revision mode to highlight any review comments or changes
• Request for a spreadsheet example including the URI for artifactOf – Gary
• Appendix II. RDF Data Model Implementation – needs a review to make sure it is in sync with the latest spec (especially naming)
• hasFile property on the document – hasFile is a property of package. Having a property at the document level is OK, but we would like to add such a property in the future. Concern about the name “hasFile” at the document level. Agreed to “referencesFile”.
• Discussion on having a property from the file to the document – agreed to postpone any changes until there is a use case which benefits from this relationship
• artifactOf – need for more information to describe how it is used. Produce some examples.
• Need to produce instructions on how to use the spec.
• PackageVerificationCode excluded file, need to review/update the cardinality – 0 or more – some question/concern on the language used to describe the cardinality (0 or more mandatory or optional)
• PackageVerificationCode excluded file – review syntax in the main document
• Conjunctinve/Disjunctive licenses – should the cardinality be 2 or more – tradeoff of additional effort for tooling to interpret manage degenerative case. Agree to 2 or more as the cardinality.
• SimpleLicenseInfo discussion – Should we have SimpleLicenseInfo a straight subclass of AnyLicenseInfo? Would be more constraining, but would also match the conceptual model – proposed for next week’s agenda
• Proposal for embedded octect stream – proposed for next week’s agenda

2011-06-14 Technical Team Minutes

Minutes 6/14/2011

Attendees:

• Bill Schineller
• Kirsten Newcomer
• Kate Stewart
• Nicholas Loke
• Peter Williams
• Gary O’Neall

Agenda:

Review of last week’s items:

• Legal language updated from last week completed
• Review of document – Kate received some comments
• Spreadsheet example of the URI for artifactOf (Gary) – Still pending
• Spec updated with change to hasFile
• PackageVerificationCode – still pending
• SimpleLicensingInfo – pending
• Embedded Octect Stream - pending

Update on Kate’s conversation with Steve

• Need to capture a “supply chain” for the origin of the packages
  • Can capture this as a reviewer, but would require a company – proposal to have Reviewer be an Agent. Agree to change the spec to accommodate company. We can change the definition of the string or we can implement Agent. For Beta, we can change the definition of the string. We would like to implement an Agent structure, but that would require a more detailed proposal and incrementing the version number. Kate will work on a proposal.
• Proposal to have a package level ArtifactOf. Agree that this will be useful. This may require two different properties to represent A) if the package is part of a larger project and B) the package originates in a particular project. We need some use cases written – Peter will write one of the use cases in a bug.
• Need to write-up usage of the spec
  • Agree to create a Wiki page for usage guidelines. This would be structured around use cases and a description of the fields. The per-field would shadow the spec. Any contributed conversations to the per-field could be rolled into the spec itself at a later date. Would like to create a separate Beta web page which would include a link to the usage guidelines page. This could be added under participation. Kirsten will add after checking with Kim.
• Crypto flag request – need a proposal.
• Suggest that we add bugs for the new proposal.
• Open source or commercial package flag request – concern that different companies/organizations have different definitions of open source and commercial package
• Package version – request to make the version parseable. Agree to add a field, but there was concern on making it parseable – Kate will add this in the next draft
• Use of term package, raises questions about the hierarchy of packages. ArtifactOf at the package level will help.
• A third delivery model – 1) SPDX is a sidecar to the package archive, 2) SPDX is embedded in the package, 3) a third proposal would be to have the SPDX document itself contains the archive.

2011-06-21 Technical Team Minutes

Minutes 6/21/2011

Attendees:

• Bill Schineller
• Kirsten Newcomer
• Branden Robinson
• Peter Williams
• Gary O’Neall
• Nicholas Loke

Agenda:

• Updates from last week

Updates since last week:

• Spreadsheet example updated with ArtifactOf
• Beta website update, since Beta is coming to a close we may not want to move the beta information

Web site for usage information for the spec:

• Consider setting this up in the technical area
• Consider just adding the information to the FAQ
• Agree to update the draft SPDX FAQ. Once beta is complete, we can go through the FAQ and separate out any information which should be in a usage (or other) area
• Added a link to the FAQ from the technical area

Tools update:

• Feedback on installation – dependency on the Java environment
• A defect is causing warnings which has caused some concerns from the Beta participants (since the call, I added this to Buzilla – id 823)

2011-06-28 Technical Team Minutes

Minutes 6/28/2011

Attendees:

• Bill Schineller
• Branden Robinson
• Peter Williams
• Gary O’Neall
• Kate Stewart

Agenda:

• Feedback from the betas

Tool defects:

• Posted as bugs in bugzilla
• Bug 824 – error if the standard licenses are not present in the spdx document
  • OK to assume that the type information will be present for non-standard licenses
  • Basic design to attempt to load the RDF graph for standard licenses
    • First attempt will be against the spdx.org/licenses website
    • If the first attempt fails, the a static file distributed with the application in the jar file will be used
• Plan to fix and updated the tools before next Tuesday’s call

Other beta feedback:

• Discussion on the Fossology support
• Recognizing “families” of licenses
• Agent definitions – disconnect between tag/value restricted to “Person …” where RDF is just a string. Decided to discuss next week. Peter will provide a proposal for RDF.
• Versions – Decided that the beta version of the spec should be 0.9. Will update spec and tools.
• Package Verification Code – update spec, documented in bug 832 – Gary and Kate to review.
• Next week, review (and clean up) bugs. Decide which ones need to be fixed for release 1.
• Discussion on the jar files/archive files found in a package. Decided to treat these as a single file with concluded licenses and “NONE” for the found license.
• FAQ’s – need to divide up the works. Will do this on next week’s call.

2011-07-05-TechnicalTeamMinutes

Minutes 7/5/2011

Attendees:

• Bill Schineller
• Kirsten Newcomer
• Branden Robinson
• Peter Williams
• Gary O’Neall
• Kate Stewart

Agenda:

• Tools update
• Review open bugs

Tools update:

• Most of the id’d issues fixed and pushed
• Added versioninfo to package, required update to template but is backwards compatible
• Can’t upload the tools – already contacted Martin
• Wrong namespace on the licenses RDFa, once fixed, the tools will obtain the standard license information from the website

Review open bugs

• 728 – move examples – Kirsten will take this as part of the web team
• 726 – Move priority to 2, Gary to coordinate with Peter [update – this has been addressed by the Linux Foundation]
• 724 – vocabulary on the website – completed, should be closed
• 656 – License text outside spreadsheet, move to priority 2
• 633 -- close
• 628 – can probably close – quite old and before we discussed the structure in S.F.
• 617 – leave open
• 812 – Add column for OSI approved – Gary to compare OSI licenses to web page before adding column
• 811 – Providing license texts as simple tar file. Assign to Rockett to include as part of the process, change priority to P3
• 739 – Should be able to close
• 738 – ask Peter if can be closed
• 737 – Should be able to close
• 715 – License ID specs, assign to Kate
• 673 – Should be able to close
• 646 – Should be able to close
• 666 – this is resolved, should be able to close
• 638 – Bill S. to add comments to clarify
• 588 Close

Additional updates:

• Should add a bug for adding license families based beta feedback
• Martin fixed the file upload problem , so the tools should be available within the next hour or two
• Jack Manbeck and Gary have been collaborating on adding HTML output as part of the pretty printer. Gary will ping Peter since he may also be thinking of similar enhancements.

2011-07-12-TechnicalTeamMinutes

Minutes 7/12/2011

Attendees:

• Bill Schineller
• Branden Robinson
• Peter Williams
• Gary O’Neall
• Kate Stewart
• Nicholaas Loke
• Marshall

Agenda:

• Package Version
• Review open bugs

Package Version:

• · Proposal – cardinality 1, String format
• · Already in ontology and tool – only difference is the property name. Peter will reply to Kate’s email with the proposed property name. Kate will update the spec document. The RDF ontology and tools have already been updated.

Review open bugs

• New bug – license text is not rendering correctly in IE
• All other defects were updated in Bugzilla – see Bugzilla comments and status for details [Note – some of the defect updates are not captured in the minutes]
• 728 – Assigned to Kirsten
• Need to add Kirsten to Bugzilla (Bill will follow-up)
• 838 – Assigned to Peter
• 729 – Some examples still need to be posted. Kate will post the examples and notify the web team so it can be placed properly in the new web design. Consider adding to spdx.org/tools
• 726 – Git repository name updated – need to update the tools documentation and spdx.org/tools text – assigned to Gary
• ??? - RDF/Tag-Value mapping – discussion as to if this is fully resolved. Agreed to close the defect and enter any specific issues if they occur.
• 638 - Conformance section – Discussed the need since the spec already defines cardinality etc. Kate will propose – see defect for details on the discussion
• 646 – closed
• 673 – closed
• 715 – assign to Kate
• 737 – closed
• 738 – Assigned to Peter
• 811 – Assign to Rockett, P3
• 818 – Set target milestone to V2 – did not come up as a blocker in the beta feedback discussion
• Need to add a “Version 2” to target milestone in Bugzilla
• 835 – Assigned to Peter
• 837 – Assigned to Peter
• 839 – Kate will review wording

2011-07-28 Technical Team Minutes

Minutes 7/28/2011

Attendees:

• Kirsten Newcomer
• Branden Robinson
• Peter Williams
• Kate Stewart
• Steve Cropper
• Jack Manbeck

Agenda:

• Discuss proposal from Steve Cropper for Supplier related fields
• Review open bugs

The team had a good discussion about the new proposed Supplier fields, including discussion of:

• Optional vs. Mandatory
• Reasons for including in GA of 1.0 rather than waiting
• Overlap with need for handling package hierarchies
• Affect on tools
  • suggested that tools could be udpated after GA date
• Use cases, including
  • open source package maintained by loose coalition where no individual has clear ownership
  • open source package where original copyright owner has died
  • package shared between supply chain partners
  • Discussed providing special options as we do for certain other fields such as NOASSERTION, NONE, and possibly ORPHANED

Spec update

• waiting for trademark info from Rockett
• waiting for input from Karen C. on confidentiality

Bug review

We ran out of time to review the bug list, but ask that everyone

• review for any open P1s assigned to them
• review closed bugs to be sure we're in agreement

Corrections, additions welcome.

2011-08-02 Technical Team Minutes

Minutes 7/28/2011

Attendees:

• Kirsten Newcomer
• Nicholas Loke
• Peter Williams
• Kate Stewart
• Steve Cropper
• Jack Manbeck
• Marshall Clow

Agenda:

• Discussion of Supplier related fields
• Review of recent updates to the Spec
• Open Action Items (see list at end of minutes)

Supplier fields discussion

• Kate has updated the working version of the spec with the two fields discussed last week
  • Package Supplier
  • Package Originator
• Today's discussion started with some email threads on intended use of 
• We seem to have a common understanding of what info should be used to fill in the Package Supplier field
• We're still working toward a common understanding for the Package Originator field
  • We discussed a few possibilities. For example, is the data in the Package Originator field
    • the copyright holder?
    • the place where the Supplier got the code?
  • We discussed the desire to capture the chain of custody in the SPDX document; Kate noted that was part of the original intent of the Reviewer field
  • We noted that there is an overlap between the goal of capturing chain of custody and the need for hierarchy in the SPDX document; hierarchy will be discussed post 1.0
• Concluded: we need to make an extra effort to document the thinking behind these fields and provide usage guidelines

Additional updates to Spec

• Kate walked the team through some additional updates that have been made to the spec as well as some planned changes based on feedback
• Key changes include:
  
  • Clean up of RDF section (typos, spelling)
  • Proposed changes to certain field names for tag/value
  • Section 1.7: Conformance statement will point to trademark statement that is being worked by legal team and will be posted to web. This is not yet finalized.
  • Section 2.2: SPDX data will still be delivered under PDDL-1.0. Confidentiality field has been dropped.
    • Acknowledged that this could be an issue for using SPDX with commercial/proprietary code and plan to discuss commercial code use case post-1.0 GA
  • Recommend that info be added on where to provide feedback

Open Action Items

• Everyone: Bug list review
  • review for any open P1s assigned to you
  • review closed bugs to be sure we're in agreement
• Start developing Guidelines for Implementation/Use and/or Best Practices 
  • Everyone: Review current FAQ as starting point. You can find it here: 
    http://spdx.org/spec/guidelines
  • If you've volunteered to update/add to a certain section, please add your name here. :-)
• Kirsten: Provide website location for 2 items so can be referenced in Spec
  • Process for requesting licenses be added to SPDX license list. 
  • SPDX trademark terms.
    • I've added placehoder text for a links here: http://spdx.org/spec 
    • I don't have the privs to create a new child page and will send a note to Martin 
• Everyone: Please review the spec with the goal of approving final version next week if possible

Corrections, additions welcome.

2011-08-09 Technical Team Minutes

Minutes 8/9/2011

Attendees:

• Bill Schineller
• Kirsten Newcomer
• Branden Robinson
• Peter Williams
• Gary O’Neall
• Kate Stewart
• Nicholaas Loke
• Jack Manbeck
• Marshal

Agenda:

• · Open bug list review
• · Spec walkthrough/check for ambiguities

Review open bug list

• · 887 - Do we have structured strings for creator, reviewer, …? Agreed that in the future, the RDF structure will probably be different than a structured string but we do not have time to create, review and implement a proposal. Agreed to have a structured string for this release – Peter will propose a more formal syntax. Note: SPDX tools currently doea a simple partial validation of strings starting with “PERSON:”, “ORGANIZATION:”, etc.
• · 728 - Move examples to spdx.org – leave in spdx.org/spec/examples – Kirsten will create subcatory for “work in progress”, once reviewed we can label the examples as conforming to the spec. Can close bug.
• · Xxx – What license is the RDF terms released under, need to confirm with legal. Peter will follow-up with legal. Proposal to make the rdf spec
• · 874 – packageOriginator and packageSuppler -> originator, supplier – spec is being updated. Tools will be updated and re-uploaded this morning to make consistent.
• · Suggest that the class order in the rdf terms page match the order from the spec
• · 656 – closed after review of license text and license index
• · 883 – agree we don’t need ascending order for license ID’s – assigned bug to Kate and will e fixed in next rev of the spec
• · 886 – broken link, assigned to Kate, will be fixed in next release
• · 888 – rdf example fix - assigned to Kate, will be fixed in next release

Walkthrough of spec changes

• · Reviewed updates (a few changes were noted “spdx.com” -> “spdx.org”)
• · Request to make sections 5 and 6 consistent in the statement for what is required and optional – Steve to send an email describing request to the group
• · Decided to change the status of the rdf terms from “testing” to “stable”

Other status

• · RDF terms will be updated by this afternoon (Peter)
• · Gary will review the doc, rdf terms, and tool property values for consistency

2011-08-23 Technical Team Minutes

Minutes 8/23/2011

Attendees:

• Bill Schineller
• Kirsten Newcomer
• Branden Robinson
• Peter Williams
• Gary O’Neall
• Kate Stewart
• Nicholaas Loke
• Jack Manbeck
• Marshal Clow

Agenda:

• · Weekly call Logistics
• · LinuxCon Feedback
• · Proposal for Spec Version numbering
• · Tools source structure
• · Verification Code algorithm
• · Composite Packages
• · “Garbage Files”

Logistics:

• Move to 2:00 Eastern to accommodate west coast- considering that we don’t currently have any attendees from Europe. Kate will update Wiki.

Feedback from LinuxCon:

• Discussed relationship between SPDX packages and the needed for a hierarchical relationship
• Discussed PDDL
• Discussed compatibility between tags and RDF for future development

Numbering for Spec. version:

• Format AA.BB.CC
  • AA – Major version - Incremented for changes incompatible with previous versions (current definition)
  • BB – Minor version - would be used when changes may impact the consumer, but is compatible with previous versions
  • CC – Micro version - would be used when the changes do not impact to the consumer of SPDX

Tools source structure:

• Create separate repositories for the different language tools
• Create a separate git-repo named “Python-SPDX-Tools”
• Rename current tools repo to “Java-SPDX-Tools”
• Kate will either send info to Gary or send info to Linux Foundation to make changes

Note: Bugzilla has a target field to indicate which release the resolution is targeted for. There are no targets for detail “CC” versions; we will use the major version targets for those changes.

Verification code algorithm:

• Need to specify a better separator character “\n” is ambiguous – Kate will choose a character and update spec
• Update to the verification code algorithm would result in an increment to the micro version (e.g. 1.0.1)