Our Pledge

We, as members, contributors, and leaders pledge to do our best to ensure that participating in work at OASIS Open is free of harassment for everyone, regardless of physical, personal, professional, or cultural characteristics.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, healthy, and productive community.

Our Standards

Examples of behavior that contributes to a positive environment for our communities include:

• Demonstrating empathy and kindness toward other people
• Being respectful of differing opinions, viewpoints, and experiences
• Accepting the consensus of the group after making our point if the collective decision does not go our way
• Giving and gracefully accepting constructive feedback
• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include, but are not limited to:

• The use of sexualized language or imagery, and sexual attention or advances of any kind
• Trolling, insulting or derogatory comments, and personal or political attacks
• Public or private harassment
• Publishing others’ private information, such as a physical or email address, without their explicit permission
• Other conduct which could reasonably be considered inappropriate in a professional setting
• Disparaging an organization, its activities, its employees, or its products and services within the context of OASIS-related activities

Enforcement Responsibilities

OASIS staff are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

OASIS staff have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. Staff may also take action to sanction behaviors that it judges to be in violation of this code of conduct, up to and including expelling individuals from a project if, in their judgment, the circumstances warrant it.

Decisions or actions by OASIS staff are subject to appeal to the OASIS Board of Directors.

Scope

This Code of Conduct generally applies to the actions of individuals. It applies both within online spaces and in public spaces when an individual is participating in or representing the project or its community. Examples include using an official project e-mail address or mailing list, posting via an official social media account or chat, participating in a project meeting, or representing the project or OASIS at an online or in-person event.

What are the boundaries of the OASIS community?

There are no hard boundaries of the community, but common places we are asked to extend guidance to are:

• Official project communication channels
• Events and meetups
• Media and web presences
• Social media

In some cases, where individual social media messages or other activities not related to a specific project are reported to the OASIS staff, we might choose to act.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the OASIS staff at code-of-conduct@oasis-open.org. All complaints will be reviewed and investigated promptly and fairly and in confidence and will result in a response that is deemed necessary and appropriate to the circumstances. All parties involved in an incident are obliged to maintain confidentiality with regard to the reporter and the accused. Further details of specific enforcement policies may be posted separately.

All community leaders are obligated to respect the privacy and security of the parties involved in the incident.

Enforcement Guidelines

OASIS staff will generally follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct, though they may escalate more quickly if the circumstances appear to warrant it:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from OASIS staff providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, via any OASIS-provided or maintained mechanism (ie email lists, Github, Slack, etc.) for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with members of the community via any OASIS-provided or maintained mechanism (ie email lists, Github, Slack, etc.) for a specified period of time, not to exceed one month. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of interaction within the community. Removal from community tools like repositories or chat groups.

Appeals

Actions taken by staff under this policy may be appealed to the OASIS Executive Director and the Board of Directors.

An appeal must be sent to the board comment list (oasis-board-comment@lists.oasis-open.org) within 30 days of the action being appealed. The Board shall hold a hearing within 45 days of receipt of the appeal. The Board shall render its decision within 30 days of the hearing. The decision of the Board shall be final.

The OASIS Board of Directors has the authority to effect such remedial action as may be necessary to remedy a complaint.

This version of the OASIS Committee Operations Process was approved by the OASIS Board of Directors on 22 July 2020 and became effective 01 December 2020. The change was announced in https://lists.oasis-open.org/archives/members/202011/msg00011.html 

The previous version, approved 22 May 2018 and effective immediately, can be found at https://www.oasis-open.org/policies-guidelines/oasis-committee-operations-process/oasis-committee-operations-process-2018-05-22/.

Table of Contents

1. Committees
1.1 Purpose of Committees
1.2 Committee Formation
1.3 Committee Membership and Participation
1.3.1 Technical Committees
1.3.2 Open Projects and Project Governing Board
1.3.3 Member Sections
1.4 Chairs
1.5 Committee Visibility and Transparency
1.5.1 Mail Lists
1.5.2 Web Pages
1.5.3 Announcements
1.6 Operations
1.7 Meetings
1.8 Voting
1.9 Closing a Committee

1. Committees

1.1 Purpose of Committees

Work at OASIS is done primarily through its committees. An OASIS committee is a group of Eligible Persons comprised of at least Minimum Membership, formed and conducted according to the provisions of this Committee Process, any other applicable policy document such as the OASIS TC Process for Technical Committees, the OASIS Open Project Rules, the OASIS Member Section Policy, or Roberts Rules of Order Newly Revised.

Each current version of the OASIS Committee Process applies to previously established committees upon its adoption.

Participation in the work of committees is open to any interested person subject to any specific requirements for the type of committee.

Defined terms in this document have the meaning provided in OASIS Defined Terms. Other OASIS policies may also apply depending on the type of committee. The complete set of OASIS policy documents can be found at https://www.oasis-open.org/policies-guidelines.

1.2 Committee Formation

The detailed requirements for starting a committee vary depending on the type of committee. In general, however, beginning a committee requires:

1.2.1 At least Minimum Membership of Eligible Persons committed to participating in the work,

1.2.2 A charter or equivalent founding document submitted to OASIS describing what the committee intends to do and other conditions pertinent to its operation, and

1.2.3 A sequence of steps followed by OASIS staff to publicize the committee, encourage others to join and participate, and set up its required infrastructure support.

For the specific requirements to start an OASIS Technical Committee, see the OASIS TC Process Section 1.2 TC Formation. For the specific requirements to start an OASIS Open Project, see the OASIS Open Project Rules. For the specific requirements to start an OASIS Member Section, see section 4 Creating a Member Section in the Member Section Policy.

1.3 Committee Membership and Participation

The work of a committee is conducted by Members who voluntarily contribute in one or more defined roles. The rules for joining the committee, the specific activities members can perform, the commitments they make, and requirements they must fulfill in order to participate vary depending on the type of committee. The roles for each type of committee are summarized in this section.

A committee Member is considered to have resigned from a committee upon sending notice of their resignation to the committees general email list. For some committees, formal resignation may have bearing upon ongoing commitments the member may have made upon joining the committee.

Persons who lose Eligible Person status shall have their committee membership terminated. Persons who lose Eligible Person status for reasons including, but not limited to, change of employment shall have up to 14 days of membership as an OASIS Individual Member in which to re-establish eligibility and continue participating in the committee. A Member shall lose membership on the 15th day after losing Eligible Person status if it is not re-established.

Termination of membership in an OASIS committee shall automatically end all rights and privileges of participation including any voting rights in that committee.

1.3.1 Technical Committees

Membership, participation requirements, voting rights and other aspects of participating in an OASIS Technical Committee (TC) are explained in the OASIS TC Process beginning at section Section 1.4 TC Membership and Participation.

TCs operate with four types of role: Observer, Member, Voting Member, or Persistent Non-Voting Members. The following table summarizes these roles.

1.3.2 Open Projects and Project Governing Board

Membership, participation requirements, voting rights and other aspects of participating in an OASIS Open Project and its Project Governing Board (PGB) are explained in the OASIS Open Project Rules beginning at Section 4 Participants and Contributors.

Open Projects operate with five types of role: Participant, Contributor, Maintainer, PGB Member, and Chair. The following table summarizes these roles.

1.3.3 Member Sections

An OASIS Member Section is a group within the consortium that advances the interests of a specific community or technology. The rules governing the formation, structure, and activities of a Member Section are explained in the Member Section Policy.

1.4 Chairs

Each committee must have a Chair or two co-Chairs. Only members of the committee are eligible to be Chair or co-Chair. A Chair is initially elected at the first meeting of a committee. The Chair is elected by Full Majority Vote of the committee. If a committee does not have a Chair then all activities, with the exception of the selection of a new Chair, are suspended. If a committee does not have a Chair for 120 days, the OASIS TC Administrator may close the committee.

The responsibilities of a Chair are as described in Roberts Rules of Order Newly Revised save for any specific responsibilities detailed in OASIS policy and rules documents.

The responsibilities of the Chair of a committee may be discharged by no more than two co-Chairs. The committee may vote at any time to elect a co-Chair, if only one Chair is seated, or to leave a second seat vacant. In the event that the Chair position is so shared each co-Chair is equally responsible for the Chair duties and responsibilities. Throughout this Committee Process, whenever a notification to the Chair is required, it must be made to both co-Chairs.

A committee Chair may be removed by action of the Board of Directors. A TC Chair may be removed at any time by a Special Majority Vote of the TC. A PGB Chair may be removed at any time by a Full Majority Vote of the PGB. In the event that a committee has co-Chairs, each may be removed individually or both may be removed by a single action.

A vacancy in chairing a committee shall be deemed to exist when (i) the Chair or one or both co-Chairs has been removed, (ii) the Chair or one or both co-Chairs has resigned the position, or (iii) the Chair or one or both co-Chairs ceases to be a member of the committee. Vacancies in chairing a committee shall be filled by election from the committee Members.

Every two years a Committee must re-appoint its chair(s). A call for candidates must be requested through the committee’s general email list inviting candidacy to be posted to that list. Committee members have 7 days after being notified to propose themselves as a candidate. All Committee members are eligible to apply including current and past chairs; no term limits apply. After the 7 Days candidacy period, if seats are contested, a ballot must be run to select the chair(s).

If no candidates come forward the work of the Committee must stop until a chair can be found.

For TCs, the timing of the process to re-appoint chairs should coincide with the TC Vitality check (Section 1.10) such that every four years the TC Charter and its chairs are reviewed.

Any provisions in the rules and policies applicable to a specific type of committee (such as Leaves of Absence for TCs) shall apply to the Chair or co-Chair of the committee in the same manner as they do to other committee members.

1.5 Committee Visibility and Transparency

The official copies of all resources of a committee and any associated subcommittees, including web pages, documents, email lists and any other records of discussions, must be located only on facilities designated by OASIS. Committees may not conduct official business or technical discussions, store documents, or host web pages on servers or systems not designated by OASIS. All web pages, documents, ballot results and email archives of all committees and subcommittees shall be publicly visible.

1.5.1 Mail Lists

Each committee shall be provided upon formation with a general discussion email list and a means to collect public comments.

All committee email lists shall be archived for the duration of the corporation, and all committee email archives shall be publicly visible.

For committees that hold meetings, the minutes of each meeting including a record of all decisions made shall be posted to that committee’s general email list.

The purpose of the committee’s public comment facility is to receive comments from the public. Comments shall be publicly archived.

1.5.2 Web Pages

OASIS shall provide each committee with a publicly accessible web page. The committee may keep the following information current on its web page: the committee name, charter, any standing rules and other adopted procedures, meeting schedules, anticipated deliverables and delivery dates, lists of members, the name and email address of the Chair or co-Chairs as well as other positions such as secretaries, editors, maintainers, etc., any subcommittees, links to the various works of the committee, and links to any IPR declarations made to the committee.

1.5.3 Announcements

OASIS shall maintain a publicly archived list for announcements from OASIS regarding its committees. Any Eligible Person shall be able to subscribe to this list. Every important change in committee status shall be posted to the announcement list. Such changes shall include but not be limited to: committee or project formation; committee charter revisions; start of public reviews; approval of work products such as Committee Specifications and Project Specifications; submission of specifications as a Candidate OASIS Standard; and approval or rejection of a proposed OASIS Standard.

1.6 Operations

Except where otherwise indicated by the rules and policies applicable to a specific type of committee, the operation of committees shall be governed by Robert’s Rules of Order Newly Revised, insofar as such rules are not inconsistent with or in conflict with this Committee Process, the OASIS Bylaws, other Board-approved policies, or with provisions of law. The duration of a committee shall be considered a single session. Formal actions of committees shall be governed by the same rules regardless of the language in which the work is taking place.

Standing rules may be adopted, amended, or rescinded by Full Majority Vote of a committee. The committee may not adopt standing rules or other Resolutions related to IPR, quorum requirements, membership, voting, participation, or that otherwise conflict with or supersede any OASIS Board-approved policy. Standing rules, and any amendments to them, must be communicated to the OASIS TC Administrator or Open Project Administrator as applicable, who may rescind them if they are in conflict with OASIS policy, and, in order to be enforceable, must be posted on the committee’s web page.

1.7 Meetings

Committee meetings must be properly called and scheduled in advance using the OASIS collaborative tools. Meetings scheduled or conducted in such a manner as to exclude the participation of any Member are subject to appeal. Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all Members of the committee. In order to enable the openness of committee proceedings, meetings should be scheduled and conducted so as to permit the presence of as many participants as is logistically feasible. Meeting minutes must be recorded and posted to the committee’s general email list.

Individual attendance must be recorded in the meeting minutes. Without a Quorum present discussions may take place at a meeting but no Resolutions may be approved; those present may act as a “Committee of the Whole” as defined in Robert’s Rules of Order Newly Revised, and make a report to the entire committee. However, the foregoing rule does not prohibit the discussion of and initiation of calls for consensus addressed to committee members asynchronously. For committees that maintain voting rights, meetings without Quorum shall still count towards attendance for purposes of Members gaining, maintaining, or losing voting rights.

1.8 Voting

When a committee uses a vote as part of their Resolution or decision making process, all votes require a Simple Majority Vote to pass except as noted elsewhere in this document or in the rules applicable to the type of committee. Any votes requiring a Special Majority Vote for approval must be conducted by the OASIS TC Administrator.

Some types of committees require members to obtain voting rights before being eligible to vote on ballots. The rules governing obtaining and maintaining voting rights are described in the relevant rules document for those types of committees. Committees may not adopt rules governing voting or voting rights or the rights of members that conflict with or supersede any OASIS Board-approved policy.

For committees using voting rights, a Member must have voting rights at the time a ballot is opened in order to vote on that ballot. Proxies shall not be allowed in committee voting.

Committees may conduct electronic ballots. An electronic ballot may be conducted during a meeting using any tool available to the TC including email and the results must be recorded in the minutes. Electronic ballots outside of a meeting shall be made either by using the committee’s general mail list or the publicly archived electronic voting functionality provided by OASIS and must remain open for a minimum of 7 days. Eligible voters must be able to change their vote up until the end of the voting period.

1.9 Closing a Committee

Unless otherwise provided in the rules and policies applicable to a specific type of committee, a committee may be closed by Full Majority Vote of that committee, by Resolution of the OASIS Board of Directors, or by the OASIS TC Administrator, OP Administrator, or Member Section Administrator as applicable.

