Other

OASIS Committee Operations Process

This version of the OASIS Committee Operations Process was approved by the OASIS Board of Directors on 03 November 2017 and became effective immediately.

The previous version was approved by the OASIS Board of Directors on 26 May 2017 and became effective 01 July 2017. The change was announced to OASIS members on 23 June 2017 in https://lists.oasis-open.org/archives/members/201706/msg00008.html.

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: ObserverMemberVoting Member, or Persistent Non-Voting Members. The following table summarizes these roles.

ObserverMemberPersistent
Non-Voting Member
Voting Member
Can attend meetingsYESYESYESYES
Can participate in meetingsNOYESYESYES
Receives email from TC listYESYESYESYES
Can send email to TC listNOYESYESYES
Can contribute documents, etc.NOYESYESYES
Can use JIRA, Wiki, etc.NOYESYESYES
Can gain voting rightsNOYESNO (must first become a Member)N/A
Can lose voting rightsNONONOYES
Has voting rightsNONONOYES
Counts towards quorumNONONOYES
Can make & second motionsNONONOYES
Is publicly listed on TC roster, minutes, etcNOYESYESYES
Is obligated by TC IPR ModeNOYESYESYES

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.

ParticipantContributorMaintainerProject Governing Board (PGB)Chair
Functions
May provide comments and bug reportsYESYESYESYESYES
May submit pull requestsNOYESYESYESYES
Respond to pull requests, etc.NONOYESNONO
Appoint and supervise Maintainer(s)NONONOYESN/A
Authorize creation of repositoriesNONONOYESN/A
Approve releasesNONONOYESN/A
Approve submissions of qualifying releases for Project Specification approvals (as defined below)NONONOYESN/A
Approve external submissions of its OASIS Standards (if any) to de jure standards bodiesNONONOYESN/A
Elect ChairNONONOYESN/A
Call and preside over any meetingsNONONONOYES
Requirements
Must be OASIS MemberNONONOYESYES
Must sign Contributor License Agreement (CLA)NOYESYESYESYES

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.

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 and 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 and referenced on the committee web page.

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, either by using the committees general mail list or the publicly archived electronic voting functionality provided by OASIS. An electronic ballot 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 AdministratorOP 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.

Open Repository Guidelines and Procedures

  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

OverviewOASIS 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-AssertionRF 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.

Open Projects Advisory Council Terms of Reference

The OASIS Open Projects Advisory Council works to create a more transparent and collaborative future for industry, open standards, and open source. OASIS Open Projects Advisory Council members are volunteers, who bring their unique, expert, and diverse perspectives for how that future can be built for the betterment of all.

Advisory Council Goals

The goal of the Open Projects Advisory Council is to influence the direction of OASIS by providing strategic insight and advice to OASIS staff, Board of Directors, and the community at-large, on the needs of open source and open standards projects and the industries they support. In particular, the Open Projects Advisory Council will:

  • Curate a vision of Open Source and Open Standards, and help OASIS deliver that vision.
  • Leverage their experience to advise on good and bad practices throughout a project lifecycle.
  • Monitor the execution of Open Projects and advise on policy and governance changes and additions.
  • Assist in building up a diverse community under the OASIS umbrella to include a wide range of perspectives from people of different race, gender, age, background, industry, and geographic location.
  • Foster open, inclusive community discussions on issues and the future of open practices.

Participation

Members of the Open Projects Advisory Council:

  • Are expected to attend quarterly calls and respond to infrequent emails, wherein they give advice to OASIS on different matters.
  • Do not have a fiduciary responsibility to OASIS and may or may not be otherwise be active in OASIS programs.
  • Are invited to join the Council by the Open Projects Administrator. Affiliation with an Open Project is not required.
  • Generously contribute their time for the good of the community and are not paid by OASIS for their service.
  • Serve for two-year terms that may be renewed on mutual agreement. AC Members may resign their membership at any time for any reason.

These Terms of Referece were approved by the OASIS Board of Directors on 11 April 2019.

Foundation-as-a-Service Operating Rules

Table of Contents

1. Overview
2. Establishment of Host LLC
3. Host LLC Governance and Administration
4. Host LLC Financial Controls
5. Creating a Foundation
6. Foundation Operation, Bylaws, and Governance
7. Foundation Financial Controls
8. Foundation Contract Administration
9. Foundation Inactivity or Termination
10. Foundation Data Availability
11. Foundation Visibility and Branding
12. Changes to these Operating Rules

1. Overview.

The OASIS Foundation-as-a-Service program provides corporate and legal infrastructure and fiscal agency services that enable groups to quickly form and run their own Foundations for advancing open source code, standards and related activities. OASIS created the Foundation-as-a-Service program for groups that wish to run as separate, freestanding development entities, hosted with OASIS assistance, but with separate brand identity, membership, and rules. Foundation-as-a-Service groups maintain their independence while enjoying the benefits of OASIS’ nonprofit corporate structure. By providing Foundations with a legal umbrella and administrative services, the Foundation-as-a-Service program helps groups grow, attract members, collect funds, support developers, hold copyrights, and much more.

2. Establishment of Host LLC.

OASIS Open, a global consortium organized as a nonprofit Pennsylvania corporation (“OASIS“), formed the OASIS Open Development Foundation LLC, a Delaware nonprofit Series Limited Liability Company (the “Host LLC“), as an independent hosting structure for freestanding nonprofit technical Foundations, hosted with OASIS assistance but with separate brand identities.

3. Host LLC Governance and Administration.

The Host LLC is governed by the terms of its Certificate of Formation and a Limited Liability Company Agreement prepared by OASIS counsel and approved by the OASIS Board (as defined below). Those company documents provide that: (a) OASIS is the sole member of the Host LLC, with authority to appoint the Managers of the Host LLC; (b) the OASIS Board initially shall appoint three Managers for the Host LLC; (c) the administration of the Host LLC shall be performed by OASIS staff under a master service contract with the Host LLC as described below; and (d) the operations and purposes of the Host LLC are limited to nonprofit activities. The Host LLC is a nonprofit subsidiary controlled by, but distinct from OASIS, so that the operations, accounts, assets, contracts and liabilities of the Host LLC, and those of any Foundation (as defined below) hosted by the Host LLC, are isolated and separate from the operations, accounts, assets, contracts and liabilities of OASIS. OASIS delegates day-to-day management of the Host LLC to the Host LLC’s Managers. The Host LLC Managers are appointed by the OASIS Board of Directors (“OASIS Board“) and may be removed or replaced at any time by the OASIS Board. A majority of the Host LLC’s Managers shall be persons acting under the direction of OASIS. The OASIS Board may appoint as Managers a minority of one or more persons from other stakeholders as it may deem appropriate. The Host LLC Managers act as stewards for the Host LLC and shall review the administrative work performed by OASIS staff under the Master Contract (as defined below), but shall defer to each Foundation Board (as defined below) on matters related to that Foundation’s activities and expenditures so long as they conform to applicable laws and the rules, budgets and procedures described herein. The Host LLC shall enter into a master administrative services contract with OASIS (the “Master Contract“), under which OASIS staff shall provide each Foundation with administrative assistance and operational and financial control services including those described below, in return for compensation to be agreed between OASIS and the Host LLC. The Host LLC also must comply with the OASIS conflict of interest, antitrust, whistleblower, and document retention and destruction policies and the OASIS privacy statement.

4. Host LLC Financial Controls.

The financial activities and budget of the Host LLC itself is administered on a day-to-day basis by OASIS staff under the Master Contract. Those administrative actions are reviewed and subject to approval by the Host LLC Managers. The funds of the Host LLC shall be deposited in, and its expenses paid from, accounts separate from those of OASIS, capable of being separately audited and, if OASIS so elects, subject to separate tax identification numbers. However, OASIS reserves the right to report its activities for tax purposes as a consolidated entity with the Host LLC and to perform any independent audit of the separate accounts of the Host LLC, or any series, or as a part of a consolidated audit or review. The Host LLC’s annual budget includes income items for (a) an administrative fee (“Hosting Fee“) collected from the Foundation Dues paid by each Foundation, based on a percentage scale or as otherwise set by the Host LLC, and (b) projected income and costs from administrative services provided to each Foundation. All accounting controls and policies employed by OASIS, including all rules relating to nonprofit status and appropriate legal purposes, are also applied to the operations and expenditures of the Host LLC. The operations, projections, and financial results of the Host LLC (and summary Foundation reporting) are included in the monthly operating reports and regular financial reporting provided by OASIS.

5. Creating a Foundation.

Each group supported by the Foundation-as-a-Service program (“Foundation“) is established as a distinct series (company sub-entity) of the Host LLC. A Foundation must be formally proposed by parties committed to join the group as initial members (“Foundation Proposers“). The following documents (collectively, the “Foundation Proposal“)​ are prepared by the Foundation Proposers and reviewed by OASIS staff for economic feasibility, nonprofit eligibility, and suitability to the Host LLC.

  • bylaws (as defined below);
  • budget, including projected financial statements for the first full year, membership categories, and dues schedule;
  • existing contracts with service providers, independent contractors or employees that will be assumed by or replaced in the Foundation, if any;
  • known risks or any anticipated legal issues;
  • planned activities;
  • prior operational history of a predecessor program, if any; and
  • such other matters as the Host LLC or Foundation Proposers determine are relevant.

The OASIS staff prepare a confidential feasibility assessment for each new proposed Foundation (the “Feasibility Summary“), including pro forma financials, for review by the Host LLC Managers. The recommendation of the Host LLC Managers, the Feasibility Summary, and the Foundation Proposal (the “Review Package“), are transmitted to the OASIS Board, on a confidential basis. Foundation Proposals proceed in one of the following ways:

  • If the Host LLC does not recommend approval, the Foundation Proposal is provided to the OASIS Board for information but requires no further action.
  • If the Host LLC recommends approval, but two or more OASIS Board members object to the Review Package within 15 days in writing to the Host LLC Managers, then the OASIS Board may act to accept, reject, or place conditions on the proposal. The Board will communicate its decision, together with its reasoning, to the Foundation Proposers and the Host LLC Managers within 30 days after the objections are made, or else the Host LLC may move to form the Foundation.
  • If the Host LLC recommends the proposal, and the OASIS Board approves the Review Package without objections as described above, the Host LLC will accept the proposal, open a new legal series and initiate the Foundation. Acceptance by the Host LLC and initiation of the Foundation must be consistent with the statements in the Review Package and comply with any conditions imposed by the OASIS Board.

Review of Foundation Proposals by OASIS and the Host LLC are intended to confirm feasibility and conformance to applicable laws, the stated purposes of OASIS, and the requirements and procedures described in these Operating Rules; they are not an assessment, critique, or endorsement of the proposed Foundation’s technical merits or goals. The Series LLC Agreement, confirming the Foundation’s acceptance into the Foundation-as-a-Service program, must be executed by a representative of the Foundation Proposers and the Host LLC.

6. Foundation Operation, Bylaws, and Governance.

