1. spdx@lists.spdx.org
  2. Messages
   Date   
Re: Proposed spec for external packages

Jeremiah Foster <jeremiah.foster@...>
 



On Tue, Aug 4, 2015 at 6:40 PM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

Its impossible to answer this question, largely because there's not enough data -- what are these "other systems" (Windows?) and what are the "external packages"? 

 Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct?

This is my assumption as well.
 
If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

My apologies in advance if I'm completely off base here.

I think you're on target. 

Much of this design is coming from the pseudo-standard world where standards are made on paper and forced to be adopted. FOSS works in completely the opposite direction; multiple implementations are tested and then adopted as a standard once proven. If this is not the planned way of working then I suggest looking at W3C's requirements for standards adoption which *requires* two independent implementations of the standard before it can be adopted. 

Regards,

Jeremiah 
Re: Proposed spec for external packages

Mike Milinkovich
 

On 04/08/2015 12:15 PM, Kate Stewart wrote:
I agree we should not depend on closed standards. However, the question is do we want to be able to reference to external packages that other systems are supporting?
Beats me. But to me the proposed solution looks much worse than whatever problem it is that you're trying to solve. Speaking of which, where is the document that describes the problem you're trying to solve?

My impression is that the consumers of open source software are trying to create a system to make it easier to identify and manage the artifacts used within their organization. Is that correct? If so, what I am missing is how you are going to motivate the producers of open source to use such a system. You're already getting our libre software for free. Why are we going to do more work to make your lives easier?

My apologies in advance if I'm completely off base here.

--
Mike Milinkovich
mike.milinkovich@...
+1.613.220.3223 (mobile)
Re: Proposed spec for external packages

Kate Stewart
 



On Tue, Aug 4, 2015 at 10:45 AM, Mike Milinkovich <mike.milinkovich@...> wrote:
On 04/08/2015 9:34 AM, Philippe Ombredanne wrote:
On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on
usage in the beginning, I'll discuss some specific use cases in the context
of SpdxTools on the call.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

 To add to Philippe's comments, and speaking on behalf of a major producer of open source software, the proposal for an "External Security and Asset Management Identifier" seems to be fundamentally flawed. A quick perusal of the tagvault.org website tells me that the spec is not publicly available (i.e. you must buy it for $265 from ANSI), and that the tools used to tag software assets are available only to members of their private club.

The SPEC being referred to is a NIST one,  rather than ANSI.   see:  http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-8060 
Which is open.

Its in its second reading right now, and its in a public comment window, before NIST adopts it. 

IMO, any requirement that open source communities use a closed standard, and proprietary tools to annotate their open source code is dead on arrival.

I agree we should not depend on closed standards.  However,  the question is do we want to be able to reference to external packages that other systems are supporting?

Kate
Re: Proposed spec for external packages

Kate Stewart
 



On Tue, Aug 4, 2015 at 10:43 AM, Kate Stewart <kstewart@...> wrote:
Hi Philippe,
    The document you commented on was from last week's discussion.  
Your input is appreciated and you're opinion is lining up 
with some of the thoughts expressed as part of the external identifier
proposal from 2 weeks ago from Bill Schineller.

here's the link: 
 

Kate

On Tue, Aug 4, 2015 at 8:34 AM, Philippe Ombredanne <pombredanne@...> wrote:
On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
> Here is the spec for the proposed EternalPackage element. While I touch on
> usage in the beginning, I'll discuss some specific use cases in the context
> of SpdxTools on the call.
>
> https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
>

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

The gist of my feedback:
- SWID tags are a nice concept but look to me at best new and may be
emerging, and at worst an unknown quantity fraught with many issues:
 - no open neutral registry (like a IANA);
 - little or no known usage in the FOSS world and no known usage by
any Linux distro as far as I know;
 - a de-jure standard backed primarily by commercial entities for
commercial licensing compliance, with a closed and pay-walled-garden
called tagvault.org;
 - little general adoption that I could find beyond a few commercial
