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/Low cost SPDX file"

From SPDX Wiki
Jump to: navigation, search
Line 23: Line 23:
 
<li>Lax SPDX consumer downloads tar ball and its SPDX file.</li>
 
<li>Lax SPDX consumer downloads tar ball and its SPDX file.</li>
 
<li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li>
 
<li>Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.</li>
 +
</ol>
 +
 +
<h3>Alternate scenario A</h3>
 +
 +
<ol>
 +
<li>Project maintainer hears about SPDX and decides to implement it for his project.</li>
 +
<li>Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.</li>
 +
<li>Project maintainer publishes limited SPDX file along side the tar ball.</li>
 +
<li>Strict SPDX consumer downloads tar ball and its SPDX file.</li>
 +
<li>Strict SPDX consumer reads the SPDX file and notes its incompleteness.</li>
 +
<li>Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.</li>
 
</ol>
 
</ol>

Revision as of 21:03, 23 May 2012

As a maintainer of an open source project i might be willing to create and maintain an SPDX file if it where simple and easy enough to do so. Maintaining data for each and every file in every package ever produced sounds like a lot of work because those files change a lot. I would like to give my users the information they need to comply with my licensing, though. An SPDX file that describes the package but omits all the file level information sounds just about right.

Stakeholders and interests

  • Project maintainer

    Wants to produce machine readable licensing information so that users can more easily adopt the package but does not want to "waste" valuable time creating that data rather than implementing features.

  • Lax SPDX consumer

    A person or organization that uses SPDX data to accomplish goals that do not require exhaustive file by file data.

  • Strict SPDX consumer

    A person or organization that uses SPDX data to accomplish goals that require exhaustive data on every file.

Main scenario

  1. Project maintainer hears about SPDX and decides to implement it for his project.
  2. Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.
  3. Project maintainer publishes limited SPDX file along side the tar ball.
  4. Lax SPDX consumer downloads tar ball and its SPDX file.
  5. Lax SPDX consumer uses the package level licensing information to ensure they are in compliance with the licensing of the package.

Alternate scenario A

  1. Project maintainer hears about SPDX and decides to implement it for his project.
  2. Project maintainer creates SPDX file that describes his package (name, description, licenseDeclared, licenseConcluded, checksum, etc) but does not included information about the files in package and does not generate packageVerificationCode.
  3. Project maintainer publishes limited SPDX file along side the tar ball.
  4. Strict SPDX consumer downloads tar ball and its SPDX file.
  5. Strict SPDX consumer reads the SPDX file and notes its incompleteness.
  6. Strict SPDX consumer initiates procedures to do a deeper analysis on the package so that its goals can be accomplished.