GitHubのコードを商用製品に使う：ライセンスと確認事項

寛容型ライセンスのMIT、Apache、BSD、コピーレフトのGPL/AGPL、LICENSEファイルがない場合、AIが追加したコードの出所の確認について。

記事の全文を読む

製品を作っていると、GitHubで既製のコードを見つけることがあります。ライブラリ、テンプレート、必要な機能をそのまま実現するプロジェクト全体などです。Claudeがそれを自分のプロジェクトに取り込むよう提案します。そこで手が止まります。コードは公開されているように見えますが、本当に使えるのでしょうか。まして、それを含む製品を販売できるのでしょうか。後になって作者から訴えられる可能性はないでしょうか。

順を追って説明します。GitHub上のオープンなコードが、それだけで利用許可を意味するわけではない理由、コードを使って製品を販売できるライセンス、対象の著作物の対応ソースを必要とする場合があるコピーレフト条件、そしてコードを使う前に1分でライセンスを確認する方法です。「状況によります」とは言いません。

Ailootの利用に関する実用的な情報はドキュメントにあります。

注意

この記事は参考情報であり、私は弁護士ではありません。以下では、一般的なライセンスや規則の条件を一次情報へのリンクとともに説明しますが、個別の状況はライセンス本文に照らして確認し、製品の規模が大きく商業目的の場合は弁護士にも相談してください。判断はご自身で行ってください。

GitHub上のコードなら無料で使えるというのは本当？

重要なポイント

いいえ。コードを閲覧できるからといって、自分の仕事で使うことが許可されているわけではありません。原則として、すべてのコードは著作権で保護されており、作者が別途許可していない限り、使用することはできません。GitHubに公開することで他の人に認められるのは、リポジトリを閲覧し、GitHub内でコピーを作ることだけです。そのコードを自分の製品に組み込む権利は、作者がリポジトリに付与したライセンスから得られます。GitHub自体がその権利を与えるわけではありません。

ここでの主な落とし穴は、「オープン」という言葉です。ソースコードが見えるので、隠されていない以上、使ってよいように思えてしまいます。しかし、その考え方は誤りです。「閲覧できること」と「利用を許諾されていること」は別です。

コードを含むあらゆる創作物は、作成された時点で原則として著作権により保護されます。作者が明示的に許可するまでは、使用できません。GitHubは、自らのライセンス解説ページでそう説明しています。

創作物を作成すると（コードも創作物です）、原則として排他的な著作権によって保護されます。別段の定めがあるライセンスを付与しない限り、他の人があなたの著作物をコピー、配布、改変すれば、権利侵害の申し立てや訴訟を受けるおそれがあります。

— choosealicense.com (GitHubの参照プロジェクト), https://choosealicense.com/no-permission/

もう一つの層はGitHub自体です。コードを公開したことでGitHubの規約に同意したのだから、そこにある他人のコードも使えると思う人がいます。規約には、まったく逆のことが書かれています。リポジトリを公開すると、作者が他の人に認めるのは閲覧とフォーク、つまりGitHub内でコピーを作成することだけです。自分の仕事でそのコードを使う許可にはなりません。

リポジトリを公開することで、あなたは他のユーザーに対し、GitHubの機能の範囲内で、サービスを通じてあなたの素材を使用、表示、複製（フォークによる）する非独占的かつ全世界的なライセンスを付与します。ライセンスを添付することで、追加の権利を付与できます。

— GitHub利用規約、セクションD、https://docs.github.com/en/site-policy/github-terms/github-terms-of-service

重要なのは最後の文にある「GitHubの機能の範囲内」と「追加の権利はライセンスから得られる」という言葉です。フォークはGitHub内にとどまります。コードを自分の製品で使う、まして販売するとなれば、作者から別途ライセンスを得る必要があります。ライセンスがなければ権利もありません。コードが目の前で公開されていても同じです。

他人のコードを使えるかどうかは何で決まる？

重要なポイント

リポジトリ内のライセンスファイルで決まります。通常はLICENSEまたはLICENSE.mdという名前です。これは作者が与える許可で、コードについて何ができて何ができないかを定めています。ライセンスで確認するのは、商用製品でコードを使えるか、改変できるか、自分のソースコードを非公開にしておけるかという3点です。ライセンスによって答えは異なるため、まずこのファイルを確認し、それからコード自体を開いてください。

要点は一つのファイルに集約されています。適切に管理されたリポジトリにはライセンスファイルがあり、通常はLICENSE、場合によってはLICENSE.mdという名前か、READMEに直接記載されています。これは作者の許可で、コードを使える条件を定めています。GitHubでは通常、ファイルを開く前でもリポジトリページのサイドバーにライセンス名が表示されます。