The relevant Administrator may close a committee that is unable to fill its Chair position for 120 days.

Unless otherwise provided in the rules and policies applicable to a specific type of committee, the relevant Administrator may close a committee whose membership falls below the Minimum Membership necessary or that fails to show activity or progress towards achieving its purpose for an extended period of time.

This version of the OASIS Open Project (OP) Rules was approved by the OASIS Board of Directors on 25 January 2022 and became effective immediately. The change was announced to OASIS members on 03 February 2022 in https://lists.oasis-open.org/archives/members/202202/msg00000.html

Table of Contents

• 1. Purpose of Open Projects
• 2. Project Formation
• 3. Roles of Parties in the Project
• 4. Contributors
• 5. Project Governing Board and Project Sponsors
• 6. Technical Steering Committees
• 7. Project Chairs, Maintainers, and Technical Steering Committees
• 8. Repositories and Project Tools
• 9. Visibility and Archival Permanence
• 10. Project Governance: Decisions and Meetings
• 11. Progression of Project Work
• 12. Releases and Group Releases
• 13. Project Specifications
• 14. OASIS Standard Approval and External Submissions
• 15. Repository and Specification Licenses
• 16. Trademarks
• 17. CLAs and License Notices
• 18. Appeals and Application of Rules
• Appendix A-1: Individual CLA
• Appendix A-2: Entity CLA

1. Purpose of Open Projects

An OASIS Open Project (or Project) is a program hosted by OASIS for the development of code, specifications and other artifacts under open source licenses, under one or more of the Applicable Licenses listed in Section 15, and selected by the Project as specified below. OASIS Open Projects are conducted according to the provisions of these Rules. The OASIS Committee Operations Process provides general provisions concerning the operation of all committees that may apply to the work of a Project Governing Board (PGB). Certain defined terms used in this document have the meaning provided in the OASIS Defined Terms.

Any person or entity, whether or not an OASIS member, may participate in or contribute to a Project, as provided by these rules. Contributions, and the acceptance or merger of contributions into the Project’s work, are managed primarily through one or more open source Project Repositories (as defined in Section 8).

Projects operate under the administrative and process rules described in this document, and are administered by the OASIS Open Project Administrator designated by OASIS.

2. Project Formation

2.1 OASIS Open Projects are initiated by one or more organizations committed to being Project Sponsors and (optionally) persons who intend to make technical contributions to the Project. Any group of at least one or more Project Sponsors whose aggregate project sponsorship dues equal or exceed the minimum threshold established by a resolution of the OASIS Board of Directors, plus one or more named Contributors, may initiate a Project by submitting to the Open Project Administrator a Charter prepared using the Open Project Charter Template maintained and made available by the Open Project Administrator. Additional membership requirements apply to some approval activities as noted below. The Charter shall be written in English and provided to OASIS in electronic form as plain text. The name proposed for the Project shall be subject to approval by the Open Project Administrator for purposes of confirming infringement and appropriate use issues. If the proposed name includes a reference to an OASIS Technical Committee (TC) or specification title, or the name of another Open Project, then the approval of any open OASIS TC or Open Project who uses that name or has authored that specification is required in advance. No information other than that requested in the template may be included in the proposal. Any documents referenced in the proposal shall be publicly available.

The Charter must include a brief statement of purpose and a scope of work for the Project. The scope of work serves as a limit on the approval of Project Standards Track Work Products. The statement of purpose is only informative, not normative. The Charter also must state the number of Project Repositories initially requested to support the Project, and the Applicable License to be applied to each requested repository.

2.2 The Open Project Administrator shall reply in writing with its approval or other disposition of the proposal described above. OASIS shall post a public notice of each approved Project to its announced public mailing list.

2.3 After formation, the Charter of an Open Project may be amended only as provided in Section 5.6.

3. Roles of Parties in the Project

The work of a Project and its administration are conducted by parties who voluntarily contribute in one or more of the following defined roles: Contributor, Maintainer, Project Governing Board (PGB), Technical Steering Committee (TSC), and Chair. A detailed and definitive description of those roles follows in Sections 4, 5, 6 ,and 7 below. A table summarizing those roles can be found in the OASIS Committee Operations Process.

4. Contributors

4.1 Any person (whether or not an OASIS member) may participate in a Project as a Contributor by providing comments or bug reports to a Project Repository, subject to the licensing rules in Sections 14, 15 and 16 below.

4.2 Any person (whether or not an OASIS member) may agree to a Contributor License Agreement (CLA), as provided in the licensing rules below, as a prerequisite for acceptance of their pull requests or other substantive contributions. If a person who signs and submits an individual CLA indicates that they represent an entity, then that individual CLA will only be deemed effective if that entity has signed and submitted an entity CLA. The Project Governing Board and Maintainers shall only act on pull requests or other substantive contributions made by project Contributors who are listed in the OASIS system as having agreed to the relevant CLA. The Project shall maintain a record of all Contributors who have made contributions to a Project.

5. Project Governing Board and Project Sponsors

5.1 Overall guidance for the Project is provided by its Project Governing Board (or PGB). The PGB is composed of one voting member from each Project Sponsor who elects to appoint a PGB member, and at least one voting at-large expert representative from the community of contributors, elected or appointed by the Technical Steering Committee (TSC). The PGB may create additional PGB member seats for expert representatives to be elected by the TSC or appointed by the PGB.

A list of PGB members shall be maintained and posted at the general information web page designated by OASIS for the Project. Certain actions taken by the PGB require affirmative action by Project Approval Minimum Membership, as defined below.

5.2 PGB members must:

• (a) have signed and submitted an individual CLA, and if appointed by an entity, that entity must have signed and submitted an entity CLA naming that project; and
• (b) either (i) represent an organization that has paid the appropriate Backer dues for that Open Project or (ii) has been appointed or elected as an expert representative as provided above.

5.3 Project Approval Minimum Membership, where it explicitly is required for the PGB’s approval of an action under these rules, means at least two Project Sponsors seated on the PGB.

5.4 The PGB shall:

• (a) select one or two Chairs and may replace and remove Chairs as provided in Section 7
• (b) ensure there are one or more Maintainers for any Project Repository
• (c) consult with the Maintainer(s) on technical decisions as described below
• (d) establish and consult with its Technical Steering Committees (TSC)
• (e) approve any Draft Project Specifications, Project Specifications, candidates for OASIS Standards or external submissions from the Project, as provided in Sections 12 and 13

Decisions by the PGB shall be made in a manner consistent with the requirements of Section 10.

5.5 Status as a PGB member who represents an organization accrues to the organizational Project Sponsor, and is transferable by that Project Sponsor from person to person, as evidenced by a notice in writing from its Primary Representative to the OASIS Open Project Administrator. A Project Sponsor may resign from PGB membership at any time, by notifying the Open Project Administrator and the PGB Chair(s) in writing.

5.6 The PGB may amend the Charter after the Project’s formation in the following manner:

(a) An amendment to the binding scope of work may only be made for the purpose of removing ambiguity or for narrowing the scope of work, and requires a Special Majority Vote  of the PGB. Such an amendment may also at the PGB’s option update the statement of purpose, list of planned deliverables and/or list of repositories and licenses.
(b) Any amendment to other elements of the Charter may be made by a Full Majority Vote  of the PGB, so long as and any additions to the list of deliverables are within the scope of
work.
(c) In any case, any amended Charter must comply with the requirements of Section 2.1, and shall not take effect until approved by the PGB and announced by the Open Project Administrator.

6. Technical Steering Committees

The PGB shall form a Technical Steering Committee (or TSC) by a resolution of the PGB. A Project’s TSC members shall be composed of the persons, selected in the manner, and chaired by such person as is provided by that resolution. The PGB must create and publish process documentation, outlining the requirements for joining and voting in the project’s TSC. The TSC shall have the duties to advise the PGB and such others as are specified by the PGB, so long as consistent with these Rules and OASIS policies. The following activities may not be delegated by the PGB, although it may consult with the TSC regarding them at the PGB’s option: election or termination of PGB Chairs, approval of any Releases, Group Releases, Project Specification Drafts, Project Specifications, and approval of candidates for OASIS Standards or external submissions.

TSC members must have signed and submitted an individual CLA, and if appointed by an entity, that entity must have signed and submitted an entity CLA. A list of TSC members shall be maintained and posted at the general information web page designated by OASIS for the Project. An individual may resign from TSC membership at any time, by notifying the Open Project Administrator and the Chair(s) in writing.

7. Project Chairs and Maintainers

7.1 The PGB shall select one or two of its members as Chairs by a Full Majority Vote, to coordinate and manage Project decision-making and logistics. The PGB may remove a Chair at any time by a Full Majority Vote. The Chair(s) of the Project shall:

• (a) be responsible for the coordination and polling of any decisions of the PGB
• (b) convene and make arrangements for any desired virtual or physical face-to-face meetings of the PGB and/or Contributors
• (c) assist and support the Maintainer(s) as appropriate
• (d) be responsible as the Project’s principal point of contact with OASIS staff and resources as needed
• (e) manage or provide for the management of communications with Contributors, any liaisons and the public as may be desirable in support of the Project’s goals.

If a PGB does not have at least one Chair then all PGB activities, with the exception of the selection of a new Chair, are suspended. If a PGB does not have a Chair for 180 days, the Open Project Administrator may declare the PGB closed. After closure of the PGB, the Project may no longer take actions that require the approval of the PGB.

7.2 The PGB shall ensure that there are one or more Maintainers to serve as the principal editor(s) of the Project’s technical work managed within its Project Repositories. Maintainers shall exercise editorial responsibility over the contents of the Project’s repositories, including by:

• (a) evaluating and responding to pull requests
• (b) designating main or recommended branches of each repository
• (c) designating deprecated branches or contributions.

Maintainers should act to carry out the technical consensus of the TSC, Contributors, and PGB, and may be removed by the PGB at any time, after notice to the Maintainer and the TSC, for failure to perform their functions as determined by the PGB. No contributed information or pull requests may be deleted from any Project Repository, due to the open nature of the Applicable Licenses and the Archival Permanence rules in Section 9.2. The appointment of a Maintainer survives the closure of the PGB, and thereafter the remaining Maintainer(s) or the Open Projects Administrator may appoint additional or replacement Maintainers.

8. Repositories and Project Tools

8.1 OASIS will support official repositories for each Project (Project Repositories) using tools selected by staff that are clearly marked as a distinct resource. The repositories listed in the Project’s Charter will be opened by OASIS staff in connection with the Project’s launch. Subject to the requirements of this Section 8, subsequent Project Repositories may be opened by (a) a decision of the PGB, or (b) if the PGB elects to adopt a Standing Rule that permits it, then a TSC or a designated maintainer may also do so. However, adding new Applicable Licenses requires PGB approval: any Project Repository that applies an Applicable License (as provided in Section 15.1) that is already not in use in other Repositories of that Project must first be approved by a Special Majority Vote of the PGB.

8.2 Each Project Repository will serve as a distinct open source project, including issue tracking, comment facilities, and such other facilities as are normally available by default.

8.3 The Project’s official Project Tools include the Project’s Repositories and these additional tools: A principal web page for each Project, which may be the home resource page of the Project’s first Project Repository, and optionally, one or more mailing lists for administration of the Project. Subscription to such lists, which shall be subject to the OASIS Mailing List Guidelines, shall be open to anyone.

9. Visibility and Archival Permanence

9.1 Visibility. Contributions, comments, decisions, records of decisions and all other resources of the Project, including web pages, documents, mailing lists and any other records of discussions, must be located only on the Project Tools designated or authorized by OASIS. Projects may not conduct official business or technical discussions, store documents, or host web pages on servers or systems not designated by OASIS. All Project Tools shall be publicly visible, and all threaded and mail list discussions shall be publicly archived.

9.2 Archival Permanence. OASIS warrants that it will not inhibit open and free access to all of the material contributed to each Project Repository, as open and freely available resources. This warranty is perpetual and will not be revoked by OASIS or its successors or assigns; however, neither OASIS nor its assigns shall be obligated to:

• (a) perpetually maintain its own existence, nor
• (b) provide for the perpetual existence of a website or other public means of accessing such material, nor
• (c) maintain any material which it is legally required to remove from publication.

Some contributed material may be treated as superseded or deprecated by Maintainers or by version control methods, as provided in these rules, but neither Maintainers nor any other party shall delete content. The original form of each contribution shall continue to be available for review, and use according to its licensure, through appropriate version control or document management methodologies.

9.3 Repository Lifecycle. Once a Project Repository has been created, it will remain open as a resource for public use and reference, and continuing repository contributions or comments, regardless of closure of the Project, under the Archival Permanence rule above, with such remaining Maintainers as may have been appointed.

9.4 Announcements. The Open Project Administrator shall create a publicly archived, subscribable list for announcements and public notices from OASIS regarding Open Projects. Every important change in Project status shall be posted to that list, including Project formation; opening of a new Project Repository; Releases; Group Releases; Draft Project Specifications; Project Specifications; Candidate OASIS Standards; and proposed external submissions.

10. Project Governance: Decisions and Meetings

10.1 Decisions by the PGB regarding the matters allocated to them by these rules normally should be made after reasonable notice to and consultation with the Project’s Contributors, and should be made by consensus except in cases where a specific majority vote is required by these rules. The Chair(s) of the Project are responsible for conducting and administrating the decision processes of the PGB and the Project, consistent with these rules.

10.2 Meetings of the PGB and any TSC must be properly called by the Chair(s) and scheduled in advance using the OASIS collaborative communication Project Tools. Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all PGB members. In order to enable the openness of proceedings, meetings also should be scheduled and conducted to permit the presence of as many Contributors as is logistically feasible. A note of each meeting’s outcomes must be posted to a publicly accessible location provided by OASIS. Meetings or decisions scheduled or conducted so as to exclude the participation of any PGB member or Contributor are subject to appeal to the Open Project Administrator.

10.3 Electronic ballots of the PGB, when required by these rules, must be conducted on facilities provided or approved by OASIS, and must remain open for a minimum period for seven days. The Chair(s) may specify a longer voting period for a particular electronic ballot. Eligible voters may change their vote up until the end of the voting period.

11. Progression of Project Work

