--- name: open-source-commercialization-research description: Research whether an open-source project can be productized commercially, separating code licensing, trademark/branding, hosted-service terms, dependency/model licenses, and product-name clearance. Use for “can we sell/host/fork this?”, “powered by X” attribution, rebranding, white-labeling, or open-core product-launch questions. version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [open-source, licensing, trademark, branding, commercialization, productization, legal-research] --- # Open-Source Commercialization Research Use this skill to produce a source-grounded preliminary business-risk assessment for commercializing an open-source project. This is legal research, not legal advice or a substitute for counsel-led clearance. ## Core rule: separate the rights layers Never infer the whole answer from the repository license alone. Analyze each layer independently: 1. **Repository copyright license** — rights to use, modify, distribute, sublicense, sell; notice/copyleft/source obligations; warranty; explicit patent grant or lack of one. 2. **Project name and visual branding** — trademarks, service marks, common-law use, logos, icons, trade dress, domains, app-store names, and implied affiliation. 3. **Hosted services and commercial APIs** — separate Terms of Service may prohibit resale, third-party access, credential sharing, white-labeling, or competitive use even when the client/runtime is open source. 4. **Dependencies and bundled material** — vendored code, plugins, skills, fonts, icons, models, datasets, and package dependencies may have separate licenses that the root license does not override. 5. **Proposed product presentation** — factual compatibility/attribution is lower risk than making the upstream mark part of the product's own source identity. 6. **Territory and vertical** — trademark rights are territorial and depend on related goods/services, channels, and likely consumer confusion. ## Research workflow ### 1. Establish the exact upstream project - Verify the official repository, project website/docs, copyright holder, legal entity, package metadata, and latest release. - Prefer official raw files and APIs over summaries: `LICENSE`, `NOTICE`, `COPYING`, `README`, package manifests, docs, and repository metadata. - Record the check date and source timestamps where available. - Inspect repository roots and code search for `trademark`, `brand`, `logo`, `legalTrademarks`, `powered by`, `white-label`, `resell`, and `NOTICE`. ### 2. Read the actual license text Report the exact permissions and obligations rather than merely naming the license. For permissive licenses, address: - Commercial use and sale - Modification and proprietary forks - Distribution/notice requirements - SaaS-only operation versus distribution - Warranty disclaimer - Patent language: distinguish an explicit patent grant (for example Apache-2.0) from a license that is silent Do not say “MIT means the name is free to use.” Copyright permission and trademark permission are different. ### 3. Investigate project branding policy and actual practice Check for: - A dedicated trademark or brand-use policy - Logo guidelines - Official examples of integrations or products using “powered by,” “built on,” or “for X” wording - Package metadata claiming a legal trademark - Terms reserving trade names and trademarks - Public use dates, repository creation, releases, and marketplace use relevant to possible common-law priority Official examples are evidence of accepted practice, **not automatically a blanket trademark license**. State that distinction explicitly. ### 4. Search trademark records At minimum, search: - Exact word mark - Dominant word alone - Close spelling/sound variants - Project owner and plausible affiliate entities - Relevant software/service classes, usually 9 and 42 plus vertical-specific classes - Major target jurisdictions for a planned international launch For U.S. records, verify material findings in official USPTO TSDR rather than relying only on trademark-directory sites. A reliable no-key status endpoint is: ```text https://tsdr.uspto.gov/statusview/sn ``` Capture: - Owner - Filing and status dates - Live/dead and examination status - Registration versus pending application - Use-based versus intent-to-use basis - Goods/services and classes - Standard-character versus design mark - Prosecution history - TSDR's generated timestamp If a bulk TSDR API requires an API key, use the public `statusview` HTML endpoint and parse the labeled fields. Do not turn temporary API access requirements into a claim that official verification is impossible. Use precise language: - A pending application is **not a registration**. - Intent-to-use means use was not claimed on filing; it does not establish current marketplace use by itself. - Public evidence predating a filing may matter, but legal priority depends on qualifying use and facts; do not declare ownership from repository dates alone. - “I did not locate a filing” is not proof that none exists; entity aliases, unindexed filings, and international records may remain. ### 5. Test likely confusion and attribution risk Assess similarity of marks and relatedness of goods/services. Also evaluate whether the presentation implies sponsorship, affiliation, certification, or an official edition. Use a practical naming ladder: | Presentation | Typical relative risk | |---|---:| | Independent brand + factual About-page attribution | Lower | | “Built on the open-source X project by Y” | Lower–moderate | | Independent brand — “Powered by X” as subordinate tagline | Moderate; permission-worthy for a prominent commercial launch | | “X for [vertical]” or “[Product] X” | Higher | | “X Pro/Cloud/Enterprise,” X in company/domain/app identity | Very high | | Official logo/icon/trade dress without permission | Very high | “Nominative fair use” is jurisdiction- and fact-dependent, not a guaranteed safe harbor. Keep factual uses truthful, minimal, subordinate, and non-confusing. ### 6. Separate source-code rights from service resale Always inspect hosted-service/API terms when the product will route customer traffic through an upstream subscription or credential. Ask: - May the service be resold or made available to third parties? - Are customer end users authorized users under the plan? - Is credential sharing forbidden? - Is commercial embedding, white-labeling, or competitive use restricted? - Is a partner/reseller/enterprise agreement available? A permissively licensed runtime does not authorize resale of the maintainer's cloud, model gateway, subscription, API quota, or brand. ### 7. Audit downstream licensing Before recommending distribution, require: - SBOM/dependency license scan - Review of bundled plugins, skills, fonts, icons, and media - Model and dataset terms - Provider/API terms - A consolidated `THIRD_PARTY_NOTICES` file - Preservation of all required copyright and license notices ## Recommendation format Lead with a direct answer, then separate: 1. **Code-license conclusion** 2. **Trademark/branding conclusion** 3. **Hosted-service/API conclusion** 4. **Known conflicting records** with status and scope 5. **Green/yellow/red naming table** 6. **Recommended wording and disclaimer** 7. **Launch checklist** 8. **Sources and as-of date** Provide language the product team can actually use, for example: ```text ProductName Built on the open-source [Upstream Project] project by [Maintainer]. ProductName is independently developed and is not affiliated with, sponsored by, or endorsed by [Maintainer]. ``` If the fork is materially modified, prefer “based on” or “built on” over “powered by.” Do not recommend using `®` without a verified registration. ## Escalation threshold Recommend written maintainer permission and trademark counsel when any of these apply: - The upstream name appears in the product, company, domain, social handle, or app-store title - The official logo or trade dress will be used - “Powered by” is a prominent commercial campaign element - A live pending/registered mark covers related software/services - The launch is multi-jurisdictional - The product resells or embeds the maintainer's hosted service When requesting permission, send the exact phrase, visual mockup, channels, commercial context, modification status, logo request, and service/API usage. Ask for written scope, required attribution, duration/revocability, and permitted placements. ## Pitfalls - Treating “open source” as permission to adopt the project name as a brand - Treating a README badge or community showcase as a legal trademark license - Calling a pending application a registered mark - Assuming no federal registration means no trademark rights - Ignoring provider/service terms because the client is MIT/Apache/BSD licensed - Copying logos because the image file sits inside an open-source repository - Declaring ownership/priority from GitHub dates alone - Giving a global clearance conclusion from a U.S.-only search - Omitting the exact proposed wording and placement from the risk assessment ## References - `references/hermes-agent-licensing-trademark-2026-07.md` — worked example and source-backed findings for Hermes Agent/Nous Research, including USPTO records and “powered by” evidence.