Skip to content

CHARTER.md

Latest commit

 

History

History
126 lines (71 loc) · 11.3 KB

CHARTER.md

File metadata and controls

126 lines (71 loc) · 11.3 KB

OpenSSF ORBIT WG Technical Charter

Open Resources for Baselines, Interoperability, and Tooling (ORBIT) Working Group

Adopted 18 April 2025

This Technical Charter sets forth the responsibilities and procedures for technical contribution to, and oversight of, the ORBIT open source community, which has been established as a Working Group (the "WG") under the Open Source Security Foundation (the “OpenSSF”). All contributors (including committers, maintainers, and other technical positions) and other participants in the WG (collectively, “Collaborators”) must comply with the terms of this Technical Charter and the OpenSSF Charter.

1. Mission and Scope

  • a. The mission of the WG is to develop and maintain interoperable resources related to the identification and presentation of security-relevant data.

  • b. The scope of the WG includes collaborative development under the WG License (as defined herein) supporting the mission, including organizing collaboration activities, defining best practices, documentation, testing, integration, and the creation of other artifacts that support the mission.

  • c. Participation in the WG through attendance or contribution is open to anyone, whether an OpenSSF member or not, so long as they abide by the terms of this Technical Charter.

2. Technical Steering Committee

  • a. The Technical Steering Committee (the "TSC") will be responsible for all oversight of the WG and reporting to the OpenSSF’s Technical Advisory Council (the "TAC").

  • b. The TSC is composed of a single lead from each Technical Initiative in the WG, documented in the charter of the respective Technical Initiative.

  • c. Participation in a call for consensus is open to anyone in the technical community that contributes text, source code, documentation or other artifacts in the source repository of the WG or any of its Technical Initiatives.

  • d. The TSC may create, change, modify, or remove roles or their definitions, so long as the definitions of roles for the WG are publicly available in the WG repository.

  • e. The TSC will be responsible for all aspects of oversight relating to the WG, which may include:

    • i. coordinating the direction of the WG;
    • ii. approving, organizing or removing activities;
    • iii. establish community norms, workflows, processes, release requirements, and templates for the operation of the WG;
    • iv. appointing representatives to work with other open source or open standards communities;
    • v. approving and implementing policies and processes for contributing (to be published in the WG repository) and coordinating with the Linux Foundation to resolve matters or concerns that may arise as set forth in Section 6 of this Technical Charter;
    • vi. facilitating discussions, seeking consensus, and where necessary, voting on technical matters relating to the WG; and
    • vii. coordinating any communications regarding the WG.

  • f. The TSC may elect a TSC Chair, who will preside over meetings of the TSC and will serve until their resignation or replacement by the TSC. The TSC Chair will serve as the WG’s voting representative on the TAC. In the event that a proxy is requested by the TSC Chair, it may be any other TSC member so designated by a silent consensus of the TSC.

  • g. The current TSC Chair is:

    • Eddie Knight, Sonatype (@eddie-knight)

3. Technical Initiatives

  • a. A Technical Initiative is a project or special interest group (SIG) that falls under the oversight of this working group at creation or was subsequently added to this section of the charter.

    • No other work streams, activities, or bodies of any kind are considered Technical Initiatives, regardless of their affiliation with the WG.

  • b. Technical Initiatives must have a clearly identified lead who, for voting purposes, is not a lead on another ORBIT WG Technical Initiative.

    • i. Leads will report to and participate in the routine activities of the TSC.
    • ii. Leads may nominate their own replacement at any time, subject to the charter of the Technical Initiative.
    • iii. In the event that the TSC elects to remove an acting lead, it must appoint a replacement in the same election.

  • c. A new Technical Initiative should only be brought into the WG after it is confirmed to be topically relevant, and interoperable with no less than two other Technical Initiatives in the WG. Acceptance must be confirmed on the proposal with a 2/3 majority approval from the Technical Steering Committee. That proposal must include an update to this document.

    • i. Interoperability is determined by the acceptance of outputs from one project as inputs to the core feature set of another.
    • ii. A project is considered interoperable if it accepts input from another project or if it provides output that is accepted as input to another project.

  • d. A Technical Initiative may be de-scoped or archived for any reason following confirmation on the proposal with a 2/3 majority approval from the Technical Steering Committee. That proposal must include an update to this document.

Active Technical Initiatives