11.1 In addition to making available the contributions provided by Contributors, via their Project Repositories, Projects may designate specific portions of their output as official Releases, Group Releases, Project Specification Drafts or Project Specifications, and nominate them for further advancement, on the terms set forth in Sections 11, 12, 13 and 14.

12.2 Where the PGB or a consensus among the Contributors indicates that a specific set of contributions should be formally considered as a Release, Group Release, Draft Project Specification or Project Specification, then in preparation for that consideration, the Maintainers shall arrange the relevant material in the relevant Project Repository or repositories so that the set can be accessed and referenced as a distinct branch (a Designated Branch).

12. Releases and Group Releases

12.1 Releases. The PGB may act to approve a Designated Branch as an official Release of the Project, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules. Any product of the Project that is composed from contributions to the Project Repositories, of any nature, is eligible for approval as a Release of the Project.

12.2 Group Releases. When desirable to aggregate outputs, the PGB may act to approve any set of the Project’s Releases or subsets of Releases as an official Group Release of the Project, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules. Group Releases may include multiple Releases that bear different Applicable Licenses. Aggregate contributions by Maintainers or others which are prepared as potential Project Specifications should instead be approved as Project Specification Drafts, as provided below.

12.3 Licensing. Releases and Group Releases bear only the license rights and covenants provided for each of the contributions included there, as evidenced by the relevant repositories’ Applicable License(s) and the CLAs.

13. Project Specifications

13.1 In order to progress a Release or Group Release by the Project as a Project Specification Draft (or PSD) or a Project Specification (or PS), the PGB and the contents of the release(s) must satisfy the additional criteria of this Section.

13.2 In order to be advanced through the approval process, a proposed Project Specification must conform to the Project Specification template provided by the Open Project Administrator, which includes methods for indicating the relevant Designated Branches and Applicable Licenses. Proposed Project Specification Drafts also should conform to that template, to the extent possible.

13.3 Project Specification Drafts. A PGB having at least Project Approval Minimum Membership may act to approve any set of contributions to the Project, including from its Releases or Group Releases, as an official Project Specification Draft, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules.

13.4 Project Specifications. A PGB having at least Project Approval Minimum Membership may act to approve any Project Specification Draft as a Project Specification, by satisfying each of the following requirements:

• (a) Written notice of that nomination must be given by the PGB to all those involved with the Project and the Open Project Administrator at least fourteen days prior to initiating a ballot. The ballot must be conducted by a Special Majority Vote of the PGB. The approval decision is subject to the process, notice and transparency rules set forth in these rules and the content requirements noted below.
• (b) Any machine-executable instructions in a specific computer language (code) that are included in the Project Specification must be composed only of one or more Releases or Group Releases bearing Implementer-Class Licenses.
• (c) Any guidance, descriptions, processes, models for the behavior of a system or service, or other content that is not machine-executable, and is included in the Project Specification, must be composed only of contributions (which may include Releases or Group Releases) previously made to a Project Repository.
• (d) The proposed Project Specification will be subject to review and confirmation of conformance by the Open Project Administrator before the approval ballot is opened.

13.5 Upon successful conclusion of the Special Majority Vote, the Open Project Administrator must give public written notice thereof, which constitutes approval, and thereafter will publish the Project Specification to the OASIS Library.

13.6 Licensing. Project Specifications bear the license rights and covenants provided for each contribution included there, as evidenced by the relevant repositories’ Applicable License(s) and the CLAs, as well as the Specification NonAssertion Covenant. Project Specifications may bear more than one Applicable License, when composed from Releases or Group Releases from multiple Project Repositories that have different Applicable Licenses.

13.7 Implementations of all kinds are welcome (partial or complete; prototype, proof-of-concept, example, model, or reference implementations), provided that PGBs may not designate any single implementation of a Project Specification as exclusive or privileged.

14. OASIS Standard Approval and External Submissions

Project Specifications are eligible for and may be submitted for approval as OASIS Standards, under the following conditions:

• (a) After three Statements of Use referencing the PS have been presented to the PGB, a PGB having at least Project Approval Minimum Membership may approve the PS as a candidate for OASIS Standard in the same manner, and subject to the same requirements, as apply to Committee Specifications as provided in Section 3.8 Approval of an OASIS Standard of the OASIS TC Process. Procedural requirements applicable to TCs in that rule apply to the PGB for this purpose, including the Special Majority Vote required to nominate a Project Specification for OASIS Standard. However, a candidate for OASIS Standard submitted by an Open Project shall be subject to the distinct licensing terms in these rules, and not the licensing terms in the OASIS IPR Policy for TCs.
• (b) Upon a successful conclusion of that PGB vote and all other requirements, the OASIS TC Administrator shall proceed with public review and a call for consent as provided in Sections 3.8.2 and 3.8.3 of the OASIS TC Process. An OASIS Standard submitted by an Open Project and approved as provided above is eligible for further external submissions as provided in and subject to the requirements in the OASIS Liaison Policy. The PGB must have at least Project Approval Minimum Membership at the time of any such action or approval; the other procedural requirements applicable to TCs in that policy apply to the PGB for this purpose.

15. Repository and Specification Licenses

15.1 Applicable Licenses; Copyright Implementation Licenses. Each Project Repository will be subject to a declared Applicable License, selected from the list of licenses in this section. Each Contributor agrees in the CLA to grant the Applicable License designated for a repository to all contributions donated to that repository by posting it or requesting its inclusion in that repository, and to all Releases issued from that repository.

Anyone may offer comments to any Project Repository, on the terms of the foregoing licenses, as evidenced in the manner noted below. Anyone will be entitled to make use of the contents of a Project Repository, according to the terms of its Applicable License.

15.2 When requesting the creation of a Project Repository, the PGB must select that repository’s Applicable License from among the following list:

• (a) Implementer-Class Licenses: Apache License v2.0; Eclipse Public License v1.0; Eclipse Public License 2.0; BSD-3-Clause License; CC-0; CC-BY 2.0; CC-BY 4.0; MIT License.
• (b) Other available licenses: Community Data License Agreement v2.

Other widely-used free and open source licenses may be added to this list after review and acceptance by OASIS and amendment of these rules.

15.3 Special Covenants for Project Specifications. In addition to the Applicable License for each Project Repository, each Contributor also agrees in the CLA to provide the additional covenants in this Section 15.3, as non-assertion covenants in favor of certain Project Specifications (collectively the Specification NonAssertion Covenant):

Contributor Covenant for Specifications. As a Contributor, you irrevocably covenant that you will not assert any patent claims licensable by you that are necessarily infringed by an implementation of your contribution to the extent that contribution is included in a Project Specification approved by the Open Project to which you made the contribution, against OASIS or any other parties who the Applicable License benefits, for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing works that Implement or Derive From your contribution.

PGB Covenant for Specifications. For any Project Repository whose Applicable License is an Implementer-Class License, if you (or your representative) are a member of that Open Project’s Governing Board, you irrevocably covenant that you will not assert any patent claims licensable by you that are necessarily infringed by an implementation of a Project Specification approved by that Open Project within the scope of work of its Charter in effect at the time such deliverable was approved, and any Maintenance Deliverable approved for it, against OASIS or any other parties who the Applicable License benefits, for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing works that Implement or Derive From that Project Specification and are compliant with all normative portions thereof. If you withdraw from the PGB, then this obligation continues to apply, but only with respect to those Project Specification Drafts approved more than 7 calendar days prior to your withdrawal, and to any Maintenance Deliverables approved for those specifications thereafter.

Scope of Implementations Benefited. As used in this covenant, works that “Implement or Derive From” a contribution or specification include:

• (a) specifications to the extent derived from code
• (b) independent code implementations of a specification
• (c) independent code implementations of a specification to the extent the specification is derived from code.

For purposes of this definition, “specifications” include documentation, data flows, data formats, application programming interfaces and process descriptions.

Withdrawal from Covenant. Your Specification NonAssertion Covenant may be suspended or revoked by you with respect to any person who alleges in writing or files a suit asserting that your Contribution, or the work to which you have contributed, constitutes direct or contributory patent infringement.

16. Trademarks

In order to incorporate a trademark or service mark into a Project, including its use in the name of an OASIS Open Project or any Release, or its inclusion in the body of such work, that mark must be:

• (a) owned by OASIS; or
• (b) otherwise as approved by the OASIS Board of Directors.

No person may use an OASIS trademark or service mark in connection with an Open Project, a Release or otherwise, except in compliance with the Applicable License for a Release or otherwise according to such license and usage guidelines as OASIS may from time to time require.

17. CLAs and License Notices

17.1 A Contributor License Agreement (or CLA) shall bind each donor of a repository contribution, issue or comment of any kind to the repository’s Applicable License. All Contributions to Project Repositories shall be subject to an Individual CLA, in the form of Appendix A-1 to these rules, by which all persons making those Contributions are bound. Where Contributions are made by or on behalf of an organization, the responsible individual will designate that organization in their Individual CLA, and that organization will be asked to provide an Entity CLA, in the form of Appendix A-2 to these rules. If that Entity CLA is not obtained, OASIS and the Project must decline contributions from that individual.

Project Sponsors who appoint a member to the PGB must provide an Entity CLA, and the persons appointed by them as PGB members must provide an Individual CLA in order to serve.

Members of OASIS who provide an Entity CLA must provide the signature (or assent) of their OASIS Primary Representative. Individuals who represent an organization also are required by the Individual CLA to obtain an Entity CLA for that organization.

17.2 While some nominal write-access privileges (such as adding issues and comments) may be granted automatically to the public by the Project Tools, only persons who have signed the CLA will be permitted to submit content other than comments or suggestions for Non-Material Changes.

17.3. Each person making a Project Repository contribution must be bound to the terms of the Individual CLA, by obtaining their signature (which may be an equivalent electronic assent) in a manner appropriate to the tools employed to implement that repository; and those signatures shall be recorded and maintained in an auditable manner. Organizational Entity CLA signatures must also be obtained, recorded and maintained in a similar manner.

17.4. Notices of the Applicable License applicable to each Project Repository shall be conspicuously visible both from each repository’s contribution channels (for potential submitters of material) and its home resource pages (for potential readers and users).

17.5 Each Repository and its contribution facility shall be conspicuously marked with the following Call for Patent Disclosure:

[OASIS requests that any party contact the OASIS Open Project Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of an OASIS Project Specification; and that any such claimant provide an indication of its willingness to grant a Specification Non-Assertion Covenant with respect to such patent claims, or otherwise to negotiate patent licenses free of charge with other parties on a non-discriminatory basis on reasonable terms and conditions.]

[OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in an OASIS Project Specification, or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.]

18. Appeals and Application of Rules

The appeals process provided in Section 4.2 of the OASIS TC Process also shall apply to the actions of the OASIS Open Project Administrator, which may be appealed as provided therein.

Changes to these rules shall apply to previously-established Open Projects upon their adoption. However, OASIS may not change the terms of any signed CLA once it has been delivered to OASIS; if a change is required a new CLA must be executed.

Appendix A-1: Individual CLA

OASIS Open Projects: Individual Contributor License Agreement (CLA)

The text and links to file i-CLAs for Open Projects are available at https://www.oasis-open.org/open-projects/cla/oasis-open-projects-individual-contributor-license-agreement-i-cla/ .

Appendix A-2: Entity CLA

OASIS Open Projects: Entity Contributor License Agreement (CLA)

The text and link to file an e-CLA for an Open Project is available at https://www.oasis-open.org/open-projects/cla/entity-cla-20210630/.

The Open Repository Guidelines and Procedures were approved by the OASIS Board of Directors on 27 April 2015 and became effective on announcement on 21 September 2015 in https://lists.oasis-open.org/archives/members/201509/msg00003.html

Table of Contents

1. REPOSITORY DEFINITION
2. REPOSITORIES ARE INITIATED BY OASIS TCs
3. REPOSITORIES ARE SEPARATE FROM A TC’S SPECIFICATION WORK
4. REPOSITORY LICENSES AND LICENSING RULES
5. PURPOSE STATEMENT AND CONTENTS
6. ARCHIVAL PERMANENCE
7. REPOSITORY MANAGEMENT
8. REPOSITORY TOOLS
9. LICENSE TOOLS AND NOTICES
10. REPOSITORY LIFECYCLE

Overview OASIS TC Open Repositories are a distinct class of information and sharing portals (for example, a GitHub project), that can be set up to support and complement the work of an OASIS Technical Committee (“TC”). These repositories add the strengths of open source development to OASIS’ existing stable and well-recognized governance process.

1. REPOSITORY DEFINITION

An OASIS TC Open Repository (“TC Open Repository”) is a distinct facility operated by OASIS for collection of voluntarily contributed information relevant to the work of a specific TC, under the rules set forth in these procedures. TC Open Repositories may reside on third-party server resources. See REPOSITORY TOOLS below.

2. REPOSITORIES ARE INITIATED BY OASIS TCs

Any Eligible OASIS TC may create one or more TC Open Repositories at its election, by a simple majority vote of its membership, conducted in the same manner as is used to approve other administrative matters consistent with the OASIS TC Process (an “Administrative Vote”). TC Open Repositories may only be created by, and in connection with the work of, Eligible OASIS TCs.

An “Eligible OASIS TC” is a currently-active OASIS TC that is operating under the Non-Assertion, RF on Limited Terms, or RF on RAND IPR Mode as defined by the OASIS IPR Policy.

3. REPOSITORIES ARE SEPARATE FROM A TC’S SPECIFICATION WORK

TC Open Repositories created by a TC are separate and distinct resources from the TC’s specification work. Specification work, sometimes described as the TC’s work product, is governed by the OASIS TC Process, and available under the licensing terms of the OASIS IPR Policy. In contrast, TC Open Repository contents are governed by these rules, and available under an open source license as provided here. Because different licenses apply, there is no guarantee that the licensure of specific material in a TC Open Repository will be compatible with the licensing requirements of an implementation of a TC’s specification.

No TC member shall have any obligation to join, contribute to, or reference, any TC Open Repository. Members of an OASIS TC incur no other licensing or disclosure obligations by reason of any TC Open Repository, unless that member explicitly contributes to it under these rules. See REPOSITORY LICENSES AND LICENSING RULES below.