Each Foundation accepted by the Host LLC is hosted in a distinct company series, established in the manner provided by the Host LLC’s governing documents and these Operating Rules. Once initiated, Foundations are subject to the continuing budgeting, feasibility, and termination requirements described in these Operating Rules. The procedural and technical work rules under which a Foundation and its members operate are set forth in its “Foundation Bylaws“, which must contain sufficient process rules to begin operations. The proposers may either use the Bylaws template provided by OASIS or create their own custom Bylaws, which will be subject to evaluation by the Host LLC. That evaluation may require additional time, and the Host LLC reserves the right to require the inclusion of certain elements and rules, and specific levels of clarity. The Foundation Bylaws must include (a) the manner of creation and maintenance of a Foundation Board of Directors (“Foundation Board“), (b) the Foundation’s intellectual property policies, (c) the expected transparency and public visibility of the Foundation and access to its outputs, and (d) its expected relationship, if any, to OASIS open standards or open source projects. The Foundation Bylaws also must confirm the Foundation’s adherence to OASIS conflict of interest, antitrust, whistleblower, privacy and information security policies and with the Foundation’s own Code of Conduct. Once a Foundation’s initial Bylaws have been approved, subsequent changes require the agreement of all members of the Foundation (each of which is a signatory to the Charter) as well as the approval of the Host LLC, and must be notified (with an opportunity to decline or depart) to all members of Foundation members in a process defined in its Bylaws. Changes to the Foundation Bylaws also shall be notified to the OASIS Board, and reviewed and subject to the same objection and consent procedure as applies to the initial Bylaws. The Foundation Member Agreement must be executed by each member of the Foundation. New members may join the Foundation (subject to the eligibility rules in its Bylaws) by executing and delivering a copy of the Member Agreement to the Host LLC and paying the required membership dues.

7. Foundation Financial Controls.

Under its Master Contract with the Host LLC, OASIS provides staff or subcontractor support for the management of the distinct accounts, assets, contracts, and liabilities of each Foundation, and day-to-day administration of its costs, expenses, and budget. As part of that support, OASIS provides or arranges for regular financial reporting to each Foundation Board, as well as to the Host LLC Managers, on a schedule similar to that employed by OASIS for other dedicated funds. The day-to-day administration of a Foundation’s financial activity is reviewed and approved by that Foundation’s Treasurer (or its Executive Director if no Treasurer is appointed), and also periodically reviewed by its Foundation Board, all subject to the requirements of its Foundation Bylaws and these Operating Rules. Each Foundation’s Board must approve in advance an annual budget for review by the Host LLC which includes:

  • projection of expected Foundation Dues from members;
  • allocation for the Hosting Fee, at the rate established by the Host LLC;
  • contracted or otherwise projected costs of any OASIS services provided to the Foundation;
  • projected costs and any income for the activities of the Foundation;
  • costs of any third-party services to be provided to the Foundation; and
  • all other elements of a budget required by the accounting policies, controls, and practices employed by OASIS for its own operations.

The methods and schedule for assessment and collection of Foundation Dues, as provided in a Foundation’s Bylaws and budget, must be conducted as determined by OASIS staff providing administrative support under the Master Contract, so as to regularize accounting, permit consolidation of reporting, and ensure for the adequate provision of sufficient resources for Foundation expenses. The first fiscal year for each Foundation ends at the same time as the then-current fiscal year of the Host LLC as directed by OASIS. However, the Foundation Board and the Host LLC, in consultation with OASIS, may mutually agree to set different fiscal year anniversaries and commensurate deadlines. Each Foundation must propose and obtain approval of its annual budget for each new fiscal year and should propose its annual budget at least 60 days before the expiry of its prior fiscal year. If a Foundation’s annual budget for the next year has not been finally approved by the Host LLC by the 30th day prior to the prior fiscal year end, the Host LLC may suspend that Foundation’s financial activity and decline to incur or make any further payments of that Foundation’s expenses at the end of that fiscal year (that is, 30 days later). The Host LLC and OASIS reserve the right to limit, decline, or suspend action on any expenses incurred, paid, or planned by a Foundation Board if at any time the existing and projected revenues do not appear to the Host LLC Managers or OASIS staff to adequately provide for those expenses. Neither the Host LLC nor OASIS has any responsibility for a Foundation’s liabilities caused by or relating to shortfalls in a Foundation’s budget or assets. All accounting controls and policies employed by OASIS, including rules relating to nonprofit status and appropriate legal purposes, also are applied to the operations and expenditures of each Foundation, as managed by OASIS staff providing administrative support under the Master Contract. The operations, projections, and financial results of the Foundation also may be reported in consolidated form to, and shall be included within, the monthly operating reports and regular financial reporting provided by OASIS.

8. Foundation Contract Administration.

A Foundation may contract separately for the provision of services, including promotional, event, and technical services, that the Foundation Board wishes to obtain, so long as those activities are consistent with these Operating Rules, its Foundation Bylaws, and its approved budget. However, such contracts, and any other legal contracts entered into by the Foundation, are subject to the approval of the Host LLC and OASIS staff. In its review and approval of proposed contracts, the Host LLC may require such additional terms or conditions as are necessary in its judgment to assure adherence to the Foundation’s budget and the financial controls described in these Operating Rules. For the benefit of each Foundation Board, OASIS will maintain information regarding the services that are available by contract to the Foundation from OASIS (“Contracted Services“) (beyond the services provided through the Master Contract in return for the Hosting Fee), as well as information regarding suggested external service resources. A Foundation, as a legal series of the Host LLC, cannot enter into mergers, acquisitions, asset dispositions, or similar agreements that substantially change its nature or company structure, except to the extent such a change is (a) recommended by its Foundation Board, (b) approved by the Host LLC, (c) consistent with applicable law, (d) approved by the OASIS Board, and then (e) duly executed by the Host LLC.

9. Foundation Inactivity or Termination.

If a Foundation either (a) fails to timely adopt an approved budget, (b) fails to maintain the minimum required number of Foundation Board members specified in its Bylaws, or (c) no longer has an Executive Director, then the Host LLC reserves the right to declare the Foundation dormant, by notifying its remaining Foundation Board members. The Host LLC may indicate that status change in its communications and decline to make any further payments or commitments or perform further services until the condition that causes the dormancy is corrected. If a Foundation has been declared dormant for more than 60 days, the Host LLC reserves the right to terminate the Foundation and wind up its existence as a legal series in a manner consistent with applicable law. If a Foundation, one or more members of its Foundation Board, one or more of its members, its Executive Director, or its Treasurer act in violation of applicable laws, or act in a manner that materially violates these Operating Rules or endangers assets of the Host LLC or OASIS, then the Host LLC reserves the right at any time at its sole discretion to (a) remove the entity so acting from its position within the Foundation, or (b) terminate the Foundation and wind up its existence as a legal series in a manner consistent with applicable law, or (c) take such other steps as may be necessary to protect the assets of the Host LLC or OASIS, or (d) any combination of the foregoing. A Foundation’s Board may also voluntarily, by a written vote of a majority of its currently-seated members (or such other minimum number as its Bylaws may specify), terminate and wind up its affairs, in which case the Host LLC shall administer its asset disposition and winding up as a legal series in a manner consistent with applicable law, over such period of time as the Host LLC may in its sole discretion agree. In the event of any termination or wind-up of a Foundation, its data assets and remaining intellectual property rights shall be handled as described below.

10. Foundation Data Availability.

Each Foundation sets its own policies regarding the accessibility of the Foundation’s documents and technical resources to the public and its own members, consistent with its Bylaws. The Host LLC retains its administrative, governance, budget, and operating records for each Foundation, for the period of time provided for that class of records in the OASIS Document Retention and Destruction Policy. During that period, the Host LLC will take reasonable steps to cooperate with appropriate requests for access to that data, from parties entitled to access, at the cost of the requesting party. Any obligation of the Host LLC, OASIS, or another contractor to retain, maintain, or support continued public availability of a Foundation’s email, web content, technical work documents, or similar data exists only to the extent specified in a written agreement for Contracted Services. Any technical or similar work associated with an entity outside the Foundation, including but not limited to OASIS, is subject to the availability rules provided by those other programs. However, notwithstanding any other term of these Operating Rules or any service agreement, neither the Host LLC, nor OASIS, nor any of their 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.

11. Foundation Visibility and Branding.

OASIS and the Host LLC each reserve the right to disclose its hosting affiliation with any Foundation. Foundation self-descriptive materials must include the statement, “Hosted by the OASIS Open Development Foundation LLC.” Foundations otherwise only may use the OASIS logo or the name of OASIS as may be approved in advance in writing by OASIS staff and in third-party references as consistent with the OASIS Trademark Policy.

12. 11. Changes to these Operating Rules.

These Operating Rules were approved by the Board of Directors of OASIS, the sole member of the Host LLC. OASIS reserves the right to amend these Operating Rules in the future.

This version of the OASIS Foundation-as-a-Service Operating Rules was approved by the OASIS Board of Directors on 18 February 2020 and became effective immediately.

GitHub Repositories for OASIS TC Members’ Chartered Work

OASIS TCs that wish to develop TC chartered deliverables using dedicated version control system support may request the creation of GitHub public repositories and/or a Subversion (SVN) repository. Whereas SVN repositories are allocated on a one-per-TC basis, multiple GitHub repositories may be requested by any TC for distinct development projects. Each GitHub repository will be configured using the default setup to support issues tracking, project boards, and a Wiki instance.

Note: As of 2017, OASIS supported two separate Organizations for public GitHub repositories, as described in detail below:

Governance. A GitHub repository for OASIS TC Members’ chartered work is governed by the same OASIS policies as govern a TC Wiki, a TC Subversion repository, a TC JIRA Issues Tracker, a TC Kavi document repository, etc. Unlike the OASIS TC Open Repositories — which also make use of GitHub public repositories for development of open source licensed assets — GitHub repositories for OASIS TC Members’ Chartered Work follow rules in the OASIS TC Process, OASIS IPR Policy, and related policies.

Repository Request. When any TC has decided to create a new GitHub repository, a TC officer (Chair or Secretary) may request a public GitHub repository using the online request form.

Maintainers. When a TC makes request for creation of a GitHub repository, one or more TC Members must be designated to serve as initial Maintainer(s) — sometimes also called “Committer(s)”. Additional or substitute Maintainers may be designated at any time from among qualified TC Members.

All TC members may “contribute” substantive content, as well as provide input via GitHub Issues, comments, GitHub conversations, Wiki edits (etc), but they do not have full Maintainer responsibilities, described below. A regular TC Member can be a “contributor” in the GitHub defined sense: “contributor is someone who has contributed to a project by having a pull request merged but does not have collaborator [ viz, direct write] access.”

A Maintainer, much like a prose specification editor, holds the pen and has direct write access to the GitHub “code” repository. A Maintainer accepts input from all TC members, evaluating it for incorporation into revised content. TC member input is expected in the form of GitHub Issues/Comments, GitHub conversations, pull requests, but might also be taken from the TC discussion list, or from TC meetings.

A Maintainer thus serves in an editorial capacity by having responsibility for assigning and closing issues, creating and associating milestones, creating releases, designating a default branch, creating and applying labels, initiating conversations on pull requests, merging and closing pull requests, assigning evaluation of a pull request, resolving merge conflicts, etc. The Maintainers may also monitor repository activity to help ensure that substantive contributions are made only by TC Members or by parties who agree to the terms of the OASIS Feedback License, as explained in the repository’s CONTRIBUTING file.