vendors of asset management tools and a few (albeit large) commercial
software vendors like Microsoft;
 - and yet another new standard on top of another standard: based on
the NIST discussion draft you provided the ambition of SWID tags seems
to be a rehash on top CPEs.

- Why limit the purpose to security? identification has a rather
general purpose.

- Why limit an external id to CPE and SWID tags? There are several
other sources of (rather widely used) globally unique ID:
 - Linux distros package name/version
 - other package managers name/version such as npm, rubygems, pypi, maven, etc
 - repo or project names on hosting sites such as Github, Google Code
(RIP), Apache, Eclipse, Sourceforge and several others.

All these should be supported and are IMHO far better and more widely
used that SWID tags. Hence my suggestion for something more inclusive
and generic.

An interesting question is how you map these to one another: for
instance what is the corresponding Debian package for a Fedora RPM?
What would be the common id for the upstream of these two packages?
What is the corresponding CPE if any?

--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Proposed spec for external packages

Mike Milinkovich
 

On 04/08/2015 9:34 AM, Philippe Ombredanne wrote:
On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on
usage in the beginning, I'll discuss some specific use cases in the context
of SpdxTools on the call.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#
To add to Philippe's comments, and speaking on behalf of a major producer of open source software, the proposal for an "External Security and Asset Management Identifier" seems to be fundamentally flawed. A quick perusal of the tagvault.org website tells me that the spec is not publicly available (i.e. you must buy it for $265 from ANSI), and that the tools used to tag software assets are available only to members of their private club.

IMO, any requirement that open source communities use a closed standard, and proprietary tools to annotate their open source code is dead on arrival.

--
Mike Milinkovich
Executive Director,
Eclipse Foundation
mike.milinkovich@...
+1.613.220.3223 (mobile)
Re: Proposed spec for external packages

Kate Stewart
 

Hi Philippe,
    The document you commented on was from last week's discussion.  
Your input is appreciated and you're opinion is lining up 
with some of the thoughts expressed as part of the external identifier
proposal from 2 weeks ago from Bill Schineller.

Kate

On Tue, Aug 4, 2015 at 8:34 AM, Philippe Ombredanne <pombredanne@...> wrote:
On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
> Here is the spec for the proposed EternalPackage element. While I touch on
> usage in the beginning, I'll discuss some specific use cases in the context
> of SpdxTools on the call.
>
> https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
>

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

The gist of my feedback:
- SWID tags are a nice concept but look to me at best new and may be
emerging, and at worst an unknown quantity fraught with many issues:
 - no open neutral registry (like a IANA);
 - little or no known usage in the FOSS world and no known usage by
any Linux distro as far as I know;
 - a de-jure standard backed primarily by commercial entities for
commercial licensing compliance, with a closed and pay-walled-garden
called tagvault.org;
 - little general adoption that I could find beyond a few commercial
vendors of asset management tools and a few (albeit large) commercial
software vendors like Microsoft;
 - and yet another new standard on top of another standard: based on
the NIST discussion draft you provided the ambition of SWID tags seems
to be a rehash on top CPEs.

- Why limit the purpose to security? identification has a rather
general purpose.

- Why limit an external id to CPE and SWID tags? There are several
other sources of (rather widely used) globally unique ID:
 - Linux distros package name/version
 - other package managers name/version such as npm, rubygems, pypi, maven, etc
 - repo or project names on hosting sites such as Github, Google Code
(RIP), Apache, Eclipse, Sourceforge and several others.

All these should be supported and are IMHO far better and more widely
used that SWID tags. Hence my suggestion for something more inclusive
and generic.

An interesting question is how you map these to one another: for
instance what is the corresponding Debian package for a Fedora RPM?
What would be the common id for the upstream of these two packages?
What is the corresponding CPE if any?

--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Proposed spec for external packages

Sai Uday Shankar Korlimarla
 

Hi Philippe, HI Yev 

Philippe, You are right about SWID.
Yev, I may be biased over using CPEs and not using SWIDs. Here are my points on SWID.

