Add country or region of origin as an optional field

[chandanbn]

Please add an optional field to declare the country or region(s) of origin or where the software as made. The value may be an array of ISO country codes.

Some countries may legally require vendors to add backdoors, weaknesses and vulnerabilities (see recent news from Southern Hemisphere). Identifying software originating from such countries enables closer scrutiny or taking additional precautionary steps. Though one should taking this information with a grain of salt and scrutinize every package prior to use for backdoors and vulnerabilities regardless of region of origin. Having this field may allow some automation in prioritization or policy enforcement.

[kestewart]

Optional field at package level suffice? I don't think we want this at the file level. Also, not sure how one counts for countries/regions when code is developed in open source and actual nationality of contributors is not tracked. Maybe an "OPENSOURCE" type of option? Thoughts?

[swinslow]

I don't tend to think that this should be added as a separate field in the Package definition (and definitely agree that it wouldn't work at the File level).

As @kestewart noted, in an open source context, contributors may be from any number of countries, and might not share their countries of origin. Additionally, the source code could be stored, and executables could be built, on servers that are located across the globe. Given all of that, I'm not sure that a Country of Origin field would be meaningful here.

That said, if someone does want to track this information for an SPDX document they are preparing, there are several existing fields where it could be stored -- e.g., 3.12: Source Information:

This field provides a place for the SPDX file creator to record any relevant background information or additional comments about the origin of the package. For example, this field might include comments indicating whether the package was pulled from a source code management system or has been repackaged.

[chandanbn]

While it may be difficult for large, legacy projects to make a statement, it helps software developers and software suppliers who want to be transparent about where their software was written or built. IMHO applies at file level as well as a package level, as different parts of a software project may have been developed in different places. It is also perfectly acceptable to have "unknown", "various countries" or an array of country codes as possible values. At the package level it would be simply an aggregation of values at file level. It is also perfectly ok to have source code and complied code to have different country of origins.

There are plenty of examples where organizations proudly make such an attestation about origin of their products: https://www.bitmi.de/leistungen/software-made-in-germany https://www.openeye.net/made-in-the-usa https://www.apple.com/designed-by-apple

Not being able to exchange such software related metadata in SPDX could be hindering software transparency.

Much of this data is perhaps can be automatically gathered and shared as demonstrated by github: https://octoverse.github.com/people#location

[swinslow]

I'd suggest moving this from consideration for 2.2 to 3.0 instead, and evaluating it in the context of the optional "profiles" that are under discussion for 3.0.

[kestewart]

Moved to 3.0 as it lines up better with the provenance and pedigree information that will be considered as part of that release.

[goneall]

This may be a good topic for the operations profile team.

Moving to 3.1 milestone.

[bact]

One possible way, in SPDX 3.0, is to use Artifact's originatedBy and suppliedBy properties, together with Agent class.

An Agent can be a Person or an Organization.

We can add an origin or a jurisdiction property to an Organization (along other contact details, which may be required by some regulations).

A Person maybe more complicated, as it can involve citizenship and residency.