License and trademark
How the code will be licensed, what the contributor agreement will ask, what the Kensora marks cover, and what will not be in the public tree.
The license, in plain words
The code will be published under the GNU Affero General Public License, version 3 (AGPLv3). You can read it, run it, change it, and share your changes. If you share a modified version, or run a modified version as a service that others use over a network, your changes must stay open too. That network clause is what sets the AGPL apart from most open source licenses: improvements stay open even when the modified code runs on a server rather than on a phone.
The license text is prepared. It takes effect when it publishes with the first public repository, and until then everything on this page describes a plan.
A planned exception so forks of the Android app can build
The Android app cannot build without linking against proprietary platform services SDKs from the platform vendor. The AGPLv3 lets a copyright holder grant narrow additional permissions on top of the license, and the published license will carry one: a linking exception for those platform SDKs, so that a fork can actually build and run the app. The exception will cover that linking and nothing else.
No warranty
The code will come with no warranty of any kind. It will be published in the hope that it is useful, but without even the implied warranties of merchantability or fitness for a particular purpose. This is the standard free software disclaimer, the license states it in full, and it means what it says: if you build and run the code yourself, you do so at your own risk.
The contributor agreement
Before a first change is merged, contributors will sign a Contributor License Agreement. It is a license grant, not an assignment: you keep your own copyright, and you grant Kensora, Inc. the rights it needs to ship the official apps and keep the project's licensing coherent. There will be an individual form and a company form, because code written for an employer may belong to the employer. The agreement will record your legal identity privately; that record is not published.
Trademark
An open source license grants rights in code, not in trademarks, and the AGPLv3 expressly permits declining to grant trademark rights. Project Kensora reserves its marks. A trademark policy file will publish with the code, and this section summarizes what it will say.
What is reserved
The Kensora name, the Kensora logo and triangle marks, and the "Project Kensora" program name are trademarks of Kensora, Inc. KENSORA is the subject of a pending United States trademark application. The marks are not licensed for use as the name or branding of any other software, service, or organization.
What you may do without asking
- Describe your work truthfully. "A fork of Kensora" or "based on Kensora source code" is nominative fair use, and it is welcome.
- Refer to the project by name in articles, reviews, research, packaging metadata, and documentation.
- Keep the required legal notices, meaning the license, notice, and trademark files, intact in a fork. Keeping them is expected.
What forks must do
A fork that you distribute, or run as a service, must use its own name and its own branding. Do not use the Kensora name or marks as your product name, app name, domain name, or logo, and do not present a fork in a way that suggests Kensora, Inc. published, certified, or operates it.
What will not be in the tree
The published tree will be a fresh-history export of the private development repository, and almost everything will be in it. A small set of files will be withheld, because Kensora, Inc. does not hold the rights to publish them, and an open source distribution must never claim to license material its publisher cannot license onward. The tree will carry a file listing every withheld item and the reason. In summary:
A licensed clinical instrument's text
Two files carry the verbatim item text of a licensed clinical instrument whose copyright belongs to a third-party publisher. Permission to publish is pending, and until it is granted those files stay out.
Two vendor hardware SDKs
Two hardware vendors' SDKs have license terms that forbid redistribution, so they cannot ship in the tree. Anyone building the related hardware features obtains those SDKs from the vendors under the vendors' own terms.
A few internal evaluation files
A small number of internal evaluation files reference a third-party clinical dataset and a vendor benchmark whose terms keep the material internal.
Brand assets, internal records, and signing material
Brand assets stay out because the marks are trademark-reserved and large media files do not belong in a source repository. Internal company records, such as review determinations and planning documents, are not part of the codebase and may publish separately later. Signing keys and similar material never ship anywhere.
What this means for building: the Android app, which is the first tree planned to publish, will build from the tree as it stands. The iOS app, which follows later, will need the vendor SDKs obtained from their vendors, and the withheld clinical instrument file either supplied under license or replaced with a stub, before it builds.
Questions
Questions about the license, the trademark policy, or the withheld list are welcome. See the support page for how to reach the project.