Initial Repository Content. At startup, each TC GitHub repository will include default files README, CONTRIBUTING, and LICENSE, provided as boilerplate by OASIS Staff. Maintainers should ensure that content in the CONTRIBUTING and LICENSE files remains unaltered; content in the README file may be adapted to reflect the TC’s project goals (viz., in sections and subsections following “Further Description of this Repository”).

Substantive Contributions and Public Feedback. Contributors to a TC GitHub Repository are expected to be Members of the associated OASIS Technical Committee, for any substantive contributions. Anyone wishing to actively participate in the TC’s technical activity is invited to join as a TC Member. Public feedback on repository content is also accepted: persons who are not TC members are invited to open issues and provide comments using a TC Repository’s GitHub Issues tracking facility or using the TC’s comment list. All such content created in GitHub Issues and/or posted to the TC’s archived comment list is governed by the terms of the OASIS Feedback License.


OASIS TC Open (Source) Repositories versus Repositories for TC Members’ Chartered Work

I. OASIS TC Open Repositories

  • 1)Who contributes? Anyone, OASIS member or not, may fully participate in any repository effort, including OASIS TC Members in any TC and Members in no OASIS TC whatsoever

  • 2) Rules and guidelines? Code development practices and process governed by TC Open Repository Guidelines and Procedures. The governance rules for making substantive contributions include terms presented in the Contributor License Agreements (CLAs), including the required Individual Contributor License Agreement for all contributors, and the Entity Contributor License Agreement when applicable.

  • 3) Public feedback? Rules provide no direct support for submitting public feedback to the sponsoring TC itself, since repository assets are not OASIS TC Work Products

  • 4) Asset use by OASIS TC(s)? Assets developed in the repository may be contributed to any OASIS TC (for use in Work Products) by a TC Member, at TC Member discretion

  • 5) Inbound? Input licensing is governed by the signed Individual Contribution License Agreement (CLA)

  • 6) Outbound? Outbound licensing is governed by FOSS (open source) licenses: BSD-3-Clause, MIT, Apache v2.0, CC-BY 2.0, CC 4.0, Eclipse Public License v1.0, etc

  • 7) Organization URI? GitHub projects use the Organization oasis-open ( https://github.com/oasis-open/ )

II. Repositories for TC Members’ Chartered Work

  • 1) Who contributes? Anyone may comment, issue pull requests, and create issues; but routine substantive contributions are expected only from sponsoring TC member participants; all contributions, whether substantive and expected or not, are governed by the terms of the OASIS Feedback License

  • 2) Rules and guidelines? Code and asset development practices and process are governed by the OASIS TC Process and the OASIS Committee Operations Process. The Contributor License Agreements (CLAs) used in OASIS TC Open Repositories are not applicable to GitHub repositories for TC Members’ Chartered work.

  • 3) Public feedback? Policy supports submission of public feedback to the TC, equivalent to submission via the TC comment list, using GitHub Issues, Comments, Pull Requests, Gists, Threaded Conversations…

  • 4) Asset use by OASIS TC(s)? Assets developed in the repository are automatically (inherently) part of official TC work, eligible for incorporation into any TC Work Product

  • 5) Inbound? Input licensing is governed by OASIS policies and agreements for contributions [def] and feedback [def]: IPR Policy: IPR Mode, Copyright Notices, Feeback License

  • 6) Outbound? Outbound licensing is governed by OASIS policies for TCs, including terms in the TC’s selected IPR Mode

  • 7) Organization URI? GitHub projects use the Organization oasis-tcs ( https://github.com/oasis-tcs/ )


Feedback or questions. Send email to TC Administration.

Privacy

Privacy Statement

OASIS Statement of Privacy Practices

May 25, 2018

Table of Contents:

1. GENERAL STATEMENT AND OVERVIEW
Introductory issues
2. USES OF YOUR PERSONAL DATA
Summary of the personal data we collect, and our purposes for doing so
Webcookies, similar technologies and DNT
E-mail lists and archives
Archival web content
3. RETENTION OF YOUR PERSONAL DATA
Summary of our reasons and practices for retaining personal data
4. YOUR ACCESS TO AND THE ACCURACY OF YOUR PERSONAL DATA
Log-in and self-help controls
Additional legal rights of European citizens and others
Help with accessing, correcting, updating, deleting, or suppressing your personal data
5. THE SECURITY OF YOUR PERSONAL DATA
Our security practices
6. SHARING YOUR PERSONAL DATA, AND LINKS TO THIRD PARTY RESOURCES
Who we share with
Third party links and resources
7. HOW TO CONTACT US
E-mail and postal addresses

1. DATA PROTECTION OVERVIEW

OASIS is a nonprofit corporation whose mission is to drive the development, convergence and adoption of open standards and open source projects for the global information society. We host collaborative, open development projects run by our members and participants, including (we are proud to say) a number of privacy and data protection projects. We are committed to protecting your privacy and personal data; building and maintaining trust; sharing our examples and tools to help other organizations and communities do the same; and serving as a demonstration and testing ground for data protection open standards, particularly those developed by our members.

We’re doing this in a rapidly-changing technical and policy environment for data protection. This is a good thing. Our communities, participants and peers are learning as everyone gains experience, and new tools emerge in response. This statement is effective as of May 25, 2018. OASIS will continue to update this statement, and our practices. as additional requirements, issues and opportunities arise.

We collect, retain, and use information about you only for specific business purposes, and when we reasonably believe that it will help administer our business, communicate with you or provide products, services, and other information of value to you. This is explained in more detail below.

2. USES OF YOUR PERSONAL DATA

We may collect data, including personal data, about you as you use our websites and tools, interact with us and participate in our programs. “Personal data” is any information that can be used to identify an individual, and may include name, postal address, e-mail address, phone number, log-in data (account name or number, password), location and IP address data, marketing preferences, social media account data, or payment data (including card numbers). We also collect personal data from trusted third-party sources and may engage third parties to collect personal data to assist us.

We collect personal data for a variety of reasons, such as:

  • Hosting collaborative projects, and providing access to materials and group communications for those projects.
  • Providing standards- and code-related services such as interoperability tests and registries.
  • Creating and maintaining an account with us.
  • Documenting any license commitments you make to benefit our projects.
  • Hosting technical events, registering and scheduling participants and speakers, and collecting requests for more information from visitors.
  • Processing your order for participation, sponsorship or conference attendance, including payment transactions.
  • Enabling the use of certain features of our services delivered over the Internet.
  • Providing you with newsletter subscriptions.
  • Sending marketing communications.
  • Personalizing your experience.
  • Providing customer service and responding to your inquiries.
  • Managing a job application.
  • Webcookie uses, as described below.
  • Other legitimate purposes permitted or required by applicable law.

WEBCOOKIES, SIMILAR TECHNOLOGIES AND DNT. In some cases, OASIS and the third parties we engage may collect data by webcookies, web logs, web beacons, and other similar applications, for several purposes. First, we use traffic log webcookies to identify which pages are being used. This helps us analyze data about web page traffic, and improve our website in order to tailor it to customer needs. Our servers may log http requests to our site, including IP, Referrer and User-Agent for traffic analysis, and we use webcookies on some pages to maintain the state of sessions and understand usage patterns.

On our public web pages (those where no log-in is required), we make no effort to identify the readers or uses of those pages. Data that we collect is used only for site improvement, server administration and usage statistics. Our web pages may link to or embed content from other sources (like videos) which are governed by the privacy policies of their originating sources.

We also maintain some website pages that only are accessible via a log-in. Those pages use webcookies that allow the creation of an account or recognize you as a logged-in account. Logged-in accounts result in the creation of a user name, e-mail address, real name and affiliation, and may include other information that you choose to give us. This information is stored in our database, and is retained so long as it’s relevant or required, consistent with law.

You can choose to accept or decline cookies. Most web browsers automatically accept cookies, but you usually can modify your browser setting to decline cookies if you prefer. That may prevent you from taking full advantage of the website’s functions.

Some web browsers may give you the ability to enable a “do not track” (DNT) feature that sends signals to the websites you visit, indicating that you do not want your online activities tracked. This is different from blocking or deleting cookies, as browsers with a “do not track” feature enabled may still accept cookies. No consistently-implemented industry open standard currently exists on how companies should respond to “do not track” signals, although one may develop. OASIS websites do not currently recognize and respond to “do not track” signals. If we do so, we will describe what we do here.

E-MAIL LISTS AND ARCHIVES. Any OASIS e-mail lists to which you post also will retain an archived record of your e-mail address, and such other information as you choose to provide. That data also will be retained so long as it’s relevant or required, consistent with law. Please think about what information you want to include in these permanent e-mail records. Generally it is our policy not to delete any information from archived messages, especially where that message may form a technical contribution or a legal or licensing commitment. For more on our handling of e-mail list archives, and how to make any requests for removal, please see our mailing list policy at: https://www.oasis-open.org/policies-guidelines/mailing-lists

ARCHIVAL WEB CONTENT. We also collect, maintain and display official and publicly-transparent records of your technical contributions, such as group membership, group leadership, and contributions by mail list, document repository, collaboration platform or teleconference. Those practices are necessary to create the legal licensure and public policy obligations, and provenance records, that apply to OASIS technical work to which you contribute. Those records usually are retained perpetually.

3. RETENTION OF YOUR PERSONAL DATA

As described above, we collect personal data for a variety of reasons, and retain it when necessary to lawfully perform those functions, most often to identify your contributions, to provide a legal record of your contributions and licensing obligations, and to maintain transparent provenance data regarding your inputs and contributing role. Usually technical contribution data will be retained so long as the technical work is available, and the identity of contributors will be publicly displayed with the work. This generally applies to our technical committees, open projects, and technical demonstration events, most of which we may retain perpetually.

We also retain the personal data necessary to administrate and enforce our contracts and mutual obligations with you (like an OASIS membership, conference registration or personal services contract). We will retain your identifying data so long as reasonably needed for our contract administration, subject to applicable laws and your rights described in this statement.

We also retain the personal data necessary to perform other services and fulfill the other roles described here, including in “Use of Your Personal Data” above. We will retain your identifying data so long as reasonably needed to perform the service or role, subject to applicable laws and your rights described here.

4. YOUR ACCESS TO AND THE ACCURACY OF YOUR PERSONAL DATA

We need your help in keeping your personal data accurate and up to date. OASIS provides a number of options to access, correct, suppress, or delete your personal data.

LOG-IN FEATURES AND SELF-HELP. If you have a log-in account with us, for access to nonpublic web pages or collaborative tools, that account management system will have a “my account” or similar feature for collecting and updating the personal data that is used by that function, and any other personal data you choose to provide to it. The most important controls for most parties working with OASIS usually will be:

  • Our member account management page at https://www.oasis-open.org/kws/my_account, which also controls your subscription to the OASIS general membership information e-mail list (members@lists.oasis-open.org), and whether certain of the personal data for the account is displayed publicly; and
  • Your election, within our members-only webpages, to join or leave specific OASIS committees or activities will control your subscriptions to those members-only e-mail lists; and
  • Our e-mail list subscription manager for publicly-available lists at https://www.oasis-open.org/mlmanage/ Our contacts with you via e-mail or similar direct communications that use personal data (like addresses), will include “unsubscribe” links if they are not managed by the subscription manager or other members’ activity controls described above.
  • Management of passwords is available either at this page when logged-in: https://www.oasis-open.org/kws/my_account, or by a password recovery feature accessible from our log-in page, or if help is needed, by contacting member-services@oasis-open.org.

You are encouraged to use these self-help controls, which are likely to satisfy most needs for personal data review, correction or maintenance. Additionally, the majority of the records of our technical and policy operations are posted to openly accessible public web pages, so a large part of our data about you also is readily available by using web search engines.

ADDITIONAL RIGHTS. Citizens of member states of the European Union and some other jurisdictions may have additional rights to copies of their personal data and to give us instructions to correct or delete that personal data. “Personal data” as used in this statement includes all personal information as defined by those legal rights. We will comply with those legal rights, and we will make good faith efforts to honor reasonable requests to access, correct, update, delete, or suppress that data, subject to any lawful basis for retention or other use as noted above.

GETTING HELP. If you need additional assistance, or help with accessing, correcting, updating, deleting, or suppressing your personal data, please feel free to contact us directly at dataprivacy@oasis-open.org, or by postal mail to our contact address below. Please be sure to include your name, e-mail address, and specific, relevant information about the material you no longer wish to receive. We will respond to your requests within 30 days of receiving them. If we are unable to honor your request, we will give you an explanation.

5. THE SECURITY OF YOUR PERSONAL DATA

We intend to protect the personal data entrusted to us and treat it securely in accordance with this statement. OASIS implements physical, administrative, and technical safeguards designed to protect your personal data from unauthorized access, use, or disclosure. OASIS also complies with its Information Security Policy regarding the classes of data defined in that document: https://www.oasis-open.org/policies-guidelines/information-security The Internet, however, cannot be guaranteed to be 100% secure, and we cannot ensure or warrant the security of any personal data you provide to us.

6. SHARING YOUR PERSONAL DATA, AND LINKS TO THIRD PARTY RESOURCES

We may share your personal data with third parties for the purposes of operating our business, delivering, improving, and customizing our services, sending marketing and other communications related to our business, and for other legitimate purposes, but in each case only as permitted by applicable law or otherwise with your consent.

We may share personal data in the following ways:

  • With service vendors or agents, business partners or contractors to provide a requested program, service or transaction. Examples include, but are not limited to: hosting websites, hosting Internet-based collaboration tools, meeting registration and management, processing of orders and credit card transactions, assisting with membership- and sales-related efforts or post-sales support, and providing customer support.
  • With co-sponsors in cases where OASIS jointly administers a program or service with a disclosed co-sponsor. We do not otherwise provide our contact data or other personal data for you to anyone for their marketing purposes.
  • In response to a request for information by law enforcement officials or other competent authorities, if we believe disclosure is required or otherwise is in accordance with applicable law and legal process; or when necessary to protect the rights, property, or safety of OASIS, you, or others; or as otherwise required by applicable law.
  • In aggregated, anonymized, and/or de-identified form which cannot reasonably be used to identify you.
  • If we otherwise notify you and you consent to the sharing.

We review our service vendors, agents, business partners, contractors and co-sponsors who receive personal data from OASIS to confirm their compliance with applicable laws.

THIRD PARTY LINKS AND RESOURCES. Our website and Internet tools may contain links to other websites or information resources. However, once you have used these links to leave our site, please note that we do not have any control over that other website. Therefore, we cannot be responsible for the protection and privacy of any information which you provide while visiting those sites, and they are not governed by this statement. You should exercise caution and look at the privacy statement or policy applicable to each website and tool you visit.

7. HOW TO CONTACT US

In addition to the specific self-help tools and contact addresses listed above, please contact us with your questions or comments about this statement dataprivacy@oasis-open.org, or by postal mail to:

Data Privacy Team
OASIS
35 Corporate Drive Suite 150
Burlington, MA 01803-4238
USA

Scott McGrath is our Information Security Officer, and Jamie Clark is our Data Protection Officer.

Open Project Rules

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

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:

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:

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.

Technical Committee (TC) Process

This version of the OASIS TC Process was approved by the OASIS Board of Directors on 26 May 2017, was announced to OASIS members on 23 June 2017, and became effective 01 July 2017. 

Table of Contents

Section 1. Technical Committees (TCs)
1.1 Purpose of TCs
1.2 TC Formation
1.3 First Meeting of a TC
1.4 TC Membership and Participation
1.5 Termination of TC Membership
1.6 Leaves of Absence
1.7 TC Transparency
1.8 TC Charter Clarification
1.9 TC Rechartering
1.10 TC Voting
1.11 TC Subcommittees
1.12 Closing a TC
1.13 Maintenance Activity of OASIS Standards Final Deliverables
1.14 Intellectual Property Rights Proceures
1.15 Commercial Terms and Conditions; Implementation Preferences

Section 2. TC Work Products
2.1 Introduction
2.2 Work Product Components
2.3 Updating References
2.4 Work Product Approvals
2.5 Approval of a Committee Specification Draft
2.6 Public Review of a Committee Specification Draft
2.7 Approval of a Committee Specification
2.8 Approval of an OASIS Standard
2.8.1 Submission of a Candidate OASIS Standard
2.8.2 Public Review of a Candidate OASIS Standard
2.8.3 Call for consent for OASIS Standard
2.9 Approved Errata

Section 3. Board of Directors Involvement in the TC Process
3.1 OASIS TC Administrator
3.2 Appeals

Section 4. Application to Existing TCs

Section 1. Technical Committees (TCs)

1.1 Purpose of TCs

An OASIS Technical Committee is a group of Eligible Persons comprised of at least the Minimum Membership, formed and conducted according to the provisions of this TC Process, to develop and approve TC Work Products and perform the other activities permitted by this TC Process. Each current version of the TC Process applies to previously established TCs upon its adoption.

The OASIS Committee Operations Process provides general provisions concerning the operation of all Committees that may apply to the work of a TC. The OASIS Naming Directives lists specific requirements that apply to TC Work Products.

Defined terms in this document have the meaning provided in OASIS Defined Terms. Additional definitions specific to the OASIS IPR Policy can be found in that document.

1.2 TC Formation

Any group of at least Minimum Membership shall be authorized to begin a Technical Committee by submitting to the OASIS TC Administrator a charter prepared using the TC Charter Template maintained and made available by the TC Administrator. The charter shall be written in English and provided to OASIS in electronic form as plain text. The name proposed for the TC shall be subject to approval by the TC Administrator. 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.

No later than 7 days following the submission of the charter, the OASIS TC Administrator shall either return the submission to its originators with an explanation indicating its failure to meet the requirements set forth in this section or shall post notice of the submission to an announced mailing list (or equivalent method), visible to the submission proposers and the OASIS Membership, for comment.

Comments will be received until the 14th day after the notice. Following the comment period, the OASIS TC Administrator shall hold a conference call among the Convener, the OASIS TC Administrator, and those proposers who wish to attend. Other OASIS Members who wish to attend may observe.

Following this conference call, the proposers may confirm that the existing charter stands or may amend it. The proposer group may submit an amended charter at any time until the 7th day before the Call for Participation. The proposers must also post a pointer to an account of each of any comments or issues raised during the comment period, along with its resolution.

Once all these elements have been received, the OASIS TC Administrator shall post them to the OASIS Membership with a Call For Participation and an announcement of a first meeting.

1.3 First Meeting of a TC

The first Meeting of a TC shall occur no less than 30 days after the Call for Participation in the case of a meeting held exclusively by telephone or other electronic means, and no less than 45 days after the Call for Participation in the case of a meeting held face-to-face.

If the first meeting of a TC is to be conducted as a face-to-face meeting, the Convener must arrange for teleconference facilities to be provided for those unable to attend in person.

Eligible Persons intending to participate in the first meeting must use the OASIS collaborative tools to register as a TC Member.

If the Eligible Person is an employee or designee of an OASIS Organizational Member, the Primary Representative of that organization must confirm to the Convener and to the TC Administrator that the person may become a Member of the TC.

Every Eligible Person who has so registered and been confirmed shall be a Member of the TC beginning with the first meeting. Every Eligible Person who has registered 7 days or more prior to the first meeting, been confirmed, and is present at the first meeting of a TC shall be a Voting Member of the TC beginning with the first meeting.

No later than 7 days prior to the meeting, the OASIS TC Administrator shall post a notice to the prospective Members on the TC’s general email list inviting indications of candidacy for TC Chair to be posted to that list.

The rules for conduct of meetings in the OASIS Committee Operations Process apply to the TC’s first Meeting. In addition, the first TC meeting has these rules:

1.3.1 The first meeting of a TC must occur at the place and time and in the manner described in the Call for Participation. Any initial TC meeting whose time or location is changed and any initial telephone or other electronic meeting that fails to grant access to every Eligible Person previously registering to attend shall be subject to appeal as provided in 3.2 Appeals.

1.3.2 At least Minimum Membership must become Voting Members at the first TC meeting or the TC shall be considered not to have been successfully started. A TC failing to start due to the absence of Minimum Membership may, with the approval of the TC Administrator, reschedule its first meeting. If the proposers do not reschedule the first meeting, the TC shall be closed.

1.3.3 At the first meeting of the TC, the Convener shall chair the meeting for the roll call and the election of the TC Chair or Co-Chairs. The TC must elect a Chair as the first order of business, from among nominations made by Voting Members at that meeting. Once the Chair is elected the role of Convener ends.

1.4 TC Membership and Participation

TC membership is per person, not per organization, and is not transferable from person to person.

Each TC Member is responsible for ensuring that their attendance at TC meetings is noted by the Chair and recorded.

1.4.1 Observer: An Eligible Person may become an Observer of a TC by registering as an Observer using the electronic collaboration tools provided by OASIS. If the Eligible Person is an employee or designee of an OASIS Organizational Member, the Primary Representative of that organization must be notified that the person has requested to become an Observer. The Observer is not a TC Member so has no attendance or participation requirements to maintain this status, other than to remain an Eligible Person.

1.4.2 Member: Any time after the first meeting, an Eligible Person shall become a TC Member by registering as a Member using the electronic collaboration tools provided by OASIS. If the Eligible Person is an employee or designee of an OASIS Organizational Member, the Primary Representative of that organization must confirm to the Chair and to the TC Administrator that the person may become a Member of the TC. Upon receipt by the Chair of confirmation by the Primary Representative, the Member may begin participating, but shall not have voting rights. A TC Member shall become eligible to vote in the TC when the requirements below are met.

1.4.3 Persistent Non-Voting Member: A Member or Voting Member who wishes to continue participating in the work of the committee but who does not wish to count for purposes of calculating Quorum, make or second motions, or vote may, at any time, change their role to Persistent Non-Voting Member by sending e-mail to both the Chair and the TC mailing list informing them of their change. The change will be effective as of the date of notice or future date specified in the email. A Persistent Non-Voting Member retains participation rights but is not eligible to vote and does not count towards Quorum. A Persistent Non-Voting Member who wishes to gain voting rights must send e-mail to both the Chair and the TC mailing list informing them of their intent to become a Voting Member and must follow the rules in section 1.4.4 as if they had lost their voting rights due to non-attendance.

1.4.4 Voting Member: A TC Member who lacks voting rights shall gain voting rights at the close of the second consecutive Meeting of the TC that he attends. If fewer than two Meetings are called within 60 days after the person becomes a Member, the Member shall gain voting rights at the close of the 60th day.

A Voting Member who is absent from two consecutive Meetings of the TC (as recorded in the minutes) loses his voting rights at the end of the second Meeting missed. If a TC has adopted a standing rule to conduct business only by electronic ballot, without Meetings, then a Voting Member who fails to cast a ballot in two consecutive Work Product Ballots for which the voting periods do not overlap loses his voting rights at the close of the second ballot missed. In case of multiple ballots taking place simultaneously, voting in a single ballot is sufficient to maintain voting rights.

Only a Voting Member may make or second a motion.

A Voting Member may at any time request to have his role changed to Member. As a Member, he will retain participation rights but will not be eligible to vote and will not count towards Quorum nor make nor second motions.

1.5 Termination of TC Membership

A TC Member shall be considered to have resigned from a TC upon his sending notification of resignation to the TC general email list.

A person who loses Eligible Person status shall have his TC Membership terminated.

Persons who lose Eligible Person status shall have up to 14 days of TC membership as an OASIS Individual Member in which to re-establish eligibility. A Member shall lose TC membership on the 15th day if Eligible Person status has not been re-established.

Termination of membership in an OASIS TC shall automatically end all rights and privileges of participation including voting rights in the TC and shall terminate membership in any Subcommittee of that TC.

1.6 Leaves of Absence

Every Voting Member of an OASIS TC may request a Leave of Absence. A Leave of Absence shall not exceed 45 days. Each request shall be made by sending an email to the TC mailing list at least 7 days before the Leave is to start. The Leave must be approved by the TC.

During a Leave of Absence, a Voting Member shall not have voting rights or participation obligations in the TC or its Subcommittees. Voting rights shall resume immediately when the Leave ends or earlier if requested by the Member.

1.7 TC Transparency

The official copies of all resources of the TC and its associated Subcommittees, including web pages, documents, email lists and any other records of discussions, must be located only on facilities designated by OASIS. TCs and SCs 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 TCs and SCs shall be publicly visible.

The permanent minutes of each TC meeting and a record of all decisions shall be posted to that TC’s general email list. All official communications and discussions of the TC must take place on the email list. Subscription to the general email list shall be required for members all Members of the TC. All TC email lists shall be archived for the duration of the corporation, and all TC email archives shall be publicly visible.

Each TC shall be provided with a public comment facility, the purpose of which is to receive comments from the public and is not for general discussion. Comments shall be publicly archived and must be considered by the TC.. TCs are not required to respond to comments. Comments to the TC made by non-TC Members, including from the public, must be made via the TC’s comment facility, and shall not be accepted via any other means.

1.8 TC Charter Clarification

A TC may clarify its Charter only for the purpose of removing ambiguity or for narrowing the scope of the topic defined by the Charter. The list of deliverables may be expanded only if the new deliverables are within the scope of the topic.

Approval for clarification shall require a Special Majority Vote of the TC.

The TC Administrator may prevent the proposed clarification from coming to vote if it is not in conformance with OASIS policies. No later than 7 days after receiving the request to start the Special Majority Vote, the TC Administrator must either open the ballot or reply to the TC with the reason why the change cannot be voted upon.

The clarified Charter shall not take effect until approved by the TC and announced by the TC Administrator.

1.9 TC Rechartering

In order to expand the scope of a TC, it must be rechartered. The TC shall retain the same name, all email lists and archives, web pages, etc. Contributions made to the TC under the prior charter must be recontributed to be used under the revised charter.

Approval for rechartering shall require a Special Majority Vote of the TC.

Rechartering shall not change the TC name nor the IPR Mode of the TC. If a different name or IPR Mode is desired then a new TC (with a unique name) must be formed and the normal rules for creating a new TC apply (see 1.2 TC Formation).

A proposal to recharter the TC must be made by Resolution and submitted to the TC Administrator. The proposal shall include all the items specified in 1.2 TC Formation including item 2(b) (date, time and location of the first meeting under the revised charter) and excluding items 2(d) and 2(e) (list of co-proposers and Primary Representative’s Statements of Support). The proposal shall clearly mark all changes from the charter in effect at the time of the proposal. The date of the first meeting must not be less than 7 days after the close of the ballot to approve rechartering.

Not later than 7 days after receiving the request to hold a vote, and if the proposal is complete, the TC Administrator shall schedule the Special Majority Vote.

If the ballot is approved, the following steps shall be taken:

  1. Within 7 days of approval, the TC Administrator shall announce the rechartering to the OASIS Membership with instructions for how and when to join the newly rechartered TC.
  2. 7 days before the first meeting, all work of the TC shall stop and the TC Administrator shall send an email to the TC mailing list describing the procedure for re-joining the TC and remove all Members and TC officers from the TC roster.
  3. OASIS members wishing to (re)join the TC shall follow the normal procedures for joining a new TC. In the event that a member is not able to join in the 7 day period before the first meeting because of lack of online access, the member’s primary representative may ask the TC Administrator to add the member to the TC.

The same rules and procedures regarding the First Meeting of a TC specified under 1.3 First Meeting of a TC also apply for the first meeting of the rechartered TC, except as superseded in this section.

The time period for determining Members’ Participation Obligation shall restart at the first meeting of the TC under the revised charter.

1.10 TC Voting

TC votes require a Simple Majority Vote to pass, except as noted elsewhere in this Process. All TC ballots requiring a Special Majority Vote for approval must be conducted by the TC Administrator; the TC Chair shall request that the TC Administrator hold the Special Majority Vote, and the TC Administrator shall set up and conduct the ballot.

A Member of a TC must have voting rights at the time a ballot is opened in order to vote on that ballot. Every Voting Member of a TC has a single vote. Organizations do not vote in TCs. Proxies shall not be allowed in TC voting.

TCs may conduct electronic ballots, either by using the TC’s general mail list or the publicly archived electronic voting functionality provided by OASIS. An electronic ballot must remain open for a minimum of 7 days. Any Work Product Ballot conducted as an electronic ballot must permit each voter to choose “yes”, “no”, or “abstain.” Eligible voters may change their vote up until the end of the voting period.

1.11 TC Subcommittees

The TC may by Resolution create a Subcommittee (SC). The TC must close a Subcommittee by Resolution.

The deliverables of the SC are made only to the TC for such further action as the TC may elect. Members of the SC must first be Members of the TC. Observers of a TC may be Observers of a SC, but may not become SC members without first becoming a Member of the TC. An SC member may resign from the SC and remain a Member of the TC.

1.12 Closing a TC

A TC may be closed by Full Majority Vote of the TC, by Resolution of the OASIS Board of Directors, or by the OASIS TC Administrator.

The TC Administrator must close a TC that has completed the deliverables listed in its Charter if the TC does not add new deliverables or that fails to elect a Chair for the period provided in OASIS Committee Operations Process.

The TC Administrator may close a TC that fails to conduct at least one Quorate Meeting or conduct any Work Product Ballots during any six month period; whose membership falls below the Minimum Membership; which has not completed its deliverables within the schedule listed in its Charter; or which has failed to show progress towards achieving its purpose as defined by its Charter.

1.13 Maintenance Activity of OASIS Standards Final Deliverables

Only one TC at a time may perform a Maintenance Activity on an OASIS Standards Final Deliverable.

Maintenance Activity on an OASIS Standards Final Deliverable is always within the scope of the TC that created the deliverable, whether or not the TC’s Charter explicitly references it.

Maintenance Activity on an OASIS Standards Final Deliverable may be done by a TC other than the TC that originated the deliverable, if: (a) the name of the OASIS Standards Final Deliverable to be maintained is listed as a deliverable in its Charter, and (b) if the originating TC is not closed, it has consented to the Maintenance Activity by a Special Majority Vote.

1.14 Intellectual Property Rights Procedures

The TC shall operate in accordance with the OASIS Intellectual Property Rights (IPR) Policy.

Notices of Disclosed Claims, as defined in and required by the OASIS IPR Policy, shall be made by sending an email message to the TC Administrator, who shall post the disclosure on the TC’s web page and notify the TC via the TC general email list. The TC shall make no formal decision with regard to the applicability or validity of an IPR disclosure.

Contributions, as defined in the OASIS IPR Policy, shall be made by sending to the TC’s general email list either the contribution, or a notice that the contribution has been delivered to the TC’s document repository; a URL or other reference to the document is not sufficient. Written contributions must be converted to electronic format and delivered to the TC’s general email list or document repository. The TC is not required to acknowledge or use any Contribution.

1.15 Commercial Terms and Conditions; Implementation Preferences

Provisions involving business relations between buyer and seller such as guarantees, warranties, and other commercial terms and conditions shall not be included in an OASIS Committee’s documents or Work Products. The appearance that a Committee or its output endorses any particular products, services or companies must be avoided. Therefore, it generally is not acceptable for a TC to include manufacturer lists, service provider lists, or similar material in the text of a Standards Track Work Product (or the equivalent). Committees may elect to supply or point to provider-neutral lists of known implementation claims, in non-normative statements or their web pages.

Where a sole source exists for essential equipment, materials or services necessary to comply with or to determine compliance with a specification or method, it is permissible to supply the name and address of the source in a footnote or informative annex as long as the words “or the equivalent” are added to the reference. In connection with a TC’s Standards Track Work Products that relate to the determination of whether products or services conform to one or more standards, that Work Product may include the process or criteria for determining conformity, as long as the description of the process or criteria is limited to technical and engineering concerns and does not include what would otherwise be a commercial term or product identification.

Implementations of all kinds are welcome (partial or complete; prototype, proof-of-concept, example, model, or reference implementation), provided that TCs do not designate any implementation of a specification as privileged or unique.

Section 2. TC Work Products

2.1 Introduction

The primary deliverables of an OASIS Technical Committee are its Work Products. These are descriptive, narrative documents and associated materials such as schemas, data dictionaries, UML models, or other associated content, that address the scope of work described in the TC’s charter.

Work Products may be either Standards Track Work Products (intended to specify how to implement some data interchange format, protocol, process definition, service protocol, etc.) or Non-Standards Track Work Products (intended to provide ancillary information to assist in understanding and implementing the Standards Track work). Non-Standards Track Work Products may not contain Normative content except as excerpts from a Standards Track Work Product.

This section defines specific requirements that apply to preparing, approving and advancing Work Products through the stages of the OASIS approval process. The OASIS Naming Directives lists additional specific requirements that apply to TC Work Products.

2.2 Work Product Components

In general, the content of a Work Product is the domain of the participants in the Technical Committee. They are presumed to be the subject matter experts in their field, best positioned to know both the solutions that must be developed and the optimum way to organize and present those solutions to their community.

The following specific requirements of the OASIS TC Process apply to all Work Products.

2.2.1 General. All documents and other files produced by the TC, including Work Products at any level of approval, must use the OASIS file naming scheme and must include the OASIS copyright notice. Work Products must be written using the OASIS document authoring templates, which shall be maintained and made available by the TC Administrator. The name of any Work Product may not include any trademarks or service marks not owned by OASIS.

2.2.2 File Formats. Editable formats of all versions of TC documents must be delivered to the TC’s document repository. Working Drafts may be in any format (i.e. produced by any application). All approved versions of OASIS Deliverables must be published in (1) editable source, (2) HTML or XHTML, and (3) PDF formats. The TC must explicitly designate one of those formats as the authoritative document.

2.2.3 Multi-Part Work Products. A Work Product may be composed of any number of files of different types, though any such multi-part Work Product must have a single Work Product name and version number. Irrespective of the number and status of the constituent parts, the Work Product as a whole must be approved by a single Work Product Ballot.

2.2.4 Allowed changes. After a Work Product has been approved as a Standards Track or Non-Standards Track Work Product (for example, as a Committee Specification Draft), no further changes may be made to the content of the Work Product except for those made by the TC Administrator as part of the official publication process of the Work Product. The TC may continue to make changes to the next working draft.

2.2.5 Computer Language Definitions. All normative computer language definitions that are part of the Work Product, such as XML instances, schemas or Java(TM) code, including fragments of such, must be well formed and valid.

For Standards Track Work Products:

  • All normative computer language definitions must also be provided in separate plain text files;
  • Each text file must be referenced from the Work Product; and
  • Where any definition in these separate files disagrees with the definition found in the specification documentation, the definition in the separate file prevails.

2.2.6 Conformance Clauses. A Standards Track Work Product that is approved by the TC at the Committee Specification Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof).

