An OASIS TC Open Repository is an optional facility that can be initiated by an OASIS Technical Committee (TC) to support its standardization work.

Development activities conducted within a TC Open Repository are distinct from OASIS TC technical development activities. Each formal specification development project at OASIS is hosted by a specific Technical Committee whose posted charter defines the purpose and scope of its activities. Technical guidance, in the form of open standards and formally approved specifications, is created only by TCs according to the rules set out in the OASIS TC Process policy, and in licensing terms provided by our IPR Policy.

A TC may wish to encourage development and sharing of additional material to supplement or support its standards work. Such supporting content may be informal in nature, and need not be incorporated into the formal specifications. Supporting resources might include use cases, sample payloads, implementation code, or best practice commentary. All of these types of information may be donated to a TC Open Repository by communities of developers and users, whether OASIS/TC members or not.

Note: the plain-language descriptions presented in this document provide a rule summary, but not the definitive statement of rules that apply to TC Open Repositories. The binding, normative rules and procedures are contained in these three documents:


1. What steps must a TC take in order to start a new TCOpen Repository?

A qualifying Technical Committee (a TC using the Non-Assertion, RF on Limited Terms, or RF on RAND IPR Mode) must vote to create a repository, and as part of that resolution, must specify the license that will apply to repository contributions, selected from the license list presented in the TC Open Repository Guidelines . The proposal for creation of a TC Open Repository must also include a written purpose statement, to be included in the repository’s README file. The TC must also designate at least one member to act as the Maintainer for the repository.

2. How is a TC Open Repository implemented in technology?

TC Open Repository Administration staff will initialize each repository with its own Web address after receipt of a TC’s qualifying request. TC Open Repositories will be set up as GitHub projects under the GitHub organization at

3. May a TC have more than one TC Open Repository?

Yes: some TCs may choose to use different GitHub repositories for different topics or types of work.

4. What governs the purpose and scope of a TC Open Repository?

A TC must provide a written purpose statement when requesting a TC Open Repository, and that text identifies the primary areas of interest. However, the implied scope will not be rigidly enforced by a formal process. Rather, community members will be encouraged to participate in any repository sub-projects of their choice; by doing so, they will set the direction for development of selected resources. However, contributions will not be deleted from the repository as a means of enforcing community expectations about purpose and scope.

5. May a TC (or Maintainers) close a TC Open Repository?

No: once a TC Open Repository is created, it is considered a permanent, independent resource that will remain open and available to its community of developers and users.

6. May a TC (or Maintainers) delete contributions from a TC Open Repository?

No: contributions to a TC Open Repository are a part of its historical record and must remain available for inspection and use, as clarified in the TC Open Repository Guidelines document (see ARCHIVAL PERMANENCE).

7. Who may contribute to a TC Open Repository?

Anyone who agrees to be bound by the repository’s licensing requirement by signing the appropriate contributor licensing agreement (CLA) may contribute, subject to evaluation of GitHub pull requests. The purpose of the CLA is to confirm that each contributor is willing to grant the open license rights associated with that repository.

8. How does a contributor agree to the Individual CLA?

Every individual contributor to any TC Open Repository must indicate agreement by responding affirmatively to the Individual CLA. If individuals are seeking to make contributions on behalf of an organization (e.g., a corporate entity such as an employer), they also confirm that the organization has assented to their contributions, expressed in the organization’s signed Entity CLA.

9. When are Entity CLAs used, and whose responsibility are they?

If an individual wishes to make contributions on behalf of an organization, then the organization may also confirm support for such contributions by completing an Entity CLA (indicating agreement). However, it is not the responsibility of an individual contributor to ensure that an organization signs an Entity CLA.

10. If I’m employed by an entity, am I also bound by the Individual CLA?

Yes: all individual contributors must agree to the Individual CLA, even if there is an applicable Entity CLA. The Individual CLA addresses the person’s own obligations, which might outlive current employment or similar relationships. OASIS validates the identity of the individual contributor together with the signed Individual CLA in the evaluation of a pull request.

11. How does OASIS provide notice of license terms, and confirm that the selected open license applies to all of the contributions in a TC Open Repository?

The license terms governing contributions to each TC Open Repository are published conspicuously from the principal web page (the README file), with details in the LICENSE file and in guidelines for contributing (the CONTRIBUTING file). All three files are listed in the root of each TC Open Repository. All contributors are required to agree to the CLAs as described above. OASIS also publishes a record of all qualifying Entity CLAs, against which readers can confirm the licensing commitments made for any particular contribution.

