← all skills

open-source-commercialization-research

/home/avalon/.hermes/skills/research/open-source-commercialization-research/SKILL.md · raw

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

2. Read the actual license text

Report the exact permissions and obligations rather than merely naming the license.

For permissive licenses, address:

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:

Official examples are evidence of accepted practice, not automatically a blanket trademark license. State that distinction explicitly.

4. Search trademark records

At minimum, search:

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:

https://tsdr.uspto.gov/statusview/sn<SERIAL_NUMBER>

Capture:

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:

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:

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:

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:

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:

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

References