法律用語に迷わないように、自分の状況について次の3つの問いからライセンスを読むとよいでしょう。

料金を支払う人がいる商用製品で、このコードを使えるか？
自分の必要に合わせてコードを改変できるか？
その後、自分の製品のソースコードを公開しなければならないか、それとも非公開のままにできるか？

ライセンス間の違いのほとんどは、3つ目の問いへの答えにあります。最初の2つについては、一般的なオープンライセンスはたいてい「はい」です。使う、改変する、販売する。つまずきやすいのは、ライセンスによって自分のコードまで公開させられるかどうかです。次に、この3つの問いに沿って主な種類を見ていきます。

コードを使って製品を販売できるライセンスは？

重要なポイント

商用製品に最も使いやすいのは、寛容型ライセンスです。MIT、Apache 2.0、BSDが該当します。コードの使用や改変、製品の販売、自分のソースコードの非公開を含め、ほとんどすべてが認められています。義務は一つあり、ライセンス本文と著作者表示を残す必要があります。Apache 2.0はさらに、特許請求からの保護を定め、改変したファイルへの表示を求めます。他人のコードにこのいずれかのライセンスが付いていれば、商用製品で安心して使えます。

まずは良い知らせから始めましょう。販売する製品を作る人にとって最適なのは、寛容型ライセンスと呼ばれるライセンス群です。いくつかありますが、特によく使われるのはMIT、Apache 2.0、BSDの3つです。いずれも最初の2つの問いに「はい」と答え、自分のソースコードを非公開にしておけます。

最も一般的で単純なのはMITです。ライセンス本文は一段落に収まります。

本ソフトウェアの複製を入手するすべての人に対し、上記の著作権表示と本許諾表示をすべての複製に含めることを条件として、本ソフトウェアを制限なく使用する権利（使用、複製、改変、結合、公開、配布、サブライセンスの付与、販売を含む）を無償で許諾します。

— MITライセンス、opensource.org、https://opensource.org/license/mit

簡単に言えば、MITは製品の販売や自分のソースコードの非公開を含め、コードをほぼ自由に使えるようにします。唯一の義務は、ライセンス本文と著作者表示を含めることです。たとえばBabel、.NET、RailsはMITで公開されているため、皆さんもすでにこのライセンスのコードを使ったことがあるでしょう。

Apache 2.0も同様ですが、重要な点が2つ加わります。第一に、特許請求に対する明示的な保護です。コードの作者は、このコードに関する特許を理由にあなたを訴えないと約束します。第二に、利用にあたっての形式的な要件がいくつか増えます。

ライセンスの複製を受領者に渡し、改変したファイルに印を付け、著作権および特許に関する表示を保持し、NOTICEファイルがある場合はその内容を読み取り可能な形で複製して含めることを条件として、改変の有無を問わず、あらゆる媒体で本著作物または派生著作物の複製を作成し、配布できます。

— Apache License 2.0、セクション4、https://www.apache.org/licenses/LICENSE-2.0

BSD（2条項版と3条項版）も基本的にMITと同様です。使用、改変、販売ができ、著作権表示を残します。違いが一目でわかるように、3つを表にまとめました。

ライセンス	製品の販売	ソースコードを非公開にできるか	必要な対応	特許保護
MIT	はい	はい	著作権表示とライセンス本文を残す	条項なし
Apache 2.0	はい	はい	著作権表示、NOTICEファイル、改変箇所の表示	あり
BSD（2条項版と3条項版）	はい	はい	著作権表示を残す	なし

自分で使う場合は、こう読み取れます。他人のコードにMIT、Apache 2.0、BSDのいずれかが表示されていれば、安心して構いません。商用製品で使い、改変し、自分のソースコードを非公開にしておけます。取り込んだ部分からライセンスファイルと著作者表示を削除しないようにしてください。

GPLとAGPLのソース提供義務はどう適用されるか？

要点

GPLもAGPLも商用利用を認めます。GPLのソース義務は対象の著作物を渡す場合に生じ、コピーを渡さない通常のサーバー利用はその契機ではありません。AGPLv3は改変版へ遠隔接続する利用者へのソース提供案内を加えます。どの結合作品が対象かを確認し、別々の独立部品すべてが自動的に対象とは考えません。

コピーレフトは、条件が適用される場合に、対象の著作物と派生物を同じライセンスで保ちます。GPLv3では、対象・結合された派生著作物のソースやバイナリのコピーを配布する場合、ライセンスと対応ソースの義務に従います。同じ製品やサーバー上の独立プログラムすべてに自動適用はされません。

