FDE BenchmarkPublic document reader
Available in sourcev0.1 · live public draft · official release pending

Canonical source view. This renders the bundled repository document as readable HTML. Source metadata remains in the repository, and relative document links remain inside this reader.

Trademark Policy

Status: v0.1 Public Draft; legal and clearance review pending

This policy explains the intended use of project names and marks. It does not claim that any mark is registered, cleared, or enforceable in a particular jurisdiction.

1. Marks covered

The policy is intended to cover names, logos, badges, slogans, and visual identifiers used to designate the LockedIn FDE Benchmark project or an official result, including:

  • LockedIn Labs;
  • LockedIn FDE Benchmark;
  • official project logos and release marks;
  • official profile, verification, or credential marks introduced by a later release.

No registration or certification-mark status should be inferred. Final ownership, registrations, and authorized forms must be confirmed through counsel before public launch.

2. Why trademark permission is separate

Open code and content licenses permit use of covered code or text under their terms. They do not authorize a user to imply that a modified benchmark, fork, service, evaluation, profile, or credential comes from or is endorsed by LockedIn Labs or the official project.

Copyright and software license terms are in the repository’s license files: the Apache License 2.0 (LICENSE) for software, schemas, fixtures, scripts, and the public site, and CC BY 4.0 (LICENSE-CONTENT.md) for specification, policy, ontology, and research content. Neither license grants any right in the marks described here.

3. Uses that generally do not require separate permission

Subject to applicable law and accurate presentation, a person may:

  • refer factually to the LockedIn FDE Benchmark project;
  • link to an official repository or release;
  • state that software implements, maps to, or was tested against a named public-draft schema when the statement is true and qualified;
  • quote the project name in criticism, research, journalism, or comparative analysis;
  • identify an unmodified official release with its exact version and public-draft status.

These uses must not imply endorsement, partnership, validation, certification, governance membership, or authorization to issue official results.

Recommended wording:

“Implements the public schema for LockedIn FDE Benchmark v0.1; not an official evaluation or credential.”

4. Uses requiring written permission

Written permission is required to:

  • use a project logo in a product, service, event, domain, application icon, or marketing campaign;
  • call a service “official,” “authorized,” “certified,” or “verified” by the project;
  • issue a badge, profile, score, credential, or verification that uses project marks;
  • use a confusingly similar product, organization, repository, or domain name;
  • imply partnership, sponsorship, signatory status, governance membership, or endorsement;
  • sell merchandise carrying project marks;
  • use a mark in a way that suggests a fork is the original project.

No permission is granted merely because a person contributed, sponsored infrastructure, joined a discussion, used a schema, or completed training.

5. Forks and modified implementations

A fork may use the openly licensed material once licenses are published, but must:

  • use a distinct name and visual identity;
  • state that it is unofficial and modified;
  • identify the upstream version and material changes;
  • remove official badges, signing keys, issuer identifiers, and claims of authorization;
  • avoid domains or package names likely to cause confusion;
  • preserve required copyright and license notices.

A fork cannot represent its scores or credentials as official LockedIn FDE Benchmark results.

6. Badges, profiles, and credentials

No official badge or credential exists in v0.1.

A future policy must define authorized issuers, exact artwork, version and status display, revocation behavior, accessibility, misuse response, and restrictions on alteration. A badge may not omit benchmark version, result status, or verification URL where those are required by the release.

Screenshots or synthetic mockups must visibly state that they are synthetic and nonofficial.

7. Third-party marks

The project must not display an outside organization’s name or logo in a way that implies contribution, sponsorship, validation, signatory status, or endorsement without written authorization.

Vendor names may be used factually in research or interoperability documentation when necessary and lawful. Vendor-specific packs must remain separate from the provider-neutral core.

Before rendering a certification, platform, or provider mark, the project must maintain a per-mark clearance record identifying the authentic asset source, owner’s current usage terms, permitted context, required attribution, modification restrictions, approval status, and review date. An icon library or publicly downloadable SVG is not by itself trademark permission.

Only authentic approved artwork may be used. The project must not typeset a certification name as a substitute logo or invent a look-alike badge. When artwork permission is absent or unclear, use accurate plain text without a logo.

Certification badge artwork must not be displayed merely because a participant names a credential. Many badge programs limit display to the credential holder or an authorized verifier; the project must confirm both the participant’s entitlement and the platform’s right to reproduce the mark before public rendering.

8. Domains and social accounts

Domains, package names, social handles, and application listings that use or closely imitate project marks require written authorization. Registration by a contributor, sponsor, or community group does not create project ownership or official status.

9. Reporting suspected misuse

The project must publish a private trademark/contact channel before operating an enforcement program. Do not post personal information or legal allegations in a public issue.

The steward should prioritize correction of likely confusion and material harm, use proportionate remedies, and distinguish good-faith nominative use or criticism from deceptive representation.

This draft may change after clearance, licensing, certification-mark, jurisdiction, or governance review. A released policy change must appear in CHANGELOG.md.

Related documents: README.md · CHARTER.md · GOVERNANCE.md · CONTRIBUTING.md