Open Source Charter & Governance

1. Mission of the Hashgraph Open Source Foundation

The Foundation’s mission is to create and support a developer ecosystem building enterprise applications, tools, libraries and core capabilities of and around the Hedera public distributed ledger (DLT) and its unique Hashgraph algorithm. The Hashgraph Open Source Foundation supports the ecosystem of the Hedera network, a fast, fair, and secure public distributed ledger.

The foundation encourages the development of applications and core platform features that support an enterprise-grade Hedera network. Additionally, applications such as: wallets, exchanges, explorers, bridges, SDKs, private ledgers, and cryptography, will be supported.

2. Role of the Hashgraph Open Source Foundation

The Hashgraph Open Source Foundation will serve a role in the open source community responsible for:

  • (a) Stewardship of the projects
    • i. Ensuring that the technologies are available to the community and vendor neutral
    • ii. Ensuring that the technologies’ brand (trademark and logo) is being cared for and used appropriately by members of the community, with a specific emphasis on uniform user experience and high levels of application compatibility
  • (b) Fostering the growth and evolution of the ecosystem in a fair and inclusive manner
    • i. Evaluating which additional technologies should be added to meet the vision of a public, enterprise-focused, DLT. And working to encourage the community to deliver, integrate and support them if, and only if, they align with the Charter and advance the mission of the Foundation.
    • ii. Providing a way to foster common technical standards across the Hashgraph ecosystem
  • (c) Serve the community by making the technology accessible and reliable.
    • i. The foundation will provide a fully integrated and qualified build of each of the constituent pieces, on a well-defined cadence across the reference architecture.
    • ii. The foundation will encourage the development of wallets, exchanges, explorers, bridges, SDKs, private ledgers, cryptographies and other projects that support the ecosystem of the Hedera network.
  • (d) Protect the security and integrity of the Hedera public network now, and in the future.
    • i. The Foundation will collaborate with the Hedera Governing Council to ensure that a version of the consensus node software (software running on a “Consensus Node”) is developed in accordance to the specification of the Hedera Governing Council or its technical subcommittee (”TechCom”).

3. The Role of Hedera

Hedera Hashgraph LLC, is responsible for the operations, governance and oversight of the software that runs on the consensus nodes that constitute the Hedera public DLT and the founding entity of the Hashgraph Foundation. Hedera is granted;

  • (a) a permanent Board seat
  • (b) a permanent seat on the Technical Oversight Committee

4. Values

The Hashgraph Open Source Foundation will strive to align with the vision of the founders to establish a 100 year network and adhere to the following principles:

  • (a) Fast is better than slow. The foundation enables projects to progress at high velocity to support aggressive adoption by users.
  • (b) Open. The foundation is open and accessible, and operates independently of specific partisan interests. The foundation accepts all contributors based on the merit of their contributions, and the foundation’s technology must be available to all according to open source values. The technical community and its decisions shall be transparent.
  • (c) Fair. The foundation seeks to avoid undue influence and bad behavior by members and contributors.
  • (d) Strong technical identity. The foundation will achieve and maintain a high degree of its own technical identity that is shared across the projects and the public stakeholder ecosystem.
  • (e) Clear boundaries. The foundation shall establish clear goals, and in some cases, what the non-goals of the foundation are, to allow projects to effectively co-exist, and to help the ecosystem understand where to focus for new innovation.
  • (f) Secure. The foundation shall oversee the architecture, design, API, and implementation of all projects to ensure compliance across the ecosystem to protect the reputation and integrity of the Hedera network, without which this ecosystem and foundation would not exist.
  • (g) Ecosystem Enhancing. The foundation exists to strengthen the ecosystem of Hedera and Hashgraph users. Projects hosted by the foundation will contribute to a stronger Hedera public DLT and Hashgraph user ecosystem.

5. Governing Board

The Hashgraph Foundation Governing Board is responsible for overall management of the Foundation, including approving major decisions, managing the budget, and establishing advisory bodies or committees to support the foundation’s mission.

