What License Do Agent Skills Use?

The Licensing Gap Nobody Talks About

You assume that because a skill is free, you can use it freely. In reality, the legal default is far more restrictive.

The official Agent Skills specification defines a license field in the SKILL.md frontmatter, but it is explicitly optional. This means skills are not required to declare their terms. When no license is present, the legal default becomes "all rights reserved."

This creates a significant risk for businesses adopting these tools. A missing license does not mean the content is public domain. It means you have no explicit permission to use, modify, or distribute the skill. For enterprise users, this is a major compliance gap.

Consider the implications of this ambiguity in a professional workflow:

• Legal uncertainty prevents teams from confidently integrating skills into production environments.
• Missing license metadata breaks the chain of attribution, making it impossible to verify source rights.
• Security vetting guides flag missing licenses as a "medium risk" indicator, pausing the adoption process.

The ecosystem currently relies on permissive licenses like MIT and Apache-2.0, which are considered the norm for skills. However, the absence of a mandatory standard means many skills ship without any declaration at all. This lack of transparency complicates the vetting process for developers and business managers alike.

Furthermore, agents do not currently surface authorship or license metadata in their outputs. This results in a broken attribution chain, regardless of the license terms used. Even if a skill requires attribution, the agent does not disclose which skill influenced its output, leaving users in the dark about their legal obligations.

This gap highlights why license verification is a critical component of skill security. Without clear terms, users cannot determine if they are legally allowed to use a skill in a commercial context. The ambiguity extends beyond just code; skills often contain instructional content that may require different licensing protections, such as Creative Commons Attribution.

As the agent skills ecosystem matures, the need for standardized licensing practices becomes increasingly urgent. Teams must look beyond simple functionality checks to understand the legal landscape of the tools they deploy. Ignoring these details can lead to unexpected legal liabilities and operational disruptions.

SkillzBench is building a free directory and MCP tool designed to address these gaps by verifying license declarations and security standards before you adopt a skill. By continuously crawling and deduping skills, the platform aims to provide the clarity that the current specification lacks. This approach ensures that every skill you equip comes with a known legal status and verified quality.

Until these standards are universal, the burden of proof falls on the user. You must verify that a skill’s license aligns with your business needs before integrating it into your agent’s workflow. This diligence is not just a technical requirement; it is a fundamental aspect of responsible AI adoption.

The current state of flux means that "free" does not always mean "safe to use." Understanding the distinction between an open-source license and a proprietary asset is essential for any organization looking to leverage AI agents effectively. The gap in declared licensing is a silent but powerful barrier to trust in the agent skills ecosystem.

MIT and Apache-2.0: The De Facto Norm

Nobody handed the agent skills ecosystem a license rulebook. The official Agent Skills specification defines a license field in SKILL.md frontmatter, but marks it as optional — skills can declare open-source terms, proprietary ones, or nothing at all. Into that vacuum, two permissive licenses stepped forward and became the default.

In practice, MIT and Apache-2.0 are the norm for agent skills, according to security vetting guides that treat unusual or missing licenses as risk flags. The specification itself uses Apache-2.0 as its primary example for the license field, and MIT is generally the most widely used license on GitHub, so both arrived with strong existing momentum. When Tencent's SkillHub mirrored 25,000 MIT-licensed skills from ClawHub, it demonstrated just how large the permissively licensed ecosystem had become — legally compliant, but controversial.

So what's the practical difference between the two? Both let anyone use, modify, and redistribute your skill, including in commercial products, with minimal strings attached. The distinctions matter mostly at the edges:

• Attribution: MIT requires only that the license text accompany copies. Apache-2.0 adds a requirement to notice and preserve changes, plus explicit NOTICE file mechanics.
• Patent protection: Apache-2.0 includes an express patent grant, protecting users from contributors suing over patents. MIT is silent on patents, leaving a small legal gap.
• Length and complexity: MIT is a few short paragraphs; Apache-2.0 runs several pages with defined terms and conditions.