Technical Initiative Lead
Open Source Project Security Baseline Ben Cotton (@funnelfiasco)
Open Source Project Security Assessments John Kjell (@jkjell)
Security Insights Specification Eddie Knight (@eddie-knight)
Gemara Jennifer Power (@jpower432)
ORBIT Tooling Travis Truman (@trumant)

4. TSC Voting

  • a. While the WG aims to operate as a consensus-based community, if any TSC decision requires a vote to move the WG forward, the voting members of the TSC will vote on a one vote per voting member basis.

  • b. Quorum for a live vote requires at least fifty percent of all voting members of the TSC to be present.

  • c. Any TSC member may determine that a decision requires a community consensus or TSC vote, while others may always require a vote by nature of this charter or by custom of the WG.

  • d. Bypassing a vote required by charter or well-established custom is grounds for removal from the TSC, subject to either a TSC vote or community consensus.

  • f. In the event a vote cannot be resolved by the TSC, any voting member of the TSC may refer the matter to the TAC for assistance in reaching a resolution.

5. Compliance with Policies

  • a. This Technical Charter is subject to the OpenSSF Charter and any rules or policies established for all WGs.

  • b. The WG participants must conduct their business in a professional manner, subject to the Contributor Covenant Code of Conduct 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct. The TSC may adopt a different code of conduct ("CoC") for the WG, subject to approval by the TAC.

  • c. All Collaborators must allow open participation from any individual or organization meeting the requirements for contributing under this Technical Charter and any policies adopted for all Collaborators by the TSC, regardless of competitive interests. Put another way, the WG community must not seek to exclude any participant based on any criteria, requirement, or reason other than those that are reasonable and applied on a non-discriminatory basis to all Collaborators in the WG community. All activities conducted in the WG are subject to the Linux Foundation’s Antitrust Policy, available at https://www.linuxfoundation.org/antitrust-policy.

  • d. The WG will operate in a transparent, open, collaborative, and ethical manner at all times. The output of all WG discussions, proposals, timelines, decisions, and status should be made open and easily visible to all. Any potential violations of this requirement should be reported immediately to the TAC.

6. Community Assets

  • a. The Linux Foundation will hold title to all trade or service marks used by the WG ("WG Trademarks"), whether based on common law or registered rights. WG Trademarks may be transferred and assigned to LF WGs to hold on behalf of the WG. Any use of any WG Trademarks by Collaborators in the WG will be in accordance with the trademark usage policy of the Linux Foundation, available at https://www.linuxfoundation.org/trademark-usage, and inure to the benefit of the Linux Foundation.

  • b. The Linux Foundation or WG must own or control the repositories, social media accounts, and domain name registrations created for use by the WG community.

  • c. Under no circumstances will the Linux Foundation be expected or required to undertake any action on behalf of the WG that is inconsistent with the policies or tax-exempt status or purpose, as applicable, of the Linux Foundation.

7. Intellectual Property Policy

  • a. Collaborators acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the WG.

  • b. Except as described in Section 6.c., all contributions to the WG are subject to the following:

    • i. All new inbound code contributions to the WG must be made using the Apache License, Version 2.0, available at https://www.apache.org/licenses/LICENSE-2.0 (the "WG License").

    • ii. All new inbound code contributions must also be accompanied by a Developer Certificate of Origin (http://developercertificate.org) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license;

    • iii. All outbound code will be made available under the WG License.

    • iv. Documentation will be received and made available by the WG under the Creative Commons Attribution 4.0 International License, available at http://creativecommons.org/licenses/by/4.0/.

    • v. To the extent a contribution includes or consists of data, any rights in such data shall be made available under the CDLA-Permissive 1.0 License.

    • vi. The WG may seek to integrate and contribute back to other open source projects ("Upstream Projects"). In such cases, the WG will conform to all license requirements of the Upstream Projects, including dependencies, leveraged by the WG. Upstream Project code contributions not stored within the WG’s main code repository will comply with the contribution process and license terms for the applicable Upstream Project.

  • c. The TSC may approve the use of an alternative license or licenses for inbound or outbound contributions on an exception basis. To request an exception, please describe the contribution, the alternative open source license(s), and the justification for using an alternative open source license for the WG. License exceptions must be approved by a two-thirds vote of the entire Governing Board.

  • d. Contributed files should contain license information, such as SPDX short form identifiers, indicating the open source license or licenses pertaining to the file.

8. Amendments

  • a. This charter may be amended by a two-thirds vote of the entire TSC and is subject to approval by the TAC.