The Governing Board does not make technical decisions for the foundation other than working with the TOC to set the overall scope for the foundation.

Membership

The Foundation shall be composed of Platinum, Gold, Silver, Academic and Non-Profit member participants.

  • (a) Platinum members shall be entitled to:
    • i. Appoint one (1) representative to the Governing Board.
    • ii. Appoint one (1) representative as a voting member in any subcommittees or activities of the Governing Board.
  • (b) Gold members shall be entitled to:
    • i. Appoint one (1) representative to the Governing Board per every five (5) Gold members, up to three (3) maximum Gold representatives.
  • (c) Silver members shall be entitled to:
    • i. Appoint one (1) representative to the Governing Board per every ten (10) Silver members, up to three (3) maximum Silver representatives.
  • (d) Academic and Non-Profit members: The Academic and Non-Profit category of participation is limited to academic and non-profit institutions respectively and requires approval by the Governing Board. Academic and Non-Profit members shall be entitled to identify their organization as members supporting the mission of Hashgraph Foundation and any other rights or benefits as determined by the Governing Board.

Governing Board Responsibilities

  • (a) The Governing Board will be responsible for marketing and other business oversight and budget decisions for the Foundation. The Governing Board does not make technical decisions other than working with the TOC to set and approve the overall scope for foundation projects.
  • (b) The Governing Board will address business matters including:
    • i. adopting the overall scope for the foundation in consultation with the TOC;
    • ii. defining and enforcing policy regarding the use of the trademarks and copyrights of the foundation;
    • iii. directing marketing, including evangelism, events and ecosystem engagement;
    • iv. creating and executing a brand compliance program, if desired;
    • vi. fundraising and financial governance overall;
  • (c) Composition – the Governing Board voting members shall consist of Member Representatives and Technical Community Representatives:
    • i. Member Representatives consist of:
      • a. one representative appointed from each Platinum member; and
      • b. the Gold and Silver member elected representatives (if any)
    • ii. Technical Community Representatives consist of:
      • a. the TOC Chair, and
      • b. two Committers elected from fully graduated projects under a process approved by the then-serving Governing Board.
    • iii. The Governing Board may extend a Platinum or Gold membership at the Silver Membership Scale rates on a year-by-year basis for up to 5 years to startup companies that are deemed strategic technology contributors by the Governing Board.
    • iv. Only one person from a group of Related Companies may serve as a Member Representative. Only one person from a group of Related Companies may serve as a Technical Community Representative.
  • (d) Responsibilities:
    • i. approve a budget directing the use of funds raised from all sources of revenue to be used for technical, marketing or community investments that advance the mission of the foundation;
    • ii. elect a Chair of the Governing Board to preside over meetings, authorize expenditures approved by the Board and manage any day-to-day operations;
      • a. The Chair of the Governing Board shall be elected to a two-year term.
    • iii. vote on decisions or matters before the Governing Board;
    • iv. define and enforce policy regarding intellectual property (copyright, patent or trademark) of the foundation;
    • v. direct marketing and evangelism efforts through events, press and analyst outreach, web, social and other marketing efforts;
    • vi. oversee operations and qualification efforts;
    • vii. establish and oversee any committees created to drive the mission of foundation;
    • viii. establish and execute a brand compliance program, if any, based on the foundation requirements, which may include a certification test, to use the brand marks established by the TOC;
    • ix. adopt guidelines or a policy for use of the trademark; and
    • x. provide financial governance overall.
  • (e) The revenues collected by the project shall be used for the following purposes:
    • i. The marketing, promotion and expansion of deployment and use of the foundation projects and related marketing activities.
    • ii. The staffing of key resources to build, run and manage project infrastructure.

6. Technical Oversight Committee (“TOC”)

