THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Technical Team/Use Cases/2.0/Collecting enough information to allow auditor to make recommendations to remove or not a component"

From SPDX Wiki
Jump to: navigation, search
Line 1: Line 1:
−
<ol><li><strong>Title:</strong> Collecting enough information to allow auditor to make recommendations to remove or not a component</li><li><strong>Primary Actor:</strong> Auditor of open source code</li><li><strong>Goal in Context:</strong> 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.</li><li><strong>Stakeholders and Interests: </strong></li><ol><li><p><strong>Consumer of the audit: </strong></p></li><ol><li>Organization which has an interest in the license obligations of the copyrighted materials</li><li>Will typically have policies (either formal or informal) on the use of open source</li></ol></ol><li><strong>Preconditions:</strong></li><ol><li>Access to souce code tree by auditor</li></ol><li><strong>Main Success Scenario:</strong></li><ol><li>Source code is analyzed by the auditor and the origin for code and associated license is created</li><li>Policy violations are identified to the file (at least) level</li><li>Information on the audit is provided in an SPDX file + additional information (e.g. report) [PLEASE BE MORE SPECIFIC WITH EXAMPLE OF TYPE OF ADDITIONAL INFO]</li><li>Remediations are made to the source to comply with the policy</li><li>Source code is re-analyzed and an SPDX file describing the compliant code is produced</li></ol><li><strong>Failed End Condition:</strong></li><li><strong>Trigger:</strong>Audit</li><li><strong>Notes:</strong>&nbsp;</li><li><strong>Example:</strong> Company has a policy not to deploy any GPL code compiled into their proprietary commercial software.&nbsp; Audit is performed to identify any GPL code and comply with the policy prior to a product release.</li></ol>
+
<ol><li><strong>Title:</strong> Collecting enough information to allow auditor to make recommendations to remove or not a component</li><li><strong>Primary Actor:</strong> Auditor of open source code</li><li><strong>Goal in Context:</strong> 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.</li><li><strong>Stakeholders and Interests: </strong></li><ol><li><p><strong>Consumer of the audit: </strong></p></li><ol><li>Organization which has an interest in the license obligations of the copyrighted materials</li><li>Will typically have policies (either formal or informal) on the use of open source</li></ol></ol><li><strong>Preconditions:</strong></li><ol><li>Access to souce code tree by auditor</li></ol><li><strong>Main Success Scenario:</strong></li><ol><li>Source code is analyzed by the auditor and the origin for code and associated license is created</li><li>Policy violations are identified to the file (at least) level</li><li>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]</li><li>Remediations are made to the source to comply with the policy</li><li>Source code is re-analyzed and an SPDX file describing the compliant code is produced</li></ol><li><strong>Failed End Condition:</strong></li><li><strong>Trigger:</strong>Audit</li><li><strong>Notes:</strong>&nbsp;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)"</li><li><strong>Example:</strong> Company has a policy not to deploy any GPL code compiled into their proprietary commercial software.&nbsp; Audit is performed to identify any GPL code and comply with the policy prior to a product release.</li></ol>

Revision as of 18:20, 9 October 2012

  1. Title: Collecting enough information to allow auditor to make recommendations to remove or not a component
  2. Primary Actor: Auditor of open source code
  3. 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.
  4. Stakeholders and Interests:

    1. Consumer of the audit:

      1. Organization which has an interest in the license obligations of the copyrighted materials
      2. Will typically have policies (either formal or informal) on the use of open source
  5. Preconditions:
    1. Access to souce code tree by auditor
  6. Main Success Scenario:
    1. Source code is analyzed by the auditor and the origin for code and associated license is created
    2. Policy violations are identified to the file (at least) level
    3. 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]
    4. Remediations are made to the source to comply with the policy
    5. Source code is re-analyzed and an SPDX file describing the compliant code is produced
  7. Failed End Condition:
  8. Trigger:Audit
  9. 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)"
  10. 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.
Retrieved from "https://wiki.spdx.org/index.php?title=Technical_Team/Use_Cases/2.0/Collecting_enough_information_to_allow_auditor_to_make_recommendations_to_remove_or_not_a_component&oldid=1767"