TC Open Repository contributions (“repo contributions”) and contents are not automatically also contributed to the TC’s Work Product as specification “Contributions” as defined in the OASIS IPR Policy. TC members may choose to use any contents of an Open repository in TC specification development, by taking the separate, additional step of offering that material as their own “Contributions” to the TC’s Work Product under the OASIS IPR Policy. Each member is responsible for determining the suitability of their own contributions.

4. REPOSITORY LICENSES AND LICENSING RULES

Each TC Open Repository will be subject to a declared “Applicable License,” selected from the list of licenses at the end of this section. The Applicable License for a repository will apply to all repo contributions donated to the repository, by posting it or requesting its inclusion in that repository. Anyone, whether an OASIS member or TC member or not, may contribute into a TC Open Repository, subject to the Applicable License, as evidenced in the manner noted in LICENSE TOOLS AND NOTICES below. Anyone (including but not limited to the TC that created it) will be entitled to make use of the contents of a TC Open Repository, according to the terms of its Applicable License.

The TC creating a TC Open Repository will select its Applicable License from among the following list: BSD-3-Clause License (which shall apply if the TC makes no license selection in its approval action); Apache License v 2.0; CC-BY 2.0; CC-BY 4.0; Eclipse Public License v 1.0. (OASIS periodically will review other widely-used free and open source licenses for inclusion in this list by amending these procedures.)

5. PURPOSE STATEMENT AND CONTENTS

Each TC Open Repository should have a purpose statement, indicating its intended contents or topic, declared by the TC that creates it, as part of its approval action. If the TC’s approval action specifies no purpose statement, then the purpose shall be any kind of information including examples, code, implementation details, bug reports, and actual, model or dummy content that may relate to the Work Products to be produced by that TC as defined in its charter.

6. ARCHIVAL PERMANENCE

OASIS warrants that it will not inhibit open and free access to all of the material contributed to each TC Open Repository, as open and freely-available resources. This warranty is perpetual and will not be revoked by OASIS or its successors or assigns; however, neither OASIS nor its assigns shall be obligated to: (a) perpetually maintain its own existence; nor (b) provide for the perpetual existence of a website or other public means of accessing such material; nor (c) maintain any material which it is legally required to remove from publication. Some contributed material may be treated as superseded by Maintainers or by version control methods. See REPOSITORY MANAGEMENT below. However, Maintainers shall not delete content; the original form of each repo contribution shall continue to be available for review, through appropriate version control or document management methodologies.

7. REPOSITORY MANAGEMENT

When a TC creates a TC Open Repository, it shall designate one or two TC members to act as its initial “Maintainer(s)”, by an Administrative Vote, to organize the material in that repository. Maintainers may exercise editorial organization of the contents of their TC Open Repository, including by classifying it, evaluating and responding to pull requests, designating main or recommended branches, and designating deprecated branches or material. However, no contributed information may be deleted from any TC Open Repository, due to the open nature of Applicable Licenses and the ARCHIVAL PERMANENCE rule. In cooperation with the community, the Maintainer(s) and the TC may select additional or successor Maintainer(s) to share responsibilities for the repository. See REPOSITORY LIFECYCLE below.

8. REPOSITORY TOOLS

OASIS will create and support TC Open Repositories using web resource tools, selected and configured by staff, that are clearly marked as a distinct resource, and under different Internet subdomains, from the Work Product of a TC conducted under the OASIS IPR Policy and TC Process. OASIS initially will create TC Open Repositories as either distinct GitHub projects, or distinct Subversion repositories. (OASIS periodically will review other widely-used tools, either hosted by OASIS or from appropriate and commercially-neutral third parties, for inclusion in this list of available platforms, by amending these procedures.)

9. LICENSE TOOLS AND NOTICES

Each TC Open Repository shall be subject to a Contributor License Agreement (“CLA”) by which all persons making repo contributions into it are bound. The CLA shall bind each donor of a repo contribution to the repository’s Applicable License and such other consistent terms as OASIS may require as a publisher to assure its availability. While certain nominal write-access privileges (such as adding issues and comments) may be granted automatically to the public by the tools, only persons who have signed the CLA will be permitted to contribute substantive content. Each person making a repo contribution must be bound to the terms of the CLA, by obtaining their signature (which may be an equivalent electronic assent) in a manner appropriate to the web resources tools employed to implement that repository; and those signatures shall be recorded and maintained in an auditable manner. Notices of the Applicable License or an appropriate link shall be conspicuously visible both from each repository’s contribution channels (for potential contributors of material) and resource pages (for potential readers and users). See the OASIS TC Open Repositories FAQ for details about the form and location of the notices.

10. REPOSITORY LIFECYCLE

Once a TC Open Repository has been created by an Eligible OASIS TC, it will remain open as a resource for public use and reference, and continuing contributions, after the OASIS TC is closed, under the ARCHIVAL PERMANENCE rule above, with such remaining Maintainers as may have been appointed. A TC may, if it so elects, designate a successor Eligible OASIS TC, by an Administrative Vote at any time prior to its closure, to assume its remaining responsibilities to its TC Open Repository.

This version of the OASIS Open Project (OP) Rules was approved by the OASIS Board of Directors on 06 March 2020 and became effective immediately. The change was announced to OASIS members on 10 March 2020 in https://lists.oasis-open.org/archives/members/202003/msg00001.html.

Table of Contents

• 1. Purpose of Open Projects
• 2. Project Formation
• 3. Roles of Parties in the Project
• 4. Contributors
• 5. Project Governing Board and Project Sponsors
• 6. Technical Steering Committees
• 7. Project Chairs, Maintainers, and Technical Steering Committees
• 8. Repositories and Project Tools
• 9. Visibility and Archival Permanence
• 10. Project Governance: Decisions and Meetings
• 11. Progression of Project Work
• 12. Releases and Group Releases
• 13. Project Specifications
• 14. OASIS Standard Approval and External Submissions
• 15. Repository and Specification Licenses
• 16. Trademarks
• 17. CLAs and License Notices
• 18. Appeals and Application of Rules
• Appendix A-1: Individual CLA
• Appendix A-2: Entity CLA

1. Purpose of Open Projects

An OASIS Open Project (or Project) is a program hosted by OASIS for the development of code, specifications and other artifacts under open source licenses, under one or more of the Applicable Licenses listed in Section 15, and selected by the Project as specified below. OASIS Open Projects are conducted according to the provisions of these Rules. The OASIS Committee Operations Process provides general provisions concerning the operation of all committees that may apply to the work of a Project Governing Board (PGB). Certain defined terms used in this document have the meaning provided in the OASIS Defined Terms.

Any person or entity, whether or not an OASIS member, may participate in or contribute to a Project, as provided by these rules. Contributions, and the acceptance or merger of contributions into the Project’s work, are managed primarily through one or more open source Project Repositories (as defined in Section 8).

Projects operate under the administrative and process rules described in this document, and are administered by the OASIS Open Project Administrator designated by OASIS.

2. Project Formation

2.1 OASIS Open Projects are initiated by one or more organizations committed to being Project Sponsors and (optionally) persons who intend to make technical contributions to the Project. Any group of at least one or more Project Sponsors whose aggregate project sponsorship dues equal or exceed the minimum threshold established by a resolution of the OASIS Board of Directors, plus one or more named Contributors, may initiate a Project by submitting to the Open Project Administrator a Charter prepared using the Open Project Charter Template maintained and made available by the Open Project Administrator. Additional membership requirements apply to some approval activities as noted below. The Charter shall be written in English and provided to OASIS in electronic form as plain text. The name proposed for the Project shall be subject to approval by the Open Project Administrator for purposes of confirming infringement and appropriate use issues. If the proposed name includes a reference to an OASIS Technical Committee (TC) or specification title, or the name of another Open Project, then the approval of any open OASIS TC or Open Project who uses that name or has authored that specification is required in advance. No information other than that requested in the template may be included in the proposal. Any documents referenced in the proposal shall be publicly available.

The Charter must include a brief statement of purpose for the Project. However, the Project’s statement of purpose does not serve as a binding scope or boundary for work created in the Project. The Charter also must state the number of initial Project Repositories requested to be opened to support the Project, and the Applicable License to be applied to each requested repository.

2.2 The Open Project Administrator shall reply in writing with its approval or other disposition of the proposal described above. OASIS shall post a public notice of each approved Project to its announced public mailing list.

3. Roles of Parties in the Project

The work of a Project and its administration are conducted by parties who voluntarily contribute in one or more of the following defined roles: Contributor, Maintainer, Project Governing Board (PGB), Technical Steering Committee (TSC), and Chair. A detailed and definitive description of those roles follows in Sections 4, 5, 6 ,and 7 below. A table summarizing those roles can be found in the OASIS Committee Operations Process.

4. Contributors

4.1 Any person (whether or not an OASIS member) may participate in a Project as a Contributor by providing comments or bug reports to a Project Repository, subject to the licensing rules in Sections 14, 15 and 16 below.

4.2 Any person (whether or not an OASIS member) may agree to a Contributor License Agreement (CLA), as provided in the licensing rules below, as a prerequisite for acceptance of their pull requests or other substantive contributions. If a person who signs and submits an individual CLA indicates that they represent an entity, then that individual CLA will only be deemed effective if that entity has signed and submitted an entity CLA. The Project Governing Board and Maintainers shall only act on pull requests or other substantive contributions made by project Contributors who are listed in the OASIS system as having agreed to the relevant CLA. The Project shall maintain a record of all Contributors who have made contributions to a Project.

5. Project Governing Board and Project Sponsors

5.1 Overall guidance for the Project is provided by its Project Governing Board (or PGB). The PGB is composed of one voting member from each Project Sponsor who elects to appoint a PGB member, and at least one voting at-large expert representative from the community of contributors, elected or appointed by the Technical Steering Committee (TSC). The PGB may create additional PGB member seats for expert representatives to be elected by the TSC or appointed by the PGB.

A list of PGB members shall be maintained and posted at the general information web page designated by OASIS for the Project. Certain actions taken by the PGB require affirmative action by Project Approval Minimum Membership, as defined below.

5.2 PGB members must:

• (a) have signed and submitted an individual CLA, and if appointed by an entity, that entity must have signed and submitted an entity CLA naming that project; and
• (b) either (i) represent an organization that has paid the appropriate Backer dues for that Open Project or (ii) has been appointed or elected as an expert representative as provided above.

5.3 Project Approval Minimum Membership, where it explicitly is required for the PGB’s approval of an action under these rules, means at least two Project Sponsors.

5.4 The PGB shall:

• (a) select one or two Chairs and may replace and remove Chairs as provided in Section 7
• (b) ensure there are one or more Maintainers for any Project Repository
• (c) consult with the Maintainer(s) on technical decisions as described below
• (d) establish and consult with its Technical Steering Committees (TSC)
• (e) approve any Draft Project Specifications, Project Specifications, Candidate OASIS Standards or external submissions from the Project, as provided in Sections 12 and 13

Decisions by the PGB shall be made in a manner consistent with the requirements of Section 10.

5.5 Status as a PGB member who represents an organization accrues to the organizational Project Sponsor, and is transferable by that Project Sponsor from person to person, as evidenced by a notice in writing from its Primary Representative to the OASIS Open Project Administrator. A Project Sponsor may resign from PGB membership at any time, by notifying the Open Project Administrator and the PGB Chair(s) in writing.

6. Technical Steering Committees

The PGB shall form a Technical Steering Committee (or TSC) by a resolution of the PGB. A Project’s TSC members shall be composed of the persons, selected in the manner, and chaired by such person as is provided by that resolution. The PGB must create and publish process documentation, outlining the requirements for joining and voting in the project’s TSC. The TSC shall have the duties to advise the PGB and such others as are specified by the PGB, so long as consistent with these Rules and OASIS policies. The following activities may not be delegated by the PGB, although it may consult with the TSC regarding them at the PGB’s option: election or termination of PGB Chairs, approval of any Releases, Group Releases, Project Specification Drafts, Project Specifications, and approval of Candidate OASIS Standards or external submissions. TSC members must have signed and submitted an individual CLA, and if appointed by an entity, that entity must have signed and submitted an entity CLA. A list of TSC members shall be maintained and posted at the general information web page designated by OASIS for the Project. An individual may resign from TSC membership at any time, by notifying the Open Project Administrator and the Chair(s) in writing.

7. Project Chairs and Maintainers

7.1 The PGB shall select one or two of its members as Chairs by a Full Majority Vote, to coordinate and manage Project decision-making and logistics. The PGB may remove a Chair at any time by a Full Majority Vote. The Chair(s) of the Project shall:

• (a) be responsible for the coordination and polling of any decisions of the PGB
• (b) convene and make arrangements for any desired virtual or physical face-to-face meetings of the PGB and/or Contributors
• (c) assist and support the Maintainer(s) as appropriate
• (d) be responsible as the Project’s principal point of contact with OASIS staff and resources as needed
• (e) manage or provide for the management of communications with Contributors, any liaisons and the public as may be desirable in support of the Project’s goals.

If a PGB does not have at least one Chair then all PGB activities, with the exception of the selection of a new Chair, are suspended. If a PGB does not have a Chair for 180 days, the Open Project Administrator may declare the PGB closed. After closure of the PGB, the Project may no longer take actions that require the approval of the PGB.

7.2 The PGB shall ensure that there are one or more Maintainers to serve as the principal editor(s) of the Project’s technical work managed within its Project Repositories. Maintainers shall exercise editorial responsibility over the contents of the Project’s repositories, including by:

• (a) evaluating and responding to pull requests
• (b) designating main or recommended branches of each repository
• (c) designating deprecated branches or contributions.

Maintainers should act to carry out the technical consensus of the TSC, Contributors, and PGB, and may be removed by the PGB at any time, after notice to the Maintainer and the TSC, for failure to perform their functions as determined by the PGB. No contributed information or pull requests may be deleted from any Project Repository, due to the open nature of the Applicable Licenses and the Archival Permanence rules in Section 9.2. The appointment of a Maintainer survives the closure of the PGB, and thereafter the remaining Maintainer(s) or the Open Projects Administrator may appoint additional or replacement Maintainers.

8. Repositories and Project Tools

8.1 OASIS will create and support official repositories for each Project (Project Repositories) using tools, selected and configured by staff that are clearly marked as a distinct resource. OASIS will initialize each Project Repository as a distinct open source project, including issue tracking, comment facilities, and such other facilities as are normally available by default.