2.2.7 Notifications. Every Work Product must clearly indicate on the cover page whether it is a Standards Track Work Product or Non-Standards Track Work Product.

2.3 Updating References

A TC wishing to update a reference in its Normative or Non-Normative References section whose status is expected to change between TC approval of a Work Product and its publication may do so in cooperation with the OASIS TC Administrator. The TC must include the anticipated change in its motion to approve the Work Product and must alert The TC Administrator to the expected changes at the time the request to publish the Work Product is made.

2.4 Work Product Approvals

Technical Committees may only approve the following types of Work Products:

2.4.1 The following Standards Track Work Products:

  1. Committee Specification Draft,
  2. Committee Specification Public Review Draft,
  3. Committee Specification,
  4. Candidate OASIS Standard,
  5. Approved Errata.

OASIS Standards are approved by the organizational members of OASIS as described in this section.

Each of the progressions above must begin with step 1, and no step may be skipped. However, a TC is not required to progress a Work Product from one step to the next.

2.4.2 The following Non-Standards Track Work Products:

  1. Committee Note Draft
  2. Committee Note Public Review Draft
  3. Committee Note

Public reviews are optional for Committee Notes. A TC may approve a Committee Note without public review and request that the TC Administrator publish it to the OASIS Library. Approval of the draft shall require a Full Majority Vote of the TC. If a TC wishes to conduct public reviews before approving a Committee Note, the same procedures for approval and public review of a Committee Specification Draft as outlined in section 2.5 and section 2.6 apply.

