When security people think about open source trust, they usually think about code signing, reproducible builds, and SBOMs. Trademarks rarely come up. This is a blind spot. In practice, the trademark on a package, the name under which it is published, the logo on its website, is the single most frequent trust signal that end users actually evaluate. When a developer pulls redis from Docker Hub or runs apt install apache2, they are trusting a name before they trust any cryptographic artifact. Trademark policy is the governance layer that protects that name, and when it fails, so does the trust chain.
The relevance of trademark policy to security has become sharper in the last few years. The Elasticsearch/OpenSearch split, the Redis/Valkey fork, and countless smaller rebrandings have taught enterprises that the code under a name can change out from under them. Simultaneously, typosquatting attacks on npm, PyPI, and Go module proxies have repeatedly demonstrated that attackers exploit the trust of names far more than they exploit cryptographic weaknesses.
What a Trademark Policy Actually Does
An open source trademark policy answers a specific question: under what conditions can someone else use the project's name, logo, or other branded elements? The answer varies dramatically across foundations and projects.
The Apache Software Foundation owns trademarks on every Apache project name. Its trademark policy, maintained by the ASF Trademark Subcommittee, specifies nominative use, distinguishes descriptive from commercial uses, and provides a formal process for enforcement. Apache has pursued trademark enforcement actions repeatedly over the years, most notably when a downstream distribution has represented itself as "the official" version of an Apache project without authorization.
The Linux Foundation owns the "Linux" trademark (licensed to them by Linus Torvalds personally, with a formal assignment in 2000). Their trademark sublicensing program, managed through the Linux Mark Institute, generates revenue and enforces consistent usage. Major distributions pay to use the "Linux" name in their product names, a practice that has been formalized since the early 2000s.
The Mozilla Foundation has historically been aggressive about the "Firefox" trademark. The policy that the Debian project had to rebrand Firefox to Iceweasel in 2006 (before reverting the rebrand in 2016 under a revised agreement) is a well-known case study. Debian's objection was that Mozilla's logo was non-free in the Debian sense; Mozilla's position was that the brand integrity of Firefox depended on trademark control.
The Free Software Foundation, by contrast, has historically taken a more permissive stance on many GNU project names while being protective of "GNU" itself and "GPL."
Trademark and the Security Chain
Trademarks contribute to security in several concrete ways.
They allow enforcement against typosquatting and impersonation. Attackers who register requests-2 on PyPI, or who publish containers named mysq1 on Docker Hub, are exploiting the credibility of the real names. When the underlying project has a clear trademark owner, that owner can pursue takedown through the registry operator, through domain dispute resolution (ICANN UDRP), or in egregious cases through the courts. Projects without clear trademark ownership struggle to do this.
They provide a ground truth for "official" binaries and builds. When you pull redis:7.2 from Docker Hub under the library/ namespace, you are relying on the combination of Docker's Official Images program and Redis Ltd.'s trademark claim to know that this image is the authentic one. The moment a fork (like Valkey) is published, clear branding is what lets users distinguish the two downstream artifacts.
They enable supply chain provenance claims. SLSA and similar provenance frameworks depend on a verifiable link between build artifacts and a canonical source. The "canonical source" is typically identified by project name, which is a trademark claim even when informal.
When Trademark Policy Collides with Forking
The Elasticsearch-to-OpenSearch transition illustrates how trademark policy shapes fork dynamics. When Elastic moved to SSPL/ELv2 in January 2021, Amazon forked from the last Apache 2.0 release (version 7.10.2) but could not, for trademark reasons, call the fork "Elasticsearch." Amazon initially shipped "Open Distro for Elasticsearch," which used the name descriptively but awkwardly. By April 2021, Amazon had renamed to "OpenSearch," donating the trademark to a neutral entity (initially held by Amazon, later transferred fully under Linux Foundation governance in September 2024).
Redis-to-Valkey followed a similar pattern with cleaner execution. The Linux Foundation's Valkey project launched in March 2024 with a new name from day one, avoiding any period of trademark ambiguity. This was possible because the backing coalition (AWS, Google Cloud, Oracle, Ericsson, Snap) agreed on naming before the fork went public.
Terraform-to-OpenTofu went through a rougher naming journey. The project was initially proposed as "OpenTF" in August 2023, then renamed to "OpenTofu" in September 2023 after HashiCorp raised trademark concerns about "TF." The rename was framed as a goodwill gesture and probably avoided protracted legal dispute.
Trademark Policy Gaps That Create Security Risk
Several classes of trademark policy gaps have real security consequences.
Unclear ownership of orphaned projects. When a project is abandoned and its trademark is not held by a foundation, the trademark status is often unclear. Anyone can register a similarly-named package on npm or PyPI. The event-stream incident of November 2018 exploited trust in a name after ownership had been transferred informally; trademark protection was not relevant because there was none.
Registry-level weaknesses. npm, PyPI, and similar registries have relatively weak trademark enforcement as a matter of policy. They will act on clear typosquatting and on DMCA-style takedowns, but they are not trademark courts. The 2023 wave of "crypto drainer" packages on npm, often named to impersonate legitimate utilities, showed how slowly registry takedowns can happen even with clear impersonation.
Vendor/project name conflicts. When a commercial entity shares its name with a project (Redis Ltd. and Redis the database, for instance), license changes and fork events can create confusion about what "Redis" even refers to. Valkey's launch required a clear statement that it was a fork of a specific Redis version (7.2.4) precisely to anchor the meaning of its own name.
Container image impersonation. Docker Hub's Official Images program and library namespace provide some trademark-adjacent protection, but the broader Hub is effectively unvetted. Attackers have repeatedly published malicious images under names that mimic legitimate projects, relying on users to pick the first plausible result.
What Good Trademark Policy Looks Like
The patterns that work in practice share several properties. A clear trademark owner, typically a foundation or a corporate entity with a documented enforcement posture. A published nominative-use policy that lets downstream users refer to the project without triggering enforcement, while preventing rebranded redistributions from claiming the official name. Enforcement resources, meaning the owner is willing and able to pursue trademark infringement when it matters. And coordination with registry operators, so takedowns on npm, PyPI, Docker Hub, and similar platforms actually happen when needed.
How Safeguard Helps
Safeguard combines trademark ownership and authenticity metadata with component identification, so when your dependencies pull from a registry, the platform surfaces whether the named package actually corresponds to the canonical upstream project. Typosquatting risk indicators flag packages with names suspiciously close to well-known projects but lacking the governance and provenance signals of the real upstream. When a project rebrands, splits, or transfers trademark ownership (Redis to Valkey, Elasticsearch to OpenSearch, Terraform to OpenTofu), Safeguard maps the transition in your SBOM so naming changes do not create blind spots in risk scoring. That gives security teams a real view of whether the names in their builds match the projects they intend to depend on.