8.2 The Project’s official Project Tools include the Project’s Repositories and these additional tools: A principal web page for each Project, which may be the home resource page of the Project’s first Project Repository, and optionally, one or more mailing lists for administration of the Project. Subscription to such lists, which shall be subject to the OASIS Mailing List Guidelines, shall be open to anyone.

9. Visibility and Archival Permanence

9.1 Visibility. Contributions, comments, decisions, records of decisions and all other resources of the Project, including web pages, documents, mailing lists and any other records of discussions, must be located only on the Project Tools designated or authorized by OASIS. Projects may not conduct official business or technical discussions, store documents, or host web pages on servers or systems not designated by OASIS. All Project Tools shall be publicly visible, and all threaded and mail list discussions shall be publicly archived.

9.2 Archival Permanence. OASIS warrants that it will not inhibit open and free access to all of the material contributed to each Project Repository, as open and freely available resources. This warranty is perpetual and will not be revoked by OASIS or its successors or assigns; however, neither OASIS nor its assigns shall be obligated to:

• (a) perpetually maintain its own existence, nor
• (b) provide for the perpetual existence of a website or other public means of accessing such material, nor
• (c) maintain any material which it is legally required to remove from publication.

Some contributed material may be treated as superseded or deprecated by Maintainers or by version control methods, as provided in these rules, but neither Maintainers nor any other party shall delete content. The original form of each contribution shall continue to be available for review, and use according to its licensure, through appropriate version control or document management methodologies.

9.3 Repository Lifecycle. Once a Project Repository has been created, it will remain open as a resource for public use and reference, and continuing repository contributions or comments, regardless of closure of the Project, under the Archival Permanence rule above, with such remaining Maintainers as may have been appointed.

9.4 Announcements. The Open Project Administrator shall create a publicly archived, subscribable list for announcements and public notices from OASIS regarding Open Projects. Every important change in Project status shall be posted to that list, including Project formation; opening of a new Project Repository; Releases; Group Releases; Draft Project Specifications; Project Specifications; Candidate OASIS Standards; and proposed external submissions.

10. Project Governance: Decisions and Meetings

10.1 Decisions by the PGB regarding the matters allocated to them by these rules normally should be made after reasonable notice to and consultation with the Project’s Contributors, and should be made by consensus except in cases where a specific majority vote is required by these rules. The Chair(s) of the Project are responsible for conducting and administrating the decision processes of the PGB and the Project, consistent with these rules.

10.2 Meetings of the PGB and any TSC must be properly called by the Chair(s) and scheduled in advance using the OASIS collaborative communication Project Tools. Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all PGB members. In order to enable the openness of proceedings, meetings also should be scheduled and conducted to permit the presence of as many Contributors as is logistically feasible. A note of each meeting’s outcomes must be posted to a publicly accessible location provided by OASIS. Meetings or decisions scheduled or conducted so as to exclude the participation of any PGB member or Contributor are subject to appeal to the Open Project Administrator.

10.3 Electronic ballots of the PGB, when required by these rules, must be conducted on facilities provided or approved by OASIS, and must remain open for a minimum period for seven days. The Chair(s) may specify a longer voting period for a particular electronic ballot. Eligible voters may change their vote up until the end of the voting period.

11. Progression of Project Work

11.1 In addition to making available the contributions provided by Contributors, via their Project Repositories, Projects may designate specific portions of their output as official Releases, Group Releases, Project Specification Drafts or Project Specifications, and nominate them for further advancement, on the terms set forth in Sections 11, 12, 13 and 14.

12.2 Where the PGB or a consensus among the Contributors indicates that a specific set of contributions should be formally considered as a Release, Group Release, Draft Project Specification or Project Specification, then in preparation for that consideration, the Maintainers shall arrange the relevant material in the relevant Project Repository or repositories so that the set can be accessed and referenced as a distinct branch (a Designated Branch).

12. Releases and Group Releases

12.1 Releases. The PGB may act to approve a Designated Branch as an official Release of the Project, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules. Any product of the Project that is composed from contributions to the Project Repositories, of any nature, is eligible for approval as a Release of the Project.

12.2 Group Releases. When desirable to aggregate outputs, the PGB may act to approve any set of the Project’s Releases or subsets of Releases as an official Group Release of the Project, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules. Group Releases may include multiple Releases that bear different Applicable Licenses. Aggregate contributions by Maintainers or others which are prepared as potential Project Specifications should instead be approved as Project Specification Drafts, as provided below.

12.3 Licensing. Releases and Group Releases bear only the license rights and covenants provided for each of the contributions included there, as evidenced by the relevant repositories’ Applicable License(s) and the CLAs.

13. Project Specifications

13.1 In order to progress a Release or Group Release by the Project as a Project Specification Draft (or PSD) or a Project Specification (or PS), the PGB and the contents of the release(s) must satisfy the additional criteria of this Section.

13.2 In order to be advanced through the approval process, a proposed Project Specification must conform to the Project Specification template provided by the Open Project Administrator, which includes methods for indicating the relevant Designated Branches and Applicable Licenses. Proposed Project Specification Drafts also should conform to that template, to the extent possible.

13.3 Project Specification Drafts. A PGB having at least Project Approval Minimum Membership may act to approve any set of contributions to the Project, including from its Releases or Group Releases, as an official Project Specification Draft, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules.

13.4 Project Specifications. A PGB having at least Project Approval Minimum Membership may act to approve any Project Specification Draft as a Project Specification, by satisfying each of the following requirements:

• (a) Written notice of that nomination must be given by the PGB to all those involved with the Project and the Open Project Administrator at least fourteen days prior to initiating a ballot. The ballot must be conducted by a Special Majority Vote of the PGB. The approval decision is subject to the process, notice and transparency rules set forth in these rules and the content requirements noted below.
• (b) Any machine-executable instructions in a specific computer language (code) that are included in the Project Specification must be composed only of one or more Releases or Group Releases bearing Implementer-Class Licenses.
• (c) Any guidance, descriptions, processes, models for the behavior of a system or service, or other content that is not machine-executable, and is included in the Project Specification, must be composed only of contributions (which may include Releases or Group Releases) previously made to a Project Repository.
• (d) The proposed Project Specification will be subject to review and confirmation of conformance by the Open Project Administrator before the approval ballot is opened.

13.5 Upon successful conclusion of the Special Majority Vote, the Open Project Administrator must give public written notice thereof, which constitutes approval, and thereafter will publish the Project Specification to the OASIS Library.

13.6 Licensing. Project Specifications bear the license rights and covenants provided for each contribution included there, as evidenced by the relevant repositories’ Applicable License(s) and the CLAs, as well as the Specification NonAssertion Covenant. Project Specifications may bear more than one Applicable License, when composed from Releases or Group Releases from multiple Project Repositories that have different Applicable Licenses.

13.7 Implementations of all kinds are welcome (partial or complete; prototype, proof-of-concept, example, model, or reference implementations), provided that PGBs may not designate any single implementation of a Project Specification as exclusive or privileged.

14. OASIS Standard Approval and External Submissions

Project Specifications are eligible for and may be submitted for approval as OASIS Standards, under the following conditions:

• (a) After three Statements of Use referencing the PS have been presented to the PGB, a PGB having at least Project Approval Minimum Membership may approve the PS as a Candidate OASIS Standard in the same manner, and subject to the same requirements, as apply to Committee Specifications as provided in Section 3.8 Approval of an OASIS Standard of the OASIS TC Process. Procedural requirements applicable to TCs in that rule apply to the PGB for this purpose, including the Special Majority Vote required to nominate a Project Specification for OASIS Standard. However, a Candidate OASIS Standard submitted by an Open Project shall be subject to the distinct licensing terms in these rules, and not the licensing terms in the OASIS IPR Policy for TCs.
• (b) Upon a successful conclusion of that PGB vote and all other requirements, the OASIS TC Administrator shall proceed with public review and a call for consent as provided in Sections 3.8.2 and 3.8.3 of the OASIS TC Process. An OASIS Standard submitted by an Open Project and approved as provided above is eligible for further external submissions as provided in and subject to the requirements in the OASIS Liaison Policy. The PGB must have at least Project Approval Minimum Membership at the time of any such action or approval; the other procedural requirements applicable to TCs in that policy apply to the PGB for this purpose.

15. Repository and Specification Licenses

15.1 Applicable Licenses; Copyright Implementation Licenses. Each Project Repository will be subject to a declared Applicable License, selected from the list of licenses in this section. Each Contributor agrees in the CLA to grant the Applicable License designated for a repository to all contributions donated to that repository by posting it or requesting its inclusion in that repository, and to all Releases issued from that repository. Anyone may offer comments to any Project Repository, on the terms of the foregoing licenses, as evidenced in the manner noted below. Anyone will be entitled to make use of the contents of a Project Repository, according to the terms of its Applicable License.

15.2 When requesting the creation of a Project Repository, the PGB must select that repository’s Applicable License from among the following list:

• (a) Implementer-Class Licenses: Apache License v2.0; Eclipse Public License v1.0; Eclipse Public License 2.0; BSD-3-Clause License; CC-BY 2.0; CC-BY 4.0; MIT License.
• (b) Other available licenses: CC-0.

Other widely-used free and open source licenses may be added to this list after review and acceptance by OASIS and amendment of these rules.

15.3 Special Covenants for Project Specifications. In addition to the Applicable License for each Project Repository, each Contributor also agrees in the CLA to provide the additional covenants in this Section 15.3, as non-assertion covenants in favor of certain Project Specifications (collectively the Specification NonAssertion Covenant):

Contributor Covenant for Specifications. As a Contributor, you irrevocably covenant that you will not assert any patent claims licensable by you that are necessarily infringed by an implementation of your contribution to the extent that contribution is included in a Project Specification approved by the Open Project to which you made the contribution, against OASIS or any other parties who the Applicable License benefits, for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing works that Implement or Derive From your contribution.

PGB Covenant for Specifications. For any Project Repository whose Applicable License is an Implementer-Class License, if you (or your representative) are a member of that Open Project’s Governing Board, you irrevocably covenant that you will not assert any patent claims licensable by you that are necessarily infringed by an implementation of a Project Specification approved by that Open Project, and any Maintenance Deliverable approved for it, against OASIS or any other parties who the Applicable License benefits, for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing works that Implement or Derive From that Project Specification and are compliant with all normative portions thereof. If you withdraw from the PGB, then this obligation continues to apply, but only with respect to those Project Specification Drafts approved more than 7 calendar days prior to your withdrawal, and to any Maintenance Deliverables approved for those specifications thereafter.

Scope of Implementations Benefited. As used in this covenant, works that “Implement or Derive From” a contribution or specification include:

• (a) specifications to the extent derived from code
• (b) independent code implementations of a specification
• (c) independent code implementations of a specification to the extent the specification is derived from code.

For purposes of this definition, “specifications” include documentation, data flows, data formats, application programming interfaces and process descriptions.

Withdrawal from Covenant. Your Specification NonAssertion Covenant may be suspended or revoked by you with respect to any person who alleges in writing or files a suit asserting that your Contribution, or the work to which you have contributed, constitutes direct or contributory patent infringement.

16. Trademarks

In order to incorporate a trademark or service mark into a Project, including its use in the name of an OASIS Open Project or any Release, or its inclusion in the body of such work, that mark must be:

• (a) owned by OASIS; or
• (b) licensed by the owner of the mark to OASIS (i) under a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license, with the rights to directly and indirectly sublicense, to copy, publish, distribute and incorporate the mark, and to prepare derivative works that use or incorporate the mark, all for the purposes of publishing, developing, maintaining and promoting any of the Project’s Contributions, Releases, Group Releases, Project Specifications or OASIS Standards, and enabling the use, re-use and implementation of any of the foregoing by coders, implementers, and end-users as sublicensees or beneficiaries; (ii) on published written license terms satisfactory to the Open Project Administrator, and (iii) on license terms that the Open Project Administration is satisfied are consistent with the Applicable License designated for the repositories in or with which such marks are used; or
• (c) otherwise as approved by the OASIS Board of Directors.

No person may use an OASIS trademark or service mark in connection with an Open Project, a Release or otherwise, except in compliance with the Applicable License for a Release or otherwise according to such license and usage guidelines as OASIS may from time to time require.

17. CLAs and License Notices

17.1 A Contributor License Agreement (or CLA) shall bind each donor of a repository contribution, issue or comment of any kind to the repository’s Applicable License. All Contributions to Project Repositories shall be subject to an Individual CLA, in the form of Appendix A-1 to these rules, by which all persons making those Contributions are bound. Where Contributions are made by or on behalf of an organization, the responsible individual will designate that organization in their Individual CLA, and that organization will be asked to provide an Entity CLA, in the form of Appendix A-2 to these rules. If that Entity CLA is not obtained, OASIS and the Project must decline contributions from that individual. Project Sponsors who appoint a member to the PGB must provide an Entity CLA, and the persons appointed by them as PGB members must provide an Individual CLA in order to serve. Members of OASIS who provide an Entity CLA must provide the signature (or assent) of their OASIS Primary Representative. Individuals who represent an organization also are required by the Individual CLA to obtain an Entity CLA for that organization.

17.2 While some nominal write-access privileges (such as adding issues and comments) may be granted automatically to the public by the Project Tools, only persons who have signed the CLA will be permitted to submit content other than comments or suggestions for Non-Material Changes.

17.3. Each person making a Project Repository contribution must be bound to the terms of the Individual CLA, by obtaining their signature (which may be an equivalent electronic assent) in a manner appropriate to the tools employed to implement that repository; and those signatures shall be recorded and maintained in an auditable manner. Organizational Entity CLA signatures must also be obtained, recorded and maintained in a similar manner.

17.4. Notices of the Applicable License applicable to each Project Repository shall be conspicuously visible both from each repository’s contribution channels (for potential submitters of material) and its home resource pages (for potential readers and users).

17.5 Each Repository and its contribution facility shall be conspicuously marked with the following Call for Patent Disclosure:

[OASIS requests that any party contact the OASIS Open Project Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of an OASIS Project Specification; and that any such claimant provide an indication of its willingness to grant a Specification Non-Assertion Covenant with respect to such patent claims, or otherwise to negotiate patent licenses free of charge with other parties on a non-discriminatory basis on reasonable terms and conditions.]

[OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in an OASIS Project Specification, or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.]

18. Appeals and Application of Rules

The appeals process provided in Section 4.2 of the OASIS TC Process also shall apply to the actions of the OASIS Open Project Administrator, which may be appealed as provided therein.

Changes to these rules shall apply to previously-established Open Projects upon their adoption. However, OASIS may not change the terms of any signed CLA once it has been delivered to OASIS; if a change is required a new CLA must be executed.

Appendix A-1: Individual CLA

OASIS Open Projects: Individual Contributor License Agreement (CLA)

[This is a verbatim display exhibit of the Web form, supplemented by several hyperlinks]

In order to contribute intellectual property into an OASIS Open Project, you must agree to be bound by the terms of this Agreement (“CLA”), so that it is clear what terms apply to your intellectual property contributions. This is a license by you as an individual, for your protection as a contributor as well as for the protection of OASIS Open and all who use the donated material. You are required to agree to this CLA before you contribute to any repository maintained by an OASIS Open Project. You can do so by completing the online form below.

Contributor information

Your personal name: *
Your email address: *
Your GitHub Username: *
Your physical mailing address, including country: *

Employer or affiliation information, if relevant

For a corporation, organization or other entity that has assigned employees or contractors to contribute to an OASIS Open Project, an Entity CLA also should be used for contributing any intellectual property owned by that entity. Signing of an Entity CLA does not remove the need for every developer or contributor to sign their own CLA as an individual, to cover any contributions not owned by the entity signing the Entity CLA.

Please provide your employer’s or organization’s name, if you are contributing material as part of your employment or engagement with them:

Employer or organization’s primary representative email address:

Agreement to License

This CLA applies to all material (“Contributions”), including any original work of authorship and any modifications or additions to an existing work, that you send, post or otherwise explicitly submit for inclusion in any OASIS Open Project, now and in the future. OASIS Open Projects are governed by the OASIS Open Project Rules, which may also affect the application of this CLA.

You agree to license all of your rights in each of your Contributions, under the terms of the specific “Applicable License” designated on the home page of the repository into which it is submitted, for the benefit of both OASIS and all later parties who that Applicable License benefits. Subject to the terms of this CLA, and without limiting the terms of the Applicable License, you also hereby grant to OASIS a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license (with the right to directly and indirectly sublicense) to prepare derivative works of, publicly display, publicly perform, and distribute each of your Contributions and such derivative works that Implement Or Derive From those Contributions (as defined in the Open Project Rules), and enable the implementation of the same by other parties.

You additionally agree to the terms of the Specification Non-Assertion Covenant set forth in the Open Project Rules, with respect to any claims licensable by you that are described in that covenant, on the terms and conditions set forth there, which apply in some cases to all contributors and in other cases only to Project Governing Board members. That covenant may be withdrawn or terminated by you as provided by those terms.

This is a license and non-assertion agreement only; it does not transfer ownership, and does not change your rights to use your own Contributions for any other purpose. You understand that OASIS, its members and the users of its Open Projects are not required to make any use of your Contributions. You represent that you have the all of the legal rights necessary to license each of your Contributions under the terms of the Applicable License and this CLA. If you are employed or are contributing your work-for-hire supplied to another party, you also represent that you have received any necessary permissions from your employer or that party to submit your Contributions and grant those licenses. Please note that you are responsible for assuring that your employer or that Party has executed an Entity CLA with OASIS, if their rights are contributed, and that an Open Project may choose to decline your contributions if those arrangements are not in place. If any part of your Contribution incorporates the original work of another party, you also represent that you have received all necessary rights and permissions from them to make the Contribution under the terms of the Applicable License.

Information and Disclosure

You agree that all OASIS Open Projects and their repositories are public, and that a record of your Contributions, including your identifying information and notices provided with them and in this CLA, may be permanently maintained and freely redistributed. OASIS guidelines and procedures for its Open Projects can be found at: https://www.oasis-open.org/policies-guidelines/open-projects-process-2018-05-22.

OASIS also calls your attention to the requests in the Call for Patent Disclosure contained in the Open Project Rules.

You agree to promptly notify OASIS by email to open-projects-cla@oasis-open.org if you become aware of any facts, changes or circumstances that would make your commitments and statements in this Entity CLA inaccurate in any way, or if you wish to withdraw from this CLA.

Processing this CLA

You may submit this CLA request by clicking the “Accept” button below. You should then receive an email message from open-projects-cla@oasis-open.org with the subject line “OASIS Open Projects: CLA Confirmation”. Please reply to that email message to confirm that the information submitted in the CLA form is correct and that you submitted the request. Approval of the CLA requires that you reply to the email message from open-projects-cla@oasis-open.org. Questions may also be submitted directly to OASIS Open Project Administration Staff at any time: send general questions to open-projects-admin@oasis-open.org and CLA-related questions to open-projects-cla@oasis-open.org.

Appendix A-2: Entity CLA

OASIS Open Projects: Entity Contributor License Agreement (CLA)

[This is a verbatim display exhibit of the Web form, supplemented by several hyperlinks]

In order to contribute intellectual property into an OASIS Open Project, individuals are required to be bound by the terms of our Contributor License Agreement, to agree to and make clear the terms that apply to their intellectual property contributions. In cases where that individual is participating and making contributions as your representative, using intellectual property that is owned by your company or organization, your company or organization (“you”) also should execute and return to OASIS this Entity Contributor License Agreement (“Entity CLA”). OASIS reserves the right to reject any contributions made by individuals who state that their contributions are owned by you, unless you provide an Entity CLA. You can do so by completing the online form below. Only a person who is authorized to commit the entity to a license agreement should submit this form.

This Entity CLA is a license by the company or organization listed below, for its protection as a contributor as well as for the protection of OASIS Open and all who use the contributed material. Signing this Entity CLA does not remove the need for every developer or contributor to sign their own CLA as an individual, to cover any contributions not owned by the entity signing the Entity CLA.

Entity information

Organization’s full legal name: *
Name of organization’s primary representative (person to be used for communications between OASIS and the organization regarding this Entity CLA): *
Representative’s email address: *
Representative’s physical mailing address, including country: *

Contributor information

Initial list of name, email, and GitHub Username of the designated employees or representatives whose contributions are subject to this Entity CLA:

CONTRIBUTORS
Name: *
Email: *
GitHub Username: *
[ ] Delete
[ ] Add another contributor

Agreement to License

This CLA applies to all material (“Contributions”), including any original work of authorship and any modifications or additions to an existing work, that your employees or other representatives designated by you send, post or otherwise explicitly submit for inclusion in any OASIS Open Project, now and in the future. OASIS Open Projects are governed by the OASIS Open Project Rules, which may also affect the application of this CLA.

You agree to license all of your rights in each of those Contributions, under the terms of the specific “Applicable License” designated on the home page of the repository into which it is submitted, for the benefit of both OASIS and all later parties who that Applicable License benefits. Subject to the terms of this Entity CLA, and without limiting the terms of the Applicable License, you also hereby grant to OASIS a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license (with the right to directly and indirectly sublicense) to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute each of those Contributions and such derivative works that Implement Or Derive From those Contributions (as defined in the Open Project Rules), and enable the implementation of the same by other parties.

You additionally agree to the terms of the Specification Non-Assertion Covenant set forth in the Open Project Rules, with respect to any claims licensable by you that are described in that covenant, on the terms set forth there, which apply in some cases to all contributors and in other cases only if your employee or other representative is a member of the Project Governing Board. That covenant may be withdrawn or terminated by you as provided by those terms.

This is a license and non-assertion agreement only; it does not transfer ownership, and does not change your rights to use your Contributions for any other purpose. You understand that OASIS, its members and the users of its Open Projects are not required to make any use of your Contributions.

You represent that you have the all of the legal rights necessary to license each of your Contributions under the terms of the Applicable License and this Entity CLA. If any part of your Contribution incorporates the original work of another party, you also represent that you have received all necessary rights and permissions from them to make the Contribution under the terms of the Applicable License.

Information and Disclosure

You agree that all OASIS Open Projects and their repositories are public, and that a record of your Contributions, including your identifying information and notices provided with them and in this Entity CLA, may be permanently maintained and freely redistributed. OASIS guidelines and procedures for its Open Projects can be found at: https://www.oasis-open.org/policies-guidelines/open-projects-process-2018-05-22.

OASIS also calls your attention to the requests in the Call for Patent Disclosure contained in the Open Project Rules.

You agree to promptly notify OASIS by email to open-projects-cla@oasis-open.org if you become aware of any facts, changes or circumstances that would make your commitments and statements in this Entity CLA inaccurate in any way, or if you wish to withdraw from this CLA. Among other things, you may modify the list of your designated employees or representatives whose contributions are subject to this Entity CLA by sending such a notice.

Processing this CLA

You may submit this CLA request by clicking the “Accept” button below. You should then receive an email message from open-projects-cla@oasis-open.org with the subject line “OASIS Open Projects: CLA Confirmation”. Please reply to that email message to confirm that the information submitted in the CLA form is correct and that you submitted the request. Approval of the CLA requires that you reply to the email message from open-projects-cla@oasis-open.org. Questions may also be submitted directly to OASIS Open Project Administration Staff at any time: send general questions to open-projects-admin@oasis-open.org and CLA-related questions to open-projects-cla@oasis-open.org.

This version of the OASIS Open Project (OP) Rules was approved by the OASIS Board of Directors on 29 June 2021 and became effective immediately. The change was announced to OASIS members on 09 July 2021 in https://lists.oasis-open.org/archives/members/202107/msg00002.html

Table of Contents

• 1. Purpose of Open Projects
• 2. Project Formation
• 3. Roles of Parties in the Project
• 4. Contributors
• 5. Project Governing Board and Project Sponsors
• 6. Technical Steering Committees
• 7. Project Chairs, Maintainers, and Technical Steering Committees
• 8. Repositories and Project Tools
• 9. Visibility and Archival Permanence
• 10. Project Governance: Decisions and Meetings
• 11. Progression of Project Work
• 12. Releases and Group Releases
• 13. Project Specifications
• 14. OASIS Standard Approval and External Submissions
• 15. Repository and Specification Licenses
• 16. Trademarks
• 17. CLAs and License Notices
• 18. Appeals and Application of Rules
• Appendix A-1: Individual CLA
• Appendix A-2: Entity CLA

1. Purpose of Open Projects

An OASIS Open Project (or Project) is a program hosted by OASIS for the development of code, specifications and other artifacts under open source licenses, under one or more of the Applicable Licenses listed in Section 15, and selected by the Project as specified below. OASIS Open Projects are conducted according to the provisions of these Rules. The OASIS Committee Operations Process provides general provisions concerning the operation of all committees that may apply to the work of a Project Governing Board (PGB). Certain defined terms used in this document have the meaning provided in the OASIS Defined Terms.

Any person or entity, whether or not an OASIS member, may participate in or contribute to a Project, as provided by these rules. Contributions, and the acceptance or merger of contributions into the Project’s work, are managed primarily through one or more open source Project Repositories (as defined in Section 8).

Projects operate under the administrative and process rules described in this document, and are administered by the OASIS Open Project Administrator designated by OASIS.

2. Project Formation

2.1 OASIS Open Projects are initiated by one or more organizations committed to being Project Sponsors and (optionally) persons who intend to make technical contributions to the Project. Any group of at least one or more Project Sponsors whose aggregate project sponsorship dues equal or exceed the minimum threshold established by a resolution of the OASIS Board of Directors, plus one or more named Contributors, may initiate a Project by submitting to the Open Project Administrator a Charter prepared using the Open Project Charter Template maintained and made available by the Open Project Administrator. Additional membership requirements apply to some approval activities as noted below. The Charter shall be written in English and provided to OASIS in electronic form as plain text. The name proposed for the Project shall be subject to approval by the Open Project Administrator for purposes of confirming infringement and appropriate use issues. If the proposed name includes a reference to an OASIS Technical Committee (TC) or specification title, or the name of another Open Project, then the approval of any open OASIS TC or Open Project who uses that name or has authored that specification is required in advance. No information other than that requested in the template may be included in the proposal. Any documents referenced in the proposal shall be publicly available.

The Charter must include a brief statement of purpose and a scope of work for the Project. The scope of work serves as a limit on the approval of Project Standards Track Work Products. The statement of purpose is only informative, not normative. The Charter also must state the number of Project Repositories initially requested to support the Project, and the Applicable License to be applied to each requested repository.

2.2 The Open Project Administrator shall reply in writing with its approval or other disposition of the proposal described above. OASIS shall post a public notice of each approved Project to its announced public mailing list.

2.3 After formation, the Charter of an Open Project may be amended only as provided in Section 5.6.

3. Roles of Parties in the Project

The work of a Project and its administration are conducted by parties who voluntarily contribute in one or more of the following defined roles: Contributor, Maintainer, Project Governing Board (PGB), Technical Steering Committee (TSC), and Chair. A detailed and definitive description of those roles follows in Sections 4, 5, 6 ,and 7 below. A table summarizing those roles can be found in the OASIS Committee Operations Process.

4. Contributors

4.1 Any person (whether or not an OASIS member) may participate in a Project as a Contributor by providing comments or bug reports to a Project Repository, subject to the licensing rules in Sections 14, 15 and 16 below.

4.2 Any person (whether or not an OASIS member) may agree to a Contributor License Agreement (CLA), as provided in the licensing rules below, as a prerequisite for acceptance of their pull requests or other substantive contributions. If a person who signs and submits an individual CLA indicates that they represent an entity, then that individual CLA will only be deemed effective if that entity has signed and submitted an entity CLA. The Project Governing Board and Maintainers shall only act on pull requests or other substantive contributions made by project Contributors who are listed in the OASIS system as having agreed to the relevant CLA. The Project shall maintain a record of all Contributors who have made contributions to a Project.

5. Project Governing Board and Project Sponsors

5.1 Overall guidance for the Project is provided by its Project Governing Board (or PGB). The PGB is composed of one voting member from each Project Sponsor who elects to appoint a PGB member, and at least one voting at-large expert representative from the community of contributors, elected or appointed by the Technical Steering Committee (TSC). The PGB may create additional PGB member seats for expert representatives to be elected by the TSC or appointed by the PGB.

