Name, Governance & Trust
Clarifying how the open-source codebase and the project name relate to each other, and why this separation is essential for security and trust.
Code vs. Name
The source code of Lethesafe™ is published under the GNU Affero General Public License v3 (AGPLv3). Everyone may read, modify, share and fork this code. The name, however, is reserved for the original project and its official releases. “Lethesafe” identifies a specific origin, governance structure and threat model. Mixing the name with unrelated forks would dilute that signal and harm users who rely on a clearly accountable source.
Official Releases
Only releases that originate from the official Lethesafe maintainers and are signed or announced through the documented channels are considered authentic Lethesafe builds. These releases stand for a public commitment to the security principles, review processes and disclosure practices described on the German pages of this site.
Forks and Derivatives
Forks are explicitly allowed, both for experimentation and for alternative governance models. Fork authors must choose a distinct name and may not suggest endorsement by the original project. This clarity protects users: the community can evaluate forks on their own merits without confusing them with the reference implementation.
Reusing the name “Lethesafe” for a fork would blur responsibility. In a security project that promises calm and transparent communication, that confusion is unacceptable. Distinct names make it obvious who answers for a release, who provides updates and who responds to disclosures.
Why Separation Matters
Security depends on predictable stewardship. Users must know which builds follow the documented threat model and which originate elsewhere. The separation between the AGPLv3 codebase and the Lethesafe™ name ensures that anyone can innovate while the official project remains a stable point of reference. It is not a legal threat; it is a trust boundary.
Respecting that boundary keeps the conversation honest. Forks can publish their improvements without constraint, and the original project can stand by its releases without being held responsible for code it never reviewed.