A Committee Note is never progressed as an OASIS standard.

2.5 Approval of a Committee Specification Draft

The TC may at any stage during development of a Work Product approve a Working Draft as a Committee Specification Draft. Approval of these drafts shall require a Full Majority Vote of the TC. The TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Specification Draft.

2.6 Public Review of a Committee Specification Draft

Before the TC can approve a Committee Specification Draft as a Committee Specification, the TC must conduct a public review of the work. The decision by the TC to submit the draft for public review requires a Full Majority Vote. The draft approved to go to review shall be called a Committee Specification Public Review Draft. The public review must be announced by the TC Administrator to the OASIS Membership, to any external stakeholders identified by the TC, and optionally to other public mail lists or other venues. The TC Administrator shall at the same time issue a call for IPR disclosure for the Committee Specification Draft.

Comments from non-TC Members must be collected via the TC’s archived public comment facility; comments made through any other means shall not be accepted. Comments made by Members of the TC must be made via the TC general email list. The TC must acknowledge the receipt of each comment, track the comments received, and post to its primary e-mail list its disposition of each comment after the end of the review period.

No changes may be made to the public review draft during a review. If the TC decides by Full Majority Vote that changes are required, the draft shall be withdrawn from review after the Chair informs the TC Administrator. The draft may be subsequently resubmitted by the TC for a new public review.