The Hashgraph Open Source Foundation’s Technical Oversight Committee is the technical body responsible for overseeing the technical details of the foundation.

  • (a) Mandate. The TOC is expected to facilitate driving neutral consensus for:
    • i. advising the Board on the technical vision for the Hashgraph Open Source Foundation,
    • ii. approving new projects within the scope of the foundation, and reviewing and/or creating a conceptual architecture for the projects,
    • iii. aligning projects, removing or archiving projects,
    • iv. accepting feedback from the end user committee, the Foundation community and ecosystem at large and mapping to projects,
    • v. aligning interfaces to components under management (code reference implementations before standardizing), and
    • vi. defining common practices to be implemented across foundation projects, if any,
    • vii. ensuring security best practices are maintained
    • viii. ensuring best practices for onboarding of new developers and establishing and maintaining an excellent developer experience
    • ix. providing technical guidance and input to the Hedera Governing Council.
  • (b) Composition. TOC members are expected to cover key technical domains: consensus technologies, operating systems, technical operations, distributed systems, user level application design, tokenization, smart contracts, etc. It shall be initially composed of nine (9) members; the Board, with input from the TOC, has the right to expand the TOC as deemed necessary.
    • i. Dr. Leemon Baird, has a permanent seat as inventor of the Hashgraph algorithm, representing himself, independent of any Related Companies, he has the right to designate an individual to act on his behalf with all his associated rights as long as he notifies the TOC in writing three business days before a meeting Dr. Baird must attend 1/3rd of all TOC meetings in a given calendar year to retain his permanent seat
    • ii. Hedera, has a permanent seat as founding member, and shall appoint one (1) TOC member to represent Hedera LLC.
    • iii. Graduated project maintainers shall together elect two (2) TOC members
    • iv. The End User TAB shall elect one (1) TOC member
    • v. TOC members shall elect two (2) TOC members
    • vi. The Governing Board shall elect two (2) TOC members
    • Each group (Dr. Leemon Baird, Hedera, Maintainers, and End User TAB) is defined as a Selecting Group.
    • vi. If more than two (2) TOC members would be from the same group of Related Companies (see section 14), either at the time of election or from a later job change, they will jointly decide who should step down, or if there is no agreement, random lots shall be drawn. Dr. Leemon Baird represents himself and does not contribute toward this number.
  • (c) Operating Model
    • i. The TOC shall select a Chair of the TOC to set agendas and call meetings of the TOC.
    • ii. The TOC is expected to meet regularly to discuss key topical issues, not less than once per month.
    • iii. The TOC may meet as needed to discuss emerging issues. Issues may be raised for TOC review by:
      • a. any TOC member,
      • b. a maintainer or top level project leader
      • c. a majority vote of the End User TAB.
    • iv. Transparency. The TOC shall hold regular open TOC meetings and all project-related decisions shall be made in those meetings, on a public mailing list, or on public issues.
    • v. Simple TOC issues may be resolved by short discussion and simple majority vote. TOC discussions may be over email or other electronic list or at a meeting of the TOC.
    • vi. After a review of the opinions and optional virtual discussion/debate options are identified, seeking consensus and taken to vote if necessary.
    • vii. The intent is for the TOC to find a path to consensus within the TOC and community. TOC decisions at meetings meeting quorum requirements shall pass with a vote greater than 50% of TOC members present.
    • viii. TOC meetings shall require a quorum of two-thirds of the TOC total members, but not less than six (6), to take a vote or make any decision. If a TOC meeting fails to meet the quorum requirement, discussions may proceed, however there shall be no voting or decisions.
    • ix. TOC decisions may be made electronically without a meeting, but to pass a vote shall require as many votes as would be needed to achieve quorum in a meeting. During an electronic vote, if any two (2) TOC members request a meeting to discuss the decision, the electronic vote in process shall end without effect, and a new vote may be initiated after the meeting to discuss the decision has completed.
  • (d) Criteria for Nomination. Nominees for the TOC shall:
    • i. commit that they have the available bandwidth to make the time to invest in the Hashgraph Open Source Foundation TOC,
    • ii. demonstrate an advanced level of professional experience as engineers in the scope of Hashgraph Open Source Foundation,
    • iii. demonstrate seniority sufficient to access additional staff or community members to assist in their TOC preparations, and
    • iv. operate neutrally in discussions and put the goals and success of the Hashgraph Open Source Foundation in balance with any particular project in the Foundation.
  • (e) Process for TOC Member Nominations and Election
    • i. Nominations: Each individual in a Selecting Group may nominate up to two (2) people, at most one (1) of whom may be from the same group of Related Companies (see section 14). Each nominee must agree to participate prior to being added to the nomination list.
      • a. A nomination requires a maximum one (1) page nomination pitch which should include the nominee’s name, contact information and supporting statement identifying the nominee’s experience in Hashgraph Open Source Foundation domains.
      • b. The TOC, shall determine the process and timeline for the nominations, qualification and election of TOC members. if the TOC wishes to change the qualifications of the members, it shall do so in consultation with the Board
      • c. A minimum of 14 calendar days shall be reserved for an Evaluation Period whereby TOC nominees may be contacted by members of the TOC.
    • ii. Qualification: After the Evaluation Period, the TOC members shall vote on each nominee individually to validate that the nominee meets the qualification criteria. A valid vote shall require at least 50% participation. Nominees passing with over 50% shall be Qualified Nominees.
    • iii. Elections: If the number of Qualified Nominees is equal to or less than the number of TOC seats available to be elected, the Qualified Nominees shall be approved after the nomination period has closed as long as there are not more than two (2) members from Related Companies. If there are more Qualified Nominees than open TOC seats available for election, then the Selecting Group shall elect the TOC members via a vote.
    • iv. TOC-Selected Seats: TOC-Selected TOC members may nominate and qualify but not vote when their seat is up for election.
    • v. Retries. If there are fewer Qualified Nominees than open TOC seats available for election by the Selecting Group, the group shall initiate another round of nominations until such time as there are adequate Qualified Nominees.
  • (f) Constraints
    • i. TOC Members shall serve two-year, staggered terms. Dr. Leemon Baird and Hedera have permanent seats.
    • ii. Non-permanent TOC members may be removed by a two-thirds vote of the other TOC members, with the impacted individual ineligible to participate in the vote.Permanent Members may be removed for violation of the Foundation’s Code of Conduct pursuant to a review and recommendation by an external, independent entity.
    • iii. Any TOC member that misses three (3) consecutive meetings shall be automatically suspended from eligibility to vote until having attended two meetings consecutively. For avoidance of doubt, the suspended TOC member shall be eligible to vote in the second consecutive meeting.
    • iv. The TOC agenda will be set by the TOC. However, it is expected that TOC discussions and decisions will cover:
      • assessing technologies to include in Hashgraph Open Source Foundation
      • defining acceptance criteria for new technologies to include in Hashgraph Open Source Foundation
      • defining processes to ratify a contributed technology as a standard API
      • identifying immediate gaps that require further investigation
      • ensuring that developer experience is being continuously reviewed and updated
      • The Board may request an item be added to the agenda

