diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3986d7e..5640ebd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -62,6 +62,14 @@ mechanism may be introduced after professional legal review. This document is not a CLA, does not transfer copyright, and does not create an implied assignment or commercial-license grant. +A Harmony-based copyright-license CLA is currently being evaluated in +[`docs/legal/CONTRIBUTOR_LICENSE_AGREEMENT_DRAFT.md`](docs/legal/CONTRIBUTOR_LICENSE_AGREEMENT_DRAFT.md), +with unresolved adoption gates recorded in +[`docs/legal/CLA_ADOPTION_CHECKLIST.md`](docs/legal/CLA_ADOPTION_CHECKLIST.md). +Both documents are non-operative drafts. Do not sign or rely on them. Opening a +pull request, issue, or discussion does not accept the draft, and no CLA +automation or electronic acceptance process is active. + Until a reviewed mechanism exists, maintainers should not merge a substantial external code or asset contribution merely because it was submitted under the repository's Community license. The required rights for the proposed diff --git a/docs/README.md b/docs/README.md index 5fc5e9d..ec9d011 100644 --- a/docs/README.md +++ b/docs/README.md @@ -68,6 +68,8 @@ without creating an unreviewed second source of truth. ## Rights and governance - [Asset provenance](legal/ASSET_PROVENANCE.md) +- [Contributor License Agreement draft](legal/CONTRIBUTOR_LICENSE_AGREEMENT_DRAFT.md) +- [CLA adoption checklist](legal/CLA_ADOPTION_CHECKLIST.md) - [Dual-licensing readiness report](legal/dual-licensing-readiness-report.md) - [Dual-licensing decision record](governance/dual-licensing-decision.md) - [Commercial-license draft](legal/COMMERCIAL-LICENSE-DRAFT.md) diff --git a/docs/legal/CLA_ADOPTION_CHECKLIST.md b/docs/legal/CLA_ADOPTION_CHECKLIST.md new file mode 100644 index 0000000..6b43274 --- /dev/null +++ b/docs/legal/CLA_ADOPTION_CHECKLIST.md @@ -0,0 +1,226 @@ +# HitTheKit CLA adoption checklist + +> **DRAFT PROCESS — NOT IN FORCE — NOT LEGALLY REVIEWED** +> +> This checklist does not activate the accompanying CLA draft, request a +> signature, or authorize substantial external contributions. + +## Selected planning model + +The current planning candidate is the Harmony Combined Contributor Agreement +Template 1.0 configured as: + +- copyright license, not copyright assignment; +- contributor retains copyright; +- broad sublicensable copyright grant; +- patent grant; +- outbound licensing based on Harmony Option Five; and +- separate treatment of individual and Legal Entity contributors still to be + decided. + +Option Five is being evaluated because it permits open-source and commercial +or proprietary outbound licenses while promising that an incorporated +Contribution is also available under the community license used for the +Material. Its breadth is not yet approved. + +## Blocking legal and identity decisions + +- [ ] Obtain review from a qualified lawyer, FOSS legal clinic, or equivalent + professional familiar with contributor agreements and dual licensing. +- [ ] Verify the legal identity and capacity of the party receiving the grant. +- [ ] Decide whether the recipient is an individual, company, foundation, or + another legal structure. +- [ ] Record the recipient's legal address and a private legal contact. +- [ ] Select governing law, forum, and dispute process with qualified advice. +- [ ] Verify chain of title and authority for the existing HitTheKit code. +- [ ] Confirm the intended MPL-2.0 transition separately; the CLA must not be + used to imply that a repository license change has already occurred. +- [ ] Review the scope of “transferable,” “irrevocable,” “otherwise exploit,” + multi-tier sublicensing, and future commercial/proprietary licensing. +- [ ] Review patent scope, Affiliate coverage, subsequently acquired claims, + combination claims, limitations, and termination/retaliation. +- [ ] Decide whether and how to address moral rights without an unnecessarily + broad waiver. +- [ ] Draft jurisdiction-appropriate warranty, disclaimer, liability, + severability, assignment, notices, and entire-agreement terms. + +## Contributor types and authority + +- [ ] Decide whether to publish separate Individual and Entity agreements. +- [ ] Define when an individual contributor needs employer consent. +- [ ] Define acceptable evidence of employer consent. +- [ ] Define the Entity signatory's required authority and title. +- [ ] Decide whether entities maintain a list of authorized contributors. +- [ ] Define how an entity adds or removes authorized contributors. +- [ ] Decide how contractors, students, public employees, and grant-funded + contributors are handled. +- [ ] Decide whether contributions from minors will be accepted. +- [ ] If minors may contribute, obtain qualified advice on age, guardian + consent, identity verification, privacy, and revocation. + +## Contributions and third-party material + +- [ ] Define the channels that count as intentionally “Submitted.” +- [ ] Define a clear “Not a Contribution” mechanism. +- [ ] Keep issues, discussions, hardware observations, ideas, and facts outside + contractual acceptance unless qualified review says otherwise. +- [ ] Define a non-owner/mixed-submission review process—or continue to reject + all mixed submissions. +- [ ] Explicitly reject unapproved third-party code, music, recordings, + performances, charts, MIDI captures, artwork, fonts, trademarks, + confidential information, and personal data. +- [ ] Require provenance and license evidence for any exceptional third-party + material accepted through a separate process. +- [ ] Confirm that a CLA grants only rights the contributor controls and never + substitutes for third-party licenses. + +## Existing and future contributions + +- [ ] Inventory any substantial external contribution made before activation. +- [ ] Decide whether prior contributors must separately opt in. +- [ ] Do not presume retroactive acceptance based on an old pull request, + commit, discussion, or repository license. +- [ ] Define the effective date for each contributor and Contribution. +- [ ] Define treatment when the community license changes after acceptance. +- [ ] Define the procedure if the receiving legal entity changes. +- [ ] Define a transparent amendment process and when re-acceptance is needed. + +## Privacy, signatures, and records + +- [ ] Publish a privacy notice before collecting acceptances. +- [ ] Identify the data controller, purposes, lawful basis, processors, + transfers, and contact. +- [ ] Decide which identity, name, email, employer, timestamp, IP address, and + other evidence is actually necessary; minimize collection. +- [ ] Define retention periods rather than retaining personal data by default. +- [ ] Define access, correction, objection, deletion, export, and complaint + handling as applicable. +- [ ] Record the exact CLA version and immutable digest accepted. +- [ ] Preserve an auditable timestamp and authenticated contributor identity. +- [ ] Design the electronic signature/acceptance action with qualified review. +- [ ] Define recovery, backup, access control, incident response, and processor + exit procedures for acceptance records. + +## CLA Assistant and repository controls + +- [ ] Complete legal and privacy review **before** enabling CLA Assistant. +- [ ] Publish only the approved, versioned CLA text—not this draft—as the + acceptance source. +- [ ] Review CLA Assistant's hosting, authentication, custom fields, privacy, + retention, availability, and version-change behavior. +- [ ] Configure a test repository before connecting HitTheKit. +- [ ] Verify individual and Entity workflows, bot comments, re-signing, and + failure/recovery behavior. +- [ ] Add the CLA status check to branch protection only after a successful + test run and with a unique check name. +- [ ] Keep maintainer bypass disabled or document narrowly reviewed emergency + handling. +- [ ] Update the pull-request template without claiming that opening a PR + constitutes acceptance. +- [ ] Update `CONTRIBUTING.md`, `GOVERNANCE.md`, privacy documentation, and the + public website only when the agreement actually enters into force. +- [ ] Publish a plain-language announcement of the effective date, scope, + contributor choices, community-license promise, and contact route. +- [ ] Confirm substantial external contributions remain blocked until every + activation item is complete. + +GitHub required status checks enforce workflow results; they do not determine +whether the CLA text or acceptance process is legally sufficient. CLA +Assistant automates prompts, GitHub authentication, acceptance records, and a +pull-request status check, but it is not the legal reviewer or receiving party. + +## DCO, CLA, and CLA Assistant are different + +| Mechanism | Primary function | What it does not establish by itself | +| --- | --- | --- | +| Developer Certificate of Origin (DCO) | Contributor attests provenance and a right to submit under the indicated open-source terms, commonly recorded with `Signed-off-by` | It does not grant HitTheKit the separate, broad sublicensing rights needed for proprietary/commercial outbound licensing. | +| Contributor License Agreement (CLA) | A contract can expressly grant copyright and patent rights while the contributor retains ownership | A draft is not operative without identified parties, reviewed terms, valid acceptance, and appropriate records. | +| CLA Assistant | Automates the presentation and collection of a project's chosen CLA and reports status to GitHub | It does not draft, approve, interpret, or make legally sufficient the CLA and privacy process. | + +MPL 2.0 grants rights from contributors to recipients of MPL-covered software, +but its contributor grant does not automatically appoint the HitTheKit +maintainer to relicense every external Contribution under unrelated proprietary +terms. The proposed CLA is intended to address that separate inbound-rights +need if qualified review approves it. + +## Review findings to resolve before adoption + +### P0 + +None identified in a non-operative documentation draft. + +### P1 — adoption blockers + +- The receiving legal party, governing law, forum, legal contact, privacy + controller, and acceptance process are unknown. +- Harmony Option Five and the copyright grant are deliberately broad; their + sublicensing, transferability, irrevocability, and proprietary-license scope + require qualified review and plain-language disclosure. +- Patent scope and any retaliation/termination mechanism are unresolved. +- Individual, Entity, employer-consent, Affiliate, and minor-contributor + processes are unresolved. +- The public `main` license and the intended MPL-2.0 state are temporarily + different; activation before the community-license transition is settled + would create avoidable ambiguity. +- Privacy, retention, version evidence, electronic signature, and treatment of + prior Contributions are unresolved. + +### P2 — process and clarity risks + +- One combined draft is convenient for review but separate Individual and + Entity forms may be clearer operationally. +- Media and third-party-content rules may need their own contributor guide and + provenance workflow rather than additional breadth in the CLA. +- A CLA tool outage, Gist change, account rename, or bot-status ambiguity needs + an operational recovery procedure. + +### P3 — editorial follow-up + +- Defined terms, capitalization, translations, accessibility, and + plain-language summaries should be normalized after legal text stabilizes. +- A version identifier and digest format should be selected before publication. + +## Pro bono review request template + +Subject: Limited pro bono review request — open-source contributor agreement + +> Hello, +> +> I maintain HitTheKit, an open-source electronic-drum learning game. The +> project is preparing to use Mozilla Public License 2.0 for its community +> edition and may later offer separate commercial licenses. I would like +> contributors to retain their copyright while granting the project the +> copyright and patent permissions needed to distribute accepted contributions +> under MPL 2.0 and, transparently, under separate commercial/proprietary terms. +> +> I have prepared a non-operative draft based on the Harmony Agreements +> copyright-license model and outbound Option Five. The project is not yet +> accepting substantial external code or assets, no one is being asked to sign +> the draft, and CLA Assistant has not been configured. +> +> I currently have no budget for a full commercial engagement. Would your +> clinic, practice, or open-source legal community be willing to provide a +> limited pro bono review of the draft, focusing on the receiving party, +> sublicensing scope, patent grant, employer/entity contributions, governing +> law, privacy and electronic acceptance? I can provide the short draft, +> adoption checklist, current license documents, and a concise list of open +> questions. +> +> I understand that availability may be limited and that an informal community +> response may not create a lawyer-client relationship or replace advice from a +> qualified professional in the relevant jurisdiction. + +## Primary drafting references + +- Harmony agreement templates and guide: + +- Mozilla Public License 2.0: + +- Developer Certificate of Origin 1.1: + +- CLA Assistant project documentation: + +- GitHub protected branches and required status checks: + + +This checklist is engineering and governance preparation, not legal advice. diff --git a/docs/legal/CONTRIBUTOR_LICENSE_AGREEMENT_DRAFT.md b/docs/legal/CONTRIBUTOR_LICENSE_AGREEMENT_DRAFT.md new file mode 100644 index 0000000..ddbbd5e --- /dev/null +++ b/docs/legal/CONTRIBUTOR_LICENSE_AGREEMENT_DRAFT.md @@ -0,0 +1,327 @@ +# DRAFT — NOT IN FORCE — NOT LEGALLY REVIEWED — DO NOT ACCEPT OR RELY ON THIS DOCUMENT + +> **No one should sign, accept, or rely on this draft.** It does not currently +> govern any contribution to HitTheKit, and opening a pull request, issue, or +> discussion does not constitute acceptance. Substantial external code and +> asset contributions remain paused under +> [`CONTRIBUTING.md`](../../CONTRIBUTING.md). + +## Drafting basis and unresolved decisions + +This planning draft is adapted from the Harmony Combined Contributor Agreement +Template 1.0. It selects the **copyright-license** model rather than copyright +assignment, includes a patent grant, and follows the substance of Harmony +Outbound License Option Five so that a covered Contribution could be offered +both under HitTheKit's community license and under separate commercial or +proprietary terms. + +This is a modified planning document, not an official Harmony agreement. The +Harmony template and guide remain the authoritative sources for the template +options. The draft must be replaced or approved by a qualified human reviewer +before adoption. + +The following decisions are deliberately unresolved: + +- receiving party: **[LEGAL REVIEW REQUIRED — LEGAL NAME AND CAPACITY]**; +- receiving-party address: **[TO BE AGREED]**; +- legal contact: **[TO BE AGREED]**; +- governing law and forum: **[TO BE AGREED]**; +- separate individual and entity forms: **[TO BE AGREED]**; +- treatment of minors: **[LEGAL REVIEW REQUIRED]**; +- employer approval and entity authorization evidence: **[TO BE AGREED]**; +- electronic acceptance and signature process: **[TO BE AGREED]**; +- privacy notice, data controller, retention, access, correction, and deletion + process: **[LEGAL REVIEW REQUIRED]**; +- versioning and record of the exact text accepted: **[TO BE AGREED]**; +- treatment of contributions made before the effective date: + **[LEGAL REVIEW REQUIRED — NO RETROACTIVE ASSUMPTION]**; and +- exact community-license transition: HitTheKit's public `main` currently uses + GPL-3.0-only, while a possible MPL-2.0 transition is separately under review. + This draft does not change the repository license. + +--- + +# HitTheKit Contributor License Agreement — planning draft + +Thank you for your interest in contributing to HitTheKit (the “Project”). This +draft uses “Project Recipient” for the person or entity that would receive the +rights below. Before adoption, “Project Recipient” must be replaced with the +verified legal identity of **[RECEIVING PARTY]**. + +If adopted after legal review, this agreement (the “Agreement”) would document +rights granted by a contributor (“You”) to the Project Recipient (“We” or +“Us”). It would become effective only through the approved acceptance process +described at **[ACCEPTANCE AND SUBMISSION INSTRUCTIONS]**. No such process is +currently active. + +## 1. Definitions + +### 1.1 Contributor + +“You” means either: + +1. the individual who submits a Contribution; or +2. the Legal Entity on whose behalf an authorized person submits a + Contribution. + +“Legal Entity” means an organization rather than a natural person. +“Affiliates” means entities that control, are controlled by, or are under +common control with that Legal Entity. Whether and how Affiliates are included +is **[LEGAL REVIEW REQUIRED]**. + +The adopted process must distinguish individual contributors from contributors +acting for a Legal Entity. An individual may not bind an employer or another +organization without authority. + +### 1.2 Contribution + +“Contribution” means the portion of an original work of authorship that You +Submit for inclusion in HitTheKit and for which You own, or have authority to +license, all rights required by this Agreement. + +A Submission is not a Contribution to the extent it contains third-party code, +music, recordings, performances, charts, MIDI captures, artwork, fonts, +trademarks, personal data, confidential material, or other material that You +do not have authority to license under this Agreement. Do not submit such +material. HitTheKit currently has no non-owner or mixed-submission acceptance +procedure. + +Bug reports, ideas, functional requests, facts, and general discussion may not +be copyrightable Contributions. Their treatment must be assessed separately; +this definition does not convert an idea or fact into owned project material. + +### 1.3 Submit + +“Submit” means intentionally providing a proposed Contribution through a +Project channel designated in the future adoption instructions for that +purpose. Ordinary participation in an issue, discussion, hardware report, or +support request is not acceptance of this Agreement. + +A communication conspicuously marked “Not a Contribution” is excluded, subject +to the adopted submission procedure. The final procedure must define which +repositories, branches, pull requests, email addresses, or other channels are +designated for Contributions. + +### 1.4 Material + +“Material” means the HitTheKit software, documentation, or other project work +into which a Contribution may be incorporated. We are not required to +incorporate or distribute any Contribution. + +### 1.5 Copyright and Patent Claims + +“Copyright” includes copyright and, where applicable, closely related rights +that You own or control and may license for the full term of those rights. + +“Patent Claims” means only patent claims that You own or control and may +license, and that would necessarily be infringed by exercising the patent +rights expressly granted in Section 2.2 with respect to the Contribution alone +or the Contribution combined with the Material to which it was submitted. + +The treatment of Affiliates, subsequently acquired claims, and patent +termination or retaliation is **[LEGAL REVIEW REQUIRED]**. + +### 1.6 Effective Date + +“Effective Date” means **[TO BE AGREED]**. The final text must not presume that +this Agreement retroactively covers a contribution or period that the +contributor did not knowingly accept. + +## 2. Grant of rights + +### 2.1 Copyright license — no assignment + +You retain ownership of the Copyright in Your Contribution and retain the same +rights to use or license it that You would have had without this Agreement. +This Agreement does not assign copyright to Us. + +Subject to the community-license commitment in Section 2.3, and to the maximum +extent You are legally able to do so, You grant Us a perpetual, worldwide, +non-exclusive, transferable, royalty-free, irrevocable license under the +Copyright in the Contribution, with the right to sublicense through multiple +tiers, to use, reproduce, make available, modify, prepare derivative works of, +display, perform, distribute, and otherwise exploit the Contribution as part +of or in connection with the Material. + +The words “transferable,” “irrevocable,” “otherwise exploit,” and “multiple +tiers” are intentionally broad adaptations of the Harmony license model and +must receive specific human legal review before adoption. + +### 2.2 Patent license + +Subject to the community-license commitment in Section 2.3, and to the maximum +extent You are legally able to do so, You grant Us a perpetual, worldwide, +non-exclusive, transferable, royalty-free, irrevocable patent license, with +the right to sublicense through multiple tiers, under the Patent Claims to +make, have made, use, sell, offer for sale, import, and otherwise transfer the +Contribution and the Contribution combined with the Material to which it was +submitted. + +No patent license is intended for claims infringed solely by unrelated changes +or combinations added after Your Contribution. The final patent scope, +limitations, Affiliate coverage, and any termination provision require +qualified review for consistency with MPL 2.0 and future commercial terms. + +### 2.3 Outbound licensing + +If We include Your Contribution in the Material, the grants in Sections 2.1 +and 2.2 are intended to allow Us to license the Contribution under open-source, +copyleft, permissive, commercial, or proprietary terms, including: + +- Mozilla Public License 2.0, if and when that becomes the adopted community + license for the relevant Material; and +- a separate commercial or proprietary HitTheKit license offered by a party + with authority over all relevant rights. + +Consistent with the purpose of Harmony Outbound Option Five, whenever We first +include a Contribution in publicly distributed Material, We would also make +that Contribution available under the community license that applies to that +Material at the time of inclusion. Exercising the grants in Sections 2.1 and +2.2 would remain subject to this commitment. The final text must specify how +the commitment works during license transitions and must not imply that MPL +2.0 itself grants Us the right to relicense a contributor's work commercially. + +This Agreement would grant rights only in Your Contribution. It would not +relicense Unity, package dependencies, third-party code, music, recordings, +charts, MIDI data, artwork, trademarks, or other material outside Your rights. + +### 2.4 Moral and similar rights + +Harmony includes a waiver and non-assertion provision for moral rights. Whether +such a provision is necessary, proportionate, or enforceable for HitTheKit is +**[LEGAL REVIEW REQUIRED]**. No waiver is included in this non-operative draft +as an approved term. + +### 2.5 Reservation of rights + +Rights not expressly licensed under this Agreement remain reserved by You. +Neither this Agreement nor a Contribution grants rights to Your name, +trademarks, or personal likeness except for accurate attribution and record +keeping expressly described in the final agreement and privacy notice. + +## 3. Contributor confirmations + +If this Agreement is adopted, You would confirm that: + +1. You have legal authority to enter into it and grant the stated rights. +2. You own or control the Copyright and Patent Claims needed for the grants. +3. The grants do not violate an agreement or obligation to an employer, + client, school, funder, or other third party. +4. If the Contribution was created in the course of employment or using an + employer's resources, You have obtained any required written employer + consent, or the authorized Legal Entity has accepted the appropriate entity + agreement. +5. You have not knowingly included third-party material unless a separately + documented Project procedure approved it in writing. No such procedure is + currently active. +6. You will identify any known restriction, provenance issue, or third-party + claim before submission. + +These confirmations are limited to matters within Your knowledge and authority +as specified in the final reviewed text. They are not a promise that the +Contribution is error-free or suitable for a particular purpose. + +Contributors who may be minors must not accept this Agreement until a qualified +reviewer has defined an appropriate age, guardian-consent, identity, and data +handling process: **[LEGAL REVIEW REQUIRED]**. + +## 4. Project decisions and no obligation + +We may accept, reject, modify, defer, or remove a Contribution. Acceptance of +this Agreement would not guarantee merge, attribution in a particular form, +support, payment, employment, or participation in project governance. + +## 5. Disclaimer and liability provisions + +Harmony includes conspicuous warranty disclaimers and a consequential-damages +waiver. The exact language and whether obligations should be mutual depend on +the chosen parties and jurisdiction. The adopted agreement must include +counsel-reviewed provisions at **[LEGAL REVIEW REQUIRED]**. + +Until then, this draft makes no warranty and does not create contractual +rights or obligations. + +## 6. Privacy, records, and electronic acceptance + +Before activation, the Project must publish a privacy notice that identifies: + +- the legal recipient/data controller and contact; +- personal data collected for acceptance; +- purpose and lawful basis; +- processors, recipients, and cross-border transfers; +- retention and deletion rules; +- contributor access, correction, objection, and other applicable rights; +- the version, timestamp, account identity, and evidence retained; and +- the process for security incidents and future agreement updates. + +The final agreement must identify the exact acceptance action and the version +accepted. CLA Assistant or another tool may automate identity checks, prompts, +records, and status checks, but using a tool does not itself make the legal +text sufficient or enforceable. + +## 7. Employer and entity contributions + +Before accepting work performed for an employer or other Legal Entity, the +Project must decide whether to require: + +- a separate Harmony-style Entity Contributor License Agreement; +- individual acceptance plus employer consent; +- a list of authorized contributors maintained by the entity; or +- another professionally reviewed process. + +The authorized signatory's name, title, authority, entity identity, Affiliates, +and changes to authorization must be recorded under the final privacy and +retention process. + +## 8. Miscellaneous terms + +The adopted agreement requires complete provisions for governing law, forum or +dispute process, assignment, successors, severability, waiver, entire +agreement, amendments, notices, language, and counterparts or electronic +signatures. Those provisions are **[TO BE AGREED AFTER QUALIFIED REVIEW]** and +are not inferred from this draft. + +## 9. Acceptance blocks — intentionally disabled + +### Individual contributor + +- Legal name: **[DO NOT COMPLETE — PROCESS NOT ACTIVE]** +- Address/contact: **[TO BE AGREED WITH PRIVACY REVIEW]** +- GitHub identity: **[TO BE AGREED]** +- Agreement version: **[TO BE AGREED]** +- Signature/acceptance: **[TO BE AGREED]** + +### Legal Entity + +- Entity legal name: **[DO NOT COMPLETE — PROCESS NOT ACTIVE]** +- Authorized signatory and title: **[TO BE AGREED]** +- Address/contact: **[TO BE AGREED WITH PRIVACY REVIEW]** +- Authorized contributors: **[TO BE AGREED]** +- Agreement version: **[TO BE AGREED]** +- Signature/acceptance: **[TO BE AGREED]** + +### Project Recipient + +- Legal identity: **[LEGAL REVIEW REQUIRED]** +- Capacity/title: **[TO BE AGREED]** +- Address/contact: **[TO BE AGREED]** +- Signature/acceptance: **[TO BE AGREED]** + +--- + +## Source attribution + +Planning source: Harmony Combined Contributor Agreement Template, version 1.0, +and the Harmony Guide to the Contributor Agreements, published at + and licensed by Project Harmony +under Creative Commons Attribution 3.0 Unported. + +Other reference points used to identify—not resolve—the required boundaries: + +- official MPL 2.0 text: ; +- Developer Certificate of Origin 1.1: ; +- CLA Assistant project documentation: + . + +No reference source, template, automation, or repository maintainer has +approved this HitTheKit draft as legally sufficient.