THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Use Cases/2.0/Collecting enough information to allow auditor to make recommendations to remove or not a component
From SPDX Wiki
< Technical Team | Use Cases/2.0
Revision as of 18:20, 9 October 2012 by Bschineller (Talk | contribs)
- Title: Collecting enough information to allow auditor to make recommendations to remove or not a component
- Primary Actor: Auditor of open source code
- Goal in Context: To provide the consumer of the code audit sufficient information to make changes to the copyrighted materials in order to comply with the consumers policies regarding open source compliance.
- Stakeholders and Interests:
Consumer of the audit:
- Organization which has an interest in the license obligations of the copyrighted materials
- Will typically have policies (either formal or informal) on the use of open source
- Preconditions:
- Access to souce code tree by auditor
- Main Success Scenario:
- Source code is analyzed by the auditor and the origin for code and associated license is created
- Policy violations are identified to the file (at least) level
- Information on the audit is provided in an SPDX file + additional information (e.g. report) [the additional, external report would for example be able to reference items in the SPDX file, and externally capture which company policy is being violated and how]
- Remediations are made to the source to comply with the policy
- Source code is re-analyzed and an SPDX file describing the compliant code is produced
- Failed End Condition:
- Trigger:Audit
- Notes: A data element missing from SPDX 1.x which may be generally needed to establish policy violations is "Code Usage information (e.g. statically vs. dynamically linked)"
- Example: Company has a policy not to deploy any GPL code compiled into their proprietary commercial software. Audit is performed to identify any GPL code and comply with the policy prior to a product release.