The TC may conduct any number of public reviews. The initial public review of a draft must take place for a minimum of 30 days, and any subsequent reviews must be held for a minimum of 15 days. Changes made to a committee draft after a review must be clearly identified in any subsequent review, and the subsequent review shall be limited in scope to changes made in the previous review. Before starting another review cycle the revisions must be re-approved as a Committee Specification Draft and then approved to go to public review by the TC.

If any changes that are Material are made to the draft after the public review then the TC must conduct another public review. The draft may not be considered for approval by the TC as a Committee Specification until it has undergone a review cycle during which it has received no comments that result in any changes that are Material.

If only Non-Material Changes are made to the draft after the public review, then the TC may proceed with the approval as a Committee Specification in accordance with Section 2.7 without conducting another public review cycle.

2.7 Approval of a Committee Specification

After the public review, the TC may approve the Committee Specification Draft as a Committee Specification. If any comments have been received during the most recent public review period, that vote may not commence any earlier than 7 days after the last day of that public review. The approval of a Committee Specification shall require a Special Majority Vote. The TC Chair shall notify the TC Administrator that the TC requests a Special Majority Vote for the advancement of the draft as a Committee Specification and provide to the TC Administrator any other required information. The TC Administrator shall set up and conduct the ballot to approve the Committee Specification

If Non-Material Changes have been made to the draft since its last public review then the TC must provide an acceptable summary that is clear and comprehensible of the changes made since the last public review and a statement that the changes are all Non-Material to the TC Administrator. The TC Administrator shall announce the opening of the ballot to approve the draft to the OASIS Membership and optionally on other public mail lists along with the summary of changes and the TC’s statement. If any Eligible Person objects that the changes are not Non-Material before the ballot closes, the TC Administrator shall halt the ballot and require the TC to submit the draft for another public review cycle. If such objection is made after the ballot has closed, the TC Administrator shall reject it and the results of the ballot shall stand.

2.8 Approval of an OASIS Standard

Approval of an OASIS Standard is a multi-step process:

  1. Submission of a Candidate OASIS Standard (COS) to the TC Administrator,
  2. Completion of a public review lasting a minimum of 60 days, and
  3. A call for consent to approve the COS as OASIS Standard.
  4. A potential single, second call for consent after addressing negative comments.

2.8.1 Submission of a Candidate OASIS Standard

After the approval of a Committee Specification, and after three Statements of Use referencing the Committee Specification have been presented to the TC, a TC may resolve by Special Majority Vote to submit the Committee Specification as a Candidate OASIS Standard. At least one of the Statements of Use must come from an OASIS Organizational Member. The TC may decide to withdraw the submission, by Special Majority Vote, at any time until the final approval. The chair shall submit the request for the Special Majority Vote using the request mechanism designated by the OASIS TC Administrator.

No part of the submission may be changed or altered in any way after being submitted to the TC Administrator, including by Errata or corrigenda. Errata, corrigenda or other changes to a Candidate OASIS Standard are not permitted after its submission for OASIS Standard approval, except that changes which address comments associated with valid objections to a call for consent for OASIS Standard may be allowed as described in section 2.8.3 below.

2.8.2 Public Review of a Candidate OASIS Standard

A public review of the Candidate OASIS Standard shall be announced by the TC Administrator to the OASIS Membership list and optionally on other public mail lists. The public review shall remain open a minimum of 60 days.

Comments from non-TC Members must be collected via the TC’s archived public comment facility; comments made through any other means shall not be accepted. Comments made by Members of the TC must be made via the TC general email list. The TC must acknowledge the receipt of each comment, track the comments received, and post to its primary e-mail list the disposition of each comment at the end of the review period.

No changes may be made to the Candidate OASIS Standard during a review. If the TC decides by Full Majority Vote that changes are needed, then the specification must be withdrawn from review after the Chair informs the TC Administrator.

Upon completion of the public review, the Chair must notify the TC Administrator of the results.

  • If no comments were received, the TC Administrator must start the call for consent for OASIS Standard within 7 days of notification.
  • If comments were received, but no changes are to be made to the Candidate OASIS Standard, the Chair will request that the TC Administrator start a Special Majority Ballot for the TC to approve continuing with the OASIS Standard call for consent. The TC Administrator will begin said ballot within 7 days of receipt. Upon successful completion of that ballot, the TC Administrator will, within 7 days, begin the call for consent for OASIS Standard approval.
  • If comments were received and only Non-Material Changes are to be made to the Candidate OASIS Standard, the editor(s) may prepare a revised Candidate OASIS Standard. Changes may only be made to address the comments. The TC must provide an acceptable summary that is clear and comprehensible of the changes made and a statement that the TC judges the changes to be Non-Material to the TC Administrator and request a Special Majority Vote to proceed with the call for consent. The TC Administrator shall hold the Special Majority Vote and announce it to the OASIS membership and optionally on other public mail lists along with the summary of changes and the TC’s statement. If the Special Majority Vote passes, the TC Administrator must start the call for consent for OASIS Standard within 7 days of notification.
  • If comments were received and Material Changes are to be made to the Candidate OASIS Standard, the editors(s) may prepare a revised specification to be approved as a Committee Specification Draft by the TC and proceed with a subsequent Public Review as noted in Section 2.6. Before resubmission the specification must be approved as a Committee Specification.

2.8.3 Call for consent for OASIS Standard

In calling for consent to progress a Candidate OASIS Standard to OASIS Standard, each OASIS Organizational Member at the time of the call shall be entitled to express their consent. Consent shall be established using the publicly archived electronic voting facility supplied by OASIS.

An announcement will be sent to each member entitled to express their consent and shall specify the closing date and time for the consent period which must be open for at least 14 days. Eligible members are assumed to agree to consent and must explicitly use the voting facility if they wish to record an objection to the Candidate OASIS Standard’s progressing.

The TC shall be required to respond only to valid objections. In order to be considered valid, an objection must:

  1. Be entered on the electronic ballot prior to its closing, and
  2. Must be accompanied by a reason for the objection and/or a proposed remedy which would satisfy the objector, provided either on the ballot or publicly to the TC’s archived public comment facility or, for a TC Member, to the TC’s mailing list.

The TC Administrator shall make the final determination as to whether objections are valid or not.

Ballot results shall be publicly visible during the consent period. Eligible Members may change their opinion up until the end of the consent period. The results of a call for consent on a proposed standard shall be provided to the membership and to the TC no later than seven days following the close of the consent period.

If at the end of the consent period:

  1. There are no valid objections, the candidate OASIS Standard shall become an OASIS Standard.
  2. 15 or more of eligible OASIS Members have submitted valid objections, the Candidate OASIS Standard shall be deemed to have been rejected and shall not progress to OASIS Standard.
  3. There are valid objections amounting to less than 15 eligible OASIS Members, the TC shall have 30 days to try to resolve the objections or withdraw the submission. If the TC takes no formal action within this 30 day period, the Candidate OASIS Standard shall not progress to OASIS Standard.

If the TC chooses to attempt to resolve the objections, the TC shall be required to interact with each objector to discuss their objections and the proposed remedies. However, if an objector does not make himself available to meet with the TC or to provide written answers to questions from the TC within the 30 day period, the TC shall not be required to take further action on that objection. The TC shall not be required to make any changes to the Candidate OASIS Standard in response to specific objections nor shall they be required to satisfy any objector.

