1. spdx@lists.spdx.org
  2. Messages
   Date   
Re: Import and export function of SPDX

Peter Williams <peter.williams@...>
 

On Tue Jun 12 16:20:35 2012, Kevin P. Fleming wrote:
On 06/12/2012 03:06 PM, Peter Williams wrote:
So the questions is: Is it better to have SPDX files which contain a
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
I would question whether this is one 'tiny little piece' or not. In my
role as a consumer of such incoming license information, I would be
unwilling to accept SPDX data describing a package unless I could
conclusively confirm that the package supplied matched the data in the
SPDX file.
Fair enough. For you that might qualify as a large piece of information. You might choose not to accept SPDX files missing this information. Obviously any file not containing the information needed to accomplish your goals is useless. I, however, might find it perfectly acceptable. The strict approach results in us both being deprived of the information.

Is it worse to receive a data set that is too incomplete to use for your purpose, or not receive any data at all? It seems to me that to two situations are practically the same, in either case you have no new information. On the other hand, if you can accomplish your goal with the incomplete data set, then receiving it improves your situation substantially. Let's err on the side of helping as many people as possible.

Even if you choose not to accept an incomplete file verbatim, having it might still be advantageous. If nothing else it gives you a place to start your investigation. For example, if i receive an SPDX file w/o a packageVerificationCode, i might decide i need to do my own analysis of the package i am using because i cannot verify that is exactly the one described by the SPDX file. Fortunately, the licensing of software packages rarely change dramatically between versions so i could use the untrusted SPDX data as a starting point. Such a head start would be likely to save a great deal of time and effort. This would be about the same process needed if i received an SPDX file with a packageVerificationCode that did not match my package.

Peter

PS: This is obviously a forward looking discussion. These fields are mandatory in 1.0, and will be in 1.1, so they need to be in SPDX files produced under those version. However, for 2.0 i think we could greatly encourage adoption by relaxing some of these constraints from "must have" to "should have". And we would get that benefit with no practical downside at all.
Re: Import and export function of SPDX

Gary O'Neall
 

I would like to know more about the use case.

If this is a producer use case where the SPDX is included with a set of
files distributed, then the archive file would be the archive file produced
and the verification code could be calculated from the files included in the
archive.

If this is an intermediate use case where existing packages are being
documented as SPDX files, I could see where it is more challenging to obtain
the archive file and verification code from the original package unless the
original package included an SPDX file or the original archive file was
maintained.

Gary

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On
Behalf Of Kevin P. Fleming
Sent: Tuesday, June 12, 2012 3:21 PM
To: spdx@...
Subject: Re: Import and export function of SPDX

On 06/12/2012 03:06 PM, Peter Williams wrote:
So the questions is: Is it better to have SPDX files which contain a
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
I would question whether this is one 'tiny little piece' or not. In my role
as a consumer of such incoming license information, I would be unwilling to
accept SPDX data describing a package unless I could conclusively confirm
that the package supplied matched the data in the SPDX file.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Import and export function of SPDX

Kevin P. Fleming <kpfleming@...>
 

On 06/12/2012 03:06 PM, Peter Williams wrote:
So the questions is: Is it better to have SPDX files which contain a
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
I would question whether this is one 'tiny little piece' or not. In my role as a consumer of such incoming license information, I would be unwilling to accept SPDX data describing a package unless I could conclusively confirm that the package supplied matched the data in the SPDX file.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@... | SIP: kpfleming@... | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
Re: Import and export function of SPDX

Peter Williams <peter.williams@...>
 

