The following is an archive of the SPDX Governance model prior to September 2021, which is no longer in effect. It is archived here for historical purposes.
See the SPDX Governance page for information about the current SPDX Governance model.
Prior SPDX Governance Model
The SPDX Governance model is based on the Meritocratic Governance model used by the Apache Software Foundation as described at OSS Watch.
SPDX® Governance Document – November 2012
0. Overview
SPDX (or Software Package Data Exchange®) is an open source project with the following goals: 1) To create an industry standard for reporting and exchanging license/copyright information and 2) build a trust relationship between different players in the software/open source ecosystem and in software supply chains.
SPDX operates much like a meritocratic, consensus-based community project[1]. Anyone with an interest in the project can join the community, contribute to the specification, and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the project community.
1. Roles and responsibilities
1.1. Users
The SPDX Community consists of those companies, individuals, or groups who use or are considering using the SPDX specification. They are important members of the community and without them the project would have no purpose. Whether as individuals or as part of an organization, SPDX users have a need to communicate in a standard way the content and licensing information for software they give to or receive from others. That said, anyone can be a user; and there are no special requirements.
The project asks its users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include:
- using the SPDX specification to describe the content and licensing of their software
- Submit bug reports/code contributions to the tools following the development process set in place
- evangelizing about SPDX (e.g. giving a talk at a conference, a link on a website and word-of-mouth awareness raising)
- informing contributors of strengths and weaknesses from a new user perspective
- Join SPDX track at Linux Foundation conferences
- providing moral support (a ‘thank you’ goes a long way)
- potentially providing financial support (currently SPDX operates with no budget, but it may eventually need one)
Users may be interested in being on the SPDX General Mailing List and participating in General Meetings to monitor the progress of the project. Community members may also join an SPDX Team.
1.2. Team Members
Team Members are community members who contribute in concrete ways to one more of the SPDX teams: Technical, Business and Legal. The respective responsibilities and activities of each team is outlined on the SPDX website. Anyone can become a Team Member.
Although there is no concrete expectation of participation, Team Member contributions are what enables the SPDX project to move forward and progress. Participation can take many forms but could include:
- contact the lead(s) of the team(s) you want to contribute to, get briefed on current state of affairs, and where help is needed the most.
- join the mailing lists and participate in the discussions.
- attend the calls (if the case) as scheduled by the various teams.
- submit feedback on the specifications following the process set in place.
- submit bug reports/code contributions to the tools following the development process set in place.
- submit new use cases, or feedback on existing ones
- join SPDX track at Linux Foundation conferences.
- create content for SPDX: papers, web site improvements, blogs, etc.
- create SPDX files for your favorite open source projects
There are no specific skill requirements and no selection process. Anyone can join a team simply by signing up for the team mailing list.
1.3. Team Leads
The activities of each team are coordinated by Team Lead(s). Team Leads are critical to advancing the project. They drive the direction of their respective teams by coordinating and facilitating the activities, tasks, and meetings for the SPDX team for which they are charged. Common Team Lead responsibilities include (directly or by delegation):
- setting the agenda, schedule meetings and keep minutes.
- leading the team meetings and tracking progress
- reporting about team progress to the Chairman on general calls
- updating the team section of the SPDX website as needed
- presenting and attending face-to-face SPDX meetings
- educating new Team Members
- manage the day-to-day planning, operation, organization, deliverables and alignment with other SPDX teams
- representing their team on the Core Team and other SPDX teams
These individuals can be nominated by Team Members or members of the Core Team. After discussion with the nominees, Team Leads are appointed by the Core Team 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 Core Team (e.g. there should not be more than one Team Lead from the same organization or company). Once someone has been appointed Team Lead, they remain in that role until they choose to retire or the Core Team casts a two-thirds majority vote to remove them. Team Leads have no additional authority over other members of the team.
1.4. Core Team
The Core Team is made up of the Team Leads and the Chairman. Members of the Core Team recommend and appoint new Team Leads and Chairman. A nomination for a new Team Lead or Chairman will result in discussion and then a vote by the existing Core Team members. Core Team membership votes are subject to consensus approval of the current Core Team members.
The Core Team is responsible for the smooth running of the SPDX project and coordinating activities between the teams. In addition, Core Team members are expected to make substantial contributions to the SPDX project. Contributions may include amongst other activities:
- reviewing the spec
- 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
The Core Team will make decisions when community consensus cannot be reached. In addition, the Core Team may maintain a private mailing list and archives. This list is used for sensitive issues, such as votes for Team Leads and legal matters that cannot be discussed in public. It is never used for project management or planning. That being said, Core Team members do not have significant authority over other members of the community.
1.5. Chairman
The Chairman leads Core Team meetings and also coordinates and leads General Meetings. Once someone has been appointed Chairman, they remain in that role until they choose to retire, or the Core Team casts a two-thirds majority vote to remove them.
The Chairman has no additional authority over other members of the Core Team: the role is one of coordinator and facilitator. The Chairman is expected to ensure that all governance processes are adhered to and has the casting vote when the project fails to reach consensus.
2. Support
All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. However, for those willing to engage with the project on its own terms, and willing to help support other users, the technical team mailing list is ideal.
3. Contributions
There are many ways to contribute as per above. Contributions to the specification, tools, website, and any other contribution to the SPDX project are governed under the relevant licensing guidelines and terms of use of the SPDX website.
4. Decision making process
Decisions about the future of the project are made within the teams’ respective areas through discussion with all members of the team who wish to participate in the discussion, from the newest user to the most experienced Core Team member. All non-sensitive project management discussion takes place in team meetings and on mailing lists.
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
4.1. Lazy consensus
Decision making typically involves the following steps:
- Proposal
- Discussion
- Vote (if consensus is not reached through discussion)
- Decision
Any team member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to a team mailing list or enter the idea to the SPDX issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval.
In general, as long as nobody explicitly opposes a proposal, it is recognized as having the support of the community. This is called lazy consensus – that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.
Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone in support of a proposal need not spend time stating their position, and others need not spend time reading such mails.
For lazy consensus to be effective, it is necessary to allow at least one week before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest, and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.
4.2. Voting
Not all decisions can be made using lazy consensus. There will be some issues about which there is legitimate disagreement that must be resolved by a vote. For these issues, the Team Lead will initiate a vote via the team’s email list and will specify date by which team members must vote via the list, allowing a minimum of one week for deliberation. Every member of the community is encouraged to express their opinion. The Team Lead will determine the result by a simple majority of those who voted. If for any reason a team cannot resolve an issue, it may invoke the assistance of the Core Team to resolve.
4.3. Changes in Governance
Changes in governance are handled as follows: Any member may propose changes to the governance model by submitting a proposed update to the language in this document to the Chairman. Within one week of receipt of the proposal, the Chairman will distribute the proposal to the full membership for comment on the General Meeting mailing list. Within three weeks of the distribution, the Chairman will convene a General Meeting to discuss. The change may be accepted or rejected by consensus, but if consensus is not reached, the Chairman will put the matter to a vote via the General Mailing list allowing two weeks for response. A vote to change the governance model requires a 2/3 majority of those who vote.