After meeting with the objectors and deciding how to resolve the objections, the TC shall prepare a comment resolution log, approve it by Full Majority Vote and submit it to the OASIS TC Administrator.

After submitting the comment resolution log to the OASIS TC Administrator, the TC shall have 30 days to take one of the following actions via Special Majority Vote:

  1. Withdraw the submission entirely.
  2. If no changes are made to the COS, request the TC Administrator to approve the submitted COS as an OASIS Standard despite the objections.
  3. Submit a Candidate OASIS Standard amended to address some or all of the issues raised by the objections and either:
    1. If no Material changes have been made to the COS, request the TC Administrator to approve the amended COS as an OASIS Standard, or
    2. If Material changes have been made to the COS, request a second call for consent to progress the amended COS to OASIS Standard.

The TC Administrator shall make the final determination as to whether changes to an amended COS are Material or Non-Material. If the TC Administrator deems any changes made to be Material, then a second call for consent shall be required. Decisions of the TC Administrator shall be subject to appeal as described in section 4.2 below.

A second call for consent shall be run in the same way as the initial call for consent with the exception that:

  1. If a valid objection from the first call for consent is substantively repeated, it shall not be counted as a valid objection for the second call for consent, and
  2. If Material changes are deemed necessary to satisfy valid objections to the second call for consent, the COS shall not become an OASIS standard.

A TC only gets one attempt to make Material changes in the consent process.

Failure of a call for consent for any reason shall not prevent a later version of the same specification from being submitted again as specified in this section.

2.9 Approved Errata

A TC may approve a set of Errata to an OASIS Standard that it developed as Approved Errata by:

  1. Adopting the set of proposed corrections as a Committee Specification Draft, in the form of a list of changes, and optionally accompanied by a copy of the original OASIS Standard text marked to incorporate the proposed changes,
  2. Confirming by Full Majority Vote that the proposed corrections do not constitute a Material Change,
  3. Submitting the proposed corrections for a 15-day public review, and completing that review, pursuant to Section 2.6, and
  4. After the public review, confirming the proposed corrections as Approved Errata by a Full Majority Vote.

Once approved, the Approved Errata shall be made available with the OASIS Standard it corrects, in any publication of that OASIS Standard.

A TC may not adopt Approved Errata to an OASIS Standard more than once in any six-month period.

Section 3. Board of Directors Involvement in the TC Process

3.1 OASIS TC Administrator

The OASIS TC Administrator shall act as the Technical Committee Liaison to the Board for the purpose of keeping the Board apprised of activities related to the TC Process. The specific duties of the TC Liaison shall be specified by the Board in consultation with the TC Administrator but shall, at a minimum, provide for the submission to the Board of a notice when a proposal has been received for the creation of a new TC and when a TC submits a Committee Specification as a Candidate OASIS Standard. Such notice shall be delivered via email to the Board immediately upon the receipt of the submission by the TC Administrator. The TC Administrator shall also send a copy of proposals for the creation of new TCs to the Technical Advisory Board (TAB) for their comment.

Notwithstanding anything to the contrary contained in this TC Process, upon majority vote of the members of the Board at a meeting thereof duly called and constituted, the creation of a new TC may be prevented, or a proposed OASIS Standard may be withheld from voting by OASIS Membership; the proposal or the submission shall be returned to the proposers or the sponsoring TC for additional consideration, with an explanation of the reasons for such action.

The Board of Directors may amend this TC Process at any time and from time to time at its sole discretion.

3.2 Appeals

Any Eligible Person who believes that:

  • an action taken or not taken by or with respect to TCs, or
  • an action taken or not taken by the TC Administrator,

is in violation of the procedures set forth in this TC Process or OASIS policies specified by the OASIS Board of Directors, may appeal such action or inaction.

Appellants shall file a complaint within 30 days of the action being appealed or at any time with respect to an inaction. The complaint shall state the nature of the objection(s), including any direct and material adverse effects upon the appellants; the section(s) of this TC Process or OASIS policies at issue; the actions or inactions at issue; and the specific remedial action(s) that would satisfy the appellants’ concerns. Previous efforts to resolve the objection(s) and the outcome of each shall be noted.

Appeals regarding actions or inactions of a TC must be made to the TC Administrator.

Appeals regarding actions or inactions of the TC Administrator must be made to the OASIS Board of Directors.

In the case of an appeal to the TC Administrator: within 15 days of receipt of the complaint, the TC Administrator shall provide a copy of the complaint to the TC; and within 30 days of such receipt, shall render a decision, with a copy to the TC.

In the case of an appeal to the OASIS Board of Directors: such appeal, in order to be valid, shall be sent to the board comment list (oasis-board-comment@lists.oasis-open.org) and the relevant TC(s). The Board shall hold a hearing (with the appellants invited) 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 brought under this TC Process.

Section 4. Application to Existing TCs

This TC Process applies to previously established TCs upon its adoption.

OASIS Defined Terms

This version of the OASIS Defined Terms was approved by the OASIS Board of Directors on 22 May 2018 and became effective immediately.

The previous version, approved 03 November 2017 and effective immediately, can be found at https://www.oasis-open.org/policies-guidelines/oasis-defined-terms-2017-11-03.

Definitions of Key Terms

1.1 Introduction

This document defines terms that carry specific meaning when used in OASIS policy and rule documents. Additional definitions specific to the OASIS IPR Policy can be found in that document.