On Tue Jun 12 12:12:42 2012, William Boyle wrote:
Why not just
support the mandatory elements? Is it so hard? Of is it just difficult
in the corporate political scene? :-(
I cannot speak for Michel, but sometimes it *is* hard. The packageVerificationCode, for example, is constructed from checksums produced by a relatively weak hash algorithm. We analyzed many packages before the advent of SPDX and collected checksums using a much stronger algorithm. We no longer have access to many of those packages. In that situation it is *impossible* to produce an SPDX file with a packageVerificationCode.

So the questions is: Is it better to have SPDX files which contain a large amount of truly useful information but that are incomplete or should we hide all that information because we are missing one tiny little piece?

I'd vote for not letting the best be the enemy of the good. The more information people have the better their decisions will be, even if that information is incomplete. The real world is imperfect, messy and ambiguous which is why being liberal in what is accepted is a virtue[1] for an data exchange format. Just look at HTML -- probably one of the most interoperable formats ever created -- would it have succeeded if browsers had been pedantic about the HTML format? I seriously doubt it, just look at the (lack of) adoption of strict XHTML.

[1]: http://en.wikipedia.org/wiki/Robustness_principle

Peter
Re: Import and export function of SPDX

William Boyle
 

So, you want Alcalu to have a private version of SPDX? Why not just support the mandatory elements? Is it so hard? Of is it just difficult in the corporate political scene? :-(

William Boyle
Senior Systems Engineer
Nokia Mobile Phones


On Tue, Jun 12, 2012 at 7:02 AM, RUFFIN, MICHEL (MICHEL) <michel.ruffin@...> wrote:
Dear all
As you probably noticed Alcatel-Lucent is trying to implement the SPDX standard.
We have an internal database on FOSS IP issues that has been created in 2002. and we are trying to implement an import/export function in SPDX standard.
We have an issue with 2 fields that do not exist in our database.: the name of the archive file and the checksum. In the SPDX standard they are mandatory and I do not see why would it be possibly to make them optional?
 
See bellow details
 
Michel
 
There are two fields that are mandatory in SPDX but have no equivalent in the
Alcatel-Lucent FOSS database.
 
These fields are:
 
4.3 Package File Name
4.3.1 Purpose: Provide the actual file name of the package. This may include the
packaging and compression methods used as part of the file name.
4.3.2 Intent: Here, the actual file name of the compressed file containing the
package is a significant technical element that needs to be included with each
package identification information.
4.3.3 Cardinality: Mandatory, one.
 
4.7 Package Verification Code
4.7.1 Purpose: This field provides an independently reproducible mechanism
identifying specific contents of a package based on the actual files (except the
SPDX file itself, if it is included in the package) that make up each package
and that correlates to the data in this SPDX file. This identifier enables a
recipient to determine if any file in the original package (that the analysis
was done on) has been changed and permits inclusion of an SPDX file as part of a
package.
4.7.2 Intent: Providing a unique identifier based on the files inside each
package, eliminates confusion over which version or modification of a specific
package the SPDX file refers to. The SPDX file can be embedded within the
package without altering the identifier.
4.7.3 Cardinality: Mandatory, one.
 
 
Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff
Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
 
 
 

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Import and export function of SPDX

Gary O'Neall
 

I believe the current SPDX tools will treat both RDF and Tag/Value in the
same manner - the documents will be readable by the tools but it will fail a
validation (missing required field). For the command line tools, the
conversions or pretty printing will still work but you will get warning.

In terms of making the fields optional - I can see this as a valuable change
for some of the use cases where that information is not available. There is
need to make sure the components described in the SPDX file match the actual
file artifacts, but that need can be filled by the per-file information.

Michel - Which use case best describes your use of SPDX
(http://spdx.org/wiki/spdx-20-use-cases). If there isn't a good
representation of your use case(s), could you provide a brief description?
I want to make sure we cover this when working on SPDX 2.0.

Thanks,
Gary

-----Original Message-----
From: spdx-tech-bounces@...
[mailto:spdx-tech-bounces@...] On Behalf Of Peter Williams
Sent: Tuesday, June 12, 2012 9:27 AM
To: RUFFIN, MICHEL (MICHEL)
Cc: spdx-tech@...; spdx@...
Subject: Re: Import and export function of SPDX

On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote:
We have an issue with 2 fields that do not exist in our database.: the
name of the archive file and the checksum. In the SPDX standard they
are mandatory and I do not see why would it be possibly to make them
optional?
I think making those fields optional would be advantageous. Would you mind
filing a bug[1] so that we don't forget to look into the issue for the next
version.

As for your immediate issues of not having data for those fields, if you are
using RDF i'd just skip them altogether in the SPDX file. While your file
will technically be invalid all reasonable SPDX consumers will not have a
problem with that information being absent unless they need it to accomplish
their goal. (In which case they cannot use your SPDX files, anyway.) If you
are using the tag-value format skipping the fields altogether will, i think,
prove problematic due to that format's stricter syntactic constraints. (Kate
or Gary, can you confirm this?)

[1]:
https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spec

Peter

PS: I am cc-ing the technical working group because it's participants are
best suited to answer these sorts of issues.

_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech
Re: Import and export function of SPDX

Peter Williams <peter.williams@...>
 

On Tue Jun 12 06:02:03 2012, RUFFIN, MICHEL (MICHEL) wrote:
We have an issue with 2 fields that do not exist in our database.: the
name of the archive file and the checksum. In the SPDX standard they
are mandatory and I do not see why would it be possibly to make them
optional?
I think making those fields optional would be advantageous. Would you mind filing a bug[1] so that we don't forget to look into the issue for the next version.

As for your immediate issues of not having data for those fields, if you are using RDF i'd just skip them altogether in the SPDX file. While your file will technically be invalid all reasonable SPDX consumers will not have a problem with that information being absent unless they need it to accomplish their goal. (In which case they cannot use your SPDX files, anyway.) If you are using the tag-value format skipping the fields altogether will, i think, prove problematic due to that format's stricter syntactic constraints. (Kate or Gary, can you confirm this?)

[1]: https://bugs.linuxfoundation.org/enter_bug.cgi?product=SPDX&component=Spec

Peter

PS: I am cc-ing the technical working group because it's participants are best suited to answer these sorts of issues.
Import and export function of SPDX

RUFFIN MICHEL
 

Dear all
As you probably noticed Alcatel-Lucent is trying to implement the SPDX standard.
We have an internal database on FOSS IP issues that has been created in 2002. and we are trying to implement an import/export function in SPDX standard.
We have an issue with 2 fields that do not exist in our database.: the name of the archive file and the checksum. In the SPDX standard they are mandatory and I do not see why would it be possibly to make them optional?
 
See bellow details
 
Michel
 
There are two fields that are mandatory in SPDX but have no equivalent in the
Alcatel-Lucent FOSS database.
 
These fields are:
 
4.3 Package File Name
4.3.1 Purpose: Provide the actual file name of the package. This may include the
packaging and compression methods used as part of the file name.
4.3.2 Intent: Here, the actual file name of the compressed file containing the
package is a significant technical element that needs to be included with each
package identification information.
4.3.3 Cardinality: Mandatory, one.
 
4.7 Package Verification Code
4.7.1 Purpose: This field provides an independently reproducible mechanism
identifying specific contents of a package based on the actual files (except the
SPDX file itself, if it is included in the package) that make up each package
and that correlates to the data in this SPDX file. This identifier enables a
recipient to determine if any file in the original package (that the analysis
was done on) has been changed and permits inclusion of an SPDX file as part of a
package.
4.7.2 Intent: Providing a unique identifier based on the files inside each
package, eliminates confusion over which version or modification of a specific
package the SPDX file refers to. The SPDX file can be embedded within the
package without altering the identifier.
4.7.3 Cardinality: Mandatory, one.
 
 
Michel.Ruffin@..., PhD
Software Coordination Manager, Bell Labs, Corporate CTO Dpt
Distinguished Member of Technical Staff
Tel +33 (0) 6 75 25 21 94
Alcatel-Lucent International, Centre de Villarceaux
Route De Villejust, 91620 Nozay, France
 
 
 

Re: Problem with PackageSourceInfo

Gary O'Neall
 

Hi Marc-Etienne,

Thanks for catching these.

The property name is rdfs:comment for Review.

I went ahead and submitted bug 1046 to fix the spec.

For 1.1, there is also a web page with the rdf terms at
http://spdx.org/system/files/terms.html

I went through looking for inconsistencies between the terms and the spec,
but missed this one.

Gary

-----Original Message-----
From: spdx-bounces@... [mailto:spdx-bounces@...] On
Behalf Of Marc-Etienne Vargenau
Sent: Monday, June 11, 2012 6:21 AM
To: VARGENAU, MARC-ETIENNE (MARC-ETIENNE)
Cc: spdx@...
Subject: Re: Problem with PackageSourceInfo

Le 11/06/2012 15:16, VARGENAU, MARC-ETIENNE (MARC-ETIENNE) a écrit :
Hello,

In the SPDX 1.0 and spdx-1.1-rc20120403.pdf I read:

7.3.6 RDF: property spdx:comment in class spdx:Review
Example:
<Review>
<rdfs:comment>
All of the licenses seen in the file, are matching what was seen
during manual inspection. There are some terms that can influence the
concluded license, and some alternatives may be possible, but the
conluded license is one of the options.
</rdfs:comment>
</Review>

What is correct: "spdx:comment" or "<rdfs:comment>"?

Best regards,

Marc-Etienne
Sorry, the Subject of the message should read "Problem with Review Comments"

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Re: Problem with PackageSourceInfo

Marc-Etienne Vargenau
 

Le 11/06/2012 15:16, VARGENAU, MARC-ETIENNE (MARC-ETIENNE) a écrit :
Hello,

In the SPDX 1.0 and spdx-1.1-rc20120403.pdf I read:

7.3.6 RDF: property spdx:comment in class spdx:Review
Example:
<Review>
<rdfs:comment>
All of the licenses seen in the file, are matching what was seen during
manual
inspection. There are some terms that can influence the concluded
license, and
some alternatives may be possible, but the conluded license is one of
the options.
</rdfs:comment>
</Review>

What is correct: "spdx:comment" or "<rdfs:comment>"?

Best regards,

Marc-Etienne
Sorry, the Subject of the message should read
"Problem with Review Comments"

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
Problem with PackageSourceInfo

Marc-Etienne Vargenau
 

Hello,

In the SPDX 1.0 and spdx-1.1-rc20120403.pdf I read:

7.3.6 RDF: property spdx:comment in class spdx:Review
Example:
<Review>
<rdfs:comment>
All of the licenses seen in the file, are matching what was seen during manual
inspection. There are some terms that can influence the concluded license, and
some alternatives may be possible, but the conluded license is one of the options.
</rdfs:comment>
</Review>

What is correct: "spdx:comment" or "<rdfs:comment>"?

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
Problem with PackageSourceInfo

Marc-Etienne Vargenau
 

Hello,

In the SPDX 1.0 and spdx-1.1-rc20120403.pdf I read:

4.9.4 Data Format: free form text that can span multiple lines.
In tag format this is delimited by <text> .. </text>.
4.9.5 Tag: “PackageSourceInfo:”
Example:
PackageSourceInfo: uses glibc-2_11-branch from git://sourceware.org/git/glibc.git.

What is wrong: the Data Format or the Example?

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
Re: Comments in SPDX files

Marc-Etienne Vargenau
 

Le 06/06/2012 01:50, kate.stewart@... a écrit :
Hello Marc-Etienne,
Good catch. Looks like you've got two bugs there, one against the translation tool, and one against the spec.

Please file the bugs from https://bugs.linuxfoundation.org,
For translation tool: Product: SPDX, Component: Pretty Printer, Version: 1.1.
For SPEC: Product: SPDX, Component: SPEC, Version 1.1
Hello Kate,

It's done. Bugs 1040 and 1041.

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
Re: Comments in SPDX files

kate.stewart@...
 

Hello Marc-Etienne,
Good catch. Looks like you've got two bugs there, one against the translation tool, and one against the spec.

Please file the bugs from https://bugs.linuxfoundation.org,
For translation tool: Product: SPDX, Component: Pretty Printer, Version: 1.1.
For SPEC: Product: SPDX, Component: SPEC, Version 1.1

Thanks! :)

Kate

--- On Tue, 6/5/12, Marc-Etienne Vargenau <Marc-Etienne.Vargenau@...> wrote:

From: Marc-Etienne Vargenau <Marc-Etienne.Vargenau@...>
Subject: Comments in SPDX files
To: "spdx@..." <spdx@...>
Date: Tuesday, June 5, 2012, 2:43 AM
Hello,

I have questions regarding the syntax of comments in an
SPDX
file in tag format.

From the examples, it seems that ## starts a comment.
For example:
## Creation Information

But I do not see where this is documented in the SPDX spec.

When I use the TagToRdf tool on my files, I get:
line 39:78: expecting '#', found '3'

This line contains an URL: http://example.com/foo#bar

Should I file a bug report?

Best regards,

Marc-Etienne

-- Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY,
FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx
Comments in SPDX files

Marc-Etienne Vargenau
 

Hello,

I have questions regarding the syntax of comments in an SPDX
file in tag format.

From the examples, it seems that ## starts a comment.
For example:
## Creation Information

But I do not see where this is documented in the SPDX spec.

When I use the TagToRdf tool on my files, I get:
line 39:78: expecting '#', found '3'

This line contains an URL: http://example.com/foo#bar

Should I file a bug report?

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
FW: May 31 General Meeting Minutes - IMPORTANT

Philip Odence
 

Arrgggh.

Sorry for the volume. In my earlier note, I provided the wrong link for the Biz Team work looking to be reviewed.
Use this one:

From: Michael Herzog <mjherzog@...>
Organization: nexB Inc
Reply-To: Michael Herzog <mjherzog@...>
Date: Thu, 31 May 2012 09:28:02 -0700
To: Phil Odence <podence@...>
Cc: "Manbeck, Jack" <j-manbeck2@...>, "Lamons, Scott" <scott.lamons@...>, Pierre Lapointe <plapointe@...>
Subject: Re: May 31 General Meeting Minutes - IMPORTANT

Phil,

The latest version of the Vision-Mission discussion is a wiki-page at http://spdx.org/wiki/spdx-vision-mission, not the PDF file which has a lot of other topics from my original slides. The current Vision-Mission wiki-page includes the latest edits from the Business Team and focuses on the charter/vision/mission points without digging into the next level of points about product management roles and the organization in general.  We probably need to work the discussion from the top down - agree on the Vision/Mission and whether our charter is to keep developing the spec or whether we expand to developing more software.

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

CONFIDENTIALITY NOTICE:  This e-mail (including attachments) may contain information that is proprietary or confidential. If you are not the intended recipient or a person responsible for its delivery to the intended recipient, do not copy or distribute it. Please permanently delete the e-mail and any attachments, and notify us immediately at (650) 380-0680.

On 5/31/2012 9:13 AM, Philip Odence wrote:
Please take the time to review Legal Team description and License List description as well as Mission/Vision work from Business Team. 


Attendance: 10

May 17 minutes approved
     

Legal Team Report - Jilayne

  • Finalizing work defining the team's mission purpose of License List that were published two weeks ago. Please comment now or hold your peace. Latest draft:

    • Legal Work Group description:

      "The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the SPDX License List; and promotes the SPDX specification to the legal community at-large."

       SPDX License List description:

      "The SPDX License List is a list of commonly found open source software licenses for the purposes of being able to easily and efficiently identify such licenses in an SPDX document. The SPDX License List includes a standardized short identifier, full name for each license, vetted license text, other basic information, and a canonical permanent URL. By providing a short identifier, users can efficiently refer to a license without having to redundantly reproduce the full license." 

  • Have been providing input to 1.1 spec to incorporate latest thinking on License List and to ensure consistent vocabulary.
  • Working to make sure new website content is up to date.
  • Turning attention back to matching guidelines. Aiming to reach closure with 1.1 release (about a month)

Business Team Report - Scott/Jack

  • Business Team is eager for feedback from other team's on Mission/Vision. Looking to come to closure in the next few weeks. Expectation is that this will help with prioritization of use cases for the 2.0 effort. Latest version (embedded in a set of slides): http://www.spdx.org/system/files/spdx_mission_review_may_2012_v2.pdf
  • Also, pulling together a description of Business Team's function. Scott has drafted and will be working on this in the next Business Team meeting.

Technical Team Report - Kate

  • 2.0 work
  • 1.1 work
    • Hoping to bring to closure in the next few weeks.
    • Near final draft to be posted next week, then open for two weeks of comment.


Cross Functional Issues – Phil

  • Website Update - Pierre
    • The effort has been rejuvinated. Content is moving to the new staging area. 
    • Web team is ready to flip the switch when content is set. No date set.
    • Pierre is confirming that Steve is prepared to move wholesale sections (past meeting minutes, License List, etc.)
  • LinuxCon Papers
    • Scott submitting 1.1 update proposal 
    • Gary has submitted a proposal for talking about the OSS tools


Attendees

  • Phil Odence, Black Duck Software
  • Pierre LaPonte, nexB
  • Kate Stewart, Canonical
  • Michael Herzog, nexB
  • Scott Lamons, HP
  • Jack Manbeck, TI
  • Jilayne Lovejoy, OpenLogic
  • Chuck Gaudreau, Protecode
  • Gary O'Neall, SourceAuditor
  • Mark Gisi, WindRiver

 



_______________________________________________
Spdx mailing list
Spdx@...https://lists.spdx.org/mailman/listinfo/spdx
May 31 General Meeting Minutes - IMPORTANT

Philip Odence
 

Please take the time to review Legal Team description and License List description as well as Mission/Vision work from Business Team. 


Attendance: 10

May 17 minutes approved
     

Legal Team Report - Jilayne

  • Finalizing work defining the team's mission purpose of License List that were published two weeks ago. Please comment now or hold your peace. Latest draft:

    • Legal Work Group description:

      "The SPDX Legal Team supports and provides recommendations to the SPDX working groups regarding licensing issues for the specification itself; maintains the SPDX License List; and promotes the SPDX specification to the legal community at-large."

       SPDX License List description:

      "The SPDX License List is a list of commonly found open source software licenses for the purposes of being able to easily and efficiently identify such licenses in an SPDX document. The SPDX License List includes a standardized short identifier, full name for each license, vetted license text, other basic information, and a canonical permanent URL. By providing a short identifier, users can efficiently refer to a license without having to redundantly reproduce the full license." 

  • Have been providing input to 1.1 spec to incorporate latest thinking on License List and to ensure consistent vocabulary.
  • Working to make sure new website content is up to date.
  • Turning attention back to matching guidelines. Aiming to reach closure with 1.1 release (about a month)

Business Team Report - Scott/Jack

  • Business Team is eager for feedback from other team's on Mission/Vision. Looking to come to closure in the next few weeks. Expectation is that this will help with prioritization of use cases for the 2.0 effort. Latest version (embedded in a set of slides): http://www.spdx.org/system/files/spdx_mission_review_may_2012_v2.pdf
  • Also, pulling together a description of Business Team's function. Scott has drafted and will be working on this in the next Business Team meeting.

Technical Team Report - Kate

  • 2.0 work
    • A little over half the use cases have been fleshed out. Others are considering in a "graveyard" unless more work gets done on them.
    • http://www.spdx.org/wiki/spdx-20-use-cases 
  • 1.1 work
    • Hoping to bring to closure in the next few weeks.
    • Near final draft to be posted next week, then open for two weeks of comment.


Cross Functional Issues – Phil

  • Website Update - Pierre
    • The effort has been rejuvinated. Content is moving to the new staging area. 
    • Web team is ready to flip the switch when content is set. No date set.
    • Pierre is confirming that Steve is prepared to move wholesale sections (past meeting minutes, License List, etc.)
  • LinuxCon Papers
    • Scott submitting 1.1 update proposal 
    • Gary has submitted a proposal for talking about the OSS tools


Attendees

  • Phil Odence, Black Duck Software
  • Pierre LaPonte, nexB
  • Kate Stewart, Canonical
  • Michael Herzog, nexB
  • Scott Lamons, HP
  • Jack Manbeck, TI
  • Jilayne Lovejoy, OpenLogic
  • Chuck Gaudreau, Protecode
  • Gary O'Neall, SourceAuditor
  • Mark Gisi, WindRiver

 
Improvements in the SPDX examples

Marc-Etienne Vargenau
 

Hello,

I suggest the following improvements in the SPDX examples.

They could be included in the final 1.1 spec.

In 4.1.6
replace
<name>glibc 2.11.1</name>
with
<name>glibc</name>

In 4.3.6
replace
<packageFileName>glibc 2.11.1</packageFileName>
with
<packageFileName>glibc-2.11.1.tar.gz</packageFileName>

This would be more realistic and align the Tag and RDF
examples.

Best regards,

Marc-Etienne

--
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Marc-Etienne.Vargenau@...
Minutes from last SPDX General Meeting

Philip Odence
 

All,

I neglected to include the minutes from the last meeting in my reminder email.
First order of business is to approve.

Phil
Today's SPDX general Meeting

Philip Odence
 

Excuse the late notice. I am traveling. Normal time/ normal agenda today.

Sent from my iPhone
961 - 980 of 1587