Skip to content

IP & licensing

AI coding assistants generate code that draws, to varying degrees, on publicly available code and data. That introduces three IP questions:

  1. Could the generated code reproduce copyrighted code verbatim?
  2. Does the generated code risk pulling in an open-source license the company cannot accept?
  3. Who is liable if either happens?

The 2022 Doe v. GitHub, OpenAI, Microsoft class action1 forced the industry to address these questions in contract; most enterprise offerings now include some form of IP indemnification. That does not relieve engineering teams of responsibility. Indemnification is a fallback, not a substitute for care.

The company's commitments

Outward-facing

  • The company publishes code under its chosen licences; AI use does not change the license terms the company offers.
  • Customers receive code and outputs without additional AI-specific license restrictions.
  • Customer-visible AI commitments (if any) are recorded in the charter and Marketing review.

Inward-facing

  • Engineers may not use AI tools that categorically refuse to offer IP indemnification.
  • Engineers must flag verbatim public-code matches reported by the tool (where available) during review.
  • Code produced with AI assistance is not special in terms of ownership; it is company work product on the same basis as any other code the engineer authors in scope.

Vendor requirements

The approved-tool list requires each tool to offer:

  • IP indemnification for infringement claims arising from generated output, at a minimum for output used substantially as produced.
  • Scope and carve-outs that are acceptable to Legal. Common carve-outs include prompts explicitly asking for specific third-party code, or failure to use the tool's filtering features.
  • Filtering features where the tool supports them (e.g., detection of verbatim public-code matches, with configurable thresholds).
  • Attribution mechanisms where the tool identifies training sources. Not universally available, but increasingly requested.

See Vendor standards for the procurement lens.

Open-source provenance

AI tools may suggest dependencies. Every dependency adoption is a license decision.

  • SCA (Software Composition Analysis) is a pre-merge gate for AI-adjacent PRs, not a post-merge alert. (An AI-generated PR can otherwise merge before the scan completes.)
  • License compatibility checked at merge time, not at release.
  • Banned licences listed in a company-wide policy (typical examples: AGPL for commercial SaaS, SSPL for re-distribution, unknown licences).
  • Package-provenance checks verify the package existed at a plausible date. This catches slopsquatting: AI suggests a package name that did not exist, an attacker registers it and ships malicious code. See Incident response scenario 3.

Verbatim matches

Where the AI tool can flag output that matches public code verbatim, that flag is a merge-blocker unless the engineer can cite the matched repository and its license is compatible.

Snippet scale

Very short snippets (idioms, common patterns) are typically not copyrightable. Longer snippets are. The company's policy is:

  • Any match > 30 characters is investigated.
  • Matches > 100 characters are treated as verbatim until shown otherwise.
  • Full-function matches are blocked pending license review.

These thresholds are typical but not universal; adjust per Legal guidance.

Training-data provenance

  • Vendors that will not disclose anything about training-data provenance score 0 on the indemnification dimension of the vendor scorecard, because indemnification depends on the vendor having meaningful control over that risk.
  • Vendors that disclose at a class level ("we include publicly available code under OSS-compatible licences; we exclude copyleft") get partial credit; Legal notes the wording and tracks changes.
  • Vendors with published training-data cards or attributions get full credit.

Engineer obligations

When an engineer uses an AI tool:

  1. Do not prompt for specific third-party code by name. Prompts that explicitly request implementations "like project X" are voided from indemnification by most vendors. Rephrase in terms of functionality.
  2. Accept only code you have verified. "The tool suggested it" is not a license defense.
  3. Use the tool's match filter if available. Disabling the filter for convenience is a policy breach.
  4. Flag matches during PR review. The PR template has a checkbox or field for verbatim matches; the reviewer checks it.
  5. Retain the prompt/output for IP-contested PRs per data-handling retention, so evidence is available if a claim arises.

Outbound licences

Code shipped to customers and to OSS projects carries the company's chosen outbound license (e.g., Apache 2.0, MIT, proprietary EULA). AI involvement does not alter this, but it does raise a question about inbound compatibility: can AI-generated code be included in an Apache-2.0 project the company publishes?

  • For Apache 2.0 / MIT outbound: yes, subject to the tool's indemnification and the reviewer's verification.
  • For copyleft outbound (GPL): permitted with extra care; verbatim matches from non-copyleft sources are not a problem, but matches from differently-licensed copyleft sources are.
  • For "proprietary only" outbound: the organization's policy should explicitly state whether AI-generated code is permitted inbound, and under what conditions.

Anti-patterns

Don't

  • Don't rely on indemnification as a primary control. It is a last-resort financial backstop, not a license-compliance program.
  • Don't disable match filters "for productivity". That routinely voids the indemnification you paid for.
  • Don't ask the tool for specific third-party code. You invalidate the vendor's indemnity and get worse results.
  • Don't skip SCA on AI-adjacent merges. Most incidents in this space are caught by SCA; letting them through is a self-inflicted wound.
  • Don't treat "we use the enterprise tier" as a complete IP answer. The enterprise tier typically provides indemnification and filters; both of which must be actively used.

Worked examples

Example 1: A tool flags a verbatim match

The tool notes that a 120-character snippet matches a public MIT repository. The engineer:

  • Does not merge until the reviewer can cite the source repo.
  • Adds a CREDITS / NOTICE entry per MIT terms.
  • Records the match in the PR description.

Example 2: A tool suggests a dependency

The tool recommends auth-utils-v3. SCA runs pre-merge and fails because:

  • The package did not exist on npm at the time of the suggestion.
  • The package that now exists is four days old and unreviewed.

The PR is blocked. Engineering opens an incident report (slopsquatting pattern; see IR scenario 3).

Example 3: A customer asks whether AI was used

A customer (often in regulated industries) asks whether AI was used to write code in a shipped product. The answer is:

  • Truthful and non-categorical ("we use approved AI tools with verification workflows; outputs are reviewed by engineers").
  • Non-specific about individual lines ("we do not attribute individual lines to AI or human authors; our Responsibilities for correctness and security are the same regardless").
  • Available in a standard statement referenced in sales materials if the question is common.

External references

  • WIPO on AI and copyright2.
  • US Copyright Office guidance on AI-generated works3.
  • GitHub's public IP indemnity terms4: a commonly-used benchmark for "what good looks like".

Next

  1. Doe v. GitHub, OpenAI, Microsoft class action, filed Nov 2022. Many claims were dismissed in subsequent rulings, but contractual indemnification language across vendors has become standard practice. ↩

  2. WIPO, Copyright and AI. ↩

  3. US Copyright Office, Copyright Registration Guidance for Works Containing AI-Generated Material, 2023. ↩

  4. GitHub, Copilot Product Specific Terms (indemnification section). ↩