1. SWID looks nice to have for software asset management and identification. CPEs can do just the same job.

2. SWID are not available in the open. I know that I currently can identify a minimum of 1902702 products by CPEs.

Instance: cpe:/a:google:chrome:43.0.2357.134 has CVE CVE-2015-5605. It is easy to perform cross-linked correlation from many sources as you pointed out. Here the below URL gives us "openSUSE-2015-513.nasl"

http://www.security-database.com/detail.php?alert=CVE-2015-5605

So we have "openSUSE-2015-513.nasl" "CVE-2015-5605"  and "cpe:/a:google:chrome:43.0.2357.134" all talking about one single product google chrome version 43.

I don't see how SWIDs will be able to help do this.

3. If I consume SWID, unless I tie the SWID to a CPE, I will not be able to move forward and gain vulnerability information. I could just stick with CPEs then.

4. Trusting a standard without paying $400 is going to be a bit difficult. Open standards are way better. I think it is easier to live with duplicates in CPE dictionary and still be able to accurately get CVE information using cross-linked information as philippe point out.

5. While ISO, Microsoft and Symantec may sound fancy, the real question is on how open is this tag information. If SWID is an open-tagging scheme, it would definitely be worth considering.

6. Anyone can read a CPE and know what it is and do not need a digital signature for integrity for that, i.e. CPEs are open and readable. SWIDs will contain information that is not consumable immediately. Either SWIDs are flawed or is duplication. As philippe points out, if SWIDs would be re-hash over CPE, it would definitely be worth consuming/exploring.

I may be wrong in my opinions but am open for learning more.

Regards
Uday






Regards
Uday

On Tue, Aug 4, 2015 at 9:15 AM, Sai Uday Shankar Korlimarla <iamudayshankar@...> wrote:

Regards
Uday



-------- Original Message --------
Subject: Fwd: Re: Proposed spec for external packages
From: Thomas T Gurney <ttg@...>
Sent: Tuesday, August 4, 2015, 09:14
To: Sai Uday Shankar Korlimarla <iamudayshankar@...>
CC:




Date: 4. Aug 2015 08:34
From: pombredanne@...
To: ybronshteyn@...
Cc: spdx@...
Subject: Re: Proposed spec for external packages

On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on
usage in the beginning, I'll discuss some specific use cases in the context
of SpdxTools on the call.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

The gist of my feedback:
- SWID tags are a nice concept but look to me at best new and may be
emerging, and at worst an unknown quantity fraught with many issues:
- no open neutral registry (like a IANA);
- little or no known usage in the FOSS world and no known usage by
any Linux distro as far as I know;
- a de-jure standard backed primarily by commercial entities for
commercial licensing compliance, with a closed and pay-walled-garden
called tagvault.org;
- little general adoption that I could find beyond a few commercial
vendors of asset management tools and a few (albeit large) commercial
software vendors like Microsoft;
- and yet another new standard on top of another standard: based on
the NIST discussion draft you provided the ambition of SWID tags seems
to be a rehash on top CPEs.

- Why limit the purpose to security? identification has a rather
general purpose.

- Why limit an external id to CPE and SWID tags? There are several
other sources of (rather widely used) globally unique ID:
- Linux distros package name/version
- other package managers name/version such as npm, rubygems, pypi, maven, etc
- repo or project names on hosting sites such as Github, Google Code
(RIP), Apache, Eclipse, Sourceforge and several others.

All these should be supported and are IMHO far better and more widely
used that SWID tags. Hence my suggestion for something more inclusive
and generic.

An interesting question is how you map these to one another: for
instance what is the corresponding Debian package for a Fedora RPM?
What would be the common id for the upstream of these two packages?
What is the corresponding CPE if any?

--
Cordially
Philippe Ombredanne
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Proposed spec for external packages

Yev Bronshteyn
 

D’oh! Arrgh! Other grunting noises!

Here is the correct link. Terribly sorry for the confusion/inconvenience.