12. What establishes the licensing rules applicable to the material contributed to a TC Open Repository? Can anyone use the material in a TC Open Repository?

The originating OASIS TC specifies what license will be applied to the material in a specific repository, selecting from the list of licenses, as identified in the TC Open Repository Guidelines. All of those licenses permit broad content reuse by the public. A link to the selected license is posted on the principal web page of each TC Open Repository.

13. What technical steps are necessary to make contributions to a TC Open Repository?

OASIS TC Open Repositories use the familiar fork-and-pull collaboration model supported by GitHub and other distributed version control systems. Anyone wishing to contribute should fork the repository, make additions or other modifications, and then submit a pull request. All TC Open Repositories are public, so anyone can fork the repository and issue a pull request. Typically, pull requests will be accompanied by supporting comments and/or issues. Community conversations about pull requests will provide the basis for a determination to merge, modify, close, or take other action, as communicated by the Maintainers.

14. Who maintains the content of a TC Open Repository?

The originating OASIS TC must designate one or more “Maintainers” to manage repository content. Maintainers (also called “committers” in some open source projects) are recognized and trusted leaders who act to implement community goals, consensus, and technical design preferences. For example, Maintainers have responsibility for assigning and closing issues, creating and associating milestones, creating releases, designating a default branch, creating and applying labels, merging and closing pull requests, assigning evaluation of a pull request, resolving merge conflicts, etc. Maintainers thus keep the community focused upon key development goals, keep repository assets clearly identified and organized, and help keep conversations on topic. The Maintainers may identify and approve additional Maintainers for the repository, pursuant to community consensus.

15. How can readers determine what material is included in a TC Open Repository?

As TC Open Repositories are implemented as GitHub public repository projects, all material contributed is publicly viewable, together with metadata identifying the contributor, the contribution date, etc. Because repository assets are managed under version control, intermediate as well as current versions will be accessible and re-usable.

16. What is the relationship between a TC’s Open Repositories and its formal specifications?

Contributions made to a TC’s Open Repository do not have any automatic relationship or status in that TC’s standards work. OASIS TCs and their specifications (Work Products) are governed by a completely different set of licensing rules and process rules than apply to OASIS TC Open Repositories and their contributions. (See the OASIS IPR Policy.) However, parties may propose the re-use of material from a TC Open Repository by a TC, or material from a TC by a TC Open Repository, under the applicable OASIS rules as described below.

Note: Because different licenses apply to the OASIS TC’s specification work, and a TC Open Repository, there is no guarantee that the licensure of specific repository material will be compatible with the licensing requirements of an implementation of a TC’s specification. Please refer to the repository’s LICENSE file for the terms of that material, and to the OASIS IPR Policy for the terms applicable to the TC’s specifications.

17. Can a contributor to a TC’s Open Repository push a contribution to the TC for use in its formal specifications?

A direct push operation from within a TC Open Repository is not supported because the two facilities are separate, and operate under different licensing rules. However, a repository contributor can also choose to offer a contribution to a TC, under the OASIS Feedback License for external comments, by posting it to that separate public comment facility, as described in the TC Process.

18. Can a TC member pull material from one of its TC Open Repositories into the TC’s formal specifications?

A direct pull operation from an associated TC Open Repository is not supported because the two facilities are separate, and operate under different licensing rules. There is no automatic assurance that material contributed to a TC Open Repository also will have appropriate licensing and permission that conforms to the TC’s licensing requirements. Individual TC members make their own determinations about the licensing suitability of their own contributions. A TC member could choose to copy material from a TC Open Repository and make a contribution of that material to the TC, if that member determines that such contribution to the TC is permitted under the applicable rules of that TC and the license applicable to the repository material.

19. If a TC has material such as code snippets in its formal specification, may it also place that material in an associated related TC Open Repository?

The TC member could arrange for this outcome, if there were desire to make the code more widely available, but in order to do so, separate and additional permissions would need to be secured from the code’s contributors. This is because material contributed to a TC under the TC’s license terms does not necessarily have the specific licensing permissions required for inclusion in a TC Open Repository. For example, contributions to an OASIS TC are licensed for use only for implementations in support of that TC’s final deliverables, while contributions to an OASIS TC Open Repository must be available for re-use for any purpose, at any time, without restriction. So, as a practical matter, TC members who wish to support cross-posting would need to cross-contribute the code snippets or similar content to the TC Open Repository as a distinct act.


Please send any feedback or questions to TC Open Repository Administration at