What is Source-Available licensing, and how does it differ from open source?
Source-available refers to a category of licensing where the source code is published somewhere visible — anyone can read it and reference the implementation logic — but this doesn't carry the full set of rights implied by an open source license. The Open Source Initiative's (OSI) definition of "open source" requires a license to permit free redistribution and place no restrictions on commercial use. Source-available licenses typically attach a field-of-use limitation instead — for example, permitting the code only for learning and reference, prohibiting it from being bundled into a product you distribute externally, or banning specific commercial uses.
What makes these two easiest to confuse is that the distribution channels look identical — source-available code is often hosted on the same platforms as open source projects, like GitHub, and looks and behaves much like an open source project on the surface. This is exactly why this license category demands extra attention to the specific terms — you can't assume you have the rights that come with open source licensing just because "the source code is visible."
Why does Source-Available licensing exist, and what problem does it solve?
This license category's emergence, to some extent, fills a middle ground between fully open source and fully closed. Some companies want to publish source code so developers can study, review, and even test it in their own environment — building trust and drawing in a developer community — without wanting a competitor to directly repackage that code into a competing product, or a cloud provider to spin it up as a paid service for resale without authorization. This concern — open-source code getting monetized by someone else while the original author sees none of the return — is part of the backdrop behind the rise of source-available licensing.
For a technical resource like a Claude Skill, choosing to publish complex Skills that are actually running in a production product as source-available strikes a middle path between two extremes: "not published at all, developers can only guess at the underlying logic" versus "fully open source, anyone can directly turn it into a competing product." It lets developers see and learn from the implementation, without meaning it can be repackaged and redistributed without limit.
What does Source-Available licensing actually look like in practice?
Take Anthropic's official anthropics/skills repository as an example: the docx, pdf, pptx, and xlsx document-processing Skills are explicitly labeled source-available, distinguished from the repo's other example-style Skills that use Apache 2.0 (a standard open source license). The official documentation states these Skills are published so developers can "reference how to write more complex Skills," but attaches a clear disclaimer alongside that: these Skills are for demonstration and educational purposes only, Claude's actual product behavior may not fully match the implementations shown here, and thorough testing in your own environment is required before use.
In practice, judging whether a piece of source-available code can be used in your scenario isn't about where it's hosted (looking identical to an open source project on GitHub) — it's about carefully reading the license's use-scope restrictions. Studying and learning from it is usually fine, but if you're planning to bundle the code, verbatim or lightly modified, into a product you intend to distribute externally or commercialize, you need to confirm first whether the terms actually permit that.
I see a technical resource labeled Source-Available — what should I confirm before using it?
The first step is finding the explicit license statement — don't draw a conclusion from the surface fact that "the source code is public" alone. This kind of statement usually appears in the repo's README, a LICENSE file, or official documentation. The second step is confirming which category your intended use falls into: pure reading and learning, testing in your own internal environment, or planning to integrate it into a product you'll distribute externally — these three uses are frequently treated differently under source-available licensing, with the first two usually fine and the third the one most likely to run into restrictions.
Third, if the same repository mixes different licenses (say, some Skills under Apache 2.0 open source and others source-available), be sure to confirm exactly which license applies to the specific item you want to use, rather than assuming the whole repo follows one set of rules just because it looks generally open — which is precisely the situation that actually exists in Anthropic's own official repository, as noted at the start of this entry.
Anthropic's official anthropics/skills repository is a concrete case in point: creative demonstration Skills in the repo like algorithmic-art and canvas-design use an Apache 2.0 open source license and can be freely reused, while the four Skills actually powering Claude's built-in document generation capability — docx, pdf, pptx, and xlsx — are explicitly labeled source-available. Same repository, publicly hosted on the same GitHub, yet governed by two different sets of license rules — exactly why you can't assume every piece of code in a repo is freely usable just because "the repo is public."
The advantage is letting a company publish complex code actually used in a production product, benefiting the developer community with learning and reference material, while still protecting its commercial interests; the drawback is that this middle ground between open and closed is inherently prone to users misjudging the scope of rights they actually have — easy to mistake "can view" for "can use" without extra care, requiring additional time to confirm license terms rather than operating on the intuition typically applied to an ordinary open source project.