├── .gitignore ├── collateral ├── Hyperledger_Aries_Logo_Black.eps ├── Hyperledger_Aries_Logo_Black.jpg ├── Hyperledger_Aries_Logo_Black.png ├── Hyperledger_Aries_Logo_Color.eps ├── Hyperledger_Aries_Logo_Color.jpg ├── Hyperledger_Aries_Logo_Color.png ├── Hyperledger_Aries_Logo_White.eps ├── Hyperledger_Aries_Logo_White.png ├── Hyperledger_Aries_Logo_Color.svg ├── Hyperledger_Aries_Logo_Black.svg └── Hyperledger_Aries_Logo_White.svg ├── MAINTAINERS.md ├── TSC.md ├── README.md ├── SECURITY.md ├── LICENSE └── Hyperledger Aries Technical Charter.md /.gitignore: -------------------------------------------------------------------------------- 1 | *.pyc 2 | __pycache__ 3 | .idea 4 | .DS_Store 5 | -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Black.eps: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_Black.eps -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Black.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_Black.jpg -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Black.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_Black.png -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Color.eps: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_Color.eps -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Color.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_Color.jpg -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Color.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_Color.png -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_White.eps: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_White.eps -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_White.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hyperledger-aries/aries/HEAD/collateral/Hyperledger_Aries_Logo_White.png -------------------------------------------------------------------------------- /MAINTAINERS.md: -------------------------------------------------------------------------------- 1 | # Maintainers 2 | 3 | This file defines the Maintainers processes (adding, removing) and duties for all repositories in the Hyperledger Aries Project, 4 | as well as the list of Maintainers for this repository. "Maintainers" are defined as any individuals with escalated GitHub privileges above 5 | "READ" in Hyperledger Aries repositories. Maintainers **MUST** abide by the Hyperledger Aries Project Charter. 6 | 7 | All other Hyperledger Aries Project repository MAINTAINERS.md files point to this file. 8 | 9 | ## Maintainers for this Repository 10 | 11 | Maintainers for this repository are listed in the [Access Control YAML file]. 12 | Search in the file for this repository. 13 | 14 | [Access Control YAML file]: https://github.com/hyperledger/governance/blob/main/access-control.yaml 15 | 16 | ## The Duties of a Maintainer 17 | 18 | Maintainers are expected to fulfill the following responsibilities for the repositories they oversee. The duties are listed in more or less priority order: 19 | 20 | - Review, respond, and act on any security vulnerabilities reported against the repository. 21 | - Review, provide feedback on, and merge or reject GitHub Pull Requests from 22 | Contributors. 23 | - Review, triage, comment on, and close GitHub Issues 24 | submitted by Contributors. 25 | - When appropriate, lead/facilitate architectural discussions in the community. 26 | - When appropriate, lead/facilitate the creation of a product roadmap. 27 | - Create, clarify, and label issues to be worked on by Contributors. 28 | - Ensure that there is a well defined (and ideally automated) product test and 29 | release pipeline, including the publication of release artifacts. 30 | - When appropriate, execute the product release process. 31 | - Maintain the repository CONTRIBUTING.md file and getting started documents to 32 | give guidance and encouragement to those wanting to contribute to the product, and those wanting to become maintainers. 33 | - Contribute to the product via GitHub Pull Requests. 34 | - Monitor requests from the Hyperledger Technical Oversight Committee about the 35 | contents and management of Hyperledger repositories, such as branch handling, 36 | required files in repositories and so on. 37 | - Contribute to the Hyperledger Project's Quarterly Report. 38 | 39 | ## Becoming a Maintainer 40 | 41 | This community welcomes contributions. Interested contributors are encouraged to 42 | progress to become maintainers. To become a maintainer the following steps 43 | occur, roughly in order. 44 | 45 | - The proposed maintainer establishes their reputation in the community, 46 | including authoring five (5) significant merged pull requests, and expresses 47 | an interest in becoming a maintainer for the repository. 48 | - A PR is created to update the [Access Control YAML file] to add the proposed maintainer on team with appropriate privileges in the relevant repositories. 49 | - The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal. 50 | - The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer. 51 | - The PR or comment from the proposed maintainer must include their 52 | willingness to be a long-term (more than 6 month) maintainer. 53 | - Once the PR and necessary comments have been received, an approval timeframe begins. 54 | - The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome. 55 | - The PR is merged and the proposed maintainer becomes a maintainer if either: 56 | - At least three (3) TSC or project Maintainers approve the PR or provide an approval comment on the PR. 57 | - If the PR does not get the requisite PR approvals, it may be closed. 58 | 59 | ## Removing Maintainers 60 | 61 | Being a maintainer is not a status symbol or a title to be carried 62 | indefinitely. It will occasionally be necessary and appropriate to move a 63 | maintainer to emeritus status. This can occur in the following situations: 64 | 65 | - Resignation of a maintainer. 66 | - Violation of the Code of Conduct warranting removal. 67 | - Inactivity. 68 | - A general measure of inactivity will be no commits or code review comments 69 | for one reporting quarter. This will not be strictly enforced if 70 | the maintainer expresses a reasonable intent to continue contributing. 71 | - Reasonable exceptions to inactivity will be granted for known long term 72 | leave such as parental leave and medical leave. 73 | - Other circumstances at the discretion of the other Maintainers. 74 | 75 | The process to remove a maintainer from active status is comparable to the process for adding a maintainer, outlined above. In the case of voluntary 76 | resignation, the Pull Request can be merged following a maintainer PR approval. If the removal is for any other reason, the following steps **SHOULD** be followed: 77 | 78 | - A PR is created to update the [Access Control YAML file] to remove the maintainer from the appropriate teams. 79 | - The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or Hyperledger GitHub organization administrator. 80 | - Once the PR and necessary comments have been received, the approval timeframe begins. 81 | - The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists. 82 | - The PR is merged and the maintainer is removed if: 83 | - The PR is approved by the maintainer to be removed, OR 84 | - At least three (3) TSC or Aries Project maintainer PR approvals or approval comments have been recorded. 85 | - If the PR does not get the requisite PR approvals, it may be closed. 86 | 87 | Returning to active maintainer status after being removed uses the same steps as adding a 88 | new maintainer. Note that the emeritus maintainer already has the 5 required 89 | significant changes as there is no contribution time horizon for those. 90 | -------------------------------------------------------------------------------- /TSC.md: -------------------------------------------------------------------------------- 1 | # Hyperledger Aries Technical Steering Committee (TSC) 2 | 3 | This file is referenced by the Hyperledger Aries Project Charter and **MUST** contain: 4 | 5 | - The list of active TSC Members 6 | - The duties of the TSC Members, including in those duties the process for updating those duties 7 | - The process to add and remove TSC Members from active status 8 | 9 | Changes to this file **MUST** be made according to the guidance in this file, and in the Hyperledger Aries Project Charter. 10 | 11 | ## Active TSC Members 12 | 13 | 14 | 15 | | GitHub ID | Name | Email | Company Affiliation | 16 | | --------------- | ---------------- | -------------------------| ------------------- | 17 | | dbluhm | Daniel Bluhm | daniel@indicio.tech | Indicio PBC | 18 | | swcurran | Stephen Curran | swcurran@cloudcompass.ca | BC Gov | 19 | | TelegramSam | Sam Curren | telegramsam@gmail.com | Indicio PBC | 20 | | WadeBarnes | Wade Barnes | wade@neoterictech.ca | BC Gov | 21 | | jamshale | Jamie Hale | | BC Gov | 22 | | JamesEbert | James Ebert | | Instnt | 23 | 24 | ## Emeritus TSC Members 25 | 26 | | Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation | 27 | |----- | --------- | ----- | ---- | ---------- | ----- | ------------------- | 28 | | | | | | | | | 29 | 30 | ## The Duties of a TSC Member 31 | 32 | TSC are expected to perform the following duties for the Hyperledger Aries project. 33 | 34 | - Attend the meetings of the TSC. 35 | - Meetings of the TSC will generally be held during the weekly Aries Working Group calls. 36 | - From time to time, special meetings of the TSC Members may be called. 37 | - Discuss issues about the Governance of the project, guided by the project's Charter, including the documented roles of TSC Members, Maintainers and Contributors. 38 | - Vote on any issues raised about the project in line with the project's Charter. 39 | - Discuss and vote on any issues/disputes about the projects escalated by the project's Maintainers or Contributors. 40 | - When moved, make changes to the project's Charter is permitted by the Charter. 41 | - Contribute to the Hyperledger Aries Project's Quarterly and Annual Report. 42 | 43 | The duties of the TSC Members may be updated through a PR to this file that is voted on by the TSC and merged by a Maintainer of this repository. 44 | Maintainers of this repository are obligated to handle PRs to this file as guided by the TSC. 45 | 46 | ## Becoming a TSC Member 47 | 48 | The following steps occur in becoming a TSC member, roughly in order. 49 | 50 | - The proposed TSC Member establishes their reputation in the Hyperledger Aries Project. 51 | - A PR is created to update this file to add the proposed TSC to the list of active TSC Members. 52 | - The PR is authored by an existing TSC Member or has a comment on the PR from an existing TSC Member supporting the proposal. 53 | - The PR is authored by the proposed TSC Member or has a comment on the PR from the proposed TSC Member confirming their interest in being a TSC Member. 54 | - The PR or comment from the proposed TSC Member must include their 55 | willingness to be a long-term (more than 6 month) TSC Member. 56 | - Once the PR and necessary comments have been received, an approval timeframe begins. 57 | - The PR **MUST** be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome. 58 | - The PR is merged and the proposed TSC Member becomes a TSC Member if either: 59 | - Two weeks have passed since at least three (3) TSC Members have approved the PR or have added an comment expressing approval of the PR, OR 60 | - An absolute majority of TSC Members have approved the PR or have added an comment expressing approval of the PR. 61 | - If the PR does not get the requisite PR approvals or comments expressing approval of the PR, it may be closed. 62 | 63 | TSC membership itself does not confer repository Maintainer status -- that is a separate process. 64 | Typically, TSC members will also be Maintainers, but the processes are independent of one another. 65 | 66 | ## Removing TSC Members 67 | 68 | Being a TSC Member is not a status symbol or a title to be carried 69 | indefinitely. It will occasionally be necessary and appropriate to move a 70 | TSC Member to emeritus status. This can occur in the following situations: 71 | 72 | - Resignation of a TSC Member. 73 | - Violation of the Code of Conduct warranting removal. 74 | - Inactivity. 75 | - A general measure of inactivity will be an extended period of not showing up to TSC Meetings, or participating in TSC discussions at Meetings or in TSC online forums. 76 | - Reasonable exceptions to inactivity will be granted for known long term 77 | leave such as parental leave and medical leave. 78 | - Other circumstances at the discretion of the other TSC Members. 79 | 80 | The process to move a TSC Member from active to emeritus status is comparable to the process for adding a TSC Member, outlined above. In the case of voluntary 81 | resignation, the Pull Request can be merged following a TSC Member PR approval or approval comment. If the removal is for any other reason, the following steps **SHOULD** be followed: 82 | 83 | - A PR is created to update this file to move the TSC Member to the list of emeritus TSC Members. 84 | - The PR is authored by, or has a comment supporting the proposal from, an existing TSC Member or Hyperledger GitHub organization administrator. 85 | - Once the PR and necessary comments have been received, the approval timeframe begins. 86 | - The PR **MAY** be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists. 87 | - The PR is merged and the TSC Members transitions to TSC Members emeritus if: 88 | - The PR is approved or an approval comment added by the TSC Members to be transitioned, OR 89 | - Two weeks have passed since at least three (3) TSC Member PR approvals or approval comments have been recorded, OR 90 | - An absolute majority of TSC Members have approved the PR or added an approval comment. 91 | - If the PR does not get the requisite PR approvals, it may be closed. 92 | 93 | Returning to active status from emeritus status uses the same steps as adding a 94 | new TSC Member. 95 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![Hyperledger Aries](collateral/Hyperledger_Aries_Logo_Color.png) 2 | 3 | Hyperledger Aries allows trusted online peer-to-peer interactions based on 4 | decentralized identities and verifiable credentials. Aries includes a protocol 5 | definition, tools, and reference implementations. The Aries protocol supports 6 | identities rooted in a variety of distributed ledgers or blockchains. This 7 | approach to identity is often called Self Soverign Identity (SSI). 8 | 9 | Key components of an Aries solution are: 10 | * [agents]( 11 | https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0004-agents/README.md), 12 | * [DID communications]( 13 | https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0005-didcomm/README.md), 14 | * [protocols]( 15 | https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md) 16 | * and [key management]( 17 | https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0051-dkms/README.md) 18 | 19 | ## Getting Started 20 | 21 | Aries is a young project that is maturing quickly. As such, be warned that the 22 | project documentation and links may get out of out-of-date. If you find there is 23 | something missing, please connect with the community on the [Aries Hyperledger 24 | Discord Channel](https://discord.com/channels/905194001349627914/905206466410057728). And of course, 25 | pull requests are always welcome to fix things that are confusing! 26 | 27 | If you are entirely new to the decentralized identity space and the Hyperledger 28 | projects there is a [Linux Foundation edX course on decentralized identity and 29 | Hyperledger Indy, Aries and 30 | Ursa](https://www.edx.org/course/identity-in-hyperledger-aries-indy-and-ursa). 31 | Start there! A companion developers edX course is planned for "early" 2020. 32 | 33 | If you know about decentralized identity and verifiable credentials and want to 34 | get started building applications on top of Aries (and Indy), the most 35 | consistently maintained [guide for new 36 | developers](https://aca-py.org/latest/gettingStarted) 37 | is the one included in the Aries Cloud Agent Python (ACApy): 38 | 39 | ## Repos 40 | 41 | The Aries project contains a number of repos, which can be grouped into some 42 | important categories. 43 | 44 | ### Aries Agent Frameworks 45 | 46 | Developers who want to solve business problems (vs. contributing directly to Aries) should start with an Aries agent framework. Agent-based applications are created by adding application-specific code that control the Aries agent. 47 | 48 | There are several Aries general purpose agent frameworks that are ready to go out of the box. 49 | 50 | - [Aries Cloud Agent - 51 | Python](https://github.com/hyperledger/aries-cloudagent-python) (ACA-Py) is 52 | suitable for all non-mobile agent applications and has production deployments. 53 | ACA-Py and a controller run together, communicating across an HTTP interface. 54 | Your controller can be written in any language and ACA-Py embeds the Indy-SDK. 55 | - [Aries Framework - 56 | .NET](https://github.com/hyperledger/aries-framework-dotnet) can be used for 57 | building mobile (via [Xamarin](https://dotnet.microsoft.com/apps/xamarin)) and 58 | server-side agents and has production deployments. The controller for an 59 | aries-framework-dotnet app can be written in any language supporting embedding 60 | the framework as a library in the controller. The framework embeds the 61 | Indy-SDK. 62 | - [Aries Static Agent - 63 | Python](https://github.com/hyperledger/aries-staticagent-python) is a 64 | configurable agent that does not use persistent storage. 65 | 66 | There are several other frameworks that are currently under active development, including: 67 | 68 | - [Aries Framework - Go](https://github.com/hyperledger/aries-framework-go) is a 69 | pure golang framework that provides a similar architecture to ACA-Py, exposing 70 | an HTTP interface for its companion controller. The framework does not 71 | currently embed the Indy SDK and work on supporting a golang-based verifiable credentials implementation is in progress 72 | - [aries-sdk-ruby](https://github.com/hyperledger/aries-sdk-ruby/blob/master/README.md) 73 | - [aries-framework-javascript](https://github.com/hyperledger/aries-framework-javascript/blob/master/README.md) 74 | 75 | ### Development Tools and Test Suites 76 | 77 | The Aries project provides some useful tools for developing agents and testing 78 | that they are compatible with other agents in the ecosystem. 79 | 80 | * [aries-toolbox](https://github.com/hyperledger/aries-toolbox) 81 | * [aries-protocol-test-suite](https://github.com/hyperledger/aries-protocol-test-suite) 82 | 83 | ### Shared Libraries 84 | 85 | *Coming Soon* 86 | There are also a set of shared open source libraries that provide C-callable 87 | APIs that can be used by agents and frameworks to support the Aries protocols. 88 | 89 | * Aries Key Management: Functions for managing keys, including storage plugins. 90 | * Aries Verifiable Data Registry Interface: An interface for verifying data 91 | agianst an underlying ledger. 92 | * Aries Util: Utility functions for Aries communication, such as message 93 | packing. 94 | 95 | While these are in development, the ACA-Py and .NET frameworks embed the Indy-SDK, while the Go framework is building the capabilities in golang. 96 | 97 | ### Protocols 98 | 99 | If you want to understand the theory and the [open standards that these agents 100 | and frameworks 101 | implement](https://github.com/hyperledger/aries-rfcs/blob/master/index.md), then 102 | you should refer to the Aries protocol documents: 103 | 104 | * [aries-rfcs](https://github.com/hyperledger/aries-rfcs) 105 | 106 | ## Project Participation 107 | 108 | You can raise issues using the GitHub issue tracker in each Aries repository. 109 | Pull requests are appreciated; please review CONTRIBUTING.md for the repository 110 | to which you want to contribute. 111 | 112 | You can reach other Aries developers: 113 | * in the [Discord](https://wiki.hyperledger.org/display/HYP/Our+chat+service) channel 114 | [#aries](https://discord.com/channels/905194001349627914/905206466410057728), 115 | * on the [mailing list](https://lists.hyperledger.org/g/aries), 116 | * or in the [Aries Working Group](https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group) weekly call. 117 | 118 | ## Relationship to Hyperledger Indy 119 | 120 | Aries grew out of the work in [Hyperledger 121 | Indy](https://github.com/hyperledger/indy-sdk/blob/master/README.md) to create 122 | technologies for managing decentralized identity. Indy provides a [specific 123 | blockchain purpose-built for 124 | identity](https://github.com/hyperledger/indy-node/blob/master/README.md). The 125 | tools created in Indy for building agents are being migrated to Aries, and 126 | extended to be blockchain-agnostic. Functionality related to the Indy ledger 127 | will remain in Indy. 128 | 129 | If you want to start build decentralized identity capabilities around Indy, you 130 | should use the existing Aries Agent frameworks described above that embed the 131 | Indy SDK. If you are already using the Indy SDK to build a decentralized 132 | identity solution, you can keep using it knowing that it will continue to be 133 | maintained. If and when the Indy SDK is fully or partially deprecated, a 134 | transition process will be communicated. 135 | -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Color.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 9 | 10 | 13 | 34 | 35 | 37 | 39 | 45 | 47 | 52 | 53 | 55 | 61 | 68 | 70 | 76 | 78 | 81 | 82 | 83 | 87 | 88 | -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_Black.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 8 | 9 | 10 | 13 | 34 | 35 | 37 | 39 | 45 | 47 | 53 | 54 | 56 | 62 | 69 | 71 | 77 | 79 | 82 | 83 | 84 | 88 | 89 | 90 | -------------------------------------------------------------------------------- /collateral/Hyperledger_Aries_Logo_White.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 8 | 9 | 10 | 13 | 34 | 35 | 37 | 39 | 45 | 47 | 53 | 54 | 56 | 62 | 69 | 71 | 77 | 79 | 82 | 83 | 84 | 88 | 89 | 90 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Hyperledger Aries Security Policy 2 | 3 | [Hyperledger security vulnerability disclosure policy]: /governing-documents/security.md 4 | 5 | ## About this document 6 | 7 | This document defines how security vulnerability reporting is handled in the 8 | Hyperledger Aries project. The approach aligns with the [Hyperledger 9 | Foundation's Security Vulnerability Reporting 10 | policy](https://toc.hyperledger.org/governing-documents/security.html). Please 11 | review that document to understand the basis of the security reporting for 12 | Hyperledger Aries. 13 | 14 | The Hyperledger Security Vulnerability policy borrows heavily from the 15 | recommendations of the OpenSSF Vulnerability Disclosure working group. For 16 | up-to-date information on the latest recommendations related to vulnerability 17 | disclosures, please visit the [GitHub of that working 18 | group](https://github.com/ossf/wg-vulnerability-disclosures). 19 | 20 | If you are already familiar with the security policies of Hyperledger Aries, and 21 | ready to report a vulnerability, please jump to [Report 22 | Intakes](#report-intakes). 23 | 24 | ## Outline 25 | 26 | This document has the following sections: 27 | 28 | - [Hyperledger Aries Security Policy](#hyperledger-Aries-security-policy) 29 | - [About this document](#about-this-document) 30 | - [Outline](#outline) 31 | - [What Is a Vulnerability Disclosure Policy?](#what-is-a-vulnerability-disclosure-policy) 32 | - [Security Team](#security-team) 33 | - [Discussion Forums](#discussion-forums) 34 | - [Report Intakes](#report-intakes) 35 | - [CNA/CVE Reporting](#cnacve-reporting) 36 | - [Embargo List](#embargo-list) 37 | - [(GitHub) Security Advisories](#github-security-advisories) 38 | - [Private Patch Deployment Infrastructure](#private-patch-deployment-infrastructure) 39 | 40 | ## What Is a Vulnerability Disclosure Policy? 41 | 42 | No piece of software is perfect. All software (at least, all software of a 43 | certain size and complexity) has bugs. In open source development, members of 44 | the community or the public find bugs and report them to the project. A 45 | vulnerability disclosure policy explains how this process functions from the 46 | perspective of the project. 47 | 48 | This vulnerability disclosure policy explains the rules and guidelines for 49 | Hyperledger Aries. It is intended to act as both a reference for 50 | outsiders–including both bug reporters and those looking for information on the 51 | project's security practices–as well as a set of rules that maintainers and 52 | contributors have agreed to follow. 53 | 54 | ## Security Team 55 | 56 | The current Hyperledger Aries security team is: 57 | 58 | | Name | Email ID | Discord ID | Area/Specialty | 59 | | -------------- | ------------------------ | ----------- | -------------------- | 60 | | Stephen Curran | swcurran@cloudcompass.ca | swcurran | | 61 | | Wade Barnes | wade@neoterictech.ca | WadeBarnes | Security, Operations | 62 | | Sam Curren | sam@indicio.tech | TelegramSam | Security | 63 | | Daniel Bluhm | daniel@indicio.tech | dbluhm | Security | 64 | 65 | The security team for Hyperledger Aries must include at least three Aries 66 | Maintainers that agree to carry out the following duties and responsibilities. 67 | Members are added and removed from the team via approved Pull Requests to this 68 | repository. For additional background into the role of the security team, see 69 | the [People Infrastructure] section of the Hyperledger Security Policy. 70 | 71 | [People Infrastructure]: https://toc.hyperledger.org/governing-documents/security.html#people-infrastructure 72 | 73 | **Responsibilities:** 74 | 75 | 1. Acknowledge the receipt of vulnerability reports to the reporter within 2 76 | business days. 77 | 78 | 2. Assess the issue. Engage with the reporter to ask any outstanding questions 79 | about the report and how to reproduce it. If the report was received by email 80 | and may be a security vulnerability, open a GitHub Security Advisory on the 81 | repository to manage the report. If the report is not considered a 82 | vulnerability, then the reporter should be informed and this process can be 83 | halted. If the report is a regular bug (but not a security vulnerability), the 84 | reporter should be informed (if necessary) of the regular process for reporting 85 | issues. 86 | 87 | 1. Some issues may require more time and resources to correct. If a particular 88 | report is complex, discuss an embargo period with the reporter during which 89 | time the report will not be publicly disclosed. The embargo period should be 90 | negotiated with the reporter and must not be longer than 90 days. 91 | 92 | 1. If necessary, create a private patch development infrastructure for the issue 93 | by emailing the [Hyperledger Community Architects]. 94 | 95 | [Hyperledger Community Architects]: mailto:community-architects@hyperledger.org 96 | 97 | 5. Request a CVE for the issue (see the [CNA/CVE Reporting](#cnacve-reporting) 98 | section). 99 | 100 | 6. Decide a date for the public release of the vulnerability report, the date 101 | the embargo period ends. 102 | 103 | 7. If applicable, notify members of the embargo list of the vulnerability, 104 | upcoming patch and release, as described above. 105 | 106 | 8. Publish a new (software) release in which the vulnerability is addressed. 107 | 108 | 9. Publicly disclose the issue within 48 hours after the release via a 109 | GitHub security advisory (see the [(GitHub) Security 110 | Advisories](#github-security-advisories) section for details). 111 | 112 | ## Discussion Forums 113 | 114 | Discussions about each reported vulnerability should be carried out in the 115 | private GitHub security advisory about the vulnerability. If necessary, a private 116 | channel specific to the issue may be created on the Hyperledger Discord server 117 | with invited participants added to the discussion. 118 | 119 | ## Report Intakes 120 | 121 | Hyperledger Aries has the following ways to submit security 122 | vulnerabilities. While the security team members will do their best to 123 | respond to bugs disclosed in all possible ways, it is encouraged for bug 124 | finders to report through the following approved channels: 125 | 126 | - Email the [Hyperledger Foundation security 127 | list](mailto:security@lists.hyperledger.org): To report a security issue, please 128 | send an email with the name of the project/repository, a description of the issue, the 129 | steps you took to create the issue, affected versions, and if known, 130 | mitigations. If in triaging the email, the security team determines the issue may be 131 | a security vulnerability, a [GitHub security vulnerability report] will be 132 | opened. 133 | - Open a [GitHub security vulnerability report]: Open a draft security advisory 134 | on the "Security" tab of this GitHub repository. See [GitHub Security 135 | Advisories](#github-security-advisories) to learn more about the security 136 | infrastructure in GitHub. 137 | 138 | [GitHub security vulnerability report]: https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability 139 | 140 | ## CNA/CVE Reporting 141 | 142 | Hyperledger Aries maintains a list of **Common Vulnerabilities and Exposures 143 | (CVE)** and uses GitHub as its **CVE numbering authority (CNA)** for issuing 144 | CVEs. 145 | 146 | ## Embargo List 147 | 148 | Hyperledger Aries does **NOT** currently maintain a private embargo list. 149 | 150 | If you wish to be added to the embargo list, please email the [Hyperledger 151 | Foundation security mailing list](mailto:security@lists.hyperledger.org), 152 | including the project name (Hyperledger Aries) and reason for being added 153 | to the embargo list. Requests will be assessed by the Hyperledger Aries 154 | security team in conjunction with the appropriate Hyperledger Staff, and a 155 | decision will be made to accommodate or not the request. 156 | 157 | For more information about embargo lists, please see the [Embargo List section 158 | of the Hyperledger Security 159 | Policy](https://toc.hyperledger.org/governing-documents/security.html#embargo-list). 160 | 161 | ## (GitHub) Security Advisories 162 | 163 | Hyperledger Aries uses GitHub Security Advisories to manage the public 164 | disclosure of security vulnerabilities. 165 | 166 | ## Private Patch Deployment Infrastructure 167 | 168 | In creating patches and new releases that address security vulnerabilities, 169 | Hyperledger Aries **MAY** use the private development features of GitHub for 170 | security vulnerabilities. GitHub has [extensive 171 | documentation](https://docs.github.com/en/code-security/security-advisories/repository-security-advisories) 172 | about these features. 173 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright 2017 Soramitsu LLC 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. -------------------------------------------------------------------------------- /Hyperledger Aries Technical Charter.md: -------------------------------------------------------------------------------- 1 | **Technical Charter (the “Charter”) for Hyperledger Aries a Series of LF Projects, LLC** 2 | 3 | **Adopted September 9, 2024** 4 | 5 | This Charter sets forth the responsibilities and procedures for technical contribution to, and oversight of, the Hyperledger Aries open source project, which has been established as Hyperledger Aries a Series of LF Projects, LLC (the “Project”). LF Projects, LLC (“LF Projects”) is a Delaware series limited liability company. All contributors (including committers, maintainers, and other technical positions) and other participants in the Project (collectively, “Collaborators”) must comply with the terms of this Charter. 6 | 7 | 1. **Mission and Scope of the Project** 8 | 9 | 1. The mission of the Aries Project is to create shared, reusable, interoperable, and scalable agents for developing critical decentralized trust solutions, including verifiable credentials and communication technologies. It is designed to be agnostic regarding DID methods, credential types, and communication protocols, with ledgers being optional. These agents represent organizations, people, and things, capable of taking actions through direct interaction or subject-approved automation, fostering robust and flexible decentralized trust solutions. 10 | 11 | 2. The scope of the Project includes collaborative development under the Project License (as defined herein) supporting the mission, including documentation, testing, integration and the creation of other artifacts that aid the development, deployment, operation or adoption of the open source project. 12 | 13 | 2. **Technical Steering Committee** 14 | 15 | 1. The Technical Steering Committee (the “TSC”) will be responsible for all technical oversight of the open source Project. 16 | 17 | 2. The TSC members are listed in the “TSC.md” file in the GitHub repository [https://github.com/hyperledger/aries](https://github.com/hyperledger/aries), along with the approach used by the Aries project for determining the voting members of the TSC. The TSC may choose an alternative approach for determining the voting members of the TSC by documenting such a change in the same document. 18 | 19 | 3. Meetings of the Technical Steering Committee are intended to be open to the public, and can be conducted electronically, via teleconference, or in person. The meetings may occur as part of regularly scheduled community calls instead of dedicated calls, when the volume of TSC related topics can be easily accommodated without additional meetings. 20 | 21 | 4. TSC projects generally will involve Contributors and Maintainers. The TSC may adopt or modify roles so long as the roles are documented in the MAINTAINERS.md file in the [https://github.com/hyperledger/aries](https://github.com/hyperledger/aries) repository. Unless otherwise documented: 22 | 23 | 1. Contributors include anyone in the technical community that contributes code, documentation, or other technical artifacts to the Project; 24 | 25 | 2. Maintainers are Contributors who have earned escalated GitHub privileges above READ for any repository in the project. Such privileges empower those individuals to modify (“commit” or “merge”) source code, documentation or other technical artifacts in a some or all of the project’s GitHub repositories. 26 | 27 | 3. A Contributor may become a Maintainer through the process outlined in the MAINTAINERS.md file in the [https://github.com/hyperledger/aries](https://github.com/hyperledger/aries) repository. A Maintainer may be removed as a Maintainer through the process outlined in the MAINTAINERS.md file in the [https://github.com/hyperledger/aries](https://github.com/hyperledger/aries) repository. 28 | 29 | 5. Participation in the Project through becoming a Contributor and Maintainer is open to anyone so long as they abide by the terms of this Charter. 30 | 31 | 6. The TSC may (1) establish work flow procedures for the submission, approval, and closure/archiving of sub-projects, (2) set requirements for the promotion of Contributors to Maintainer status, as applicable, and (3) amend, adjust, refine and/or eliminate the roles of Contributors, and Maintainers, and create new roles, and publicly document any TSC roles, as it sees fit. 32 | 33 | 7. The TSC may elect a TSC Chair, who will preside over meetings of the TSC and will serve until their resignation or replacement by the TSC. The TSC Chair, or any other TSC member so designated by the TSC, will serve as the primary communication contact between the Project and LF Decentralized Trust Foundation, a directed fund of The Linux Foundation. 34 | 35 | 8. Responsibilities: The TSC will be responsible for all aspects of oversight relating to the Project, which may include: 36 | 37 | 1. coordinating the technical direction of the Project; 38 | 39 | 2. approving project or system proposals (including, but not limited to, archiving and changing a sub-project’s scope); 40 | 41 | 3. organizing sub-projects and removing sub-projects; 42 | 43 | 4. creating sub-committees or working groups to focus on cross-project technical issues and requirements; 44 | 45 | 5. appointing representatives to work with other open source or open standards communities; 46 | 47 | 6. establishing community norms, workflows, issuing releases, and security issue reporting policies; 48 | 49 | 7. approving and implementing policies and processes for contributing (to be published in the CONTRIBUTING file) and coordinating with the series manager of the Project (as provided for in the Series Agreement, the “Series Manager”) to resolve matters or concerns that may arise as set forth in Section 7 of this Charter; 50 | 51 | 8. discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and 52 | 53 | 9. coordinating any marketing, events, or communications regarding the Project. 54 | 55 | 3. **TSC Voting** 56 | 57 | 1. While the Project aims to operate as a consensus-based community, if any TSC decision requires a vote to move the Project forward, the voting members of the TSC will vote on a one vote per voting member basis. 58 | 59 | 2. Quorum for TSC meetings requires at least fifty percent of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met but will be prevented from making any decisions at the meeting. 60 | 61 | 3. Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require a majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting require a majority vote of all voting members of the TSC. 62 | 63 | 4. In the event a vote cannot be resolved by the TSC, any voting member of the TSC may refer the matter to the Series Manager for assistance in reaching a resolution. 64 | 65 | 4. **Compliance with Policies** 66 | 67 | 1. This Charter is subject to the Series Agreement for the Project and the Operating Agreement of LF Projects. Contributors will comply with the policies of LF Projects as may be adopted and amended by LF Projects, including, without limitation the policies listed at https://lfprojects.org/policies/. 68 | 69 | 2. The TSC may adopt a code of conduct (“CoC”) for the Project, which is subject to approval by the Series Manager. In the event that a Project-specific CoC has not been approved, the LF Projects Code of Conduct listed at [https://lfprojects.org/policies](https://lfprojects.org/policies) will apply for all Collaborators in the Project. 70 | 71 | 3. When amending or adopting any policy applicable to the Project, LF Projects will publish such policy, as to be amended or adopted, on its web site at least 30 days prior to such policy taking effect; provided, however, that in the case of any amendment of the Trademark Policy or Terms of Use of LF Projects, any such amendment is effective upon publication on LF Project’s web site. 72 | 73 | 4. All Collaborators must allow open participation from any individual or organization meeting the requirements for contributing under this Charter and any policies adopted for all Collaborators by the TSC, regardless of competitive interests. Put another way, the Project community must not seek to exclude any participant based on any criteria, requirement, or reason other than those that are reasonable and applied on a non-discriminatory basis to all Collaborators in the Project community. 74 | 75 | 5. The Project will operate in a transparent, open, collaborative, and ethical manner at all times. The output of all Project discussions, proposals, timelines, decisions, and status should be made open and easily visible to all. Any potential violations of this requirement should be reported immediately to the Series Manager. 76 | 77 | 5. **Community Assets** 78 | 79 | 1. LF Projects will hold title to all trade or service marks used by the Project (“Project Trademarks”), whether based on common law or registered rights. Project Trademarks will be transferred and assigned to LF Projects to hold on behalf of the Project. Any use of any Project Trademarks by Collaborators in the Project will be in accordance with the license from LF Projects and inure to the benefit of LF Projects. 80 | 81 | 2. The Project will, as permitted and in accordance with such license from LF Projects, develop and own all Project GitHub and social media accounts, and domain name registrations created by the Project community. 82 | 83 | 3. Under no circumstances will LF Projects be expected or required to undertake any action on behalf of the Project that is inconsistent with the tax-exempt status or purpose, as applicable, of the Joint Development Foundation or LF Projects, LLC. 84 | 85 | 6. **General Rules and Operations.** 86 | 87 | 1. The Project will: 88 | 89 | 1. engage in the work of the Project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of LF Projects, Joint Development Foundation and other partner organizations in the open source community; and 90 | 91 | 2. respect the rights of all trademark owners, including any branding and trademark usage guidelines. 92 | 93 | 7. **Intellectual Property Policy** 94 | 95 | 1. Collaborators acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the Project. 96 | 97 | 2. Except as described in Section 7.c., all contributions to the Project are subject to the following: 98 | 99 | 1. All new inbound code contributions to the Project must be made using Apache License, Version 2.0 available at http://www.apache.org/licenses/LICENSE-2.0 (the “Project License”). 100 | 101 | 2. All new inbound code contributions must also be accompanied by a Developer Certificate of Origin ([http://developercertificate.org](http://developercertificate.org)) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license; 102 | 103 | 3. All outbound code will be made available under the Project License. 104 | 105 | 4. Documentation will be received and made available by the Project under the Creative Commons Attribution 4.0 International License (available at [http://creativecommons.org/licenses/by/4.0/](http://creativecommons.org/licenses/by/4.0/)). 106 | 107 | 5. The Project may seek to integrate and contribute back to other open source projects (“Upstream Projects”). In such cases, the Project will conform to all license requirements of the Upstream Projects, including dependencies, leveraged by the Project. Upstream Project code contributions not stored within the Project’s main code repository will comply with the contribution process and license terms for the applicable Upstream Project. 108 | 109 | 3. The TSC may approve the use of an alternative license or licenses for inbound or outbound contributions on an exception basis. To request an exception, please describe the contribution, the alternative open source license(s), and the justification for using an alternative open source license for the Project. License exceptions must be approved by a two-thirds vote of the entire TSC. 110 | 111 | 4. Contributed files should contain license information, such as SPDX short form identifiers, indicating the open source license or licenses pertaining to the file. 112 | 113 | 8. **Amendments** 114 | 115 | 1. This charter may be amended by a two-thirds vote of the entire TSC and is subject to approval by LF Projects. 116 | 117 | --------------------------------------------------------------------------------