THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
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
- Title: Patch provider provides SPDX data for the patch indicating it licensed matching whatever files it applies to.
- Primary Actor: Patch Provider
- Goal in Context: To indicate the licensing information as SPDX data for the patch.
- Preconditions:
- Committer simply wants his patch to have licensing information matching the code it's applied to.
- Stakeholders and Interests:
- Patch Provider:
- To communicate that the patch should be licensed the same way as the code it applies to.
- 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 licenses of the files it is applied to.
- Failed End Condition: Patch supplier doesn't communicates inaccurate incomplete licensing information for their patch.
- Trigger:
- Creation of a patch
- 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).