Hyperledger Project Charter
The Linux Foundation | Effective 22 January 2016
1. Mission of Hyperledger Project (“HLP”).
The mission of HLP is to:
a. create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.
b. create an open source, technical community to benefit the ecosystem of HLP solution providers and users, focused on blockchain and shared ledger use cases that will work across a variety of industry solutions;
c. promote participation of leading members of the ecosystem, including developers, service and solution providers and end users; and
d. host the infrastructure for HLP, establishing a neutral home for community infrastructure, meetings, events and collaborative discussions and providing structure around the business and technical governance of HLP.
a. HLP shall be composed of Premier, General and Associate Members. All Premier and General Members must be current corporate members of The Linux Foundation (at any level) to participate in HLP as a member. Anyone may propose a contribution to HLP’s technical codebase regardless of membership status. All participants in HLP, including Associate Members, enjoy the privileges and undertake the obligations described in this Hyperledger Project Charter, as from time to time amended by the Governing Board with the approval of The Linux Foundation (“LF”). During the term of their membership, all members will comply with all such policies as the LF Board of Directors and/or the HLP may from time to time adopt with notice to members.
b. The Associate Member category of membership is limited to non-profits, open source projects, and Government entities, and requires approval by the Governing Board of HLP (“Governing Board”), or, if the Governing Board sets criteria for joining as an Associate Member, the meeting of such criteria. If the Associate Member is a membership organization, Associate Membership in HLP does not confer any benefits or rights to the members of the Associate Member.
c. Premier Members shall be entitled to appoint a representative to the Governing Board, the Marketing Committee and any other committees established by the Governing Board.
d. General Members shall be entitled to annually elect one representative to the Governing Board for every ten (10) General Members, up to a maximum of two (2) representatives, provided that there shall always be at least one (1) General Member representative, even if there are less than ten (10) General Members. The election process shall be determined by the Governing Board.
e. Premier Members, General Members and Associate Members shall be entitled to:
i. participate in Project general meetings, initiatives, events and any other activities; and
ii. identify themselves as members of, or participants in, HLP.
3. Governing Board
a. Composition – the Governing Board voting members shall consist of:
i. Up to twenty-one (21) Premier Members with one representative appointed by each Premier Member;
ii. elected General Member representative(s) per Section 2.d.;
iii. one representative elected by the End User Technical Advisory Board, as defined in Section 6 below; and
iv. the Chair elected by the TSC, as defined in Section 4 below.
b. Conduct of Meetings
i. Governing Board meetings shall be limited to the Governing Board representatives and follow the requirements for quorum and voting outlined in this Charter. The Governing Board may decide whether to allow one named representative to attend as an alternate.
ii. The Governing Board meetings shall be confidential unless approved by the Governing Board. The Governing Board may invite guests to participate in consideration of specific Governing Board topics (but such guest may not participate in any vote on any matter before the Governing Board). The Governing Board should encourage transparency, including the public publication of public minutes within a reasonable time following their approval by the Governing Board.
c. Responsibilities – the Governing Board shall be responsible for:
i. approving a budget directing the use of funds raised by HLP from all sources of revenue;
ii. electing a Chair of HLP to preside over Governing Board meetings, authorize expenditures approved by the budget and manage any day-to-day operations;
iii. overseeing all Project business and marketing matters;
iv. adopt and maintain policies or rules and procedures for HLP (subject to LF approval) including but not limited to a Code of Conduct, a trademark policy and any compliance or certification policies;
v. working with the TSC on defining and administering any programs for certification, including any Project certification or processes for HLP;
vi. coordinating with the EU-TAB (as defined in Section 6 below) to enable End User adoption, inclusion in technical community conversations and overall participation in HLP;
vii. approving procedures for the nomination and election of (1) General Member representatives to the Governing Board, and (2) any officer or other positions created by the Governing Board.
viii. voting on all decisions or matters coming before the Governing Board.
4. Technical Steering Committee (“TSC”)
i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.
ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.
b. TSC projects generally will involve Maintainers and Contributors:
i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.
ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.
c. Participation in HLP through becoming a Contributor and/or Maintainer is open to anyone. The TSC may:
i. establish work flows and procedures for the submission, approval and closure or archiving of projects,
ii. establish criteria and processes for the promotion of Contributors to Maintainer status, and
iii. amend, adjust and refine the roles of Contributors and Maintainers listed in Section 4.b., create new roles and publicly document responsibilities and expectations for such roles, as it sees fit.
d. The TSC shall elect a TSC Chair, who will also serve as a voting member of the Governing Board, and is expected to act as a liaison between the Governing Board and technical leadership of HLP.
e. Responsibilities: The TSC is responsible for:
i. coordinating the technical direction of HLP;
ii. approving project proposals (including, but not limited to, incubation, deprecation and changes to a project’s charter or scope) in accordance with a project lifecycle document to be developed, approved and maintained by the TSC;
iii. designating Top Level Projects;
iv. creating sub-committees or working groups to focus on cross-project technical issues or opportunities;
v. coordinate technical community engagement with the End User (as defined in Section 6 below) community and with any End User SIGs (as defined in Section 6 below) with respect to requirements, architecture, implementation, use cases, etc.;
vi. communicating with external and industry organizations concerning Project technical matters;
vii. appointing representatives to work with other open source or standards communities;
viii. establishing community norms, workflows or policies for releases;
ix. discussing, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and
x. establishing election processes for Maintainers or other leadership roles in the technical community that are not within the scope of any single project.
5. Marketing Committee
a. Composition: the Marketing Committee shall consist of:
i. one appointed voting representative from each Premier Member;
ii. non-voting representative(s), appointed by members of any other class of membership; and
iii. any non-voting Maintainer appointed by the TSC.
b. Responsibilities: The Marketing Committee shall be responsible for designing, developing and executing marketing efforts on behalf of the Governing Board. The Marketing Committee is expected to coordinate closely with the Governing Board, End User and technical communities to maximize the outreach and visibility of HLP throughout the industry.
6. End User Technical Advisory Board (EU-TAB)
a. An End User is defined as any company running or intending to run an application or service as part of an industry solution that incorporates the technology produced by the HLP, who do not offer that application or service for sale to others.
b. The EU-TAB shall be composed of members of HLP who are End Users. The EU-TAB shall approve new End User members. The Governing Board will approve an initial set of End User members sufficient to setup an EU-TAB.
c. The EU-TAB shall coordinate the efforts of End Users through meetings, mailing lists, or creation of Special Interest Groups (SIGs).
d. The EU-TAB may decide whether any meeting, SIG, or other End User activity shall be limited to members or open to non-member participants.
a. While it is the goal of HLP to operate as a consensus based community, if any decision requires a vote to move forward, the representatives of the Governing Board, TSC, Marketing Committee or EU-TAB, as applicable, shall vote on a one vote per voting representative basis.
b. Quorum for Governing Board, TSC, Marketing Committee or EU-TAB meetings shall require two-thirds of the voting representatives. The Governing Board, TSC, Marketing Committee or EU-TAB may continue to meet if quorum is not met, but shall be prevented from making any decisions at the meeting. Any Governing Board voting representative who fails to attend two consecutive Governing Board meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a Governing Board meeting.
c. Except as provided in Section 13.d. and 14.a., decisions by vote at a meeting shall require a majority vote, provided quorum is met. Except as provided in Section 13.d. and 14.a., decisions by electronic vote without a meeting shall require a majority of all voting representatives.
d. In the event of a tied vote with respect to an action that cannot be resolved by the Governing Board, the chair shall be entitled to refer the matter to the LF for assistance in reaching a decision. For all decisions in the TSC, Marketing Committee or other committee created by the Governing Board, if there is a tie vote, the matter shall be referred to the Governing Board.
e. All resolutions proposed for adoption by the Governing Board at a meeting, excluding resolutions to adopt minutes, shall be circulated in draft form to the members of the Governing Board at least two business days prior to the date of the meeting, and the text of such draft votes may be altered at such meeting.
8. Antitrust Guidelines
a. All members shall abide by The Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/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 Governing Board shall not seek to exclude any member based on any criteria, requirements or reasons other than those that are reasonable and applied on a non-discriminatory basis to all members.
9. Code of Conduct
a. The Governing Board shall adopt a specific Project code of conduct, with approval from the LF.
a. The Governing Board shall approve an annual budget and never commit to spend in excess of funds raised. The budget and the purposes to which it is applied shall be consistent with the non-profit mission of The Linux Foundation.
b. The Linux Foundation shall provide the Governing Board with regular reports of spend levels against the budget. In no event will The Linux Foundation have any obligation to undertake any action on behalf of HLP or otherwise related to HLP that will not be covered in full by funds raised by HLP.
c. In the event any unbudgeted or otherwise unfunded obligation arises related to HLP, The Linux Foundation will coordinate with the Governing Board to address gap funding requirements.
11. General & Administrative Expenses
a. The Linux Foundation shall have custody of and final authority over the usage of any fees, funds and other cash receipts.
b. A General & Administrative (G&A) fee will be applied by the Linux Foundation to funds raised to cover Finance, Accounting, and operations. The G&A fee shall equal 9% of HLP’s first $1,000,000 of gross receipts and 6% of HLP’s gross receipts over $1,000,000.
c. Under no circumstances shall The Linux Foundation be expected or required to undertake any action on behalf of HLP that is inconsistent with the tax exempt purpose of The Linux Foundation.
12. General Rules and Operations. The HLP project shall be conducted so as to:
a. 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 The Linux Foundation in the open source software community;
b. respect the rights of all trademark owners, including any branding and usage guidelines;
c. engage The Linux Foundation for all HLP press and analyst relations activities;
d. upon request, provide information regarding Project participation, including information regarding attendance at Project-sponsored events, to The Linux Foundation;
e. coordinate with The Linux Foundation in relation to any websites created directly for HLP; and
f. operate under such rules and procedures as may from time to time be approved by the Governing Board and confirmed by The Linux Foundation.
13. Intellectual Property Policy
a. Members agree that all new inbound code contributions to HLP shall be made under the Apache License, Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0). All contributions shall be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org) that is submitted through a Governing Board and LF-approved contribution process. Such contribution process will include steps to also bind non-Member Contributors and, if not self-employed, their employer, to the licenses expressly granted in the Apache License, Version 2.0 with respect to such contribution.
b. All outbound code will be made available under the Apache License, Version 2.0.
c. All documentation will be contributed to and made available by HLP under the Creative Commons Attribution 4.0 International License (available at http://creativecommons.org/licenses/by/4.0/).
d. 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 HLP’s mission, the Governing Board may approve the use of an alternative license for specific inbound or outbound contributions on an exception basis. Any exceptions must be approved by a two-thirds vote of the entire Governing Board and the LF and must be limited in scope to what is required for such purpose. Please email firstname.lastname@example.org to obtain exception approval.
e. Subject to available Project funds, HLP may engage The Linux Foundation to determine the availability of, and register, trademarks, service marks, and certification marks, which shall be owned by the LF.
a. This charter may be amended by a two-thirds vote of the entire Governing Board, subject to approval by The Linux Foundation.