A list of PGB members shall be maintained and posted at the general information web page designated by OASIS for the Project. Certain actions taken by the PGB require affirmative action by Project Approval Minimum Membership, as defined below.

5.2 PGB members must:

• (a) have signed and submitted an individual CLA, and if appointed by an entity, that entity must have signed and submitted an entity CLA naming that project; and
• (b) either (i) represent an organization that has paid the appropriate Backer dues for that Open Project or (ii) has been appointed or elected as an expert representative as provided above.

5.3 Project Approval Minimum Membership, where it explicitly is required for the PGB’s approval of an action under these rules, means at least two Project Sponsors seated on the PGB.

5.4 The PGB shall:

• (a) select one or two Chairs and may replace and remove Chairs as provided in Section 7
• (b) ensure there are one or more Maintainers for any Project Repository
• (c) consult with the Maintainer(s) on technical decisions as described below
• (d) establish and consult with its Technical Steering Committees (TSC)
• (e) approve any Draft Project Specifications, Project Specifications, candidates for OASIS Standards or external submissions from the Project, as provided in Sections 12 and 13

Decisions by the PGB shall be made in a manner consistent with the requirements of Section 10.

5.5 Status as a PGB member who represents an organization accrues to the organizational Project Sponsor, and is transferable by that Project Sponsor from person to person, as evidenced by a notice in writing from its Primary Representative to the OASIS Open Project Administrator. A Project Sponsor may resign from PGB membership at any time, by notifying the Open Project Administrator and the PGB Chair(s) in writing.

5.6 The PGB may amend the Charter after the Project’s formation in the following manner:

(a) An amendment to the binding scope of work may only be made for the purpose of removing ambiguity or for narrowing the scope of work, and requires a Special Majority Vote  of the PGB. Such an amendment may also at the PGB’s option update the statement of purpose, list of planned deliverables and/or list of repositories and licenses.
(b) Any amendment to other elements of the Charter may be made by a Full Majority Vote  of the PGB, so long as and any additions to the list of deliverables are within the scope of
work.
(c) In any case, any amended Charter must comply with the requirements of Section 2.1, and shall not take effect until approved by the PGB and announced by the Open Project Administrator.

6. Technical Steering Committees

The PGB shall form a Technical Steering Committee (or TSC) by a resolution of the PGB. A Project’s TSC members shall be composed of the persons, selected in the manner, and chaired by such person as is provided by that resolution. The PGB must create and publish process documentation, outlining the requirements for joining and voting in the project’s TSC. The TSC shall have the duties to advise the PGB and such others as are specified by the PGB, so long as consistent with these Rules and OASIS policies. The following activities may not be delegated by the PGB, although it may consult with the TSC regarding them at the PGB’s option: election or termination of PGB Chairs, approval of any Releases, Group Releases, Project Specification Drafts, Project Specifications, and approval of candidates for OASIS Standards or external submissions.

TSC members must have signed and submitted an individual CLA, and if appointed by an entity, that entity must have signed and submitted an entity CLA. A list of TSC members shall be maintained and posted at the general information web page designated by OASIS for the Project. An individual may resign from TSC membership at any time, by notifying the Open Project Administrator and the Chair(s) in writing.

7. Project Chairs and Maintainers

7.1 The PGB shall select one or two of its members as Chairs by a Full Majority Vote, to coordinate and manage Project decision-making and logistics. The PGB may remove a Chair at any time by a Full Majority Vote. The Chair(s) of the Project shall:

• (a) be responsible for the coordination and polling of any decisions of the PGB
• (b) convene and make arrangements for any desired virtual or physical face-to-face meetings of the PGB and/or Contributors
• (c) assist and support the Maintainer(s) as appropriate
• (d) be responsible as the Project’s principal point of contact with OASIS staff and resources as needed
• (e) manage or provide for the management of communications with Contributors, any liaisons and the public as may be desirable in support of the Project’s goals.

If a PGB does not have at least one Chair then all PGB activities, with the exception of the selection of a new Chair, are suspended. If a PGB does not have a Chair for 180 days, the Open Project Administrator may declare the PGB closed. After closure of the PGB, the Project may no longer take actions that require the approval of the PGB.

7.2 The PGB shall ensure that there are one or more Maintainers to serve as the principal editor(s) of the Project’s technical work managed within its Project Repositories. Maintainers shall exercise editorial responsibility over the contents of the Project’s repositories, including by:

• (a) evaluating and responding to pull requests
• (b) designating main or recommended branches of each repository
• (c) designating deprecated branches or contributions.

Maintainers should act to carry out the technical consensus of the TSC, Contributors, and PGB, and may be removed by the PGB at any time, after notice to the Maintainer and the TSC, for failure to perform their functions as determined by the PGB. No contributed information or pull requests may be deleted from any Project Repository, due to the open nature of the Applicable Licenses and the Archival Permanence rules in Section 9.2. The appointment of a Maintainer survives the closure of the PGB, and thereafter the remaining Maintainer(s) or the Open Projects Administrator may appoint additional or replacement Maintainers.

8. Repositories and Project Tools

8.1 OASIS will create and support official repositories for each Project (Project Repositories) using tools, selected and configured by staff that are clearly marked as a distinct resource. OASIS will initialize each Project Repository as a distinct open source project, including issue tracking, comment facilities, and such other facilities as are normally available by default.

8.2 The Project’s official Project Tools include the Project’s Repositories and these additional tools: A principal web page for each Project, which may be the home resource page of the Project’s first Project Repository, and optionally, one or more mailing lists for administration of the Project. Subscription to such lists, which shall be subject to the OASIS Mailing List Guidelines, shall be open to anyone.

9. Visibility and Archival Permanence

9.1 Visibility. Contributions, comments, decisions, records of decisions and all other resources of the Project, including web pages, documents, mailing lists and any other records of discussions, must be located only on the Project Tools designated or authorized by OASIS. Projects may not conduct official business or technical discussions, store documents, or host web pages on servers or systems not designated by OASIS. All Project Tools shall be publicly visible, and all threaded and mail list discussions shall be publicly archived.

9.2 Archival Permanence. OASIS warrants that it will not inhibit open and free access to all of the material contributed to each Project Repository, as open and freely available resources. This warranty is perpetual and will not be revoked by OASIS or its successors or assigns; however, neither OASIS nor its assigns shall be obligated to:

• (a) perpetually maintain its own existence, nor
• (b) provide for the perpetual existence of a website or other public means of accessing such material, nor
• (c) maintain any material which it is legally required to remove from publication.

Some contributed material may be treated as superseded or deprecated by Maintainers or by version control methods, as provided in these rules, but neither Maintainers nor any other party shall delete content. The original form of each contribution shall continue to be available for review, and use according to its licensure, through appropriate version control or document management methodologies.

9.3 Repository Lifecycle. Once a Project Repository has been created, it will remain open as a resource for public use and reference, and continuing repository contributions or comments, regardless of closure of the Project, under the Archival Permanence rule above, with such remaining Maintainers as may have been appointed.

9.4 Announcements. The Open Project Administrator shall create a publicly archived, subscribable list for announcements and public notices from OASIS regarding Open Projects. Every important change in Project status shall be posted to that list, including Project formation; opening of a new Project Repository; Releases; Group Releases; Draft Project Specifications; Project Specifications; Candidate OASIS Standards; and proposed external submissions.

10. Project Governance: Decisions and Meetings

10.1 Decisions by the PGB regarding the matters allocated to them by these rules normally should be made after reasonable notice to and consultation with the Project’s Contributors, and should be made by consensus except in cases where a specific majority vote is required by these rules. The Chair(s) of the Project are responsible for conducting and administrating the decision processes of the PGB and the Project, consistent with these rules.

10.2 Meetings of the PGB and any TSC must be properly called by the Chair(s) and scheduled in advance using the OASIS collaborative communication Project Tools. Meetings may be conducted face-to-face or via telephone conference or other electronic media that allow participation of all PGB members. In order to enable the openness of proceedings, meetings also should be scheduled and conducted to permit the presence of as many Contributors as is logistically feasible. A note of each meeting’s outcomes must be posted to a publicly accessible location provided by OASIS. Meetings or decisions scheduled or conducted so as to exclude the participation of any PGB member or Contributor are subject to appeal to the Open Project Administrator.

10.3 Electronic ballots of the PGB, when required by these rules, must be conducted on facilities provided or approved by OASIS, and must remain open for a minimum period for seven days. The Chair(s) may specify a longer voting period for a particular electronic ballot. Eligible voters may change their vote up until the end of the voting period.

11. Progression of Project Work

11.1 In addition to making available the contributions provided by Contributors, via their Project Repositories, Projects may designate specific portions of their output as official Releases, Group Releases, Project Specification Drafts or Project Specifications, and nominate them for further advancement, on the terms set forth in Sections 11, 12, 13 and 14.

12.2 Where the PGB or a consensus among the Contributors indicates that a specific set of contributions should be formally considered as a Release, Group Release, Draft Project Specification or Project Specification, then in preparation for that consideration, the Maintainers shall arrange the relevant material in the relevant Project Repository or repositories so that the set can be accessed and referenced as a distinct branch (a Designated Branch).

12. Releases and Group Releases

12.1 Releases. The PGB may act to approve a Designated Branch as an official Release of the Project, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules. Any product of the Project that is composed from contributions to the Project Repositories, of any nature, is eligible for approval as a Release of the Project.

12.2 Group Releases. When desirable to aggregate outputs, the PGB may act to approve any set of the Project’s Releases or subsets of Releases as an official Group Release of the Project, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules. Group Releases may include multiple Releases that bear different Applicable Licenses. Aggregate contributions by Maintainers or others which are prepared as potential Project Specifications should instead be approved as Project Specification Drafts, as provided below.

12.3 Licensing. Releases and Group Releases bear only the license rights and covenants provided for each of the contributions included there, as evidenced by the relevant repositories’ Applicable License(s) and the CLAs.

13. Project Specifications

13.1 In order to progress a Release or Group Release by the Project as a Project Specification Draft (or PSD) or a Project Specification (or PS), the PGB and the contents of the release(s) must satisfy the additional criteria of this Section.

13.2 In order to be advanced through the approval process, a proposed Project Specification must conform to the Project Specification template provided by the Open Project Administrator, which includes methods for indicating the relevant Designated Branches and Applicable Licenses. Proposed Project Specification Drafts also should conform to that template, to the extent possible.

13.3 Project Specification Drafts. A PGB having at least Project Approval Minimum Membership may act to approve any set of contributions to the Project, including from its Releases or Group Releases, as an official Project Specification Draft, after giving notice to all Contributors via the Project Tools at least fourteen days prior to initiating a PGB vote or consensus call. Such approval decisions are subject to the process, notice and transparency provisions of these rules.

13.4 Project Specifications. A PGB having at least Project Approval Minimum Membership may act to approve any Project Specification Draft as a Project Specification, by satisfying each of the following requirements:

• (a) Written notice of that nomination must be given by the PGB to all those involved with the Project and the Open Project Administrator at least fourteen days prior to initiating a ballot. The ballot must be conducted by a Special Majority Vote of the PGB. The approval decision is subject to the process, notice and transparency rules set forth in these rules and the content requirements noted below.
• (b) Any machine-executable instructions in a specific computer language (code) that are included in the Project Specification must be composed only of one or more Releases or Group Releases bearing Implementer-Class Licenses.
• (c) Any guidance, descriptions, processes, models for the behavior of a system or service, or other content that is not machine-executable, and is included in the Project Specification, must be composed only of contributions (which may include Releases or Group Releases) previously made to a Project Repository.
• (d) The proposed Project Specification will be subject to review and confirmation of conformance by the Open Project Administrator before the approval ballot is opened.

13.5 Upon successful conclusion of the Special Majority Vote, the Open Project Administrator must give public written notice thereof, which constitutes approval, and thereafter will publish the Project Specification to the OASIS Library.

13.6 Licensing. Project Specifications bear the license rights and covenants provided for each contribution included there, as evidenced by the relevant repositories’ Applicable License(s) and the CLAs, as well as the Specification NonAssertion Covenant. Project Specifications may bear more than one Applicable License, when composed from Releases or Group Releases from multiple Project Repositories that have different Applicable Licenses.

13.7 Implementations of all kinds are welcome (partial or complete; prototype, proof-of-concept, example, model, or reference implementations), provided that PGBs may not designate any single implementation of a Project Specification as exclusive or privileged.

14. OASIS Standard Approval and External Submissions

Project Specifications are eligible for and may be submitted for approval as OASIS Standards, under the following conditions:

• (a) After three Statements of Use referencing the PS have been presented to the PGB, a PGB having at least Project Approval Minimum Membership may approve the PS as a candidate for OASIS Standard in the same manner, and subject to the same requirements, as apply to Committee Specifications as provided in Section 3.8 Approval of an OASIS Standard of the OASIS TC Process. Procedural requirements applicable to TCs in that rule apply to the PGB for this purpose, including the Special Majority Vote required to nominate a Project Specification for OASIS Standard. However, a candidate for OASIS Standard submitted by an Open Project shall be subject to the distinct licensing terms in these rules, and not the licensing terms in the OASIS IPR Policy for TCs.
• (b) Upon a successful conclusion of that PGB vote and all other requirements, the OASIS TC Administrator shall proceed with public review and a call for consent as provided in Sections 3.8.2 and 3.8.3 of the OASIS TC Process. An OASIS Standard submitted by an Open Project and approved as provided above is eligible for further external submissions as provided in and subject to the requirements in the OASIS Liaison Policy. The PGB must have at least Project Approval Minimum Membership at the time of any such action or approval; the other procedural requirements applicable to TCs in that policy apply to the PGB for this purpose.

15. Repository and Specification Licenses

15.1 Applicable Licenses; Copyright Implementation Licenses. Each Project Repository will be subject to a declared Applicable License, selected from the list of licenses in this section. Each Contributor agrees in the CLA to grant the Applicable License designated for a repository to all contributions donated to that repository by posting it or requesting its inclusion in that repository, and to all Releases issued from that repository.

Anyone may offer comments to any Project Repository, on the terms of the foregoing licenses, as evidenced in the manner noted below. Anyone will be entitled to make use of the contents of a Project Repository, according to the terms of its Applicable License.