7. End User Community

  • (a) End User Members in the Hashgraph Open Source Foundation shall be entitled to coordinate and drive activities important to users of the Foundation’s technology. Any member or non-member who is an End User, each an “End User Participant”, shall have the right to participate. The End User Participants are expected to help provide input to the TAB and Hashgraph Open Source Foundation community on topics relevant to users.
  • (b) The End User Community Members shall elect an End User Technical Advisory Board.
  • (c) End User Community Members will be approved by the means established by the End User TAB.

8. End User Technical Advisory Board (“End User TAB”)

  • (a) Composition: The End User TAB shall be initially composed of five (5) representatives from End User Participants plus a designated liaison member of the TOC to facilitate input from the End User TAB to the TOC.
  • (b) Selection: All End User Participants may nominate one (1) representative and the End User Community shall vote to select the End User TAB members using a process approved by the then current End User TAB.
  • (c) The End User TAB may alter the size of the End User TAB by two-thirds vote, provided there are a minimum of five (5) possible representatives.
  • (d) End User representatives should be nominated on operational and technical acumen. Nominees should have significant practical experience with building and operating infrastructure and applications which embody the principles of the Hashgraph Open Source Foundation.
  • (e) The End User TAB will discuss and progress topics with a focus on identifying gaps and proposing priorities for the TOC and the Hashgraph Open Source Foundation developer community.
  • (f) The End User TAB may also focus on proactively advancing topics of concern to End Users, promoting market adoption of Hashgraph Open Source Foundation, or hosting meetings for End Users
  • (g) If the End User TAB desires, it may approve subcommittee Special Interest Groups (“SIGs”) to address industry or specialized topics.
  • (h) The End User TAB shall provide input to the Board and the TOC and shall be taken together with other input and feedback to make decisions and plans. The recommendations are advisory only and at no point shall the recommendations of the End User TAB be used to order or direct the Board or any TOC or project participant toward any action or outcome.