ウェブサービスでGPLライブラリをホストし、利用者へコピーを渡さないだけなら、全サービスの公開が必要とはいえません。対象の結合アプリを顧客へ配布する場合は義務が生じえます。統合方法とライセンスを確認して、添付すべきソースを判断してください。利用者へ送るブラウザークライアントは、別の配布上の問題です。

AGPLv3は、プログラムを改変し、その版を利用者が遠隔ネットワークで使う場合、対応ソースを目立つ形で提供する条件を加えます。単にAGPL部品をホストすると、独立した部分まで全公開になる、という意味ではありません。

非公開製品では、対象の著作物、部品の結合、コピーの配布、AGPLのネットワーク利用を調べます。義務を満たせなければ互換性のある寛容型の代替か別の許可を選んでください。商用利用自体は可能で、問題は実際のライセンスと統合への適合です。

リポジトリにライセンスファイルがまったくない場合は？

重要なポイント

ライセンスファイルがなければ、そのコードは使用できません。これは「無料」という意味ではありません。むしろライセンスがなければ、コードは作者の完全な著作権保護下にあり、使用、複製、改変する権利はありません。GitHub内で閲覧やフォークができても、この点は変わりません。コードを製品に組み込む権利は得られません。本当にそのコードが必要なら、作者に連絡して許可を求めるか、ライセンスが追加されるまで待つのが、問題のない唯一の方法です。

よくある誤りは、ライセンスがなければ制限もなく、自由にコードを使えると思い込むことです。逆です。ライセンスがないことは許可ではなく、原則として許可がないことを意味します。ライセンスのないコードは作者の完全な著作権保護下にあり、手を触れてはいけません。

最初に説明したルールがここでも当てはまります。コードは原則として著作権で保護されており、明示的な許可がなければ、複製、改変、配布はできません。GitHub内で閲覧やフォークができても、その壁を越えることはできません。自分の製品でコードを使う権利は与えられないのです。

ライセンスがないコードがどうしても必要な場合、実際には次のように対応してください。

作者に連絡する。 リポジトリのディスカッション欄やメールで、コードを使えるか、どのような条件かを尋ねます。作者がライセンスの追加を単に忘れていて、尋ねれば追加してくれることもあります。
代替を探す。 ほとんどの用途には似たリポジトリが2つ目、3つ目、10個目とあります。その中から適切なMITまたはApacheライセンスが付いたものを見つけられるでしょう。
使わない。 許可がなく、代替もなければ、そのコードはあなたのものではありません。販売するつもりの製品に組み込むことはできません。「誰にわかるだろう」という誘惑は、製品が収益を上げ、注目を集め始めたときに、悪い結果を招きます。

Claude自身が他人のコードをプロジェクトに追加した場合は？

重要なポイント

これは別のケースであり、リポジトリを直接コピーすることと混同しないことが大切です。特定のリポジトリから自分でコードを取る場合、そのライセンスに従わなければなりません。ClaudeなどのAIが依頼に応じてコードを生成する場合、通常は他人のファイルをコピーするのではなく、タスクに合わせて独自のテキストを組み立てます。その場合、問題となるのは生成コードの権利です。ただし、AIが他人のライセンス付きコードの認識可能な一部を明確に再現した場合は、ライセンス条件が適用されます。どちらの場合も出所を確認する価値があります。

ここにはもう一つの層があり、最初のケースと混同しやすいところです。リポジトリを訪れてファイルをコピーする場合は、先ほど説明したライセンス上の義務が直接適用されます。一方、Claudeに依頼してコードを書いてもらう場合は別です。

通常、AIは他人のファイルをコピーするのではなく、依頼に合わせて独自のテキストを組み立てます。その場合、問題は別の領域、つまり生成コードを誰が所有するのか、販売できるのかという点に移ります。これは独立した大きなテーマであり、AIが書いたコードの所有者は誰かという記事で取り上げました。

ただし、覚えておきたい例外があります。AIが、よく知られたライブラリの関数全体など、他人のコードの認識可能な一部をほぼ一言一句そのまま生成することがあります。その場合、誰が実際にキーを押したかに関係なく、そのライブラリのライセンスが適用されます。したがって、Claudeが丸ごと取り込んだ既製の大きなコードブロックは、自分でコピーした場合と同じように確認してください。

コードを使う前にライセンスを確認する方法：手順

重要なポイント

