CruxAbyss Development Team License Agreement for "Echo Land"


Preamble

This License Agreement (hereinafter referred to as the "Agreement") is made and entered into by and among the members of the CruxAbyss development team (hereinafter referred to as the "Development Team"). This Agreement sets forth the terms and conditions under which the Development Team shall collaborate on "Echo Land" (hereinafter referred to as the "Project"), hosted on the [https://github.com/CruxAbyss/Echo-Land].


1. Confidentiality

1.1 Each member of the Development Team agrees to maintain the confidentiality of the Project's content. Sharing any content within the Project's repository with individuals outside of the Development Team is strictly prohibited.


2. Originality and Attribution

2.1 All `pull requests` made to the Project must be the original work of the contributing member or legitimately derived from AI-assisted development, ensuring compliance with all relevant copyright laws. Plagiarism is strictly forbidden, and any usage of copyright-free media, AI-generated content, or work must be properly cited and attributed. Members are responsible for ensuring that any AI-generated content is used in accordance with the terms and conditions of the AI service provider and does not infringe on any copyrights or intellectual property rights.


3. Contribution Requirements

3.1 Each member is required to make at least 5 "significant" contributions to the Project to be recognized as a formal member of the Development Team, which ensures inclusion in the game developers list. This requirement underscores the importance of substantial and impactful participation in the Project's development process. Failure to meet this requirement will result in the member not being credited as a game developer for the Project. Additionally, members who do not fulfill this criterion will be formally expelled from the team upon the completion of the Project.

3.2 Members must use their own accounts for all contributions. Contributions made through accounts other than one's own will not be recognized.

3.3 All members are responsible for frequently checking the Project's board to stay updated on the status of all tasks. Members must accurately update the board to reflect the current status of tasks they are involved in.

3.4 Contributions that identify a problem and propose a feasible plan for its resolution should be submitted as an `issue` in the repository. Non-Core Members are limited to working on 1 `issue` within their specified area at any given time. Upon selecting 1 `issue` to work on, non-Core Members must update the `issue` status on the Project's board by moving the `issue` from `Todo` to `In Progress`. This update must be maintained until the member creates the `pull request` for that `issue` with the `pull request` has been `merged` and the `issue` has been `resolved` by the reviewers, ensuring transparent and up-to-date tracking of project contributions and progress. 


4. Conduct and Discipline

4.1 Members are expected to maintain professional conduct throughout the development process. Meaningless or spam `pull requests` will be deleted, not counted as contributions, and may result in the issuance of 1 formal warning.

4.2 Members who accumulate 2 formal warnings will be expelled from the Development Team. 1 "significant" contribution can eliminate 1 formal warning.

4.3 Upon joining the Development Team, every member is required to remain actively engaged, which encompasses frequently making contributions and responding promptly to communications. This active participation ensures a consistent and dedicated effort towards the Project's objectives. Failure to maintain this level of engagement may result in the issuance of 1 formal warning or, in cases of prolonged or repeated non-compliance, direct expulsion from the team. 

4.4 `Pull request` reviews, labeling (contribution importance and area(s)), and feedback must be completed within 3 days (72 hours) by the Core Members, who are the only members permitted to act as reviewers. Failure to meet this deadline without a valid reason will result in the issuance of 1 formal warning to the responsible Core Member, and the assignment of the review task to another Core Member to ensure timely progress.

4.5 Members may request emergency leave for temporary inactivity due to extenuating circumstances, such as illness or bereavement. Approval for such leave requires the support of more than half of the Core Members. Requests must be submitted in writing, clearly stating the reason for the leave and the expected duration of inactivity. Members are encouraged to communicate their situations as transparently as possible to facilitate understanding and support from the Development Team.


5. Membership and Voting Rights

5.1 Members who have made 1 or more "critical" contributions will be designated as Core Members. This heightened requirement for Core Member status reflects the Development Team's commitment to ensuring that voting on critical decisions and the role of reviewing `pull requests` are responsibilities entrusted to members who have demonstrated a significant and sustained contribution to the Project. Core Members are essential to maintaining the high standard of quality and consistency in the development process.

5.2 The invitation of new members requires the approval of more than half of the Core Members, ensuring that new additions to the team reflect a substantial majority agreement and align with the Development Team's strategic goals and cultural fit.

5.3 Any modifications to this License require the approval of more than half of the Core Members, emphasizing the importance of a strong consensus in the evolution and governance of the Project's collaborative framework.


6. Recognition and Contributions Scale

6.1 Contribution Levels Definitions:

- "Minor" Contribution: Identifying a meaningful issue within the game and proposing a feasible plan for resolution or improvement. Example: Submit an `issue` that points out a small logic problem in the game script and lists a way to resolve it, or submit a `pull request` that resolves a minor problem in the characters' lines.

- "Moderate" Contribution: Identifying a meaningful problem within the game and providing a detailed plan to address the issue or make improvements. Example: Submit an `issue` that points out a meaningful problem in the game UI and outlines a comprehensive solution to enhance that feature, or submit a `pull request` that substantially resolves a small problem.

- "Notable" Contribution: Directly resolving a meaningful problem or implementing a significant improvement within the game. Example: Submit a `pull request` that successfully integrates a new game mechanic, such as Gomoku, with coding, or submit an `issue` that identifies a major problem in the game script's logic timeline, and provides a very detailed guideline for solutions, accompanied by useful information such as external links, academic papers, or instructional videos, thereby offering a well-rounded approach to addressing the identified issue.

- "Significant" Contribution: Addressing a major issue or implementing a major improvement within the game, substantially enhancing the game's quality or user experience. Example: Submit a `pull request` that optimizes and overhauls the game code to significantly improve game performance in one part, or submit a `pull request` that encompasses the comprehensive refactorization of the game script to enhance clarity and readability.

- "Critical" Contribution: Making a transformative impact on the game, such as completing a major milestone or delivering a set of features that drastically enhance the game's value. Example: Submit a `pull request` that creates the entire script for the game, or submit a `pull request` demonstrating the contributor's creation of an impeccable website for the development team.

6.2 The scale of contributions is as follows: 10 "minor" contributions are equivalent to 1 "moderate" contribution, 10 "moderate" contributions are equivalent to 1 "notable" contribution, 10 "notable" contributions are equivalent to 1 "significant" contribution, and 10 "significant" contributions are equivalent to 1 "critical" contribution.

6.3 5 "significant" contributions guarantees the recognition in the game developers list, and 1 "critical" contribution guarantees an irrevocable specified position in the game developers list.

6.4 Contribution Labeling: The contribution level (i.e., minor, moderate, notable, significant, critical) of each member's `issue` or `pull request` will be determined and labeled by the reviewers, ensuring a fair and consistent assessment of the value and impact of the contribution to the project.


7. Labeling of Issues and Pull Requests

For the purpose of maintaining a systematic and organized approach to tracking and assessing contributions to the Project, the following labeling protocol is hereby established:

- Contribution Importance Label: Every `issue` and `pull request` submitted to the Project must be assigned a single label that signifies the contribution's level of importance. Acceptable labels under this category are limited to, "minor", "moderate", "notable", "significant", and "critical". The highest contribution label which 1 `issue` can receive is "notable". Contributions that resolve an `issue` and provide substantial improvement to the Project should be submitted as a `pull request`.

- Area Label: Alongside the contribution importance label, each `issue` and `pull request` must also be tagged with a single area label that identifies the specific domain or aspect of the Project to which the contribution pertains. Acceptable labels under this category are limited to, "Programming", "Project Management", "Art", "Sound and Music", "Narrative and Writing", "Quality Assurance", "UI/UX Design", "Technical Art", "Community Management" and "Marketing and Public Relations". The area label facilitates the efficient allocation and review of tasks by relevant team members.

- Labeling Restriction: It is mandatory that each `issue` and `pull request` carry exactly one label from each of the two categories described above (Contribution Importance and Area). Failure to assign the required labels will result in the `issue` or `pull request` being considered a meaningless contribution, which will not be counted towards the contributor's total contributions.


8. Enforcement and Resolution

8.1 Violations of this Agreement may result in disciplinary action, up to and including expulsion from the Development Team.

8.2 Disputes arising under this Agreement shall be resolved by the Core Members, whose decision shall be final and binding.


9. Amendment

This Agreement may be amended only by a written agreement signed by more than half of the Core Members. This requirement for a supermajority ensures that significant changes to the Agreement reflect a broad consensus among the Core Members, underpinning the stability and integrity of the Development Team's operational and collaborative principles.


10. Administrative Authority

The admin of the Development Team holds the highest position within the hierarchy of the Project's governance structure. As such, the admin possesses the authority to make unilateral decisions regarding any aspect of the Project, its management, or its development process without necessitating the approval or vote of more than half of the Core Members. This provision is designed to enable swift decision-making in situations where rapid or decisive action is required for the Project's benefit or to resolve disputes that cannot be settled through the standard consensus process among Core Members.

The admin's authority includes, but is not limited to, changes in project direction, alterations to the Agreement, resolution of disputes, and decisions on membership status. While this power is significant, it is expected that the admin will exercise this authority judiciously, with a primary focus on the Project's success and the welfare of the Development Team as a whole.


11. Conflict Resolution Process

To maintain a harmonious and productive environment within the Development Team, it is essential to have a structured process for addressing and resolving conflicts that may arise among members.

- Reporting Conflicts: Members who encounter conflicts with other team members are encouraged to report these issues to the Core Members Team for resolution. This approach ensures that conflicts are addressed promptly and effectively, with the aim of finding a constructive resolution that benefits all parties involved.

- Involvement of Core Members in Conflicts: In instances where a Core Member is directly involved in a conflict, the affected member(s) should escalate the issue to the admin of the Development Team. The admin will then assume responsibility for resolving the conflict, taking into consideration the best interests of the Development Team and the Project.


12. Prohibited Conduct and Consequences

The Development Team is committed to maintaining a respectful, safe, and secure environment for all members. As such, any form of misbehavior, including but not limited to sexual harassment, discrimination, bullying, plagiarism, or the unauthorized disclosure of Project files and sensitive information (hereinafter referred to as "Prohibited Conduct"), is strictly forbidden.

- Immediate Expulsion: Members found to have engaged in Prohibited Conduct will be subject to immediate expulsion from the Development Team. This action is taken to protect the welfare of all team members and preserve the integrity of the Project.

- Legal Action: In cases involving severe violations, such as sexual harassment or the leaking of Project files, the Development Team reserves the right to pursue further legal complaints against the offending member. Such measures are deemed necessary to safeguard the Project's assets, the personal safety of team members, and the Development Team's reputation.


13. Reinstatement Policy

13.1 In the interest of maintaining the integrity and safety of the Development Team and its members, specific policies are hereby established regarding the rejoining of expelled members:

- General Expulsion: Members expelled from the Development Team for reasons other than Prohibited Conduct, as outlined in section 12, may petition for reinstatement after a mandatory exclusion period of one (1) year from the date of expulsion. Reinstatement is subject to a review and approval process by the Core Members, which requires a unanimous decision in favor of the expelled member's return.

- Expulsion for Prohibited Conduct: Members expelled due to engaging in Prohibited Conduct, including but not limited to sexual harassment, discrimination, bullying, plagiarism, or unauthorized disclosure of Project files and sensitive information, are permanently barred from rejoining the Development Team. This measure reflects the Development Team's commitment to safeguarding the welfare of its members and the integrity of the Project.

13.2 Petition for Reinstatement: Expelled members seeking to rejoin the Development Team must submit a written petition to the Core Members, outlining the reasons for their request and demonstrating a clear and genuine commitment to adhering to the Project's standards and ethical guidelines. The petition will be carefully reviewed, and a decision will be made in accordance with the principles of fairness, the member's past contributions, and the potential impact of their reinstatement on the Project and team dynamics.

13.3 Finality of Decision: The decision made by the Core Members regarding a petition for reinstatement is final and binding. Members who are denied reinstatement may not reapply for inclusion in the Development Team.


14. Income Distribution Policy

14.1 Finalization of Contributions: Upon the completion of the Project, the record of contributions will be finalized. No further contributions will be accepted for the purpose of income distribution calculations.

14.2 Revenue Sharing: When Project's product is released on public platforms (e.g., Steam) and generates income, the revenue will be distributed among the Development Team members according to their contributions. The Project encompasses 10 defined areas of contribution ("Programming", "Project Management", "Art", "Sound and Music", "Narrative and Writing", "Quality Assurance", "UI/UX Design", "Technical Art", "Community Management" and "Marketing and Public Relations"), with each area allocated an equal share of 10% of the total income generated by the Project.

14.3 Contribution-Based Allocation: Within each area, income distribution will be based on the significance of contributions made by individual members. The contribution levels (minor, moderate, notable, significant, critical) are quantified based on their defined equivalents in critical contributions. The income for each area will be divided among its contributors in proportion to the total critical contribution equivalents they have made.

14.4 Calculation and Rounding: The calculation of each member's share of income will be precise to 3 significant figures. For illustrative purposes, consider a scenario: Within the "Programming" area, two members, Bob and Alice, have contributed to the area's success. Bob's contributions are quantified as equivalent to 2.01 critical contributions (consisting of 2 critical and 1 notable contributions), while Alice's contributions amount to 0.9736 critical contributions (derived from 9 significant, 5 notable, 23 moderate, and 6 minor contributions). The income ratio for distribution within the "Project Management" area is thus determined by the sum of their critical contribution equivalents, forming a total of 2.9836 (= 2.01 + 0.9736). The specific percentage of the area's allocated income (10% of total income) is then divided by this sum to establish a base percentage value. Consequently, the income shares for Bob and Alice are calculated based on their proportional contribution to the area, rounded to three significant figures for precision. Under this calculation, Alice is allocated approximately 3.26% of the total income, and Bob receives approximately 6.73%, reflecting their respective contributions' significance to the "Project Management" area's success.

14.5 Implementation of Distribution: This policy ensures a fair and transparent distribution of income, reflecting the value of contributions made by each team member to the Project's success. The Development Team's admin will oversee the implementation of this policy to ensure accuracy and fairness in the distribution process.


15. Acknowledgement and Acceptance

By contributing to the Project, each member, whether present or future, agrees to be bound by the terms of this Agreement. Current members shall acknowledge their acceptance of this Agreement by signing below. New members shall acknowledge their acceptance of this Agreement by making their first contribution to the Project repository, at which point they agree to adhere to all terms and conditions set forth herein.


Continuous Agreement

This Agreement shall be deemed as continuous and will automatically apply to all current and future members of the Development Team unless otherwise terminated or amended as stipulated in section 9. Amendments.

IN WITNESS WHEREOF, the current parties have executed this Agreement as of the Effective Date. New members shall be considered as having executed this Agreement upon their acceptance as per the above Acknowledgement and Acceptance clause.

Feb 3, 2024


Signatures of all current Development Team members:

Louis Liu (Admin),