9. Hashgraph Open Source Foundation Projects

  • (a) It is expected that member companies, and open source community members will bring project assets to the TOC for discussion and inclusion into the Hashgraph Open Source Foundation. All such contributions should meet a set of technical criteria created by the TOC, and aligned to the Foundation’s Charter and Mission. The goal is to have an increasing bazaar of projects related to and that integrate with projects already accepted into the Foundation.
  • (b) Projects can be associated with the Hashgraph Open Source Foundation in the following three (3) ways:
    • i. Included in the Foundation, under a neutral home for collaboration
      • a. All aspects of the project are governed by the Foundation
      • b. The project may be marketed by the Foundation as a Hashgraph Open Source Foundation project
      • c. The project should be integral to the Hashgraph ecosystem as defined by the Foundation Charter and Mission and as determined by the Board and TOC (e.g. such as the Consensus Node software, SDK TCK, documentation, developer tooling, etc.)
    • ii. Associated with the Foundation via an API or specification
      • a. Includes components where the Hashgraph Open Source Foundation may offer or enable multiple options
      • b. The project is referred to as a component that the Hashgraph Open Source Foundation integrates with, not as a project hosted by the Foundation
      • c. Integration and compliance are defined by an API or specification
      • d. Active development on the project or component is ideally done in the upstream community
    • iii. Used by the Hashgraph Open Source Foundation
      • a. A project or component must be licensed under an OSI-approved and Apache compatible license and is well managed and used as a component in the Hashgraph Open Source Foundation
      • b. Project is not actively marketed by the Hashgraph Open Source Foundation,
      • c. Active development on the project or component is ideally done in the upstream community
  • (c) Existing open source projects may continue to run through their existing technical governance structure subject to TOC review to maintain cohesion and velocity. Projects approved by the Board and TOC for inclusion in the Hashgraph Open Source Foundation will be subject to the Technical Oversight Committee.
  • (d) A standard protocol to achieve committer status shall be established across projects based on an individual’s level and duration of contribution. Maintainer status is achieved through contribution to a given project over time and validation by peer maintainers.
  • (e) New open source projects initiated in the Hashgraph Open Source Foundation shall complete a project proposal template adopted by the TOC and be submitted to the Board for approval and inclusion in the Hashgraph Open Source Foundation. The TOC members shall be afforded sufficient time to discuss and review new project proposals. New project proposals shall include details of the roles in the project and identify alignment with the Hashgraph Open Source Foundation’s role and values.

10. Marketing Committee

  • (a) Composition: the Marketing Committee will be open to all members to participate. A Chair of the Marketing Committee will work with the Foundation Marketing Manager to develop meeting agendas, moderate discussions and help the committee progress against its goals. The Marketing Committee shall seek consensus where possible.
  • (b) Responsibilities: The Marketing Committee shall be responsible for developing marketing strategies, plans, messaging, etc., and supporting the execution of those marketing efforts by the Marketing Manager on behalf of the Hashgraph Open Source Foundation.
  • (c) If the Marketing Committee becomes too large to operate effectively, the Marketing Committee may choose to elect a Marketing Board and delegate decision authority to the Marketing Board.

