あなたのサイドプロジェクトがちょうど500スターを超え、見知らぬ誰かが初めての本格的なプルリクエストを開いたとします。何ヶ月も先延ばしにしてきた問題を解決する2,000行のコードです。マージボタンを押したくなります。しかしその前に、気まずい問いを立ててください。あなたにはそのコードをリリースする法的権利が本当にあるのか——そして、そのコントリビューターがどこの企業に勤めていようと、自分のライセンスの下で永遠にリリースし続ける権利があるのか、と。
リポジトリにコントリビューションポリシーがなければ、正直な答えは「確信がない」です。コントリビューターは書いた一行一行の著作権を依然として保有しており、プロジェクトのライセンスだけでは、誰が誰に何を許諾したかを常に確定できるわけではありません。この不確実性は、それが問題になる日まで見えません。リライセンス、買収、企業ユーザーによるライセンスのデューデリジェンス、あるいはコントリビューターの雇用主がその成果はもともと自社のものだと主張する日まで。
この問題を解決する仕組みは2つあり、ほぼすべてのオープンソースプロジェクトはそのどちらかを選びます。コントリビューターライセンス契約（CLA）と、開発者オリジン証明書（DCO）です。どちらも、コントリビューターがその贡献を行うことを許されており、プロジェクトにそれを配布する権利があることを確立するために存在します。両者は、重み、摩擦、そして後で何ができるかという点で大きく異なります。本ガイドでは、それぞれの仕組み、どちらをいつ選ぶべきか、そして選んだ方を半日でセットアップする方法を解説します。
そもそもプロジェクトにコントリビューションポリシーが必要な理由
著作権は自動的に発生します。誰かがコードを書いた瞬間、その人はそれを所有します——登録も著作権表示も不要です。その人があなたのプロジェクトにコードを提出すると、あなたのオープンソースライセンスは多くのことをカバーしますが、コントリビューションポリシーでしか埋められない隙間が残ります。
- インバウンドの許諾。 あなたのアウトバウンドライセンス（MIT、Apache-2.0、GPL）は、ユーザーがあなたのコードで何をしてよいかを定めます。コントリビューションポリシーは、受け取る贡献が互換性のある条件の下で届くことを明示し、ファイルごとの来歴を手作業で追わなくても、結合した成果物を配布できるようにします。
- 雇用主の主張。 ほとんどの雇用契約は、少なくとも従業員の職務に関連する成果物について、サイドプロジェクトの知的財産権を雇用主に帰属させます。コントリビューターに提出する権利があることの確認を求めるポリシーは、その責任——そして書面の記録——をコントリビューター側に置きます。
- リライセンスの選択肢。 将来ライセンスを変更したり、商用版を追加したり、プロジェクトを財団に寄贈したりしたいなら、すべてのコントリビューターからの権利が必要です。何十人もの過去のコントリビューターから事後に許可を集めるのは、苦痛から不可能の間にあります。初日に選んだポリシーが、その扉を開いたままにできるかを決めます。
- 特許の保護。 コードの贡献は特許権を伴うことがあります。明示的な特許許諾を含むポリシーもあれば、含まないものもあります。これは多くのメンテナーが思っている以上に重要です。
これらはいずれも、顧問弁護士を抱える必要はありません。CLAかDCOを選び、リポジトリに書き記し、自動的に執行するだけです。それぞれの選択が何を伴うかを見ていきましょう。
コントリビューターライセンス契約（CLA）とは？
コントリビューターライセンス契約（CLA）は、コントリビューターとプロジェクト（あるいはその背後にある企業や財団）との間で署名される法的文書です。コントリビューターは一度署名すれば、その署名が将来のすべての贡献をカバーします。
オープンソースライセンスと異なり、CLAは標準化されていません。各プロジェクトが独自に作成しますが、ほとんどは2つのおなじみの形に収まります。
個人CLAと法人CLA
- 個人CLA（ICLA）： 個人が自分のために贡献する際に署名するもの。通常、プロジェクトに広範な著作権許諾と、多くの場合特許許諾を与えますが、コントリビューターは自身の著作権を保持します。
- 法人CLA（CCLA）： 企業が署名し、その従業員の贡献を承認するもの。企業は自社の人間が提出する成果物について同じ権利を許諾します。CCLAなしで法人からの贡献を受け入れるプロジェクトは、すべての従業員の上司がそれを把握し——承認している——と信頼しているわけですが、まさにその種の信頼はデューデリジェンスの最中に蒸発します。
ライセンス許諾か著作権譲渡か
現代のCLAのほとんどはライセンス許諾です。コントリビューターは所有権を保持し、プロジェクトに永続的、世界中、ロイヤリティフリーのライセンスを与えます——多くの場合、リライセンスを許すほど広範なものです。Apache Software FoundationのICLAが典型例です。
少数のプロジェクトは著作権譲渡を用います。コントリビューターが所有権を完全に移転する方式です（Free Software Foundationのアプローチ）。譲渡はプロジェクトに執行とリライセンスの最大限の自由を与えますが、コントリビューターに最も多くを求め、コミュニティ主導のプロジェクトでは人気を失っています。
CLAがあなたとコントリビューターに課すコスト
トレードオフは摩擦です。初めてのコントリビューターはプルリクエストを離れ、法的文書を読み、署名し（通常は電子的に）、メンテナーがコードをレビューする前にステータスチェックが緑になるのを待たなければなりません。ツールのおかげでこれはほぼ苦痛ではなくなりました——CLA Assistantのようなボットがプルリクエストに署名リンクをコメントし、署名を自動的に記録します——それでも「あなたのバグを直した」と「私の修正をマージしてよい」の間のゲートです。通りすがりのコントリビューターの中には、これで離脱する人もいます。
その代わりに、プロジェクトは署名された監査可能な記録を得ます。この人物が、この日に、これらの権利を許諾した、という記録です。企業が後ろ盾のプロジェクト、デュアルライセンスのプロジェクト、そしていつか買収される可能性のあるものにとって、その書面の記録は実際の金銭的価値があります。
開発者オリジン証明書（DCO）とは？
開発者オリジン証明書（DCO）は、CLAの重みを避けるために、2004年にLinux FoundationがLinuxカーネル向けに導入しました。これはコントリビューターが署名して保管する契約ではありません。5段落からなる短い証明（バージョン1.1）であり、コントリビューターがコミットメッセージにSigned-off-by行を追加することで、コミットごとにそれを表明します。
Fix off-by-one error in retry backoff calculation
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
Signed-off-by: Alex Rivera <[email protected]>行を追加するのはフラグ1つです。git commit -sが、設定されたGitアイデンティティを使って自動的に付加します。署名することで、コントリビューターは次を証明します。
- その贡献を作成した（全体または一部）ものであり、プロジェクトのオープンソースライセンスの下で提出する権利がある、または
- その贡献が、この提出を許す適切なオープンソースライセンスの下にある先行成果物に基づくものである、または
- 上記のいずれかを証明した別の誰かから贡献を受け取り、自分はそれを変更していない、そして
- その贡献とその記録——自分の署名を含む——が公開され、無期限に保持されることを理解している。
仕組みはこれだけです。別途の文書も、アカウント連携も、プロジェクトごとのオンボーディングもありません。執行はステータスチェックです。DCOアプリまたは同等のチェックが、プルリクエストのすべてのコミットに有効な署名があることを検証し、メンテナーは緑になったときだけマージします。
DCOの意図的な限界
DCOがしないことに注目してください。プロジェクトのアウトバウンドライセンスが既に伝える以上のライセンスは許諾しません——贡献がプロジェクトのライセンス条件の下で届くことに依存しています。特許許諾は含みません。そして、コントリビューターごとに署名して保管するものではないため、誰が何に同意したかの中央登録簿は存在せず、git履歴そのものが記録です。
支持者はこれを利点と考えます。DCOの低い参入障壁こそが要点なのです。Linuxカーネル、GitLab（2017年にCLAから切り替え）、Chef（2016年に切り替え）はいずれも、コミットごとの証明が、すべてのコントリビューターに負担を課すことなく必要な来歴を与えると結論づけました。OpenStackの技術委員会は2025年、すべての贡献についてCLAをDCOに置き換えることを決議しました。業界の流れは紛れもありません——しかし流れは、あなたのプロジェクトにとっての判決ではありません。次の節で説明します。
CLA vs. DCO 対比表
| 観点 | CLA | DCO |
|---|---|---|
| 法的仕組み | コントリビューターごとに一度署名・保管される契約 | コミットメッセージ内のコミットごとの証明 |
| コントリビューターがすること | 文書に署名する（通常はボットのリンク経由） | git commit -sでSigned-off-byを追加する |
| 著作権の扱い | プロジェクトへの明示的なライセンス許諾（または譲渡） | 贡献はプロジェクトのライセンスの下で届く。別途の許諾なし |
| 特許許諾 | 通常含まれる | なし |
| リライセンスの自由 | 広範な許諾がしばしばそれを許す | 追加の権利なし。リライセンスには全コントリビューターの同意が必要 |
| コントリビューターの摩擦 | 高い：読み、署名し、チェックを待つ | 最小限：Gitのフラグ1つ |
| 執行ツール | CLA Assistant、EasyCLA、カスタムボット | DCOアプリ、コミットメッセージのチェック |
| 同意の記録 | 署名データベース | git履歴そのもの |
| 雇用主のカバー | 法人CLAが従業員を明示的にカバーする | コントリビューターが提出する権利があることを自己証明する |
| 最適な用途 | 企業が後ろ盾の、デュアルライセンスの、または買収に関わるプロジェクト | 贡献の摩擦が最も重要なコミュニティプロジェクト |
CLAが正しい選択となる場合
プロジェクトの将来がDCOでは捉えられない権利に依存するかもしれないなら、CLAを選んでください。
- デュアルライセンスやリライセンスを計画している。 商用版、ライセンス変更、コピーレフトから寛容型ライセンスへの移行が少しでもあり得るなら、広範なライセンスバックを伴うCLAが、その選択肢を開いたままにする唯一の軽量な方法です。何年も後に同意を再構築するのは悪夢のシナリオです。
- 企業がプロジェクトを支えている。 企業スポンサー、買収者、知的財産のデューデリジェンスを行うエンタープライズ顧客は、考古学ではなく署名登録簿を求めます。Google、Apacheプロジェクト、Canonicalはいずれもまさにこの理由でCLAを使っています。
- あなたの領域で特許が重要である。 コーデック、無線プロトコル、MLモデルアーキテクチャ——特許の多い分野では、CLAの明示的な特許許諾が、DCOが黙って飛ばす実際の役割を果たします。
- 財団がそれを要求している。 ある財団は、ホスティングや卒業の条件として自らのCLAを義務付けています。DCOで十分だと決めつける前に確認してください。
この道を選ぶなら、CLA自体は標準的で退屈なものに保ってください。ゼロから起草するのではなくApache ICLAやHarmonyのテンプレートから始め、個人版と法人版の両方を公開し、初日に署名ボットを組み込んで、摩擦をPDFの往復ではなくワンクリックにしましょう。
DCOが勝つ場合
贡献が生命線であり、摩擦が敵であるなら、DCOを選んでください。
- カジュアルなコントリビューターが多いコミュニティプロジェクト。 ドキュメントの修正、誤字の訂正、小さなバグ修正——署名のゲートで最も離脱しやすい贡献は、まさにDCOが優雅に扱えるものです。
- 寛容型ライセンスで、リライセンスの予定がない。 プロジェクトが永遠にMITかApache-2.0のままで、商用版がロードマップになければ、CLAの追加の権利はほとんど何ももたらしません。
- 個人メンテナーと小規模チーム。 DCOは署名インフラも、契約を保持する法人格も、法人向け書式に副署するプロセスも必要としません。
CONTRIBUTING.mdとステータスチェックで運用できるガバナンスです。 - 最大限の互換性の姿勢。 一部のコントリビューター——特に厳格な知的財産ポリシーを持つ大企業に雇用されている人々——は、DCOには署名できても、法務レビューなしに外部のCLAには署名できません。DCOはその扉を開いたままにします。
どちらを選んでも、決定を書き記してください。ポリシーを明記し、正確な署名またはサインオフの流れを示し、全文にリンクするCONTRIBUTING.mdが、最も一般的な混乱の原因を取り除きます。つまり、失敗したステータスチェックから要件を推測するコントリビューターです。
どちらの選択も台無しにする5つの過ち
1. 両方を言う。 現実で最もよくある失敗は、ある段落でDCOの署名を求め、別の段落でCLAの署名を求めるCONTRIBUTING.mdです——たいてい中途半端な移行の後です。コントリビューターは一方の指示に従い、もう一方のチェックが失敗し、メンテナーがそれでもマージしてしまい、両方の意味が無くなります。1つの仕組みを選び、それを執行し、もう一方の痕跡をすべて削除してください。
2. 自動執行がない。 散文でしか述べられていないポリシーは提案にすぎません。チェックをプルリクエストのワークフローに必須のステータスチェックとして組み込んでください——署名にはDCOアプリ、サインオフにはCLA AssistantまたはEasyCLA——そうすれば、同意のない贡献が事故やメンテナーの疲労でマージされることはありません。
3. 法人コントリビューターを無視する。 企業があなたのプロジェクトを使い、パッチを当てるなら、従業員は勤務時間中にコードを提出します。CLAポリシーなら、関係が温かいうちに早くCCLAを署名してもらうことを意味します。DCOポリシーなら、誰かの最初の贡献が知的財産の事件にならないよう、署名要件を十分に可視化することを意味します。
4. 雇用契約が贡献を許していると決めつける。 同じコインの裏側です。他のプロジェクトに贡献するなら、まず自分の雇用契約を確認してください。多くは職務関連のサイドプロジェクトの知的財産権をデフォルトで雇用主に帰属させます。DCOの証明（「これを提出する権利がある」）は、その書類がそう述べている場合にのみ真です。
5. AI支援コードへのポリシーがない。 機械生成の贡献は、2004年当時のDCOの文言もほとんどのCLAテンプレートも想定していなかった来歴の問題を提起します。あなたの立場を決めてください——レビュー付きで許可、開示必須、または禁止——そして最初のAI生成プルリクエストが届いた後にではなく、届く前に、CLA/DCOポリシーと並べてCONTRIBUTING.mdに明記してください。
プロジェクトの金銭面も忘れずに
メンテナーが確定申告の時期まで先延ばしにする部分がここにあります。プロジェクトが最初の1ドルを稼いだ瞬間——GitHub Sponsorsの支払い、Open Collectiveの寄付、あなたのREADMEがきっかけで舞い込んだコンサルティング案件——それは財務を持ち、財務には帳簿が必要です。
贡献の来歴を監査可能にするのと同じ規律が、プロジェクトのお金を管理可能にします。スポンサー収入を給与とは別に追跡し、何が課税対象の自営業所得かを把握しましょう。プロジェクトの経費——ドメイン更新、CIの分数、弁護士がCLAをレビューに費やした午後——を独自の勘定に記録し、控除が個人のカード明細に消えてしまわないようにしましょう。プロジェクトがLLCになったり財政ホストに参加したりするなら、きれいな履歴記録がその移行を、フォレンジックではなく退屈なものにします。
プレーンテキスト会計はこのワークフローに驚くほどよく合います。帳簿はコードの隣のバージョン管理に置かれ、すべての仕訳に履歴があり、何もプロプライエタリな形式に隠れません。私たちのドキュメントでは、最初の帳簿を数分で動かす方法を解説しています。
プロジェクトの帳簿をgit履歴と同じくらいきれいに保つ
CLAとDCOのどちらを選ぶかは半日で決まりますが、何年も後に来歴やプロジェクトの財務を解きほぐすのは何週間もかかります。今すぐ贡献の方針を決め、その執行を自動化し、プロジェクトのお金にコミットと同じ配慮を払いましょう。Beancount.ioは、あなたの財務データに完全な透明性とコントロールをもたらすプレーンテキスト会計を提供します——ブラックボックスも、ベンダーロックインもありません。無料で始めると、開発者や財務のプロフェッショナルがなぜプレーンテキスト会計に切り替えているのかがわかります。