15.2 When requesting the creation of a Project Repository, the PGB must select that repository’s Applicable License from among the following list:

• (a) Implementer-Class Licenses: Apache License v2.0; Eclipse Public License v1.0; Eclipse Public License 2.0; BSD-3-Clause License; CC-BY 2.0; CC-BY 4.0; MIT License.
• (b) Other available licenses: CC-0.

Other widely-used free and open source licenses may be added to this list after review and acceptance by OASIS and amendment of these rules.

15.3 Special Covenants for Project Specifications. In addition to the Applicable License for each Project Repository, each Contributor also agrees in the CLA to provide the additional covenants in this Section 15.3, as non-assertion covenants in favor of certain Project Specifications (collectively the Specification NonAssertion Covenant):

Contributor Covenant for Specifications. As a Contributor, you irrevocably covenant that you will not assert any patent claims licensable by you that are necessarily infringed by an implementation of your contribution to the extent that contribution is included in a Project Specification approved by the Open Project to which you made the contribution, against OASIS or any other parties who the Applicable License benefits, for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing works that Implement or Derive From your contribution.

PGB Covenant for Specifications. For any Project Repository whose Applicable License is an Implementer-Class License, if you (or your representative) are a member of that Open Project’s Governing Board, you irrevocably covenant that you will not assert any patent claims licensable by you that are necessarily infringed by an implementation of a Project Specification approved by that Open Project within the scope of work of its Charter in effect at the time such deliverable was approved, and any Maintenance Deliverable approved for it, against OASIS or any other parties who the Applicable License benefits, for making, having made, using, marketing, importing, offering to sell, selling, and otherwise distributing works that Implement or Derive From that Project Specification and are compliant with all normative portions thereof. If you withdraw from the PGB, then this obligation continues to apply, but only with respect to those Project Specification Drafts approved more than 7 calendar days prior to your withdrawal, and to any Maintenance Deliverables approved for those specifications thereafter.

Scope of Implementations Benefited. As used in this covenant, works that “Implement or Derive From” a contribution or specification include:

• (a) specifications to the extent derived from code
• (b) independent code implementations of a specification
• (c) independent code implementations of a specification to the extent the specification is derived from code.

For purposes of this definition, “specifications” include documentation, data flows, data formats, application programming interfaces and process descriptions.

Withdrawal from Covenant. Your Specification NonAssertion Covenant may be suspended or revoked by you with respect to any person who alleges in writing or files a suit asserting that your Contribution, or the work to which you have contributed, constitutes direct or contributory patent infringement.

16. Trademarks

In order to incorporate a trademark or service mark into a Project, including its use in the name of an OASIS Open Project or any Release, or its inclusion in the body of such work, that mark must be:

• (a) owned by OASIS; or
• (b) otherwise as approved by the OASIS Board of Directors.

No person may use an OASIS trademark or service mark in connection with an Open Project, a Release or otherwise, except in compliance with the Applicable License for a Release or otherwise according to such license and usage guidelines as OASIS may from time to time require.

17. CLAs and License Notices

17.1 A Contributor License Agreement (or CLA) shall bind each donor of a repository contribution, issue or comment of any kind to the repository’s Applicable License. All Contributions to Project Repositories shall be subject to an Individual CLA, in the form of Appendix A-1 to these rules, by which all persons making those Contributions are bound. Where Contributions are made by or on behalf of an organization, the responsible individual will designate that organization in their Individual CLA, and that organization will be asked to provide an Entity CLA, in the form of Appendix A-2 to these rules. If that Entity CLA is not obtained, OASIS and the Project must decline contributions from that individual.

Project Sponsors who appoint a member to the PGB must provide an Entity CLA, and the persons appointed by them as PGB members must provide an Individual CLA in order to serve.

Members of OASIS who provide an Entity CLA must provide the signature (or assent) of their OASIS Primary Representative. Individuals who represent an organization also are required by the Individual CLA to obtain an Entity CLA for that organization.

17.2 While some nominal write-access privileges (such as adding issues and comments) may be granted automatically to the public by the Project Tools, only persons who have signed the CLA will be permitted to submit content other than comments or suggestions for Non-Material Changes.

17.3. Each person making a Project Repository contribution must be bound to the terms of the Individual CLA, by obtaining their signature (which may be an equivalent electronic assent) in a manner appropriate to the tools employed to implement that repository; and those signatures shall be recorded and maintained in an auditable manner. Organizational Entity CLA signatures must also be obtained, recorded and maintained in a similar manner.

17.4. Notices of the Applicable License applicable to each Project Repository shall be conspicuously visible both from each repository’s contribution channels (for potential submitters of material) and its home resource pages (for potential readers and users).

17.5 Each Repository and its contribution facility shall be conspicuously marked with the following Call for Patent Disclosure:

[OASIS requests that any party contact the OASIS Open Project Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of an OASIS Project Specification; and that any such claimant provide an indication of its willingness to grant a Specification Non-Assertion Covenant with respect to such patent claims, or otherwise to negotiate patent licenses free of charge with other parties on a non-discriminatory basis on reasonable terms and conditions.]

[OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in an OASIS Project Specification, or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.]

18. Appeals and Application of Rules

The appeals process provided in Section 4.2 of the OASIS TC Process also shall apply to the actions of the OASIS Open Project Administrator, which may be appealed as provided therein.

Changes to these rules shall apply to previously-established Open Projects upon their adoption. However, OASIS may not change the terms of any signed CLA once it has been delivered to OASIS; if a change is required a new CLA must be executed.

Appendix A-1: Individual CLA

OASIS Open Projects: Individual Contributor License Agreement (CLA)

[This is a verbatim display exhibit of the Web form, supplemented by several hyperlinks]

In order to contribute intellectual property into an OASIS Open Project, you must agree to be bound by the terms of this Agreement (“CLA”), so that it is clear what terms apply to your intellectual property contributions. This is a license by you as an individual, for your protection as a contributor as well as for the protection of OASIS Open and all who use the donated material. You are required to agree to this CLA before you contribute to any repository maintained by an OASIS Open Project. You can do so by completing the online form below.

Contributor information

Your personal name: *
Your email address: *
Your GitHub Username: *
Your physical mailing address, including country: *

Employer or affiliation information, if relevant

For a corporation, organization or other entity that has assigned employees or contractors to contribute to an OASIS Open Project, an Entity CLA also should be used for contributing any intellectual property owned by that entity. Signing of an Entity CLA does not remove the need for every developer or contributor to sign their own CLA as an individual, to cover any contributions not owned by the entity signing the Entity CLA.

Please provide your employer’s or organization’s name, if you are contributing material as part of your employment or engagement with them:

Employer or organization’s primary representative email address:

Agreement to License

This CLA applies to all material (“Contributions”), including any original work of authorship and any modifications or additions to an existing work, that you send, post or otherwise explicitly submit for inclusion in any OASIS Open Project, now and in the future. OASIS Open Projects are governed by the OASIS Open Project Rules, which may also affect the application of this CLA.

You agree to license all of your rights in each of your Contributions, under the terms of the specific “Applicable License” designated on the home page of the repository into which it is submitted, for the benefit of both OASIS and all later parties who that Applicable License benefits. Subject to the terms of this CLA, and without limiting the terms of the Applicable License, you also hereby grant to OASIS a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license (with the right to directly and indirectly sublicense) to prepare derivative works of, publicly display, publicly perform, and distribute each of your Contributions and such derivative works that Implement Or Derive From those Contributions (as defined in the Open Project Rules), and enable the implementation of the same by other parties.

You additionally agree to the terms of the Specification Non-Assertion Covenant set forth in the Open Project Rules, with respect to any claims licensable by you that are described in that covenant, on the terms and conditions set forth there, which apply in some cases to all contributors and in other cases only to Project Governing Board members. That covenant may be withdrawn or terminated by you as provided by those terms.

This is a license and non-assertion agreement only; it does not transfer ownership, and does not change your rights to use your own Contributions for any other purpose. You understand that OASIS, its members and the users of its Open Projects are not required to make any use of your Contributions. You represent that you have the all of the legal rights necessary to license each of your Contributions under the terms of the Applicable License and this CLA. If you are employed or are contributing your work-for-hire supplied to another party, you also represent that you have received any necessary permissions from your employer or that party to submit your Contributions and grant those licenses. Please note that you are responsible for assuring that your employer or that Party has executed an Entity CLA with OASIS, if their rights are contributed, and that an Open Project may choose to decline your contributions if those arrangements are not in place. If any part of your Contribution incorporates the original work of another party, you also represent that you have received all necessary rights and permissions from them to make the Contribution under the terms of the Applicable License.

Information and Disclosure

You agree that all OASIS Open Projects and their repositories are public, and that a record of your Contributions, including your identifying information and notices provided with them and in this CLA, may be permanently maintained and freely redistributed. OASIS guidelines and procedures for its Open Projects can be found at: https://www.oasis-open.org/policies-guidelines/open-projects-process-2018-05-22.

OASIS also calls your attention to the requests in the Call for Patent Disclosure contained in the Open Project Rules.

You agree to promptly notify OASIS by email to open-projects-cla@oasis-open.org if you become aware of any facts, changes or circumstances that would make your commitments and statements in this Entity CLA inaccurate in any way, or if you wish to withdraw from this CLA.

Processing this CLA

You may submit this CLA request by clicking the “Accept” button below. You should then receive an email message from open-projects-cla@oasis-open.org with the subject line “OASIS Open Projects: CLA Confirmation”. Please reply to that email message to confirm that the information submitted in the CLA form is correct and that you submitted the request. Approval of the CLA requires that you reply to the email message from open-projects-cla@oasis-open.org. Questions may also be submitted directly to OASIS Open Project Administration Staff at any time: send general questions to open-projects-admin@oasis-open.org and CLA-related questions to open-projects-cla@oasis-open.org.

Appendix A-2: Entity CLA

OASIS Open Projects: Entity Contributor License Agreement (CLA)

[This is a verbatim display exhibit of the Web form, supplemented by several hyperlinks]

In order to contribute intellectual property into an OASIS Open Project, individuals are required to be bound by the terms of our Contributor License Agreement, to agree to and make clear the terms that apply to their intellectual property contributions. In cases where that individual is participating and making contributions as your representative, using intellectual property that is owned by your company or organization, your company or organization (“you”) also should execute and return to OASIS this Entity Contributor License Agreement (“Entity CLA”). OASIS reserves the right to reject any contributions made by individuals who state that their contributions are owned by you, unless you provide an Entity CLA. You can do so by completing the online form below. Only a person who is authorized to commit the entity to a license agreement should submit this form.

This Entity CLA is a license by the company or organization listed below, for its protection as a contributor as well as for the protection of OASIS Open and all who use the contributed material. Signing this Entity CLA does not remove the need for every developer or contributor to sign their own CLA as an individual, to cover any contributions not owned by the entity signing the Entity CLA.

Entity information

Organization’s full legal name: *
Name of organization’s primary representative (person to be used for communications between OASIS and the organization regarding this Entity CLA): *
Representative’s email address: *
Representative’s physical mailing address, including country: *

Contributor information

Initial list of name, email, and GitHub Username of the designated employees or representatives whose contributions are subject to this Entity CLA:

CONTRIBUTORS
Name: *
Email: *
GitHub Username: *
[ ] Delete
[ ] Add another contributor

Agreement to License

This CLA applies to all material (“Contributions”), including any original work of authorship and any modifications or additions to an existing work, that your employees or other representatives designated by you send, post or otherwise explicitly submit for inclusion in any OASIS Open Project, now and in the future. OASIS Open Projects are governed by the OASIS Open Project Rules, which may also affect the application of this CLA.

You agree to license all of your rights in each of those Contributions, under the terms of the specific “Applicable License” designated on the home page of the repository into which it is submitted, for the benefit of both OASIS and all later parties who that Applicable License benefits. Subject to the terms of this Entity CLA, and without limiting the terms of the Applicable License, you also hereby grant to OASIS a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license (with the right to directly and indirectly sublicense) to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute each of those Contributions and such derivative works that Implement Or Derive From those Contributions (as defined in the Open Project Rules), and enable the implementation of the same by other parties.

You additionally agree to the terms of the Specification Non-Assertion Covenant set forth in the Open Project Rules, with respect to any claims licensable by you that are described in that covenant, on the terms set forth there, which apply in some cases to all contributors and in other cases only if your employee or other representative is a member of the Project Governing Board. That covenant may be withdrawn or terminated by you as provided by those terms.

This is a license and non-assertion agreement only; it does not transfer ownership, and does not change your rights to use your Contributions for any other purpose. You understand that OASIS, its members and the users of its Open Projects are not required to make any use of your Contributions.

You represent that you have the all of the legal rights necessary to license each of your Contributions under the terms of the Applicable License and this Entity CLA. If any part of your Contribution incorporates the original work of another party, you also represent that you have received all necessary rights and permissions from them to make the Contribution under the terms of the Applicable License.

Information and Disclosure

You agree that all OASIS Open Projects and their repositories are public, and that a record of your Contributions, including your identifying information and notices provided with them and in this Entity CLA, may be permanently maintained and freely redistributed. OASIS guidelines and procedures for its Open Projects can be found at: https://www.oasis-open.org/policies-guidelines/open-projects-process-2018-05-22.

OASIS also calls your attention to the requests in the Call for Patent Disclosure contained in the Open Project Rules.

You agree to promptly notify OASIS by email to open-projects-cla@oasis-open.org if you become aware of any facts, changes or circumstances that would make your commitments and statements in this Entity CLA inaccurate in any way, or if you wish to withdraw from this CLA. Among other things, you may modify the list of your designated employees or representatives whose contributions are subject to this Entity CLA by sending such a notice.

Processing this CLA

You may submit this CLA request by clicking the “Accept” button below. You should then receive an email message from open-projects-cla@oasis-open.org with the subject line “OASIS Open Projects: CLA Confirmation”. Please reply to that email message to confirm that the information submitted in the CLA form is correct and that you submitted the request. Approval of the CLA requires that you reply to the email message from open-projects-cla@oasis-open.org. Questions may also be submitted directly to OASIS Open Project Administration Staff at any time: send general questions to open-projects-admin@oasis-open.org and CLA-related questions to open-projects-cla@oasis-open.org.