On Aug 4, 2015, at 9:04 AM, Kate Stewart <kstewart@...> wrote:

Hi Yev,
    The spec you linked to was the one I created for las week's call.
Is there a different document we should be refering to?

Thanks, Kate

On Mon, Aug 3, 2015 at 10:00 PM, Yev Bronshteyn <ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on usage in the beginning, I'll discuss some specific use cases in the context of SpdxTools on the call.


Thanks!

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Proposed spec for external packages

Philippe Ombredanne
 

On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on
usage in the beginning, I'll discuss some specific use cases in the context
of SpdxTools on the call.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

The gist of my feedback:
- SWID tags are a nice concept but look to me at best new and may be
emerging, and at worst an unknown quantity fraught with many issues:
- no open neutral registry (like a IANA);
- little or no known usage in the FOSS world and no known usage by
any Linux distro as far as I know;
- a de-jure standard backed primarily by commercial entities for
commercial licensing compliance, with a closed and pay-walled-garden
called tagvault.org;
- little general adoption that I could find beyond a few commercial
vendors of asset management tools and a few (albeit large) commercial
software vendors like Microsoft;
- and yet another new standard on top of another standard: based on
the NIST discussion draft you provided the ambition of SWID tags seems
to be a rehash on top CPEs.

- Why limit the purpose to security? identification has a rather
general purpose.

- Why limit an external id to CPE and SWID tags? There are several
other sources of (rather widely used) globally unique ID:
- Linux distros package name/version
- other package managers name/version such as npm, rubygems, pypi, maven, etc
- repo or project names on hosting sites such as Github, Google Code
(RIP), Apache, Eclipse, Sourceforge and several others.

All these should be supported and are IMHO far better and more widely
used that SWID tags. Hence my suggestion for something more inclusive
and generic.

An interesting question is how you map these to one another: for
instance what is the corresponding Debian package for a Fedora RPM?
What would be the common id for the upstream of these two packages?
What is the corresponding CPE if any?

--
Cordially
Philippe Ombredanne
Re: Proposed spec for external packages

Kate Stewart
 

Hi Yev,
    The spec you linked to was the one I created for las week's call.
Is there a different document we should be refering to?

Thanks, Kate

On Mon, Aug 3, 2015 at 10:00 PM, Yev Bronshteyn <ybronshteyn@...> wrote:
Here is the spec for the proposed EternalPackage element. While I touch on usage in the beginning, I'll discuss some specific use cases in the context of SpdxTools on the call.


Thanks!

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Proposed spec for external packages

Yev Bronshteyn
 

Here is the spec for the proposed EternalPackage element. While I touch on usage in the beginning, I'll discuss some specific use cases in the context of SpdxTools on the call.

https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing

Thanks!
SPDX 2.0 Bakeoff at Linux Con NA - August 17 9am - Virginia Room

kate.stewart@...
 

Hi,
    We're now less than on month away from LinuxCon, and we wanted to get some information out for those who want to participate in the SPDX 2.0 Bakeoff.  If you can make it to Seattle that’s fantastic -- we look forward to meeting you or re-connecting!  If you can’t make it in person that’s OK -- you may still upload your SPDX files.   

A folder has been setup to share SPDX files for the SPDX Bakeoff workgroup session scheduled for Monday morning August 17, 2015.    We’ll be meeting in Virginia Room (located on the 4th floor, Union St side of hotel) from 9:00am - 1:00pm.

In order to facilitate the analysis and discussion we are asking everyone who has tools that generate SPDX to at least generate an SPDX file (tag-value format) for Time v1.7 (a small package for the purpose of comparing SPDX output from different tools), cpio 2.10 and spdx-tools v 2.0 .   

Please use the links to the source packages in the table below so that we are comparing “apples to apples.”   Then simply create a folder with the name of your organization and just drop the SPDX files in there.    If you have any questions or problems email spdx-tech@....   

Also please fill out our sign-up form to let us know what additional topics you would like to see covered in this session.