Why did permissive licenses win in a spec that never mandated one? Skills live on GitHub, where permissive licensing is already the cultural default, and skill authors want adoption — the same instinct that drives open-source libraries. A restrictive license would limit how many agents and platforms can carry a skill, and adoption is the whole point. Permissive terms also align with how skill authors see themselves: sharing useful knowledge, not selling software.

But the norm has cracks. Critics argue MIT was designed for source code, while skills are often closer to documentation, methodology, or instructional content — and MIT doesn't require attribution in agent outputs, since agents don't currently surface which skill influenced a response. That's why community discussions now propose hybrid declarations like "MIT AND CC-BY-4.0" to cover both the code and the prose.

For anyone adopting skills, the bigger risk isn't choosing between MIT and Apache-2.0 — it's the missing license. A skill with no declared license defaults to "all rights reserved," meaning you can't legally confirm your right to use it at all. That's why SkillzBench is building a license-check into its Verify process: every skill it crawls from GitHub gets its licensing validated alongside security scanning, and skills without declared terms get flagged rather than assumed safe. Licensing is one signal feeding the 0-100 trust score; how much a skill actually lifts your agent's performance is benchmarked and shown separately.

Permissive licensing won by default, not by decree. Knowing that — and knowing where the defaults fall short — puts you ahead of most of the market.

Skills, proven. Join the SkillzBench waitlist to get license-checked, security-scanned, benchmarked skills the moment we launch — free, always.

The Code vs. Content Debate and the Tencent Precedent

When Tencent's SkillHub mirrored 25,000 MIT-licensed skills from ClawHub, it did nothing illegal. That's exactly the problem.

MIT was written for source code. Many agent skills, though, are closer to documentation, methodology, or instructional content — well-researched how-to guides distilled into a SKILL.md package. Applying a code-centric license to what is essentially knowledge work creates a gap between what creators imagined they were sharing and what the license actually permits in the hands of a major corporation, a gap analysts have called significant.

The Tencent mirror made that gap concrete. Under MIT, SkillHub could legally copy, rehost, and build services on top of tens of thousands of community-created skills without contributing anything back. The move was fully compliant — and it still sparked a debate about whether permissive licensing enables value extraction without contribution, challenging the implicit assumption that open skills exist for community benefit rather than corporate aggregation.

This is why some in the community argue MIT is the wrong tool for the job. Alternatives being discussed include:

• Creative Commons Attribution (CC BY), which requires attribution and better fits instructional prose
• Hybrid declarations such as "MIT AND CC-BY-4.0," applying different licenses to code and documentation within the same skill
• Business Source Licenses (BSL), which restrict commercial use for a period — typically around four years — before converting to full open source

The proposal for hybrid licensing comes from a real structural problem: skills combine knowledge, instructions, and code, and a single license rarely fits all three. Others counter that the license field in SKILL.md frontmatter is superfluous entirely, since a standard LICENSE.txt file does the job — a reminder that even the mechanics of declaring a license remain unsettled.

There's a deeper wrinkle, too. Agents currently internalize skill knowledge without surfacing authorship or license metadata in their outputs, so even an attribution-requiring license has no practical attribution chain today. The person reading the agent's answer never learns which skill shaped it.

For anyone adopting skills in a business context, the takeaway is that "MIT" doesn't mean "risk-free" — it means "anything goes, including aggregation you didn't intend." It's one reason SkillzBench, which is building license-checking into its free skills directory, treats license signals as part of trust rather than an afterthought. Knowing what a skill's license actually permits — and what it doesn't — is now part of due diligence, not legal trivia.

The Attribution Gap in Agent Outputs

Even if every agent skill shipped with a crystal-clear license, there's a deeper problem: the agent never tells you which skill it used. When Claude Code or Cursor draws on a skill to produce an answer, the output carries no authorship, no license notice, no provenance — just a polished result that appears from nowhere.