1.2.Definitions

  1. Administrative Document” is a document that is used by a committee only in support of internal operations. Examples are minutes, agenda, liaison statements, issue lists, bug lists, etc. Inter-group communications to request review, respond to review comments, or to respond to questions or requests for clarifications are considered to be Administrative Documents. Administrative Documents are not Standards Track Work Products, Non-Standards Track Work Products nor Project Standards Track Work Products. An Administrative Document must not use a Work Product template.
  2. Approved Errata” is a set of Non-Material corrections to an OASIS Standard that have been approved by a Full Majority Vote of an OASIS Technical Committee or Project Governing Board.
  3. Candidate OASIS Standard” is an OASIS Committee Specification or Project Specificationthat has been approved by a Special Majority Vote of an OASIS Technical Committee or Project Governing Board for submission to the OASIS Membership for consideration to become an an OASIS Standard. A Candidate OASIS Standard is an OASIS Standards Final Deliverable and is subject to the patent licensing and other obligations explained in the OASIS IPR Policy.
  4. Chair” is a committee member elected by the other members to schedule, officiate at and conduct meetings, provide leadership, act as primary liaison to OASIS staff and in general ensure a committee works efficiently to achieve its goals.
  5. Charter” is the organizational document for a committee comprised of the items included in the template for the proposal to form that committee. The items in a charter vary depending on the type of committee being formed.
  6. Committee Note” is a Non-Standards Track Work Product that has been approved by a Full Majority Vote of an OASIS Technical Committee. A Committee Note is not subject to the patent licensing and other obligations explained in the OASIS IPR Policy.
  7. Committee Note Draft” is a Non-Standards Track Work Product that has been approved by a Full Majority Vote of a Technical Committee. A Committee Note Draft is not subject to the patent licensing and other obligations explained in the OASIS IPR Policy.
  8. Committee Note Public Review Draft” is a Committee Note Draft that has been approved by a Full Majority Vote of a Technical Committee. A Committee Note Public Review Draft is not subject to the patent licensing and other obligations explained in the OASIS IPR Policy.
  9. Committee Specification” is a Standards Track Work Product that has been approved as such by a Special Majority Vote of a Technical Committee. A Committee Specification is an OASIS Standards Final Deliverable and subject to the patent licensing and other obligations explained in the OASIS IPR Policy.
  10. Committee Specification Draft” is a Standards Track Work Product that has been approved by a Full Majority Vote of a Technical Committee. A Committee Specification Draft is not an OASIS Standards Final Deliverable and is not subject to the patent licensing and other obligations explained in the OASIS Intellectual Property Rights (IPR) Policy.
  11. Committee Specification Public Review Draft” is a Standards Track Work Product that has been approved by a Full Majority Vote of a Technical Committee. A Committee Specification Public Review Draft is not an OASIS Standards Final Deliverable and is not subject to the patent licensing and other obligations explained in the OASIS Intellectual Property Rights (IPR) Policy.
  12. Conformance clause” is a statement in a Standards Track Work Product that references one or more Normative Statements in order to describe a condition that an implementation must satisfy in order for it to conform to that part of the Work Product.
  13. Contributor License Agreement (CLA)” is a form signed by a person who wishes to submit material to an OASIS Open Repository or Open Project. The CLA binds the donor to the repository’s applicable license and such other consistent terms as OASIS may require as a publisher to assure its availability.
  14. Convener” is an Eligible Person who serves in the role of organizing the activities leading up to the first meeting of a Technical Committee.
  15. Day” or “Days” means calendar days unless otherwise specified.
  16. Eligible Person” is one of a class of individuals that includes (a) OASIS Individual Members, (b) employees or designees of OASIS Organizational Members, and (c) such other persons as may be designated by the OASIS Board of Directors.
  17. Errata” is a set of Non-Material corrections to an OASIS Standard that have not yet been approved by an OASIS Technical Committee or Project Governing Board as an Approved Errata.
  18. Full Majority Vote” is a vote in which more than 50% (more than half) of the eligible voters vote “yes.” If the vote is held in a committee meeting, more than 50% of the total eligible voters must vote “yes” regardless of the number of present. Abstentions are not counted. For example, if an OASIS Technical Committee has 20 Voting Members on its roster and 12 are present in a meeting, at least 11 Voting Members must vote “yes” for a motion to pass.
  19. IPR” means intellectual property rights.
  20. IPR Mode” is one of the licensing modes defined in section 10 of the OASIS Intellectual Property Rights (IPR) Policy. IPR Mode generally refers to the mode selected by the proposers of a Technical Committee in its charter.
  21. Leave of Absence” is an approved absence from the work of a Technical Committee during which time the member’s standing in the committee shall be maintained and the member shall be free of any participation or other obligations until the time of his or her return.
  22. Material Change” is any change to the content of a Work Product that that would require a compliant application or implementation to be modified or rewritten in order to remain compliant or which adds new features or otherwise expands the scope of the work product.
  23. Meeting” is a gathering of a committee’s members that is properly called and scheduled in advance using the OASIS collaborative tools.
  24. Member“, with respect to a committee, is an Eligible Person who has taken the necessary steps to join the committee and is allowed to subscribe to that committee’s email list, participate in its discussions, attend and participate in its meetings, and make contributions to the committee’s work.
  25. Minimum Membership” is five Voting Members of a committee required to maintain voting rights for its members or, in the case of a committee not required to maintain voting rights or for a project about to be formed, five Eligible Persons, at least two of which represent different OASIS Organizational Members. For Project Governing Boards, Project Approval Minimum Membership is defined separately below.
  26. Non-Material Change” is any change to the content of a Work Product that does not add or remove any feature of the Work Product and that: (a) constitutes only error corrections, editorial changes, or formatting changes; or (b) is a pro forma change to content required by TC Administration.
  27. Non-Normative Reference” is a reference in a Standards Track Work Product or Project Standards Track Work Product to an external document or resource provided to the implementer for informative purposes only and which has no bearing on any Normative Portions of the Work Product.
  28. Non-Standards Track Work Product” is a Work Product produced and approved by an OASIS Technical Committee in accordance with the TC Process that may be progressed to Committee Note. Non-Standards Track Work Products are intended to be informative and explanatory in nature. They are not subject to the patent licensing and other obligations explained in the OASIS Intellectual Property Rights (IPR) Policy Non-Standards Track Work Products must not contain language that would otherwise fall within the definition of Normative Portion.
  29. Normative Portion” is a portion of an OASIS Standards Final Deliverable or Project Standards Final Deliverable that must be implemented to comply with such deliverable. If such deliverable defines optional parts, Normative Portions include those portions of the optional part that must be implemented if the implementation is to comply with such optional part. Examples and/or reference implementations and other specifications or standards that were developed outside the TC or PGB and which are referenced in the body of a particular final deliverable that may be included in such deliverable are not Normative Portions.
  30. Normative Reference” is a reference in a Standards Track Work Product or Project Standards Track Work Product to an external document or resource with which the implementer must comply, in part or in whole, in order to comply with a Normative Portion of the Work Product.
  31. OASIS Deliverable” is any of the following: Committee Specification Drafts, Committee Specification Public Review Drafts, Committee Specifications, Candidate OASIS Standards, OASIS Standards, Approved Errata, Committee Note Drafts, Committee Note Public Review Drafts, and Committee Notes.
  32. OASIS Individual Member” is an OASIS Member who is classified as such in their executed Membership Agreement.
  33. OASIS Member” is a person, organization or entity who is a voting or non-voting member of the corporation, as defined by the OASIS Bylaws.
  34. OASIS Non-Standards Draft Deliverable“means any of the following: Committee Note Drafts and Committee Note Public Review Drafts.
  35. OASIS Non-Standards Final Deliverable” means any of the following: Committee Notes.
  36. OASIS Open Project Administrator” is the person or persons representing OASIS in administrative matters relating to Open Projects, Open Repositories, or Project Governing Boards. All official communications must be sent to op-admin@oasis-open.org.
  37. OASIS Organizational Member” is an OASIS Member who is classified as such in their executed Membership Agreement.
  38. OASIS Standards Draft Deliverable” indicates draft work products developed under the OASIS Intellectual Property Rights (IPR) Policy comprising any of the following: Committee Specification Draft or Committee Specification Public Review Draft.
  39. OASIS Standards Final Deliverable” indicates final work products developed under the OASIS Intellectual Property Rights (IPR) Policy, comprising any of the following when originating from a Technical Committee: Committee Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata.
  40. OASIS Standard” is a Candidate OASIS Standard that has been approved by the OASIS Membership following the procedures explained in section 2.8.3 of the OASIS TC Process.
  41. OASIS TC Administrator” is the person or persons representing OASIS in administrative matters relating to Technical Committees. All official communications must be sent to tc-admin@oasis-open.org.
  42. Observer” is an Eligible Person who has taken the necessary steps to join a Technical Committee, is subscribed to the TC email list, and may attend TC meetings, but is not allowed to participate in TC email list discussions, participate or speak in TC meetings, or make Contributions to the TC. Observers are not listed on a TC’s public roster. The process for becoming an Observer is defined in section 1.4 of the OASIS TC Process.
  43. Open Project” is a group comprised of at least the Minimum Membership formed and conducted according to the provisions of the OASIS Open Project Rules for the purpose of developing source code, data specifications and other artifacts under a specified open source license.
  44. 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 the OASIS Open Repository Guidelines and Procedures.
  45. Persistent Non-Voting Member” is a Technical Committee Member who wishes to participate in the work of the committee but who does not wish to count for purposes of calculating quorum, make or second motions, or vote.
  46. Primary Representative“, for any OASIS Organizational Member, is the person designated by that Member to serve as the consortium’s principal contact for administrative issues.
  47. Project Approval Minimum Membership” shall have the meaning defined for such term in the OASIS Open Project Rules.
  48. Project Governing Board“(or “PGB“) means a group comprised of at least the Minimum Membership formed and conducted according to the provisions of the OASIS Open Project Rules.
  49. Project Standards Final Deliverable” indicates final work products developed under the OASIS Open Project Rules, comprising any of the following when originating from a PGB: Project Specification, Candidate OASIS Standard, OASIS Standard, or Approved Errata.
  50. Project Standards Track Work Product” is a Work Product produced and approved by a Project Governing Board in accordance with the OASIS Open Project Rules that may be promoted to Project Specification or OASIS Standard.
  51. Project Specification” is one or more Release(s) or subsets of Release(s) of an OASIS Open Project properly prepared and nominated by the Project Governing Board (PGB) and approved as such by the Members of the PGB by a Special Majority Vote.
  52. Project Sponsor” shall have the meaning defined for such term in the OASIS Open Project Rules.
  53. Public” and “publicly” is all persons, organizations and entities, whether or not OASIS Members.
  54. Quorum” is the number of Eligible Persons in a committee that must be present in a meeting so that Resolutions and decisions may be made. The quorum for OASIS committee meetings is a simple majority (more than half) of the Voting Members or, for committees that do not use voting rights, a simple majority of the Members.
  55. Quorate Meeting” is a committee meeting at which a Quorum is present.
  56. Release,” with respect to an OASIS Open Project, is a collection of links to resources within the project that enable the Project Governing Board to deliver software to users.
  57. Resolution” is a decision reached by a Technical Committee by vote, or by a PGB when voting is used. Resolutions require a Simple Majority Vote to pass, unless a Full Majority Vote or Special Majority Vote is required under the applicable Process. The Open Project Rules govern when PGBs must conduct a vote in order to reach decisions.
  58. Simple Majority Vote” is a vote in which the number of “yes” votes cast is greater than the number of “no” votes cast. Abstentions are not counted. For example, in a Quorate Meeting in which 20 Voting Members are present, if 7 vote “yes” and 4 vote “no”, the motion passes.
  59. Special Majority Vote” is a vote in which at least 2/3 (two thirds) of the eligible voters vote “yes” and no more than 1/4 (one fourth) of the eligible voters vote “no”. These numbers are based on the total number of eligible voters in the committee. Abstentions are not counted. For example, in a Technical Committee in which there are 30 Voting Members, at least 20 Voting Members must vote “yes” for a motion to pass; but if 8 or more vote “no” then the motion fails. All Special Majority Votes must be conducted via electronic ballot by the OASIS TC Administrator.
  60. Standards Track Work Product” is a Work Product produced and approved by a Technical Committee in accordance with the OASIS TC Process and the OASIS Intellectual Property Rights (IPR) Policy that may be promoted to Committee Specification or OASIS Standard.
  61. Statement of Use“, with respect to a Committee Specification or Project Specification, is a written statement that a party has successfully used or implemented that specification in accordance with all or some of its conformance clauses, identifying those clauses that apply, and stating whether its use included the interoperation of multiple independent implementations. The Statement of Use must be made to a specific version of the Specification and must include the Specification’s approval date. The party may be an OASIS Member or a non-member. In case of a non-member, the Statement of Use must be submitted via the Technical Committee’s or Project Governing Board’s comment facility. A TC or PGB may require a Statement of Use to include hyperlinks to documents, files or demonstration transcripts that enable the committee’s members to evaluate the implementation or usage. A Statement of Use submitted to the TC or PGB must be approved by TC Resolution or PGB action as an acceptable Statement of Use with respect to the Specification. A party can only issue one Statement of Use for a given specification. When issued by an OASIS Organizational Member, a Statement of Use must be endorsed by the Organizational Member’s Primary Representative.
  62. Subcommittee” (or “SC“) is a group of Members of a TC producing recommendations for consideration by the parent TC.
  63. Technical Committee” (or “TC“) means a group comprised of at least the Minimum Membership formed and conducted according to the provisions of the OASIS TC Process.
  64. Voting Member” is a Member of a committee who has voting rights in the committee. The process for gaining voting rights is defined differently for each type of committee.
  65. Work Product” is a package of materials (e.g. narrative documents, schemas, sample code) being prepared under a single name and version number and which is either a Standards Track Work Product or Non-Standards Track Work Product, or a Project Standards Track Work Product. Other outputs of an OASIS Open Project, including Releases and Group Releases, are not included in this definition.
  66. Work Product Approval Motion” is any motion to initiate a Work Product Ballot.
  67. Work Product Ballot” is any TC ballot for the:
    1. approval of a Committee Specification Draft or Committee Note Draft,
    2. start of a Public Review,
    3. approval of a Committee Specification or a Committee Note, or
    4. submission of a Committee Specification as a Candidate OASIS Standard.
  68. Working Draft” is a preliminary version of a Work Product produced by one or more TC Members that has not yet been voted on by the TC and approved as a Committee Specification Draft or a Committee Note Draft. Some examples are initial contributions and revisions made by editors or other TC Members.

OASIS Committee Operations Process

This version of the OASIS Committee Operations Process was approved by the OASIS Board of Directors on 22 May 2018 and became effective immediately.

The previous version, approved 03 November 2017 and effective immediately, can be found at https://www.oasis-open.org/policies-guidelines/oasis-committee-operations-process-2017-11-03.

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.

Observer

Member

Persistent Non-Voting Member

Voting Member

Can attend meetings

YES

YES

YES

YES

Can participate in meetings

NO

YES

YES

YES

Receives email from TC list

YES

YES

YES

YES

Can send email to TC list

NO

YES

YES

YES

Can contribute documents, etc.

NO

YES

YES

YES

Can use JIRA, Wiki, etc.

NO

YES

YES

YES

Can gain voting rights

NO

YES

NO (must first become a Member)

N/A

Can lose voting rights

NO

NO

NO

YES

Has voting rights

NO

NO

NO

YES

Counts towards quorum

NO

NO

NO

YES

Can make & second motions

NO

NO

NO

YES

Is publicly listed on TC roster, minutes, etc

NO

YES

YES

YES

Is obligated by TC IPR Mode

NO

YES

YES

YES

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.

Participant

Contributor

Maintainer

Project Governing Board (PGB)

Chair

Functions

May provide comments and bug reports

YES

YES

YES

YES

YES

May submit pull requests

NO

YES

YES

YES

YES

Respond to pull requests, etc.

NO

NO

YES

NO

NO

Appoint and supervise Maintainer(s)

NO

NO

NO

YES

N/A

Authorize creation of repositories

NO

NO

NO

YES

N/A

Approve releases

NO

NO

NO

YES

N/A

Approve submissions of qualifying releases for Project Specification approvals (as defined below)

NO

NO

NO

YES

N/A

Approve external submissions of its OASIS Standards (if any) to de jure standards bodies

NO

NO

NO

YES

N/A

Elect Chair

NO

NO

NO

YES

N/A

Call and preside over any meetings

NO

NO

NO

NO

YES

Requirements

Must be OASIS Member

NO

NO

NO

YES

YES

Must sign Contributor License Agreement (CLA)

NO

YES

YES

YES

YES

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.

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 and 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 and referenced on the committee web page.

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, either by using the committees general mail list or the publicly archived electronic voting functionality provided by OASIS. An electronic ballot 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.

No results with the selected filters