When this skill is activated, always start your first response with the 🧢 emoji.

IP Management

Disclaimer: This skill provides general educational information about intellectual property concepts and practices. It is not legal advice. Always consult a qualified IP attorney before making decisions that may have legal consequences for your organization.

Intellectual property management is the practice of identifying, protecting, and leveraging the intangible assets of an organization - inventions, brand identity, creative works, and confidential know-how. For software companies, IP decisions affect competitive moats, open-source strategy, hiring, M&A, and regulatory exposure. This skill covers the full IP lifecycle: choosing the right protection mechanism, complying with open-source license obligations, managing patents and trademarks, and building policies that prevent IP loss.

When to use this skill

Trigger this skill when the user:

• Needs to choose an open-source license for a new project or repository
• Wants to audit third-party open-source dependencies for license compliance
• Is filing or researching a trademark application
• Needs to protect trade secrets in a company or product
• Is negotiating or reviewing IP assignment clauses in contractor or employment agreements
• Wants to build or review a company IP policy
• Needs to understand the difference between patent, trademark, copyright, and trade secret
• Is evaluating whether to open-source internal tooling

Do NOT trigger this skill for:

• Contract negotiation beyond IP clauses (use a contracts or legal operations skill)
• Software licensing agreements between commercial vendors (SaaS terms, enterprise contracts)

Key principles

1. Protect early - IP rights are often time-sensitive. Patent applications in most jurisdictions operate on a first-to-file basis. Trademark rights are strengthened by early registration and consistent use. Waiting until a product launches to think about IP protection means leaving gaps that competitors can exploit.

2. Open-source licenses have real obligations - Using open-source code is not free of legal risk. Copyleft licenses (GPL, AGPL) impose reciprocal disclosure requirements. Ignoring these obligations can result in forced open-sourcing of proprietary code, injunctions, and reputational damage. Every dependency has a license; treat it as a contract.

3. Trade secrets need active protection - A trade secret is only legally protected if the owner takes reasonable steps to keep it secret. That means access controls, NDAs, confidentiality policies, and employee training. A trade secret shared carelessly in a public Slack channel or leaked through a contractor is lost forever.

4. IP assignment in employment contracts must be explicit - In most jurisdictions, work created by an employee in the scope of their job belongs to the employer by default - but "scope" is ambiguous. Contractor work is often not assigned by default. Every employment and contractor agreement must contain an explicit, broad IP assignment clause. Audit historical agreements before an acquisition.

5. Audit regularly - Open-source dependency licenses change between versions. New hires bring IP from former employers. Contractors create work under unclear ownership. Regular IP audits - at least annually and before any M&A process - catch problems while they are still fixable.

Core concepts

IP types

When to use which:

• Use patents for novel algorithms or technical methods that could be independently reinvented by a competitor.
• Use trademarks to protect brand identity and prevent customer confusion.
• Use copyright to prevent verbatim copying of code and documentation (it is automatic; open-source licenses are built on top of copyright).
• Use trade secrets for formulas, datasets, processes, or architecture that derive value from remaining confidential and cannot be reverse-engineered easily.

Open-source license spectrum

Licenses range from permissive (few obligations) to strong copyleft (reciprocal disclosure required). The spectrum:

Permissive                    Weak copyleft       Strong copyleft
    |                              |                    |
   MIT        Apache 2.0         LGPL          GPL       AGPL
    |              |               |             |          |
Use freely,  + patent grant,  Linking OK,   Modifications  Network use
attribution  + patent peace   but mods to   must be GPL    must be AGPL
only         clause           lib = LGPL

See references/license-comparison.md for a detailed comparison table including BSL (Business Source License) and compatibility matrix.

IP ownership in employment

Default rules (varies by jurisdiction):

Risk at M&A: Acquirers conduct IP due diligence. Missing assignments, unclear contractor agreements, and "moonlighting" projects create escrow holdbacks and deal risk. Audit before starting any fundraising or acquisition process.

Common tasks

Choose an open-source license

Decision matrix:

1. Do you want to allow proprietary use without sharing back?
   YES -> Go to step 2
   NO  -> Choose GPL-3.0 (or AGPL-3.0 if server-side use matters)

2. Do you want a patent grant to protect users?
   YES -> Apache-2.0 (preferred for corporate use)
   NO  -> MIT (simplest, most permissive)

3. Is this a library that will be linked into proprietary apps?
   YES -> Consider LGPL-2.1 or MIT/Apache (LGPL allows proprietary linking)
   NO  -> MIT or Apache-2.0

4. Do you want a time-delayed open-source commitment (startup model)?
   YES -> BSL (Business Source License) with a defined change date

5. Is this infrastructure software where SaaS competition is the concern?
   YES -> AGPL-3.0 (requires disclosure even for network use)

Practical recommendations:

• Libraries intended for broad ecosystem adoption: MIT or Apache-2.0
• CLI tools and standalone applications: MIT, Apache-2.0, or GPL-3.0
• Server software where you want to prevent closed-source forks: AGPL-3.0
• Commercial open-core products: BSL with 4-year change date to Apache-2.0 or GPL

Audit open-source dependencies

Compliance audit process:

1. Inventory all dependencies - Run a software composition analysis (SCA) tool:

   • Node.js: license-checker, licensee, or fossa
   • Python: pip-licenses or licensecheck
   • Java/JVM: license-maven-plugin or gradle-license-plugin
   • Go: go-licenses
   • Multi-language: FOSSA, Snyk, or Black Duck

2. Classify by risk tier:

   Tier	Licenses	Action
   Green	MIT, BSD-2, BSD-3, ISC, Apache-2.0	Approved; attribution required
   Yellow	LGPL-2.1, LGPL-3.0,