SPDX files to be compared:



Simple SPDX Document Creation
SPDX Document Creation with
Internal Relationships
SPDX Document Creation with
External Relationships
Packages

Notes
This is the same package we used for the SPDX 1.1 bake-off.  It is a small package and should be reasonably straight forward.  Deprecated fields should not be used.
This is a package has a bit more files to it and there are different file types and relationships internal to the package.
This is a Maven project with external dependencies listed in the project POM.  Don’t pay too much attention to the SPDX file in the git repository - it is a 1.2 version and does not include all of the dependencies.


Reference Information:


Instructions:  

  1. Create a folder for your tool in “SPDX 2.0 Bake-Off” folder.    
    1. see example “doSoCs (UNO)”
    2. please remember to make sure that it is readable.
  2. Create a copy of the template for the tools’ environment context  and put into your tool’s folder.
  3. Add the SPDX files generated for the reference examples into your tool’s folder.
  4. Ideally, please consider run the SPDX files through the verification tool (aka translator) indicate if not run.  The verification tool can be downloaded from https://github.com/spdx/tools/releases/download/V2.0.2/spdx-tools-2.0.2-jar-with-dependencies.jar.  Verification can be run executing the downloaded jar file with the command “verify” with a single parameter of the SPDX file (e.g. java -jar spdx-tools-2.0.2-jar-with-dependencies.jar myspdxfile.spdx). 
  5. If you have any questions,  feel free to email spdx-tech@... and we’ll try to help.

Thanks,
Jack, Gary & Kate

SPDX General Meeting Minutes

Philip Odence
 


Thanks again to Gary and the UNO team for the interesting presentation.


L. Philip Odence
General Manager Audit Services
Vice President of Corporate and Business Development
Black Duck Software, Inc.
8 New England Executive Park, Suite 211, Burlington MA 01803
Phone: 781.810.1819, Mobile: 781.258.9502
Skype: philip.odence



General Meeting/Minutes/2015-07-02

  • Attendance: 15
  • Lead by Phil Odence
  • Minutes of May meeting approved

UNO - Matt Germonprez[edit]

  • Tools
    • DoSOCS - evolved from Yacto tool
      • Generalized to create ways of generating SPDX docs from various dev processes
      • Resulted DoSOCS- Ways to scan packages and repos (now source, but in theory binary) to generate SPDX
        • Main use case is generating SPDX 2.0 docs
        • Store in a relational database - trick was mapping obj-oriented SPDX to rel database
        • Very generic. Even on the back end; developed with FOSSology, but could plug in commercial scanners
        • Future- intake of SPDX
        • Idea is that this will eventually pull in all tools Git, Yacto, etc
        • And, can be tied into Jenkins
        • Ultimately will support an enterprise process to maintain a inventory of SPDX docs that come out of their processes
      • Also exploring production of security vulnerability info
        • Looking for where vulnerability info could be stored.
        • Need a spot for CPE (and other common ID standards)
        • Which would allow for vulnerability info
        • Tech team has been pursuing this idea
        • Group needs to address the mission creep issue
    • Git Scanner
      • Analyzes branch and contributes SPDX doc
    • Eclipse Plug In


Tech Team Report - Kate & Gary[edit]

  • Proposal for wording on Snippets 
    • Up as a Googledoc and available for review
  • Also one for None/No Assertion
  • Some discussion of best practices as well
    • Looking for folks to sign up on the wiki page to write up parts
  • Kicked of discussion Bake Off and what examples to use
  • BillS writing up proposal for including external component identifiers (GAV, CPE, others)
    • General agreement with concept
  • Tools
    • Discussion has been going for a couple months about mapping/reconciling various sources of tools (SPDX group, UNO)
    • Bakeoff at LinuxCon NA (Monday, 8-noon)
      • Will have 2-3 examples
        • Candidates are examples on best practices page
      • Tool providers will provide SPDX docs 
      • Should learn a lot from comparisons

