A SKILL.md file is source-available the moment you publish it. Anyone who reads your skill can copy the prompt scaffolding, the anti-trigger rules, the tool allowlist, even the example invocations. That makes licensing more important for skills than for most software, and also a little weirder — you're licensing prose and YAML, not a compiled binary.
This guide walks through the licences that actually matter for SKILL.md authors, what each one buys you, how the license: frontmatter field flows into the catalog, when to request an attribution override, and what derivative skill etiquette looks like in practice. The goal is a one-screen decision you can make today and not regret in eighteen months.
A traditional npm package can ship a minified bundle and a LICENSE file and call it a day. The user runs the code; they never read it. A SKILL.md file is the opposite shape. It exists to be read — by Claude, by your teammates, by the next person who forks it. Every word of the prompt, every entry in the allowed-tools: list, every example in the body is right there in plaintext.
That changes the licensing calculus in three concrete ways. First, copying is frictionless: someone reading your skill can lift a clever anti-trigger paragraph in three seconds. Second, derivative works are the norm, not the exception — most non-trivial skills started life as a fork of something else. Third, the line between "using your skill" and "reading your skill" effectively does not exist, because reading is using.
If you don't pick a licence, the default in most jurisdictions is "all rights reserved." That means people can run your skill (arguably, depending on how they got it) but they cannot legally redistribute it, modify it, or include it in their own catalog. In practice the no-licence default means your skill becomes invisible — nobody wants to build on something that might force a takedown later.
A few things licensing does not control on a skill:
~/.claude/skills/ regardless of licence.What licensing does control: redistribution (can a catalog mirror your SKILL.md?), modification (can someone fork it?), attribution (do they have to credit you?), and patent grants (if your skill encodes a patented workflow, do users get a licence to that patent?). For the vast majority of skills, only the first three matter. We'll cover the patent case in the Apache section.
One more thing worth saying out loud: choosing a permissive licence is not the same as giving up authorship. You are still the author. Your name still goes in the frontmatter. The licence governs what other people can do with the file; it does not transfer authorship or moral rights. Authors of GPL projects still own their work — they just chose a particular distribution model.
MIT is the right choice for roughly 80% of skills published today. It's permissive (lets people do almost anything), short (the entire licence fits in a screen), legally well-tested (decades of case law), and recognised by every catalog and tool in the ecosystem.
The full text is about 170 words. Here it is, the only thing you need to drop into a LICENSE file alongside your skill:
MIT License
Copyright (c) 2026 Your Name
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...What MIT permits: anyone can use, copy, modify, merge, publish, distribute, sublicense, and sell your skill. They can fork it into a closed-source product, bundle it with proprietary code, or ship it inside a commercial Claude Code distribution. The only obligation is that the copyright notice travels with substantial copies.
What MIT does not include: any patent grant. If your skill encodes a workflow you have a patent on (rare for skills, but possible), MIT doesn't license that patent to users. They could be sued for using your skill in a way that practises the patent. If this matters to you, use Apache 2.0 instead.
The "substantial portions" clause is loose by design. Nobody is going to chase you down for quoting a paragraph from an MIT-licensed skill in a blog post. The intent is to prevent someone from forking the entire skill, rebranding it, and stripping your name off.
Set license: MIT in your frontmatter and drop the text above into LICENSE. That's it. The catalog picks up the SPDX identifier, downstream forks can stay MIT or relicense to anything compatible (Apache, BSD, MPL — but not GPL unless they accept the relicensing implications discussed below), and you have done your future-self a favour.
Apache 2.0 is MIT with two important additions: an explicit patent grant and a NOTICE file mechanism. It's the right choice when your skill (or the workflow it encodes) might brush against patents, or when you're publishing under a corporate identity and your legal team prefers the clearer indemnification language.
The patent grant is the headline feature. When you license a skill under Apache 2.0, you grant every user a perpetual, worldwide, royalty-free licence to any patent claims that read on your skill as you distributed it. The catch — and it's a useful one — is that the grant terminates if the user sues you (or anyone else) claiming the skill infringes their patents. This creates a peace-of-mind dynamic: contributors and users can build on the skill without fear that the original author secretly holds a patent they'll later weaponise.
For most prose-and-YAML skills this is theoretical. You probably don't have patents on the workflow your skill encodes. But for skills that touch novel algorithms (a custom retrieval strategy, a clever fine-tuning loop, an unusual evaluation method), the grant is genuinely valuable. Likewise, if you work at a company with a patent portfolio and you're contributing skills as part of your job, Apache 2.0 protects users from a future where your employer's legal team gets aggressive.
The NOTICE file is the second piece. Apache 2.0 lets you ship a separate NOTICE file alongside LICENSE that contains attribution text downstream users must preserve in their own distributions. It's the polite way to require credit without the all-caps drama of "YOU MUST INCLUDE THIS BANNER." A typical skill NOTICE reads:
code-review-pro
Copyright 2026 Acme Engineering
This skill includes structured-comment templates derived from
the Conventional Comments specification (conventionalcomments.org)
used under CC BY 4.0.Downstream forks have to keep that text. They can add their own attributions but cannot strip yours.
Frontmatter is license: Apache-2.0. Use the full text in LICENSE (it's about 11KB — too long to paste here) and optionally a short NOTICE. Apache 2.0 and MIT are compatible in the sense that you can incorporate MIT-licensed code into an Apache 2.0 project, but not the reverse: an MIT project cannot silently absorb Apache 2.0 code because the Apache patent and attribution clauses must travel with it.
When in doubt between MIT and Apache 2.0: pick MIT if you're a solo author and the skill is workflow-prose; pick Apache 2.0 if there's any chance of patent exposure or if your contributions are corporate.
The GPL family is copyleft: anyone who distributes a derivative of your work must release the derivative under the same licence. This is a deliberate viral mechanism — it ensures that improvements flow back to the commons rather than getting absorbed into proprietary forks.
For SKILL.md content the calculus is interesting. A skill is typically read by Claude and interpreted as prompt scaffolding. The skill itself doesn't compile into a running binary; it runs as instructions. So what counts as a "derivative work" of a GPL'd skill?
The conservative reading: forking the SKILL.md, modifying it, and distributing the modified version absolutely creates a derivative. That's textbook GPL territory. The looser question: does invoking the skill from inside a proprietary agent product create a derivative? Probably not — invoking a tool is not the same as modifying it, in the same way that running a GPL command-line tool from a closed-source shell script doesn't make the script GPL. But the FSF has historically taken aggressive readings, and there's no settled case law on "skill as runtime instruction."
The practical consequence: GPL'd skills are fine for community projects but discourage commercial adoption. Many companies have blanket policies against incorporating GPL code into shipped products, and that policy will catch your skill in its net even if a court might disagree.
AGPL (Affero GPL) raises the stakes further. AGPL was written to close the "SaaS loophole" in GPLv3 — under plain GPL, a company can run a modified GPL program on a server and never trigger the distribution clause that would force them to share their changes. AGPL says: if users interact with the program over a network, you must offer them the source.
For skills, AGPL has a specific resonance worth thinking about. Consider a skill that orchestrates code generation on customer infrastructure: it reads a prompt, generates a script, and the generated script runs in the customer's environment. The skill is the orchestrator; the generated code is the output. If you AGPL the skill, you're saying that anyone running the skill as part of a hosted product must publish their modifications to the skill itself — not the generated code, but the SKILL.md and any wrapper scripts.
This can be a sensible choice if you want to ensure that managed-Claude-Code platforms (the ones running on customer infra and selling "hosted SKILL.md authoring") contribute back. It's a hostile choice if you want maximum adoption.
Frontmatter: license: GPL-3.0-or-later or license: AGPL-3.0-or-later. The -or-later suffix matters — it lets future GPL versions apply automatically, which is generally what you want. The full text goes in LICENSE; it's about 35KB. If you're publishing under GPL, you should also know that you cannot incorporate Apache 2.0 code into a GPLv2 project (incompatibility), but Apache 2.0 is compatible with GPLv3.
You can publish a skill with no licence, or with an explicit proprietary licence. People do this. It almost never accomplishes what they want.
Here's the problem. A SKILL.md file is, by definition, the entire payload. There is no compiled artefact, no obfuscated binary, no API gate. The moment you publish the file — on GitHub, in an internal wiki, anywhere — every reader has the full source. Proprietary licensing on a SKILL.md is the legal equivalent of writing "do not read this" on the cover of a book that's open on every page.
The technical realities of how skills are distributed make enforcement nearly impossible. Catalogs mirror SKILL.md files to make discovery work. Users install skills by copying files to ~/.claude/skills/. Search engines index public repos. By the time you notice someone has reproduced your skill, the file has been copied to dozens of places, none of which you control.
The legitimate use cases for proprietary skills are:
~/.claude/skills/ on team machines, in a private internal mirror. "Proprietary" then just means "not published," which is a coherent posture.What does not work: publishing a SKILL.md to a public catalog with license: proprietary in the frontmatter and expecting people to respect it. They'll respect the spirit (won't fork it into a competing product) but the practical reach of that licence is approximately zero. Catalogs typically refuse to admit proprietary-licensed skills or admit them with no installable mirror, which defeats the point.
If you publish a skill at all, pick a real licence. The world is better off with your skill under MIT than gathering dust in a private repo because you couldn't bring yourself to pick something permissive.
One genuine middle ground worth mentioning: source-available licences like the Business Source License (BSL) or Polyform Shield. These let you restrict commercial use for a defined period (often four years) before automatically converting to a permissive licence. BSL is overkill for almost every skill, but if you're shipping a clever evaluation methodology that you'd like to commercialise for a couple of years before opening up, it's a coherent option. license: BUSL-1.1 is the SPDX identifier.
The license: field in your SKILL.md frontmatter is the machine-readable signal that catalogs and tools key off. It should always be an SPDX identifier — a short, standardised string from the Software Package Data Exchange registry.
The common ones for skills:
| SPDX ID | Licence | One-line summary |
|---|---|---|
MIT | MIT | Do anything, keep the copyright notice. |
Apache-2.0 | Apache 2.0 | MIT plus patent grant plus NOTICE. |
BSD-3-Clause | BSD 3-Clause | Like MIT but adds a no-endorsement clause. |
GPL-3.0-or-later | GPL v3+ | Derivatives must be GPL. |
AGPL-3.0-or-later | AGPL v3+ | GPL plus network-use is distribution. |
MPL-2.0 | Mozilla Public | File-level copyleft. Rarely used for skills. |
CC0-1.0 | CC0 | Public-domain dedication. No rights reserved. |
Unlicense | The Unlicense | Like CC0 but written differently. |
What catalogs do with this field:
license: field, or with license: proprietary or license: see LICENSE, often gets rejected by catalog admission pipelines because the licence terms can't be machine-read.A few specific gotchas:
license: "MIT OR Apache-2.0". This is common in the Rust ecosystem.license: LicenseRef-MyCustomLicense and ship the full text in LICENSE. Expect lower install rates — most filters reject anything they can't recognise.GPL-3.0-only means just version 3; GPL-3.0-or-later means version 3 or any future GPL. Pick deliberately.If you're using a frontmatter field reference, the license: entry sits alongside name:, description:, author:, and the other standard fields. See the frontmatter fields guide for the full schema; this section just covers the licence-specific behaviour.
The catalog has a mechanism called attribution overrides that exists because frontmatter doesn't always capture the full credit chain for a skill. It's worth understanding both as an author and as someone who might forge a derivative.
Here's the problem it solves. Imagine you publish a skill code-review-strict. The frontmatter has author: [email protected] because you're the maintainer. But the skill is actually a fork of someone else's code-review-basic, and you used a substantial chunk of their anti-trigger prose. You credit them in the body ("adapted from Acme Inc.'s original") but the catalog's machine-readable author field still says it's yours. Search and discovery treat the original author as invisible.
An attribution override is a small, hand-curated record that says: for this slug, also credit X with Y relationship. It's stored separately from the skill itself — typically in a catalog-maintained JSON file — and rendered in the skill's attribution section. Crucially, it survives upstream regeneration: if the catalog re-mines your skill tomorrow and your frontmatter still says author: [email protected], the override keeps adding the upstream credit.
When should you request an override on your own skill? Three scenarios cover most cases:
The mechanism is editorial, not paid. Catalogs don't charge for attribution overrides and don't use them as a promotional tool. The acceptance criteria are simple: the requested credit must be true (you can show the lineage), the upstream author must not have explicitly refused credit, and the override doesn't change ranking or visibility — only the displayed attribution.
From a derivative-author perspective: requesting an override on your own forked skill is the polite thing to do and takes about two minutes. From an upstream author perspective: if you see a fork that hasn't credited you, you can request an override be added to it. Catalogs generally honour these requests when the lineage is documented.
What an override does not do: it doesn't transfer copyright, it doesn't change the licence, it doesn't grant the upstream author any control over the fork's future direction. It's purely a credit mechanism. If the upstream licence required something stronger (e.g., GPL requires source-availability of derivatives), the override is a layer on top of those underlying obligations, not a substitute for them.
Most non-trivial skills are derivatives. Someone published cold-outreach-v1; you forked it, added the four-tier follow-up cadence your team uses, and shipped cold-outreach-team-v2. The mechanics of doing this properly aren't complicated, but they do involve more than just copying the file.
The chain-of-attribution every derivative skill should preserve:
source: or upstream: field, if present, points at where you forked from. This isn't standardised across all skill schemas, but most catalogs honour a source: https://github.com/upstream/repo field for lineage tracking.A useful frontmatter template for a fresh derivative:
---
name: cold-outreach-team-v2
description: Cold outreach with four-tier follow-up cadence...
license: MIT
author: [email protected]
source: https://github.com/upstream/cold-outreach-v1
based-on: cold-outreach-v1
---What counts as enough of a change to warrant a new name versus contributing back upstream? There's no rule, but a useful heuristic: if the upstream maintainer would accept your changes as a PR, send the PR instead of forking. Forking is the right move when your additions are opinionated (your team's specific cadence), domain-specific (medical-billing variant of a generic invoicing skill), or experimental (you're testing an unusual approach the upstream author doesn't want to commit to).
Two specific patterns to avoid. First, the silent fork: copying an MIT skill, removing the LICENSE file, and republishing under your own name. This is a licence violation even though MIT is permissive — the obligation to retain the copyright notice is the only thing MIT actually requires. Second, the licence-laundering fork: taking a GPL skill, rewriting the prose slightly, and publishing under MIT. Courts call this a derivative work; the GPL terms still apply.
If you genuinely want to write something inspired by a GPL skill without inheriting its licence, the safe path is a clean-room reimplementation: read the GPL skill, write down what it does in plain English, hand that description to someone who hasn't read the original, and have them write a fresh skill. Tedious, but it's the only path that survives legal scrutiny.
Many skills today contain prose that was drafted by Claude or another model. The frontmatter you wrote yourself; the anti-trigger paragraphs you might have asked the model to draft and then edited. What licence governs that AI-drafted content?
The current consensus, as of mid-2026, is roughly: AI-generated text is treated as authored by the human who prompted, edited, and curated it, with caveats. The US Copyright Office has consistently held that purely AI-generated works (no human creative input beyond the prompt) are not copyrightable. Works with meaningful human curation, editing, and selection are copyrightable in the human-contributed portions. Other jurisdictions differ — the UK has a separate "computer-generated works" provision that's friendlier to authorship claims; the EU is still working through the AI Act implications.
The practical implications for SKILL.md authors:
Practical advice: treat AI-drafted prose the same way you'd treat prose you wrote yourself with heavy editing assistance from a friend. Licence the skill under MIT or Apache 2.0; you're the human author; the AI was a tool. Don't claim AI-drafted material as wholly original creative work in any context where that matters (academic publication, art-prize submissions); for software-tool authorship, the framing is uncontroversial.
One area genuinely in flux: training data licensing. There's an emerging norm — pushed by groups like the Generative AI Code License framework — to add a frontmatter field declaring whether the skill author consents to the skill being used as training data for future models. This is not yet standardised, and most catalogs don't surface it, but if you have strong feelings either way, you can add training-consent: yes or training-consent: no to your frontmatter. Treat it as a signal, not a binding contract.
If you're publishing a skill in the next hour and you don't want to think about any of this further, here's the answer.
Use MIT. Put this in your frontmatter:
---
name: your-skill-name
description: One sentence about what the skill does.
author: [email protected]
license: MIT
---Drop this LICENSE file next to your SKILL.md:
MIT License
Copyright (c) 2026 Your Name
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject
to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.That's the whole decision. MIT is the right answer for solo authors, for hobby skills, for skills you might want a company to adopt later, for skills that started life as a draft from Claude and got heavily edited, for almost everything.
Deviate from MIT only if one of these applies:
One last thing: licences are not forever. You can relicense your own work whenever you want, as long as you have the rights to do so (i.e., no contributors with code under the old licence who haven't agreed to the change). If you publish under MIT today and decide in two years that Apache 2.0 fits better, bump the frontmatter, update the LICENSE file, and explain the change in your next release notes. The old MIT-licensed versions are still MIT-licensed forever; the new versions are Apache. Both can coexist.
Publishing a skill with a clear licence is one of the cheapest, highest-leverage things you can do for the next person who reads it. Pick MIT. Move on. Get back to writing the actual skill.
Found a bug or want a topic covered? Email [email protected] or open an issue via GitHub.
SKILL.md files, not affiliated with, endorsed by, or sponsored by Anthropic.