Hi All,
Thanks Gary for the modeling updates, and Roger, Jeremiah for raising the
topic of traceability and how to universally refer to specific software assets.
I'm in the camp that believes this is a critical Use Case remaining to be
addressed within SPDX and other contexts for how to refer to software assets.
Such that someone picking up an SPDX document containing an analysis of a
codebase with lots of files, some of which are directly taken from releases of
OSS projects, can not only say their codebase contains a file/library
(re?)named 'v2.jar' with sha1='4c490d7d15919d9927a9722c73a5a473af92163f' under
license 'Apache-2.0', but can express that the jar was taken from the Maven
repository where its unique identifier is 'jaxb:activation:1.0.2'.
(within the 'namespace' "Maven" the unique naming convention is specified by
http://maven.apache.org/guides/mini/guide-naming-conventions.html)
Or that they included Debian package 'acl2-books-source_4.2-1_all.deb' with
sha1='d9d340cb55b681972e288d792a81295e1ede7cd0' and express that it was taken
from Debian package management system where the naming convention is
<foo>_<VersionNumber>-<DebianRevisionNumber>_<DebianArchitecture>.deb
per http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html
Similarly if they take a Ruby gem from rubygems.org (<package>/<version>), or
a Nuget package from nuget.com (<package>/<version>), or a snapshot of source
code from github.com (<owner>/<repo>/<commithash>)?
The point: specify the 'namespace' within which the identifier is unique,
and an understood naming convention within that namespace that is well known
(machine readable).
I don't know if a catalogue of all the namespaces and the unique naming
conventions within them has been published, and if not I think SPDX can write
this into specification.
In my opinion, Mitre CPE (vendor / product /version ) doesn't quite fit the
bill.
The ISO/IEC 19770-2:2009 seems like a good but lofty concept. If my quick
read of http://en.wikipedia.org/wiki/ISO/IEC_19770 is correct, it centers
around a central issuer of IDs http://tagvault.org/swid-tags/ and costs
money, so I think it will be slow to adoption.
My proposal is sort of an 'if you can't beat them, join them' approach:
adopt the unique identification schemes already in place per namespace / site /
community.
Attached cartoon you may find humorous / relevant (from http://xkcd.com/927/)
- Bill
________________________________
From: [email protected] [[email protected]] on
behalf of Jeremiah Foster [[email protected]]
Sent: Friday, March 14, 2014 4:07 AM
To: [email protected]
Subject: Re: RDF Terms for the SPDX 2.0 model
On Fri, Mar 14, 2014 at 8:00 AM, Meier, Roger
<[email protected]<mailto:[email protected]>> wrote:
Hi Gary
Thank you for this great work!
I recently had a discussion on traceability of software components across
software management platforms.
Currently I see two directions in that area:
- Common Platform Enumeration - https://cpe.mitre.org/specification/
- ISO/IEC 19770-2:2009
Did you discuss such a use case already?
Personally I think it would be worth to add a Package CPE Name attribute to the
Package Information section of SPDX, e.g.
Package Name: Linux Kernel
Package Version: 3.2.17
Package CPE: cpe:/o:linux:linux_kernel:3.2.17
What is the rationale for doing this? On a typical GNU/Linux system this
information is already available via other means. What use case does SPDX solve
here?
Regards,
Jeremiah
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
