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/Patch provider provides patch subject to existing SPDX data of project"
From SPDX Wiki
Bschineller (Talk | contribs) |
|||
Line 1: | Line 1: | ||
− | <ol style="color: #4d4d4d; font-family: Arial, Helvetica, sans-serif; font-size: 13px;"><li><strong>Title:</strong> Patch provider provides patch subject to existing SPDX data of project</li><li><strong>Primary Actor:</strong> Patch Provider</li><li><strong>Goal in Context:</strong> To indicate the licensing the patch is licensed subject to the specific SDPX data of the project.</li><li><strong>Preconditions:</strong> <ol><li>Committer simply wants his patch to have licensing information matching the project its applied to.</li><li>The project to which the patch applies has existing SPDX data to refer to.</li></ol></li><li><strong>Stakeholders and Interests:</strong> <ol><li><strong>Patch Provider:</strong> <ol><li>To communicate that the patch should be licensed the same way as the overall project it's contributed to by referencing the projects SPDX data.</li></ol></li><li><strong>Upstream maintainers: </strong><ol><li>To be able to document the license information for the patches they receive</li><li>To have a paper trail of the licensing information for their project. </li><li>To have their licenses respected</li></ol></li><li><strong>Third party patch appliers (think Yocto):</strong><ol><li>To be able to know whether or not they have licensing issues when they apply a patch to upstream.</li></ol></li><li><strong>Consumers of upstream source:</strong><ol><li>To receive accurate and clear information of licensing of upstream source</li><li>To be able to comply easily with licenses for upstream source</li><li>To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.</li></ol></li></ol></li><li><strong>Main Success Senario:</strong> Patch supplier communicates that their patch is licensed matching the SPDX data specified for the project.</li><li><strong>Failed End Condition:</strong> Patch supplier | + | <ol style="color: #4d4d4d; font-family: Arial, Helvetica, sans-serif; font-size: 13px;"><li><strong>Title:</strong> Patch provider provides patch subject to existing SPDX data of project</li><li><strong>Primary Actor:</strong> Patch Provider</li><li><strong>Goal in Context:</strong> To indicate the licensing the patch is licensed subject to the specific SDPX data of the project.</li><li><strong>Preconditions:</strong> <ol><li>Committer simply wants his patch to have licensing information matching the project its applied to.</li><li>The project to which the patch applies has existing SPDX data to refer to.</li></ol></li><li><strong>Stakeholders and Interests:</strong> <ol><li><strong>Patch Provider:</strong> <ol><li>To communicate that the patch should be licensed the same way as the overall project it's contributed to by referencing the projects SPDX data. </li></ol></li><li><strong>Upstream maintainers: </strong><ol><li>To be able to document the license information for the patches they receive</li><li>To have a paper trail of the licensing information for their project. </li><li>To have their licenses respected</li></ol></li><li><strong>Third party patch appliers (think Yocto):</strong><ol><li>To be able to know whether or not they have licensing issues when they apply a patch to upstream.</li></ol></li><li><strong>Consumers of upstream source:</strong><ol><li>To receive accurate and clear information of licensing of upstream source</li><li>To be able to comply easily with licenses for upstream source</li><li>To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.</li></ol></li></ol></li><li><strong>Main Success Senario:</strong> Patch supplier communicates that their patch is licensed matching the SPDX data specified for the project.</li><li><strong>Failed End Condition:</strong> Patch supplier communicates inaccurate incomplete licensing information for their patch.</li><li><strong>Trigger:</strong><ol><li>Creation of a patch</li></ol></li></ol> |
Revision as of 18:28, 26 June 2012
- Title: Patch provider provides patch subject to existing SPDX data of project
- Primary Actor: Patch Provider
- Goal in Context: To indicate the licensing the patch is licensed subject to the specific SDPX data of the project.
- Preconditions:
- Committer simply wants his patch to have licensing information matching the project its applied to.
- The project to which the patch applies has existing SPDX data to refer to.
- Stakeholders and Interests:
- Patch Provider:
- To communicate that the patch should be licensed the same way as the overall project it's contributed to by referencing the projects SPDX data.
- Upstream maintainers:
- To be able to document the license information for the patches they receive
- To have a paper trail of the licensing information for their project.
- To have their licenses respected
- Third party patch appliers (think Yocto):
- To be able to know whether or not they have licensing issues when they apply a patch to upstream.
- Consumers of upstream source:
- To receive accurate and clear information of licensing of upstream source
- To be able to comply easily with licenses for upstream source
- To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
- Patch Provider:
- Main Success Senario: Patch supplier communicates that their patch is licensed matching the SPDX data specified for the project.
- Failed End Condition: Patch supplier communicates inaccurate incomplete licensing information for their patch.
- Trigger:
- Creation of a patch