SPDX Project Governance Policy 1.0

This document provides the governance policy for the SPDX Project. It is derived from the Community Specifications Governance Policy 1.0.

1. Teams

The SPDX Project includes one or more "Teams", each of which is a separate workstream involved in the development and maintenance of aspects of the SPDX specification, software and other content. The Teams include:

Technical Team: maintains and publishes the SPDX Specifications and tools
Legal Team: maintains and publishes the SPDX License List and associated collateral
Outreach Team: promotes the use of SPDX by the broader community and ecosystem

The Steering Committee may from time to time establish additional Teams, modify the roles of existing Teams, or disband Teams.

2. Roles, Responsibilities, and Terms.

The Project may include the following roles. Additional roles may be adopted and documented by the Steering Committee.

2.1. Participants. "Participants" are those persons that have made Contributions to the Working Group subject to the Community Specification License, or otherwise contributed to or particpated in the Project.

2.2. Members. “Members” are those entities that have agreed to and signed the SPDX Project Membership Agreement and are current members of The Linux Foundation. Each Member may nominate one person from their organization as a candidate for selection to serve as a Member Representative on the Steering Committee.

2.3. Team Lead. Each Team will have one to three Team Leads. "Team Leads" are responsible for organizing activities of a particular Team around developing, maintaining, and updating the materials developed by that Team. Team Leads are also responsible for determining consensus and coordinating appeals. Team Leads should have the approprate background or training for their specific role. Examples of the responsibilities of a Team Lead (directly or by delegation) include:

setting the agenda, scheduling meetings and keeping minutes
leading the Team meetings and tracking progress
reporting about Team progress to the community on general calls
updating the Team section of the SPDX website as needed
presenting and attending face-to-face SPDX meetings
educating new Participants in the Team
manage the day-to-day planning, operation, organization, deliverables and alignment with other Teams
representing their Team on the Steering Committee and in discussions with other Teams
ensuring that the contents of a Team's materials accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines

2.4. Chair. The "Chair" is responsible for organizing the general calls, including sending the invite, posting minutes, and coordinating guest speakers.

2.5. Steering Committee. The "Steering Committee" is the body that is responsible for governing the SPDX Project. The Steering Committee consists of (i) the Chair; (ii) the Team Leads; and (ii) up to two Member Representatives. The Steering Committee will meet regularly as needed, but no less then once per quarter. Examples of the responsibilities of the Steering Committee include:

enable the smooth running of the SPDX Project
coordinating activities between the Teams
participating in strategic planning, such as coordinating face-to-face meetings or suggesting and approving changes to the governance model
creating or restructuring Teams
responding to specific issues or concerns above and beyond the domain of the various Teams
making decisions when community consensus cannot be reached, pursuant to the appeal process documented below
adopting and maintaining policies or rules and procedures for the Project (subject to LF approval) as appropriate, such as a Code of Conduct, trademark policy, and any compliance or certification policies
overseeing and making decisions regarding use of funding allocated to the SPDX Project, including delegating such oversight to Participants that the Steering Committee designates for particular uses

2.6. Team Lead and Chair Terms. During the initial year, the Steering Committee will group the Team Leads and Chair into two groups, one to serve an initial two-year term, and the other for an initial one-year term. Thereafter, the Team Leads will serve two year terms and Chair will serve a one year term.

At the expiration of a Team Lead term, any Participant may submit a nomination for a Team Lead role.

At the expiration of a Team Lead term, or if a Team Lead or the Chair resigns or ceases to participate prior to the end of their term, the Steering Committee will determine whether and when to fill the role.

The Steering Committee may add additional Team Leads as it deems necessary up to the maximum number of Team Leads for a Team as stated above.

At the expiration of a Chair term, the Steering Committee will then choose a Chair from among the Team Leads and Member Representatives.

After discussion with the nominees, the Steering Committee will select the Team Leads from the group of (as applicable) nominees taking into account such things as the nominees’ willingness to take on the role, skills, and level of participation as well as the need to maintain a balanced perspective on the Steering Committee (e.g., no more than two people from the same group of related companies should be on the Steering Committee). A Team Lead nominee may not deliberate or vote on their own appointment. An individual may serve for any number of terms if chosen by the Steering Committee.

