Kensora logoKensora logo Project Kensora
Preparing for launch.

Frequently asked questions

Plain answers about the open source plan, the license, contributing, and where the hard lines are.

The plan

Why is Kensora going open source?

For three reasons. Privacy claims should be checkable: how Kensora stores, syncs, and protects information should be something you can read for yourself, not something you take on faith. Languages and cultures need native speakers: Kensora aims to work in the words and norms people actually live in, and no small team can carry it everywhere alone. And parity needs more hands: the Android app is catching up to iOS feature by feature, and contributions checked against shared behavior contracts can speed that up.

Why AGPLv3?

The AGPLv3 is a copyleft license: you can read the code, run it, change it, and share your changes, and a modified version you share stays open under the same terms. The network clause is why it is the AGPL and not an ordinary copyleft license: if you run a modified version as a service that other people use over a network, those people must be offered your modified source too. In short, improvements to Kensora stay open, whoever makes them and wherever they run. The license texts are drafted but not yet in force; they take effect when the first repository publishes.

When can I contribute?

Not yet. Contributions open when two things happen: the contributor license agreement publishes and the first repository goes public. Neither has happened yet, so for now there is no repository to send a pull request to. Watch the home page, which will link the repository the day it goes public, and the roadmap, which tracks the steps between here and there.

Is any user data in the repositories?

No, and there never will be. The planned public tree is a fresh-history export of the code alone: no user data, no health data, no journals, nothing personal about anyone. Signing keys and machine-local configuration are excluded as well, along with a small set of third-party materials the project cannot license onward, and the tree will say exactly what is withheld and why. The code is the code.

Using the code

Can I use Kensora code in my own product?

Yes, once it publishes, under the AGPL's terms. In plain words: a product that includes the code must be licensed under the AGPLv3 as well, the people who use it, including over a network, must be able to get its complete source, and the license and notice files stay intact. The license text, not this summary, is the binding document; the license page covers the plan in more detail. The Kensora name and marks are not part of the grant, which is the next question.

Can I fork Kensora?

Yes. An open source license grants rights in code, not in trademarks, so a fork that you distribute or run as a service uses its own name and its own branding. Do not use the Kensora name, logo, or marks as your product's name or branding, and do not present a fork as something Kensora, Inc. published, certified, or operates. Saying truthfully that your project is a fork of Kensora, or based on Kensora source code, is nominative fair use and is welcome. A trademark policy will publish with the repository and spell this out. KENSORA is the subject of a pending United States trademark application.

Does open code mean I can check the privacy claims myself?

You will be able to read exactly what the code does: what is stored, what leaves the device, and what never does. That is the point of opening it.

One honest boundary: reading source is not the same as auditing the app installed from a store. Kensora does not claim that a store binary provably matches the published source. Open code makes the design checkable; it is not proof about the binary on your phone. The Android repository publishes first, so the Android code is where this kind of reading becomes possible earliest.

Contributing

Do I need to be a programmer?

No. Knowledge is a contribution, and the planned tracks reflect that. Once the tracks open: if you are fluent in another language, you will be able to translate general interface strings. If you are local to a country or region, you will be able to help verify crisis lines against real sources. If you are a native speaker, you will be able to review crisis wording and idioms in your language. If you live with a mood disorder, or support someone who does, your feedback on how features actually land is a contribution in itself. Clinicians and researchers can bring literature and critique, screen-reader users and accessibility auditors can bring findings, and security researchers can report privately. The contributing page describes each track.

What is the Claude workflow the project keeps mentioning?

Kensora is developed with a queue driven workflow built around Claude Code, an AI coding tool from Anthropic: work is queued as small, well defined tasks, and each session does one task against the project's tests and review gates. The repository will ship a public version of this workflow, and a step-by-step guide will teach it. Contributors who want to use it run Claude Code on their own Anthropic account, at their own cost. Project Kensora is not affiliated with or endorsed by Anthropic.

Will I be paid?

No. Contributing is unpaid, and maintainers may decline a change or ask for a different approach. Every accepted contribution will be credited in the contributors ledger under the name you choose.

Can I contribute under a pseudonym?

Yes, and it is a first-class option, not a workaround. Contributing to a mental-health project can itself be a personal disclosure, and you control what is public. The planned contributor agreement records your legal identity privately and is not published.

One thing to choose deliberately before your first pull request: a pull request publishes the name and email address in your git configuration, worldwide and permanently, and git history cannot be fully unpublished later. Set them to the identity you want the world to see.

Safety and the company

Why are safety decisions not up for a community vote?

Because people in distress may be on the other end of them. Project Kensora is open source with closed gates: the code is open to read, run, fork, and improve, but decisions about what ships to people are not crowd-sourced. Crisis copy in every language, crisis-language word lists, helpline data, and any user-facing text that states what Kensora does for health form a locked tier. Contributors, including automated review sessions, can raise reviews and findings on the locked tier; they can never clear them. Clinical and legal review inside the project, plus maintainer sign-off, are mandatory there, and this asymmetry is deliberate and permanent. The governance page has the full picture.

These are the project's internal review seats, run with AI assistance under the project lead's authority; they are not an external clinician's or attorney's sign-off, and Kensora does not represent them as such.

Who is behind Project Kensora?

Project Kensora is run by Kensora, Inc., a Delaware public benefit corporation, the company that makes the Kensora app. Today the project has one maintainer: the founder, who personally merges every change and triggers every release. That is stated plainly rather than dressed up. The license and contributor agreement are being structured so the code remains usable by everyone if the project ever stops; a fuller continuity plan is an open item, not a promise.

Is Kensora a crisis service?

No. Kensora is not a crisis service, and it does not detect or prevent any medical or mental-health condition or emergency. The app helps people see shifts from their own baseline and understand their own patterns, and everything on this site describes how the software works, never what it can promise about anyone's health. Neither the app nor any project repository, now or later, is a way to reach help. If you are in danger or in crisis, contact your local emergency number or find a helpline at findahelpline.com.

Still have a question?

If it is not answered here, write to hello@kensora.io. Security reports go privately to security@kensora.io, never to a public issue.