Legal Team Report - Paul[edit]

  • Putting together rev License List (2.1) including exceptions
    • Lots of new exceptions
  • Mark Gisi is leading exploration of standard headers


Biz Team Report - Jack[edit]

  • Working on new guidance pages
    • Phil and Jack have been prototyping
  • LinuxCon
    • Back off Monday
    • Aiming for BoF on Tuesday
    • SPDX talk from Gary (Tues am)
    • Mark will be giving a more general talk that will relate to SPDX (Tues pm)


Cross Functional Topics - Phil[edit]

  • Continually looking for presenters for General Meeting


Attendees[edit]

  • Phil Odence, Black Duck
  • Mike Dolan, Linux Foundation
  • Mark Gisi, Wind River
  • Scott Sterling, Palamida
  • Gary O’Neill, SourceA
  • Kate Stewart, LF
  • Hassib Khanafer, Protecode
  • Paul Maddick, HP
  • Scott Lamons
  • Jack Manbeck, TI
  • Matt Germonprez, UNO
  • Tom Gurney, UNO
  • Uday Shankar, UNO
  • Michael H- nexB
  • Kirsten Newcomer, Black Duck
UNO SPDX Project Repositories

Matt Germonprez <germonprez@...>
 

Hi everyone, 

Thanks for the chance to discuss the UNO SPDX tools at the General Meeting. Here are the links to the GH repositories for projects that are currently active: 

DoSOCS: 

GitScanner:

Eclipse Plugin:

Feel free to contact us with any questions. 

Regards,
Matt

--
Mutual of Omaha Associate Professor
College of Information Science & Technology 
University of Nebraska Omaha
Re: SPDX General Meeting Thursday

Jeremiah Foster <jeremiah.foster@...>
 

Hi,

I would love to hear about SPDX 2 integrated into yocto or Open Embedded if someone has done that.

Regards,

Jeremiah

On Jul 1, 2015 2:09 PM, "Philip Odence" <podence@...> wrote:

I’m trying to spice up every General Meeting with a speaker talking about a special topic, usually their organizations’ use of SPDX or work related to. If you have any ideas for future presentations, PLEASE contact me. I assure you that even the simplest adoption story if of great interest. 

This month, Matt Germonprez will provide an update on the Univ of Nebraska/Omaha’s work with SPDX.


GENERAL MEETING

