Source-Available（ソース公開）とは何ですか？オープンソースとどう違いますか？
Source-Availableとは、あるカテゴリのライセンス方式を指す。ソースコードは閲覧できる場所に公開されており、誰でも読んで実装ロジックを参考にできるが、これはオープンソースライセンス（Open Source License）が暗に含む完全な権利とは異なる。Open Source Initiative（OSI）による「オープンソース」の定義では、ライセンスが自由な再配布を許可し、商業利用を制限しないことが求められる。一方Source-Availableライセンスは通常、「使用範囲制限」（field-of-use limitation）を付加する——例えば学習・参考目的にのみ使用を許可し、外部配布する自社製品への組み込みを禁止したり、特定の商業利用を禁じたりする。
両者が最も混同されやすい点は、配布チャネルがまったく同じであることだ——Source-Availableのコードは、オープンソースプロジェクトと同じくGitHubなどのプラットフォームに置かれることが多く、見た目も使い方もオープンソースプロジェクトによく似ている。これこそ、この種のライセンスで条項の細部に特に注意を払う必要がある理由であり、「ソースコードが見える」というだけで、オープンソースライセンスに付随する権利を自分が持っていると単純に仮定してはならない。
Source-Availableライセンスはなぜ存在するのですか？どんな問題を解決していますか？
この種のライセンスの登場は、ある程度「完全なオープンソース」と「完全な非公開」の間の中間地帯を埋めるためのものだ。企業の中には、開発者が学び、精査し、あるいは自分の環境でテストできるようにソースコードを公開し、それによって信頼を築き開発者コミュニティの参加を促したいと考える一方で、競合他社がそのコードをそのまま競合製品にパッケージ化したり、クラウドサービス事業者が無許可でそれを使って有料サービスを立ち上げ転売したりすることは望まない企業もある。「オープンソースコードが他者に収益化される一方で、元の作者には見返りがない」というこの懸念こそ、Source-Availableのようなライセンスモデルが台頭してきた背景の一部だ。
Claude Skillのような技術リソースについて言えば、実際の製品で稼働している複雑なSkillをSource-Availableとして公開するという公式の選択は、「まったく公開せず、開発者は基盤ロジックを推測するしかない」ことと「完全にオープンソースで、誰でもそのまま競合製品を作れる」という二つの極端の間で、折衷案を選んだことを意味する。開発者は実装を見て学べるが、無制限に再パッケージ化して配布できるわけではない。
Source-Availableライセンスは実際にはどのように機能しますか？
Anthropic公式のanthropics/skillsリポジトリを例にとると、docx、pdf、pptx、xlsxという4つの文書処理Skillは明確にSource-Availableとラベル付けされており、リポジトリ内のApache 2.0（標準的なオープンソースライセンス）を採用する他の例示的なSkillとは区別されている。公式の説明では、これらのSkillを公開する目的は開発者が「より複雑なSkillの書き方を参考にする」ためだとしつつ、明確な免責事項も付記されている：これらのSkillはデモンストレーションと教育目的のみであり、Claude製品での実際の動作はここで示されている実装と完全には一致しない可能性があり、使用前には必ず自分の環境で十分にテストすることが求められる。
実務上、あるSource-Availableのコードが自分の用途で使えるかどうかを判断する鍵は、それがどこに置かれているか（GitHub上でオープンソースプロジェクトと同じように見える）ではなく、ライセンス条項の使用範囲制限を注意深く読むことにある。研究・学習目的であれば通常問題はないが、コードをそのまま、あるいは軽微な修正を加えて、外部配布や商業化を予定している自社製品に組み込むつもりなら、条項がそこまでの範囲を許可しているかを事前に必ず確認する必要がある。
あるSource-Available表示の技術リソースを見つけた場合、使用前に何を確認すべきですか？
第一のステップは、明確なライセンス説明文を見つけることだ。「ソースコードが公開されている」という表面的な事実だけで結論を出してはいけない——通常この種の説明はリポジトリのREADME、LICENSEファイル、あるいは公式ドキュメントに記載されている。第二のステップは、自分の用途がどのカテゴリに該当するかを具体的に確認することだ。純粋な閲覧・学習、自社内部環境でのテスト、あるいは外部配布する製品への組み込みという三つの用途は、Source-Availableライセンスの下でしばしば区別して扱われ、前二者は通常問題ないが、三つ目が最も制限条項に抵触しやすい。
第三に、同じリポジトリ内に異なるライセンスが混在している場合（例えば一部のSkillはApache 2.0のオープンソース、一部はSource-Availableなど）、使用したい項目に具体的にどのライセンスが適用されるかを一つずつ確認することが不可欠だ。リポジトリ全体が開放的に見えるからといって、すべての内容に同じルールが適用されると仮定してはならない——これはまさに本項目冒頭で触れた、Anthropic公式リポジトリで実際に起きている状況である。
Anthropic公式のanthropics/skillsリポジトリは具体的な事例だ。リポジトリ内のalgorithmic-artやcanvas-designといった創作デモンストレーション系Skillはapache 2.0のオープンソースライセンスを採用しており、自由に再利用できる。しかし、Claudeの組み込み文書生成能力を実際に支えているdocx、pdf、pptx、xlsxという4つのSkillは、明確にSource-Availableとラベル付けされている。同じリポジトリで、同じようにGitHub上に公開されているにもかかわらず、二つの異なるライセンスルールが適用されている——これこそ「このリポジトリは公開されている」というだけで、中のすべてのコードが自由に使用できると仮定してはならない理由だ。
利点は、企業が商業的利益を保護しながら、実際の製品で使われている複雑なコードを公開でき、開発者コミュニティが学習と参照の恩恵を受けられることだ。欠点は、このオープンとクローズの中間に位置するグレーゾーンが、ユーザーが自分の持つ権利の範囲を誤判断しやすい性質を本質的に持っている点で、うっかり「見られる」を「使える」と誤解しやすく、通常のオープンソースプロジェクトに対する直感で操作するのではなく、ライセンス条項の細部を確認する余分な時間が必要になる。