This is what community discussions call the broken attribution chain. As a GitHub discussion on the Agent Skills specification notes, agents internalize skill knowledge but do not surface authorship or license metadata in their outputs. The consequence is stark: even a license like CC BY, which explicitly requires attribution, becomes practically unenforceable when no downstream user ever sees the connection between an output and the skill that shaped it.

The problem compounds because licensing itself is optional. The official specification marks the license field in SKILL.md frontmatter as optional, and security vetting guides warn that a missing license defaults to "all rights reserved," creating legal uncertainty for anyone using the skill commercially. Meanwhile, the visible metadata gap extends to major directories — the widely referenced awesome-agent-skills catalog contains no explicit license information in its listings.

Why does this matter for the licensing debate itself? Because it exposes a flaw in the "just use MIT" argument:

• MIT requires preserving a copyright notice in copies of the software — but an agent's output is not a "copy" anyone distributes, so the notice vanishes.
• Attribution-based licenses like CC BY depend on a visible chain from creator to end user, which agents currently break.
• The Tencent SkillHub incident — 25,000 MIT-licensed skills mirrored from ClawHub — showed how permissive terms enable large-scale extraction without contribution, even when fully legal.

This is why some community voices argue the license choice is almost secondary to the plumbing. One contributor to the specification discussion, olaservo, proposes hybrid declarations such as "MIT AND CC-BY-4.0" — MIT covering the executable code, Creative Commons covering the instructional prose — precisely so that the content component carries attribution obligations that survive beyond the code itself.

Until agents surface provenance natively, the burden falls on tooling. SkillzBench is being built to close exactly this gap: its verification process is designed to license-check every skill it indexes and pin each one to a commit SHA, so the attribution chain exists on the directory side even when the agent stays silent. For teams adopting agent skills in production workflows, that external record may soon be the only reliable answer to "whose work is this, and under what terms?"

How to Vet Skill Licenses Before You Use Them

You found a promising skill in a GitHub repo — but do you actually have the right to use it? Before you load anything into your agent, a two-minute license check can save you from real legal headaches later.

Start by looking for a license declaration in two places: the license field in the SKILL.md frontmatter and a LICENSE.txt file in the repository root. The official Agent Skills specification makes this field optional, so many skills simply won't have one. When that happens, copyright law defaults to "all rights reserved" — meaning you have no confirmed legal right to use the skill at all, according to security vetting guidance.

Treat a missing license as a warning, not a technicality. Security reviewers flag absent licenses as a medium-risk signal because usage rights are unclear, and deviations from permissive norms like MIT or Apache-2.0 should pause your evaluation entirely.

Here is a quick vetting checklist before you adopt any skill:

• Check the SKILL.md frontmatter for a `license` field, and confirm a LICENSE.txt exists in the repo.
• Note whether the license is permissive (MIT, Apache-2.0) or unusual — unusual choices deserve a closer look.
• Watch for hybrid declarations like "MIT AND CC-BY-4.0," which some contributors now propose for skills that mix code with instructional content.
• Remember that "free to download" is not the same as "free to use commercially."

That last point matters more than most teams realize. Even under permissive licenses, corporate extraction can be legally compliant yet ethically contested — when Tencent mirrored 25,000 MIT-licensed skills into its SkillHub, it sparked debate about value extraction without giving back, as one analysis noted. And licensing is only one risk surface: research has found roughly 26% of skills carry at least one vulnerability, so a clean LICENSE.txt tells you nothing about code safety.

Doing this manually for every skill gets tedious fast. SkillzBench is building automated license-checking into its verification pipeline, so every skill in its directory gets scanned for license declarations and flagged when legal rights are unclear — feeding directly into a 0–100 Trust Score alongside security, quality, maintenance, and community signals. It is the same checklist above, run automatically on every version, pinned to a commit SHA so the license you vetted is the license you get.