Skill licensing and attribution

[olaservo]

The SKILL.md spec defines an optional license: frontmatter field. Since agent skills are often a combination of knowledge, instructions, and code it would be useful to add guidance around:

• Choosing a license to use when authoring agent skills
• How skill consumers should attribute the skills used to influence a given output from an agent, depending on the license details

More specifically:

• Creative Commons licensing such as "CC BY 4.0" could be a good default to recommend for the SKILL.md file and other prose/documents included in the skill.
• For skills with executable bundles that are a hybrid artifact with prose plus optional files like scripts/ (code-shaped), a hybrid license could be used, which is often used for libraries and docs sites that combine code and docs. For example "MIT AND CC-BY-4.0"
• Creative Commons explicitly recommends against using CC for software, so hybrid licenses could either use a format like license: Apache-2.0 (code) + CC-BY-4.0 (docs) in the frontmatter, or defer to bundled files (license: See LICENSE.txt)

Attribution is also an interesting related problem:

• The basic lifecycle of a skill is that an agent loads the skill, internalizes the knowledge in its context window, and emits output to an end user.
• Agents might parse the optional skill metadata such as the author, or the license, but don't surface any of this in their outputs when the skill is used.
• Unless the agent surfaces authorship, there is no attribution chain at all, regardless of what the license requires.

tldr; lets make it more clear how licenses should be defined and how they should be cited or attributed by skill consumers. This lays a better foundation for giving authors credit (and a foundation for future compensation models).

(Credit to this blog post and the AI Disclosures project for inspiring this topic!)

[jonathanhefner]

My personal take is that the license field is superfluous. I think using a combination of README.md and/or LICENSE.txt (just like pre-AI open-source does) is sufficient. I would be very interested to hear about cases where the license field provides more value though!

• Unless the agent surfaces authorship, there is no attribution chain at all, regardless of what the license requires.

What is this motivation in this use case? Or, in other words, why would attribution be necessary when using a skill?

[olaservo]

My personal take is that the license field is superfluous. I think using a combination of README.md and/or LICENSE.txt (just like pre-AI open-source does) is sufficient.

Yes, I can see just the LICENSE.txt file being totally sufficient (and discoverable) vs. really needing the field. To me the main concern is knowing where to find the license info in a consistent way, which LICENSE.txt could already solve for.

What is this motivation in this use case? Or, in other words, why would attribution be necessary when using a skill?

My motivation is mostly aspirational at this point. A few things I was thinking about:

• knowing that an output was based on skill X from author Y lets someone judge how much to trust it
• in general, it lets a skill get traced back to its source
• it's also something that a future compensation model could build on

What makes me want to raise this for skills specifically is that attribution for inference time content could easily be trackable in a consistent way for skills, given that they already have a simple standardized structure and retrieval/activation patterns. Harnesses don't surface any of that in derived outputs yet, but I think they could in the future if the source metadata was reliable enough.

[IsmaelMartinez]

Picking up the "why would attribution matter" question, there's a related need that's separate from credit or licensing: provenance for freshness.

A lot of skills aren't original prose, they distil an upstream source of truth (an ADR, an RFC, a standards page). When that upstream changes, the skill silently goes stale and nothing in the format records where its knowledge came from. We run this in production today: each skill declares its upstream document plus a ref, and a scheduled job flags when the upstream has moved so the skill can be refreshed.

That's distinct from provenance-for-credit (this thread) and provenance-for-integrity (the signing/digest work in #358 and #418). Is there appetite for a small optional convention to declare a skill's upstream sources? Happy to share what we run as prior art if useful.

[olaservo]

Hi @IsmaelMartinez that makes sense to me and has come to mind too. Would love to hear more about your prior work on this!

[IsmaelMartinez]

Glad it resonates; what we run in production today is registry-scoped: a single source map at the repo root records each skill's upstream document(s) plus a ref or last-reviewed marker, and a scheduled job compares the upstream's current ref against that marker and opens a change request when they diverge, so the declaration and the drift engine stay cleanly separate. The piece worth standardising is just the declaration, ideally one that travels with the skill rather than sitting in a root manifest like ours, most naturally a small optional namespaced block under metadata (pending the richer-value question in #211) or an optional per-skill sidecar file if people prefer structured values today, with drift and refresh left to tooling. I'd be happy to write this up with a sanitised prior-art example, kept distinct from the integrity (#358/#418) and dependency-pinning (#226/#210) work; would you rather keep it on this thread, or should I open an Ideas discussion for it?