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 SPDX data for the patch indicating it is licensed however the hell its applied"

From SPDX Wiki
Jump to: navigation, search
Line 1: Line 1:
−
<ol style="color: #4d4d4d; font-family: Arial, Helvetica, sans-serif; font-size: 13px;"><li><strong>Title:</strong>&nbsp;Patch provider provides SPDX data for the patch indicating it licensed matching whatever files it applies to.</li><li><strong>Primary Actor:</strong>&nbsp;Patch Provider</li><li><strong>Goal in Context:</strong>&nbsp;To indicate the licensing information as SPDX data for the patch.</li><li><strong>Preconditions:</strong>&nbsp;<ol><li>Committer simply wants his patch to have licensing information matching the code it's applied to.</li></ol></li><li><strong>Stakeholders and Interests:</strong>&nbsp;<ol><li><strong>Patch Provider:</strong>&nbsp;<ol><li>To communicate that the patch should be licensed the same way as the code it applies to.</li></ol></li><li><strong>Upstream maintainers:&nbsp;</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.&nbsp;</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>&nbsp;Patch supplier communicates that their patch is licensed matching the licenses of the files it is applied to.</li><li><strong>Failed End Condition:</strong>&nbsp;Patch supplier communicates inaccurate incomplete licensing information for their patch.</li><li><strong>Trigger:</strong><ol><li>Creation of a patch</li></ol></li><li><strong>Notes:</strong>&nbsp; This probably involves work with the legal group around an ASLICENSEDAS-1.0 short form, which would involve drafting a license indicating this, and such a license should probably exclude intentional indications of other licenses (say if the patch actually changed license information in the files deliberately).</li></ol>
+
<ol style="color: #4d4d4d; font-family: Arial, Helvetica, sans-serif; font-size: 13px;"><li><strong>Title:</strong>&nbsp;Patch provider provides SPDX data for the patch indicating it licensed matching whatever files it applies to.</li><li><strong>Primary Actor:</strong>&nbsp;Patch Provider</li><li><strong>Goal in Context:</strong>&nbsp;To indicate the licensing information as SPDX data for the patch.</li><li><strong>Preconditions:</strong>&nbsp;<ol><li>Committer simply wants his patch to have licensing information matching the code it's applied to.</li><li>(the code being patched may likely not even have SPDX data with it to begin with)</li></ol></li><li><strong>Stakeholders and Interests:</strong>&nbsp;<ol><li><strong>Patch Provider:</strong>&nbsp;<ol><li>To communicate that the patch should be licensed the same way as the code it applies to.</li></ol></li><li><strong>Upstream maintainers:&nbsp;</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.&nbsp;</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>&nbsp;Patch supplier communicates that their patch is licensed matching the licenses of the files it is applied to.</li><li><strong>Failed End Condition:</strong>&nbsp;Patch supplier communicates inaccurate incomplete licensing information for their patch.</li><li><strong>Trigger:</strong><ol><li>Creation of a patch</li></ol></li><li><strong>Notes:</strong>&nbsp; This probably involves work with the legal group around an ASLICENSEDAS-1.0 short form, which would involve drafting a license indicating this, and such a license should probably exclude intentional indications of other licenses (say if the patch actually changed license information in the files deliberately).</li></ol>

Revision as of 18:30, 26 June 2012

  1. Title: Patch provider provides SPDX data for the patch indicating it licensed matching whatever files it applies to.
  2. Primary Actor: Patch Provider
  3. Goal in Context: To indicate the licensing information as SPDX data for the patch.
  4. Preconditions: 
    1. Committer simply wants his patch to have licensing information matching the code it's applied to.
    2. (the code being patched may likely not even have SPDX data with it to begin with)
  5. Stakeholders and Interests: 
    1. Patch Provider: 
      1. To communicate that the patch should be licensed the same way as the code it applies to.
    2. Upstream maintainers: 
      1. To be able to document the license information for the patches they receive
      2. To have a paper trail of the licensing information for their project. 
      3. To have their licenses respected
    3. Third party patch appliers (think Yocto):
      1. To be able to know whether or not they have licensing issues when they apply a patch to upstream.
    4. Consumers of upstream source:
      1. To receive accurate and clear information of licensing of upstream source
      2. To be able to comply easily with licenses for upstream source
      3. To be able to subset, extend, or aggregate artifacts and pass on clear authoritative verifiable license for the resulting new copyrightable artifacts.
  6. Main Success Senario: Patch supplier communicates that their patch is licensed matching the licenses of the files it is applied to.
  7. Failed End Condition: Patch supplier communicates inaccurate incomplete licensing information for their patch.
  8. Trigger:
    1. Creation of a patch
  9. Notes:  This probably involves work with the legal group around an ASLICENSEDAS-1.0 short form, which would involve drafting a license indicating this, and such a license should probably exclude intentional indications of other licenses (say if the patch actually changed license information in the files deliberately).
Retrieved from "https://wiki.spdx.org/index.php?title=Technical_Team/Use_Cases/2.0/Patch_provider_provides_SPDX_data_for_the_patch_indicating_it_is_licensed_however_the_hell_its_applied&oldid=1808"