手順は次のとおりです。リポジトリページを開いてサイドバーのライセンス名を確認し、LICENSEファイル自体を開き、種類が寛容型（MIT、Apache、BSD）かコピーレフト型（GPL、AGPL）かを見分け、自分の状況と照らし合わせて、そのコードを使うか代替を探すかを決めます。ライセンスがまったくなければ、使わないでください。確認は数分で済み、コードをプロジェクトに入れた後ではなく、その前に行うべきです。

サードパーティのコードをプロジェクトに取り込む前に確認するための短いチェックリストにまとめましょう。上から順に進めてください。

リポジトリページでライセンス名を確認する
GitHubでリポジトリを開きます。ライセンス名は通常、右側の列かファイル一覧の下に表示されます。たとえば「MIT License」「Apache-2.0」「GPL-3.0」です。空欄でライセンスファイルもなければ、それだけですでに注意が必要です。最後の手順で改めて確認してください。
ライセンスファイル自体を開く
ファイル一覧でLICENSE、LICENSE.md、またはCOPYINGを探して開きます。サイドバーに表示された名前と一致していること、またライセンスがリポジトリ内の別の部分だけではなく、使うコードにも適用されることを確認してください。
寛容型かコピーレフト型かを見分ける
MIT、Apache 2.0、BSDは寛容型で、コードを非公開の商用製品に使えます。GPLとAGPLはコピーレフト型です。対象の著作物、配布、AGPLのネットワーク条件を調べてソース義務を判断します。名称だけでは独立部品のどこまでが対象か確定しません。
自分の状況と照らし合わせる
3つの問いに答えてください。製品を販売するのか、コードを改変するのか、ソースコードを非公開にしたいのか。MIT、Apache、BSDは販売する非公開製品に適しています。GPLやAGPLでは、どの対象・結合作品に対応ソースが必要か、何が義務の契機かを特定し、その条件を満たせるか評価します。
ライセンスがなければ使わない
ライセンスファイルがなく、READMEにも許可について何も書かれていなければ、そのコードは使用できません。作者に連絡して許可を求めるか、適切なライセンスが付いた同等品を探してください。「公開されている」は許可を意味しません。

この確認が面倒に思えるのは、製品が成長して収益を上げ始め、誰かに中のサードパーティコードについて尋ねられる、そのときまでです。最初にかける2分は、後で紛争に対処するコストより小さいものです。公開後に製品を止めずに続ける方法については、別の記事で取り上げています：AIで製品を作った。その次は？。

よくある質問

GitHub上の他人のコードを含む製品を販売できますか？

はい。コードにMIT、Apache 2.0、BSDなどの寛容型ライセンスが付いている場合は可能です。これらは商用製品でのコード使用と販売、自分のソースコードの非公開を認めており、ライセンス本文と著作者表示を残すことだけを求めます。GPLとAGPLも商用利用できますが、ソース義務は対象著作物と、配布または該当するAGPLのネットワーク条件によります。ライセンスファイルがなければ、コードをまったく使用できません。

GitHubリポジトリにライセンスがないとはどういう意味ですか？

コードを使用できないという意味です。原則として、ライセンスがないことは許可がないことを意味し、「無料」という意味ではありません。コードは作者の完全な著作権保護下にあります。GitHub内でリポジトリを閲覧したりフォークしたりできても、製品でコードを使う権利は得られません。コードが必要なら、作者に連絡して許可を求めるか、オープンライセンスが付いた同等品を探してください。

MITは、自分の製品においてGPLとどう違いますか？

MITでは、コードを使用、改変し、製品を販売し、自分のソースコードを非公開にできます。義務はライセンス本文を残すことだけです。GPLも商用利用できますが、対象の結合・派生著作物を渡す場合には対応ソースと同じライセンスの義務に従います。コピーを渡さないホストは別で、独立部品すべてが自動的に対象ではありません。

MITライセンスのコードを使う場合、何か対応が必要ですか？

はい、一つだけ簡単なことがあります。プロジェクト内で、使ったコードのMITライセンス本文と著作者表示を残してください。通常、それは元のコードに付属するLICENSEファイルです。MITではそれ以外のことは求められません。コードを改変し、製品を販売し、ソースコードを非公開にできます。

Claude自身が私ではなく他人のコードを追加した場合は？

それでも出所を確認してください。AIは通常、依頼に合わせて独自のテキストを生成するため、その場合は生成コードの権利という別の問題になります。しかし、AIが有名なライブラリの他人のコードの認識可能な一部をほぼ一言一句そのまま再現した場合は、そのライブラリのライセンスが適用されます。丸ごと取り込まれた大きな既製のコードブロックは、自分でコピーして貼り付けた場合と同様に確認してください。

出典

Ailootを開く。

詳細を見る