11. IP Policy

  • (a) Any project that is added to the Hashgraph Open Source Foundation must have ownership of its trademark and logo assets transferred to the Hashgraph Open Source Foundation.
  • (b) Each project shall determine whether it will require use of an approved Hashgraph Open Source Foundation Contributor License Agreement. For projects that select to use a CLA, all code contributors will undertake the obligations set forth in the Apache contributor license agreement(s), altered only as necessary to identify Hashgraph Open Source Foundation as the recipient of the contributions, and which shall be approved by the TOC. See Hashgraph Open Source Foundation Contributor License Agreements.
  • (c) All new inbound code contributions to the Hashgraph Open Source Foundation shall be (i) accompanied by a Developer Certificate of Origin sign-off (https://developercertificate.org) and (ii) made under the Apache License, Version 2.0 (available at https://www.apache.org/licenses/LICENSE-2.0), such license to be in addition to, and shall not supersede, obligations undertaken under the contribution license agreement(s) provided for in (b) above.
  • (d) All outbound code will be made available under the Apache License, Version 2.0.
  • (e) All projects evaluated for inclusion in the Hashgraph Open Source Foundation shall be completely licensed under an OSI-approved open source license. If the license for a project included in Hashgraph Open Source Foundation is not Apache License, Version 2.0, approval of the Board shall be required.
  • (f) All documentation will be received and made available by the Hashgraph Open Source Foundation under the Creative Commons Attribution 4.0 International License.
  • (g) If an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project or is otherwise required to achieve the Hashgraph Open Source Foundation’s mission, the Board, with recommendation from the TOC may approve the use of an alternative license for inbound or outbound contributions on an exceptional basis.

12. Antitrust Guidelines

  • (a) All members shall abide by the requirements for The Hashgraph Open Source Foundation set forth in the Foundation’s Antitrust Policy.
  • (b) All members shall encourage open participation from any organization able to meet the membership requirements, regardless of competitive interests. Put another way, the Hashgraph Open Source Foundation shall not seek to exclude
  • members based on any criteria, requirements or reasons other than those used for all members.

13. Code of Conduct

  • (a) All participants agree to abide by The Hashgraph Open Source Foundation Code of Conduct.
  • (a). Definitions:
    • i. “Subsidiaries” shall mean any entity in which a Member owns, directly or indirectly, more than fifty percent of the voting securities or membership interests of the entity in question;
    • ii. “Related Company” shall mean any entity which controls or is controlled by a Member or which, together with a Member, is under the common control of a third party, in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or membership interests of the entity in question; and
    • iii. “Related Companies” are entities that are each a Related Company of a Member.
  • (b). Only the legal entity which has executed a Participation Agreement and its Subsidiaries shall be entitled to enjoy the rights and privileges of such Membership; provided, however, that such Member and its Subsidiaries shall be treated together as a single Member.
  • (c) If a Member is itself a foundation, consortium, open source project, membership organization, user group or other entity that has members or sponsors, then the rights and privileges granted to such Member shall extend only to the employee-representatives of such Member, and not to its members or sponsors
  • (e). Memberships shall be non-transferable, non-salable and non-assignable, except that any Member may transfer its current Membership benefits and obligations to a successor to substantially all of its business and/or assets, whether by merger, sale or otherwise; provided that the transferee agrees to be bound by this Charter and the Bylaws and policies.

15. General Rules and Operations.

Member organizations in the Hashgraph Open Source Foundation shall:

  • (a) demonstrate plans and the means to coordinate with the open source project’s developer community, including on topics such as branding, logos, and other collateral that will represent the community;
  • (b) engage in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of The Hashgraph Open Source Foundation in the open source software community;
  • (c) respect the rights of all trademark owners, including any branding and usage guidelines;
  • (d) engage The Hashgraph Open Source Foundation marketing committee for all press and analyst relations activities;
  • (e) handle known or discovered security vulnerabilities through the designated channel (https://hackerone.com/hedera-hashgraph?type=team) and not disclose them publicly until resolved.

16. Amendments

This charter may be amended by a two-thirds vote (excluding abstentions) of all Board members