2.7. Member Representative Terms. The initial Member Representatives will be selected by the Team Leads and Chair from among nominees made by Members during the initial four months and serve a one year term. At the end of the term or resignation of a Member Representative, Members may submit nominations to the Steering Committee according to the process set forth by the Steering Committee. Each subsequent term for each Member Representative will be for a period of one year, adjusting to align with the Member term as needed.

3. Decision Making.

3.1. Consensus-Based Decision Making. Teams make decisions through a consensus process ("Approval" or "Approved"). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Team Lead will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Team Participants and nature of support and objections. A Team Lead will document evidence of consensus in accordance with these requirements.

3.2. Team Lead Appeal Process. Decisions may be appealed be via a pull request or an issue, and that appeal will be considered by the applicable Team Leads in good faith, who will respond in writing within a reasonable time.

3.3. Steering Committee Appeal Process. Decisions that have been appealed to the Team Leads may in extraordinary cases be appealed to the Steering Committee for reconsideration. An appeal to the Steering Committee must specify in detail (1) the specific decision that is being appealed; (2) the basis for contending that the decision was not aligned with the purposes, goals or scope of SPDX; and (3) an explanation of why the decision is extraordinary enough to warrant an appeal to the Steering Committee. The appeal will be considered by the Steering Committee in good faith, who will respond in writing within a reasonable time. The Steering Committee may decline to consider appeals that are unexceptional, unfounded or excessive, including because of their repetitive character.

3.4. Amendments to Governance Documents. The documents in this Governance repository may be amended by a two-thirds vote of the entire Steering Committee and are subject to approval by The Linux Foundation. However, entries may be added to the Notices file in this Governance repository as described therein.

4. Ways of Working.

Inspired by ANSI’s Essential Requirements for Due Process, the SPDX Working Group and Teams must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of the SPDX Specification. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus.

4.1. Openness. Participation is open to all persons who are directly and materially affected by the activity in question. There will be no undue financial barriers to participation. Voting membership on the consensus body will not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required.

4.2. Lack of Dominance. The development process will not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.

4.3. Balance. The development process should have a balance of interests. Participants from diverse interest categories will be sought with the objective of achieving balance.

4.4. Coordination and Harmonization. Good faith efforts will be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.

4.5. Consideration of Views and Objections. Prompt consideration will be given to the written views and objections of all Participants.

4.6. Written procedures. This governance document and other materials documenting the SPDX Specification development process are available to any interested person.

5. Specification Development Process.

The following describes the public process by which new versions of the SPDX Specification as a whole can be transitioned from Draft Specification to Approved Specification status. Other portions of the SPDX project, such as the SPDX License List, will follow development and release processes as documented in their respective repositories.

5.1. Draft. During the specification development process, Participants may submit issues and pull requests to the SPDX Specification repository. Pull requests will be merged upon Approval of the applicable Team. Each updated version of the SPDX Specification following the merging of a pull request will be considered a "Draft Specification".

5.2. Process for Approved Specification status. Upon the determination by the applicable Team that it has achieved the objectives for its specification as described in the Scope, the Team will Approve that Draft Specification as a candidate for "Approved Specification" status. The following process will then be used:

A Team Lead will distribute that version of the Draft Specification to the Working Group's general mailing list.
The Team Lead will state in the distribution that the Draft Specification is a candidate for "Approved Specification" status, and will announce the start of a two-week review period (the "Review Period").
During the Review Period, Participants may raise any issues regarding the Draft Specification. Such issues will be considered and resolved in the ordinary course.
The Team Leads may, in their discretion, extend the Review Period for a longer period of time, but will not shorten it to be less than the initial two-week period.
After the completion of the Review Period and upon the Approval of the Working Group (which may include the absence of, or resolution in the ordinary course of, any issues raised during the Review Period), the Draft Specification will be progressed to be an "Approved Specification".

5.3. Publication and Submission. Upon the designation of a Draft Specification as an Approved Specification pursuant to the above process, the Team Lead will publish the Approved Specification in a publicly available location, including the terms under which the Approved Specification is being made available.

5.4. Submissions to Standards Bodies. No Draft Specification or Approved Specification may be submitted to another standards development organization without Working Group Approval. Upon reaching Approval, the Team Lead will coordinate the submission of the applicable Draft Specification or Approved Specification to another standards development organization. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions.

6. Non-Confidential, Restricted Disclosure.

Information disclosed in connection with any Working Group or Team activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Steering Committee meeting minutes will be published in summary form, as appropriate (e.g., sensitive matters may not be made public). If the Working Group or a Team is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group or Team.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!