Based on discussions from today's calls (unless someone chimes up on the list
;-)) we'll go with the following updates for the File Type fields. (note: its
an optional field)
6.2.1 Purpose: This field provides information about the type of file
identified. This information can be determinative of license compliance
requirements. The options to populate this field are limited to:
(a) SOURCE if the file is human readable source code (.c, .html, etc.);
(b) BINARY if the file is a compiled object, target image or binary executable
(.o, .a, etc);
(c) ARCHIVE if the file represents an archive (.tar, .jar, etc.);
(d) CRUFT if the file is a generated artifact of the build or repository it was
stored in (.svn, .git, etc)
(e) PICTURE if the file contains a potentially copyrightable picture or image
(.jpeg, .png, etc.) or
(f) OTHER if the file doesn't fit into the above categories (SPDXfiles, audio,
data files, etc.)
When comparing to the usage_types inRelationship and Usage Types Document it
was agreed that there could be
multiple mappings, and we wouldn't constrain the usage type to be checked
against the file types at this point.
We also reviewed the relationship types, so unless anyone else has a strong
opinion, those will be the ones we'll be
documenting in 2.0.
Anyone have specific concerns? Corrections/updates to the notes I took? :-)
Thanks, Kate
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