Meeting Time: Thurs, July 2, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:
Conference code:  7812589502
Toll-free dial-in number (U.S. and Canada):  (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF

 
Administrative Agenda
Attendance

Presentation – Matt

Technical Team Report - Kate


Legal Team Report - Jilayne


Business Team Report – Jack


Cross Functional Issues – Phil

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
SPDX General Meeting Thursday

Philip Odence
 

I’m trying to spice up every General Meeting with a speaker talking about a special topic, usually their organizations’ use of SPDX or work related to. If you have any ideas for future presentations, PLEASE contact me. I assure you that even the simplest adoption story if of great interest. 

This month, Matt Germonprez will provide an update on the Univ of Nebraska/Omaha’s work with SPDX.


GENERAL MEETING

Meeting Time: Thurs, July 2, 8am PDT / 10 am CDT / 11am EDT / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:
Conference code:  7812589502
Toll-free dial-in number (U.S. and Canada):  (877) 435-0230
International dial-in number: (253) 336-6732
For those dialing in from other regions, a list of toll free numbers can be found: https://www.intercallonline.com/portlets/scheduling/viewNumbers/viewNumber.do?ownerNumber=6053870&audioType=RP&viewGa=false&ga=OFF

 
Administrative Agenda
Attendance

Presentation – Matt

Technical Team Report - Kate


Legal Team Report - Jilayne


Business Team Report – Jack


Cross Functional Issues – Phil
Re: Zero Clause BSD (0BSD)

J Lovejoy
 

Hi Rob,

Thanks for you email. To request a new license be added to the SPDX License List, you need to provide the info listed on this page (most of which you already have) http://spdx.org/spdx-license-list/request-new-license and send it to the SPDX-Legal mailing list. If you are not a member there, you can join the legal mailing list here: http://spdx.org/participate/legal-team

Thanks!

Jilayne
SPDX Legal Team co-lead

On Jun 12, 2015, at 1:01 PM, Rob Landley <rob@...> wrote:

I'm told I should contact you about registering Toybox's "zero clause
bsd" license for an official 0BSD acronym/abbreviation.

The license text itself (paragraphs 2 and 3 here):

https://github.com/landley/toybox/blob/master/LICENSE

Is 2 clause BSD with the removal of half a sentence:


https://github.com/landley/toybox/commit/ee86b1d8e25cb0ca9d418b33eb0dc5e7716ddc1e

This simplification makes the license function as a public domain
license (such as unlicense.org or creative commons zero), specifically
it means that combining works from multiple sources allows the license
text to collapse together, so you don't wind up with nonsense such as
Android's dozens of concatenated license copies for toolbox:

https://github.com/android/platform_system_core/blob/master/toolbox/NOTICE

(I asked why they had multiple copies of _identical_ license text, and
they said the copyright dates had changed so a strict reading of the
"copy exactly" part of the license meant... Don't laugh, the
"about->license" pulldown in the kindle paperwhite has over _300_pages_
of this nonsense. It's a chronic issue with bsd-alikes.)

So yeah, zero clause BSD. In toybox. Is there a form I should fill out?

Rob
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Zero Clause BSD (0BSD)

Rob Landley <rob@...>
 

I'm told I should contact you about registering Toybox's "zero clause
bsd" license for an official 0BSD acronym/abbreviation.

The license text itself (paragraphs 2 and 3 here):

https://github.com/landley/toybox/blob/master/LICENSE

Is 2 clause BSD with the removal of half a sentence:


https://github.com/landley/toybox/commit/ee86b1d8e25cb0ca9d418b33eb0dc5e7716ddc1e

This simplification makes the license function as a public domain
license (such as unlicense.org or creative commons zero), specifically
it means that combining works from multiple sources allows the license
text to collapse together, so you don't wind up with nonsense such as
Android's dozens of concatenated license copies for toolbox:

https://github.com/android/platform_system_core/blob/master/toolbox/NOTICE

(I asked why they had multiple copies of _identical_ license text, and
they said the copyright dates had changed so a strict reading of the
"copy exactly" part of the license meant... Don't laugh, the
"about->license" pulldown in the kindle paperwhite has over _300_pages_
of this nonsense. It's a chronic issue with bsd-alikes.)

So yeah, zero clause BSD. In toybox. Is there a form I should fill out?

Rob
Re: Exclusion of NONE and NOASSERTION from ABNF

Mark Gisi
 

Hi Terin,

On the surface the following appears to be syntactically convenient:
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")

but semantically incorrect. Let me try to explain using a database data field analogy.

NONE and NOASSERTION are defined at the SPDX document field level and even have different semantic values with respect to different fields. SPDX fields can have several different types assigned which is analogous to a database field. For example, a database field may contain values of *type* Character, Integer, Float, Boolean, Date and so forth. A database field can also contain the special value NULL, which does not belong to a specific data type, but instead represents a special field value (NULL = missing unknown data). NONE and NOASSERTION are analogous to NULL, where a license expression is analogous to a type such as Character, Integer, Float, Boolean, Date and so forth.

A license expression represents the licensing terms of a piece of software (source or binary). In less precise terms, it represents the distribution obligations for a software component. NONE and NOASSERTION do not semantically represent that. To include NONE and NOASSERTION as validate license expressions is analogous to adding NULL to a database type which would be semantically awkward.

In summary, on the surface the following appear syntactically convenient:
license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")

But semantically it is not correct, and therefore, NONE or NOASSERTION should not be included in the ABNF definition for a license expression.

At least that is one perspective.

Best,
- Mark

Mark Gisi | Wind River | Director, IP & Open Source
Tel (510) 749-2016 | Fax (510) 749-4552

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On Behalf Of Terin Stock
Sent: Thursday, June 11, 2015 9:21 AM
To: Kate Stewart
Cc: spdx@...
Subject: Re: Exclusion of NONE and NOASSERTION from ABNF

Kate:

I'm unsure of any use case where you would want to mix NONE or NOASSERTION with either simple-expression or compound-expression in the same package. You may however want to use these strings when packaging code that has no license or where you are unsure of the license.

In ABNF speak was thinking more along the lines of

license-expression = 1*1(simple-expression / compound-expression / "NONE" / "NOASSERTION")
--
#Terin Stock


On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart <kstewart@...> wrote:
Hi Terin,

On Thu, Jun 11, 2015 at 10:52 AM, Terin Stock <terinjokes@...> wrote:

The ABNF in Appendix IV of the 2.0 version of the specification
allows for short form identifiers, LicenseRef values or combinations
to form a license-expression. However the values "NONE" and
"NOASSERTION" are not valid in a license expression, despite their
useful and defined meaning in the specification.

There are tools that validate their license fields using a
license-expression (two such tools being the package managers npm and
composer, in JavaScript and PHP, respectfully), making the values
"NONE" and "NOASSERTION" invalid.

Are these two values excluded from the ABNF on purpose?

Can you give us a real life use case where either "NONE" or "NOASSERTION"
should be used in combination with other licenses?

If there's a compelling use case as to why it should be allowed, that
can't be expressed another way, we can certainly revisit adding it to
the specification if the folk on the legal team agree.

Thanks, Kate
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Exclusion of NONE and NOASSERTION from ABNF

Kate Stewart
 

Hi Terin

On Thu, Jun 11, 2015 at 11:20 AM, Terin Stock <terinjokes@...> wrote:
Kate:

I'm unsure of any use case where you would want to mix NONE or
NOASSERTION with either simple-expression or compound-expression in
the same package.

Neither could we.  :-)
 
You may however want to use these strings when
packaging code that has no license or where you are unsure of the
license.

In ABNF speak was thinking more along the lines of

license-expression = 1*1(simple-expression / compound-expression /
"NONE" / "NOASSERTION")

Ah yes, that should be considered. 

Right now when NONE or NOASSERTION are permitted, they are associated
with the actual fields in the specification (ie. LicenseConcluded, etc.) , but this 
may be a more elegant way to express it.   Will need to take a pass through all
the other fields using them and see if there are any snags.

The next tech call on the 16th is a joint call with the legal team where we
plan on talking about the NONE/NOASSERTION language.   It probably makes
sense to consider this, as well at that time.    Please feel free to join in to the 
call if you'd like. 

Thanks for raising this.

Kate
 
--
#Terin Stock


On Thu, Jun 11, 2015 at 9:07 AM, Kate Stewart
<kstewart@...> wrote:
> Hi Terin,
>
> On Thu, Jun 11, 2015 at 10:52 AM, Terin Stock <terinjokes@...> wrote:
>>
>> The ABNF in Appendix IV of the 2.0 version of the specification allows for
>> short form identifiers, LicenseRef values or combinations to form a
>> license-expression. However the values "NONE" and "NOASSERTION" are not
>> valid in a license expression, despite their useful and defined meaning in
>> the specification.
>>
>> There are tools that validate their license fields using a
>> license-expression (two such tools being the package managers npm and
>> composer, in JavaScript and PHP, respectfully), making the values "NONE" and
>> "NOASSERTION" invalid.
>>
>> Are these two values excluded from the ABNF on purpose?
>
>
> Can you give us a real life use case where either "NONE" or "NOASSERTION"
> should be used in combination with other licenses?
>
> If there's a compelling use case as to why it should be allowed, that can't
> be expressed another way, we can certainly revisit adding it to the
> specification if the folk on the legal team agree.
>
> Thanks,  Kate
>
641 - 660 of 1624