LLVM開発者ポリシー

はじめに

このドキュメントには、LLVM開発者ポリシーが記載されており、開発者とその貢献に対するプロジェクトのポリシーを定義しています。このポリシーの目的は、LLVMの開発の分散性から生じる可能性のある誤解、やり直し、混乱をなくすことです。ポリシーを明確に述べることで、各開発者がLLVMに貢献する際に何を期待すべきかを事前に知ることができるようにすることを願っています。このポリシーは、Clang、LLDB、libc++など、すべてのllvm.orgサブプロジェクトに適用されます。

このポリシーは、次の目的を達成するためにも設計されています。

1. LLVMプロジェクトにユーザーと開発者の両方を引き付ける。

2. 貢献者にとって可能な限りシンプルで簡単なものにする。

3. トップオブツリーを可能な限り安定させる。

4. プロジェクトの著作権、ライセンス、および特許ポリシーについて、プロジェクトへの貢献者に周知させる。

このポリシーは、LLVMに頻繁に貢献する人を対象としています。一度限りのパッチを提供することに関心のある人は、llvm-commitsメーリングリストに送信し、別の開発者と協力してプロセスを進めることで、非公式な方法で貢献できます。

開発者ポリシー

このセクションには、LLVM開発者に関連するポリシーが含まれています。LLVMに日常的に貢献していない人からの一度限りのパッチは常に歓迎しますが、システムを全員にとって可能な限り効率的に保つために、頻繁に貢献する人にはより多くのことを期待しています。LLVMに頻繁に貢献する人は、LLVMが高い品質基準を維持するために、次の要件を満たす必要があります。

最新情報の入手

開発者は、LLVMディスコースフォーラムを読み、関心のあるカテゴリを購読して通知を受け取ることで、最新情報を入手する必要があります。

他の人が行っている変更に注意を払うことは、他の人が何に興味を持っているかを確認し、プロジェクト全体の流れを見るための良い方法です。

プロジェクトへの貢献は、GitHubプルリクエストを通じて行われます。pr-subscribers-* GitHubチームのいずれかに参加することで、コードベースの特定の領域の通知を購読できます。このマッピングは、どのチームがリポジトリ内の特定のパスに関連付けられているかを示しています。

llvm-commits、cfe-commits、lldb-commitsなど、関心のあるサブプロジェクトの「コミット」メーリングリストを購読することもできます。

見つからない機能やバグは、GitHubイシュートラッカーで追跡され、ラベルが割り当てられます。アクティブな開発者には、 incoming イシューを監視することをお勧めします。issue-subscribers-*チームのいずれかに参加することで、特定のコンポーネントの通知を購読できます。また、llvm-bugsメーリングリストを購読して、プロジェクト全体で発生しているバグや機能強化を追跡することもできます。コンポーネントに incoming するバグを積極的にキャッチし、迅速に対処してくれる人には本当に感謝しています。

すべての公開LLVMメーリングリストとディスコースフォーラムは公開され、アーカイブされていることに注意してください。また、機密保持または非開示の通知は尊重できません。

パッチの作成と提出

レビューのためにパッチを作成する場合、目標はレビュー担当者ができるだけ簡単に読めるようにすることです。そのため、次のようなことをお勧めします

1. パッチは、ブランチではなく、古いバージョンのLLVMでもなく、git mainに対して作成してください。これにより、パッチを簡単に適用できます。gitからのクローン方法については、入門ガイドを参照してください。

2. 同様に、パッチは生成後すぐに提出する必要があります。パッチが作成された時点と適用された時点の間に基になるコードが変更されると、古いパッチが正しく適用されない場合があります。

3. パッチを作成したら、GitHubプルリクエストを作成します（または、該当する場合は直接コミットします）。

パッチを提出する際には、パッチ自体に機密保持または非開示の通知を追加しないでください。これらの通知はLLVMのライセンス条項と矛盾しており、貢献が除外される可能性があります。

コードレビュー

LLVMにはコードレビューポリシーがあります。コードレビューは、ソフトウェアの品質を向上させる1つの方法です。LLVMのコードレビュープロセスについて詳しくは、LLVMコードレビューポリシーとプラクティスを参照してください。

破壊的変更の可能性のある変更を行う

ツールの新しいバージョンにアップグレードする際の潜在的な問題について、ユーザーとベンダーに通知してください。たとえば、将来削除される予定の機能の廃止、既に廃止された機能の削除、診断の警告からエラーへのアップグレード、重要なデフォルト動作の切り替え、または認識を高める価値があると.思われるその他の潜在的に破壊的な状況などです。このような変更については、以下を行う必要があります

警告

Phabricatorは廃止され、読み取り専用モードで利用できます。新しいコードの投稿には、GitHubプルリクエストを使用してください。このセクションには、更新が必要な古い情報が含まれています。

• 変更のコードレビューを実行する際には、該当する「ベンダー」グループをレビューに追加して、認識してもらってください。これらのグループの目的は、破壊的変更の可能性がある変更が検討されているが、まだ承認されていないことをベンダーに早期に通知することです。ベンダーは変更に関する早期のテストフィードバックを提供することで、許容できない破損を警告できます。現在のベンダーグループのリストは次のとおりです

  • Clangベンダー

  • libc++ベンダー

  ベンダーグループへの参加に関心のある人は、Phabricatorのベンダーの「メンバー」ページにある「プロジェクトに参加」リンクをクリックすることで参加できます。

• 変更をリポジトリにコミットする際には、破壊的変更の可能性に関する適切な情報を、プロジェクトのリリースノートの破壊的変更の可能性セクションに追加してください。リリースノートには、変更の内容、潜在的に破壊的な内容、およびユーザーと共有するのに適したコード例、リンク、動機に関する情報を含める必要があります。これにより、ユーザーは、そのリリースへのアップグレードに伴う潜在的な問題について知ることができます。

• 変更がリポジトリにコミットされた後、リリースノートに記載されている破壊的変更の可能性は、Discourseのお知らせチャンネルに投稿する必要があります。投稿には、potentially-breakingラベルと、プロジェクト固有のラベル（clang、llvmなど）を付ける必要があります。これは、リリース前にユーザーに破壊的変更の可能性を通知できるもう1つのメカニズムです。「ベンダー」グループへの参加よりもトラフィックが少ない代替手段です。potentially-breakingラベルが付いた新しいお知らせを自動的に通知するには、Discourseのユーザー設定ページに移動し、通知->タグの下にあるウォッチカテゴリのいずれかにラベルを追加します。

コードオーナー

LLVMプロジェクトは、ソースベースの高品質に加えて、迅速な開発を維持するために、プロセスの2つの機能に依存しています。信頼できるメンテナーのためのコードレビューとコミット後レビューの組み合わせです。この両方を備えることは、ほとんどの人がほとんどの場合正しいことを行い、自分が正しいと確信している場合にのみコミット前レビューなしでパッチをコミットするという事実を利用する優れた方法です。

この手法の鍵は、コミットされたすべてのパッチがコミット後にレビューされることをプロジェクトが保証する必要があるということです。誰もが他の誰かがレビューすると想定し、パッチがレビューされないままになることを防ぐ必要があります。この問題を解決するために、コードの一部に対する「所有者」という概念があります。コード所有者の唯一の責任は、コードの担当領域へのコミットが、自分自身または他の誰かによって適切にレビューされるようにすることです。現在のコード所有者のリストは、LLVMソースツリーのルートにあるCODE_OWNERS.TXTファイルにあります。

コードの所有権はレビュー担当者とは全く異なることに注意してください。誰でもコードをレビューできます。興味のある人からのコードレビューを歓迎します。コード所有者は、コミットされたすべてのパッチが実際にレビューされることを保証するための「最後の防衛線」です。

コード所有者であることは、あまり華やかな立場ではありませんが、プロジェクトの継続的な成功にとって非常に重要です。人々は忙しくなり、興味は変わり、予期せぬことが起こるため、コードの所有権は純粋にオプトインであり、誰でもいつでも「称号」を辞退することができます。今のところ、コード所有者にどのように選出されるかについての公式なポリシーはありません。

テストケース

開発者は、修正されたバグと追加されたすべての新機能のテストケースを作成する必要があります。テストケースの承認を得るためのヒントをいくつか紹介します。

• すべての機能と回帰テストケースは、llvm/testディレクトリに追加されます。適切なサブディレクトリを選択する必要があります（詳細はテストガイドを参照）。

• テストケースは、LLVMアセンブリ言語で記述する必要があります。

• テストケース、特に回帰テストは、bugpointまたは手動で可能な限り縮小する必要があります。失敗したプログラム全体をllvm/testに配置することは、すべての開発者に*テスト時間*の負担をかけるため、受け入れられません。短くしてください。

• プライベートバグトラッカー、社内ドキュメントなど、コミュニティ全体が利用できないリソースへのリンクを追加することは避けてください。代わりに、テストに十分なコメントを追加して、そのようなリンクの背後にあるコンテキストを提供してください。

llvm/testとclang/testは、回帰テストと小規模な機能テストのみを対象としていることに注意してください。より広範なテストケース（アプリケーション全体、ベンチマークなど）は、llvm-testテストスイートに追加する必要があります。 llvm-testスイートは、カバレッジ（正確性、パフォーマンスなど）テスト用であり、機能テストや回帰テスト用ではありません。

リリースノート

LLVMの多くのプロジェクトは、リリースノートを通じて重要な変更をユーザーに伝えます。通常、プロジェクトのdocs/ReleaseNotes.rstにあります。ユーザーに影響を与える、またはユーザーが知りたいと思う可能性のあるプロジェクトへの変更は、作者またはコードレビュー担当者の判断で、できれば変更を反映したコミットの一部として、プロジェクトのリリースノートに追加する必要があります。リリースノートの追加を通常必要とする変更の例（このリストは網羅的ではありません）

• コマンドラインオプションの追加、削除、または変更。

• 診断の追加、削除、または再グループ化。

• ユーザーに大きな影響を与える可能性のあるバグの修正（バグデータベースで修正された問題へのリンクを貼ってください）。

• 広範囲に影響を与える、または新しいプログラミングパラダイムを可能にする最適化の追加または削除。

• Cの安定したAPIの変更。

• 非推奨の機能の削除など、将来のリリースで行われる予定の破壊的な変更の可能性についてユーザーに通知します。この場合、リリースノートは、潜在的な混乱を示すのに十分な情報と例とともに、ノートの破壊的変更の可能性セクションに追加する必要があります。さらに、このセクションへの新しいエントリは、Discourseのお知らせチャネルで発表する必要があります。詳細は、破壊的変更の可能性のある変更を行うを参照してください。

コードレビュー担当者は、コードレビューを実行する際にリリースノートが必要と思われる場合は、それを要求することをお勧めします。

品質

メイン開発ブランチにコミットされる前に、変更が満たす必要がある最低限の品質基準は次のとおりです。

1. コードは、LLVMコーディング標準に準拠する必要があります。

2. コードは、少なくとも1つのプラットフォームで正常にコンパイルされる必要があります（エラーや警告なし）。

3. バグ修正と新機能には、テストケースを含める必要があります。そうすれば、将来、修正/機能が回帰した場合に備えることができます。

4. コードは、llvm/testテストスイートに合格する必要があります。

5. コードは、llvm-testの妥当なサブセットで回帰を引き起こしてはなりません。「妥当な」とは、貢献者の判断と変更の範囲によって異なります（より侵襲的な変更には、より多くのテストが必要です）。妥当なサブセットは、「llvm-test/MultiSource/Benchmarks」のようなものかもしれません。

6. ソースコードとテストファイルのリンクが、公開されているリソースを指していること、また、重要なコンテキストを提供するのではなく、追加情報を追加するために主に使用されていることを確認してください。周囲のコメントは、そのようなリンクの背後にあるコンテキストを提供するのに十分なものである必要があります。

さらに、コミッターは、変更が原因で将来発生する問題に対処する責任があります。例えば

• コードは、サポートされているすべてのプラットフォームで正常にコンパイルされる必要があります。

• 変更は、llvm-testスイートで正確性の回帰を引き起こしてはならず、主要なパフォーマンスの回帰を引き起こしてはなりません。

• 変更セットは、LLVMツールの性能または正確性の低下を引き起こしてはなりません。

• 変更は、該当するすべてのターゲットでLLVMによってコンパイルされたコードのパフォーマンスまたは正確性の低下を引き起こしてはなりません。

• 変更によって発生するGitHubの問題に対処する必要があります。

提出前にこれに対処することを望んでいますが、すべての提出についてこれをすべてテストすることは不可能であることを理解しています。私たちのビルドボットと夜間テストインフラストラクチャは、通常、これらの問題を発見します。良い経験則として、変更の翌日には、夜間テスターに回帰がないかを確認することです。ビルドボットは、コミットのグループにあなたのコミットが含まれていて、障害が発生した場合、あなたに直接メールを送信します。ビルドボットのメッセージを確認して、自分の責任かどうかを確認し、そうであれば、破損を修正する必要があります。

これらの品質基準に違反するコミット（例：非常に壊れている）は、元に戻される場合があります。これは、変更によって他の開発者の進捗が妨げられる場合に必要です。開発者は、問題が修正された後、変更を再コミットすることができます。

コミットメッセージ

コミットメッセージの形式は強制しませんが、レビュー、ログの検索、メールのフォーマットなどを容易にするため、これらのガイドラインに従うことをお勧めします。これらのガイドラインは、他のオープンソースプロジェクトで使用されているルールと非常によく似ています。

最も重要なことは、メッセージの内容は、変更の根拠を伝えるように注意深く記述する必要があるということです（詳細に掘り込みすぎずに）。また、曖昧になったり、過度に具体的になったりするのも避けるべきです。たとえば、「ビットが正しく設定されていませんでした」と書くと、レビュー担当者はどのビットについて、なぜ正しくなかったのか疑問に思うでしょう。一方、「TargetInfoのオーバーフロービットを正しく設定する」と書けば、変更のほとんどすべてが伝わります。

以下は、メッセージ自体の形式に関するガイドラインです。

• コミットメッセージを、空白行で区切られたタイトルと本文に分割します。

• 元の作者でない場合は、コミットの「作者」プロパティが元の作者に設定され、「コミッター」プロパティが自分自身に設定されていることを確認してください。 git commit --amend --author="John Doe <jdoe@llvm.org>"のようなコマンドを使用して、作者プロパティが正しくない場合は修正できます。プロジェクトがgitに移行する前に使用していた属性付けの方法を含む詳細については、変更の属性付けを参照してください。

  まれに複数の作者がいる場合は、gitタグ「Co-authored-by:」を使用して追加の作者をリストしてください。

• タイトルは簡潔にする必要があります。すべてのコミットは、最初の行を件名としてリストにメールで送信されるため、長いタイトルは好ましくありません。短いタイトルは、git logでも見栄えがよくなります。

• 変更がコードの特定の部分（バックエンドや最適化パスなど）に限定されている場合は、行の先頭に角かっこでタグを追加するのが慣例です。たとえば、「[SCEV]…」や「[OpenMP]…」などです。これは、メールフィルターとコミット後レビューの検索に役立ちます。

• 本文がある場合は、タイトルと空行で区切る必要があります。

• 本文は簡潔ながらも説明的で、完全な推論を含める必要があります。変更を理解するために必要な場合を除き、例、コードスニペット、詳細な詳細は、バグコメント、Webレビュー、またはメーリングリストに任せる必要があります。.

• テキストの書式設定とスペルは、ドキュメントとコード内のコメントと同じルールに従う必要があります。例：大文字化、ピリオドなど。

• コミットが最近コミットされた別のパッチに対するバグ修正、またはパッチの revert もしくは reapply の場合は、以前の関連するコミットの git コミットハッシュを含めます。これは、「コミットNNNNを元に戻す。PR＃が発生したため」のように単純なものにすることができます。

• パッチがレビューされている場合は、こちらに示すように、レビューページへのリンクを追加します。パッチが GitHub Issues のバグを修正する場合は、こちらで説明されているように、クローズされる Issue への参照を追加することをお勧めします。

• ダウンストリームのコンシューマーを含む、プロセスを自動化するために、コミットメッセージに他のメタデータを追加することも可能です。このメタデータには、コミュニティ全体が利用できないリソースへのリンクを含めることができます。ただし、そのようなリンクやメタデータは、コミットメッセージを自己説明的にする代わりに使用すべきではありません。このような非公開のリンクは、提出されたコードに含めてはならないことに注意してください。

これらの推奨事項の軽微な違反については、コミュニティは通常、コントリビューターにこのポリシーを思い出させることを、リバートよりも優先します。軽微な修正や省略は、コミットメーリングリストに返信を送信することで処理できます。

パッチのリバートポリシー

コミュニティとして、私たちは、迅速な反復開発を可能にしつつ、ツリーの先端を良好な状態に保つことを強く重視しています。そのため、他のオープンソースプロジェクトよりも、ツリーを健全に保つためにリバートを多用する傾向があり、私たちの規範は少し異なります。

誰かがあなたの変更をリバートした場合、どのように対応すべきでしょうか？

• パッチがリバートされるのは正常で健全なことです。パッチがリバートされたからといって、必ずしもあなたが何か間違ったことをしたとは限りません。

• パッチをリバートしてくれた人に、あなたに代わってタスクを実行してくれたことに対して、明確に感謝することをお勧めします。

• 問題に対処するためにさらに情報が必要な場合は、リバートしたパッチの作成者と元のコミットスレッドでフォローアップしてください。

いつ自分の変更をリバートすべきでしょうか？

• 変更に重大な問題があることがわかった場合は、いつでもリバートする必要があります。「修正して前進する」のではなく、「グリーンにリバートする」ことを強くお勧めします。最初にリバートし、オフラインで調査してから、修正されたパッチを再適用することをお勧めします。必要に応じて、別のレビューラウンドを行うこともあります。

• ビルドボットをすぐに修正できない方法で壊した場合、リバートしてください。

• 問題を示すテストケースがコミットスレッドで報告された場合は、リバートしてオフラインで調査してください。

• かなりの量のコミット後レビューフィードバックを受け取った場合は、リバートして、再コミットする前にフィードバックに対処してください。（場合によっては、別のレビューラウンドの後に行います。）

• 他のコントリビューターからリバートを依頼された場合は、リバートして、リクエストのメリットをオフラインで話し合ってください（ただし、そうすることでツリーの先端がさらに不安定になる場合は除きます）。

いつ他の人の変更をリバートすべきでしょうか？

• 一般的に、作成者自身がこれらのガイドラインに従って変更をリバートする場合、他のコントリビューターは作成者への配慮としてリバートすることをお勧めします。これは、私たちの規範が他の規範と大きく異なる主要なケースの1つです。私たちは一般的に、リバートを開発の通常の過程と考えています。コントリビューターが常に利用可能であるとは想定しておらず、問題のあるパッチがリバートされ、次の機会に復帰できるという保証により、これが可能になります。

リバートに関する期待事項は何ですか？

• 最善の判断をしてください。不明な場合は、コミットスレッドでメールを開始して支援を求めてください。私たちはすべてのケースを列挙しようとしているのではなく、一連のガイドラインを提供しようとしています。

• 変更をリバートすることで、ツリーの先端の安定性が向上することを確認する必要があります。場合によっては、一連の変更の1つをリバートすると、状況が改善するどころか悪化する可能性があります。適切なパッチまたはパッチセットがリバートされていることを確認するために、合理的な判断が期待されます。

• リバートコミットのコミットメッセージには、パッチがリバートされる理由を説明する必要があります。

• リバートについて言及した元のコミットメールに返信するのが通例です。これは、パッチがリバートされたことを元の作成者に通知する役割と、llvm-commits をフォローしている他の人がコンテキストを追跡するのに役立つ役割の両方を果たします。

• 理想的には、公開して再現可能なテストケースを共有する準備ができている必要があります。可能な場合は、コミットスレッドまたはPRでテストケースを共有することをお勧めします。リバーターは、テストケースを最小限に抑え、実用的な場合は依存関係を整理することをお勧めします。これは、独自のパッチをリバートする場合にも当てはまります。フォローしている可能性のある他の人々のために理由を文書化することは非常に重要です。

• パッチの作成者が根本原因をデバッグするための手段を提供するという約束なしにリバートすることは合理的とはみなされません。何らかの理由で公開リプロデューサーを共有できない状況が発生した場合（たとえば、パッチの作成者がアクセスできないハードウェアが必要な場合、内部ワークロードのコンパイル時間の大幅な低下など）、リバーターは、パッチの作成者と積極的に協力して、候補パッチのデバッグとテストを行うことが期待されます。

• リバートは、合理的にタイムリーに行う必要があります。2時間前に送信された変更は、事前の議論なしにリバートできます。2年前に送信された変更はリバートできません。正確な移行ポイントは判断が難しいですが、おそらくツリーに数日存在している場合です。不明な場合は、コミットスレッドに返信し、作成者に少し応答する時間を与え、作成者が積極的に応答していないようであればリバートを進めることをお勧めします。

• リバートされたパッチを再適用する場合、コミットメッセージを更新して、対処された問題と対処方法を示す必要があります。

コミットアクセスの取得

高品質なパッチを提出してきた実績のあるコントリビューターにコミットアクセスを付与します。コミットアクセスが必要な場合は、GitHubのユーザー名とともにChrisにメールを送信してください。これは、SVNアクセス権を持つ以前のコントリビューターと新しいコントリビューターの両方に当てはまります。承認されると、GitHubの招待状がGitHubアカウントに送信されます。GitHubから通知が届かない場合は、招待リンクに直接アクセスしてください。招待を受け入れると、コミットアクセス権が付与されます。

コミットアクセスを取得する前は、コミットアクセスを持つ誰かに代わってコミットを依頼するのが一般的です。その場合は、コミットの作成者プロパティで使用したい名前とメールアドレスを指定してください。

外部追跡の目的で、コミットされた変更は、コミットが着陸した後すぐにコミットメーリングリストに自動的に反映されます（例：llvm-commits）。これらのメーリングリストはモデレートされているため、大きなコミットではモデレーターがメールを承認する必要があることは珍しくありません。そのため、コミットがアーカイブにすぐに表示されなくても心配しないでください。

最近コミットアクセスが付与された場合は、これらのポリシーが適用されます

1. LLVMのすべての部分に対して、*承認後コミット*が付与されます。パッチの承認を得る方法については、LLVMコードレビューポリシーとプラクティスを参照してください。承認されると、自分でコミットできます。

2. 明白だと思うパッチは、承認なしでコミットできます。これは明らかに主観的な決定です。私たちは単に、あなたが良識ある判断をすることを期待しているだけです。例としては、ビルドの破損の修正、明らかに壊れたパッチのリバート、ドキュメント/コメントの変更、その他の軽微な変更などがあります。後続の変更を行う予定のないコード以外では、フォーマットまたは空白のみの変更のコミットは避けてください。また、フォーマットまたは空白の変更を、最初にフォーマットを修正するか（理想的には）、または後で行うことで、機能的な変更から分離するようにしてください。このような変更は、非常に局所的である必要があり、コミットメッセージには、コミットが機能を変更することを意図していないことが明確に記載されている必要があります。通常は、NFCと記載されています。

3. 自分が貢献または保守（つまり、責任が割り当てられている）しているLLVMの部分には、ビルドを壊さないという条件付きで、承認なしでパッチをコミットできます。これは「信頼はするが検証する」ポリシーであり、この種のコミットはコミット後にレビューされます.

4. これらのポリシーに複数回違反した場合、または1回重大な違反をした場合、コミットアクセスが取り消される可能性があります。

いずれの場合も、変更は引き続きコードレビューの対象となります（変更の性質に応じて、コミット前またはコミット後）。他の人が作成したパッチもレビューすることをお勧めしますが、必須ではありません。

大きな変更を行う

開発者がLLVMに貢献することを目的とした主要な新しいプロジェクトを開始する場合、可能な限りLLVMディスカッションフォーラムに投稿してコミュニティに知らせる必要があります。これは、以下の理由によります。

1. LLVMの今後の変更についてコミュニティに知らせるため

2. 複数の関係者が同じ作業を行い、互いに知らないことによって作業が重複することを避けるため

3. 提案された作業に関する技術的な問題が、重大な作業が行われる前に議論され、解決されるようにするため

LLVMの設計は、すべてのパーツがうまく適合し、可能な限り一貫性を保つように慎重に管理されています。LLVMの動作方法を大きく変更したり、主要な新しい拡張機能を追加する予定がある場合は、作業を開始する前に開発コミュニティと合意を得るのが良い考えです。

新しい機能の設計が完了したら、作業自体は長期開発ブランチとしてではなく、一連の段階的な変更として行う必要があります。

段階的な開発

LLVMプロジェクトでは、すべての重要な変更を一連の段階的なパッチとして行います。私たちは、大きな変更や長期開発ブランチを非常に嫌います。長期開発ブランチには、次のような多くの欠点があります。

1. ブランチには、メインラインを定期的にマージする必要があります。ブランチ開発とメインライン開発が同じコード部分で行われる場合、マージの競合の解決に多くの時間がかかる可能性があります。

2. コミュニティの他の人は、ブランチの作業を無視する傾向があります。

3. 大きな変更（ブランチがメインラインにマージされたときに発生する）は、コードレビューが非常に困難です。

4. ブランチは、夜間テスターインフラストラクチャによって定期的にテストされません。

5. モノリシックな大きな変更として開発された変更は、多くの場合、変更セット全体が完了するまで機能しません。それを一連の小さな変更に分割することで、作業の一部がメインリポジトリにコミットされる可能性が高まります。

これらの問題に対処するため、LLVMは段階的な開発スタイルを使用しており、コントリビューターは、大規模/侵襲的な変更を行う際にこのプラクティスに従う必要があります。いくつかのヒントを以下に示します。

• 大規模/侵襲的な変更には通常、大きな変更を行う前に必要な多くの二次的な変更があります（APIのクリーンアップなど）。これらの種類の変更は、多くの場合、主要な変更が行われる前に、その作業とは独立して行うことができます。

• 残りの相互に関連する作業は、可能であれば、無関係な変更セットに分解する必要があります。これが完了したら、最初の増分を定義し、変更の最終目標について合意を得ます。

• セット内の各変更は、スタンドアロン（バグを修正するためなど）にすることも、開発目標に向けて機能する計画された一連の変更の一部にすることもできます。

• それぞれの変更は可能な限り小さくするべきです。これは、作業を（論理的な進行に）簡素化し、コードレビューを簡素化し、変更に対して否定的なフィードバックを受ける可能性を減らします。小さな増分は、高品質なコードベースの維持を容易にします。

• 多くの場合、大きな変更を行うための独立した前段階として、新しいAPIを追加し、クライアントが新しいAPIを使用するように徐々に移行することがあります。新しいAPIを使用するための各変更は、多くの場合「明白」であり、レビューなしでコミットできます。新しいAPIが導入され、使用されると、APIの基礎となる実装を置き換えることがはるかに容易になります。この実装の変更は、APIの変更とは論理的に分離されています。

大きな変更を加えたいと考えていて、それが不安な場合は、まず変更について話し合い、コンセンサスを得るようにし、変更を行うための最良の方法について質問してください。

変更の帰属

コントリビューターがLLVMプロジェクトにパッチを提出すると、コミットアクセス権を持つ他の開発者は、適切な場合（コードレビューの進行状況などに基づいて）、作成者の代わりにコミットすることができます。その際、貢献者への貢献の正しい帰属を保持することが重要です。しかし、ソースコードに「このコードはJ. Random Hackerによって書かれた」のようなランダムな帰属で埋め尽くされることは望ましくありません（これはノイズが多く、気が散ります）。実際には、リビジョン管理システムは誰が何を変更したかの完全な履歴を保持しており、CREDITS.txtファイルにはより高レベルの貢献が記述されています。他の誰かのパッチをコミットする場合は、コミットメッセージセクションで概説されている簡単な方法で変更の帰属に従ってください。全体的に、ソースコードに貢献者の名前を追加しないでください。

また、パッチの作成者がプロジェクトにパッチを提出していない場合、または作成者に代わってパッチを提出する権限を与えられていない場合（一緒に仕事をしていて、会社がパッチを貢献することを許可している場合など）は、他の人が作成したパッチをコミットしないでください。作成者は、最初に関連するプロジェクトのコミットリスト、開発リスト、またはLLVMバグトラッカーコンポーネントにパッチを提出する必要があります。誰かがあなたに個人的にパッチを送ってきた場合は、最初に適切なリストに提出するように促してください。

以前のバージョン管理システム（Subversion）は、gitのように作成者とコミッターを区別していませんでした。そのため、古いコミットでは異なる属性メカニズムが使用されていました。以前の方法は、コミットメッセージの別の行に「Patch by John Doe.」を含めることであり、この形式に依存する自動化されたプロセスがあります。

禁止

禁止の目的は、コミュニティの人々がLLVMプロジェクトスペースでLLVMコミュニティ行動規範を常に尊重していない人々と対話しなければならないことから保護することです。あらゆる種類の貢献（プルリクエスト、課題レポート、フォーラムへの投稿など）には、コミュニティとの対話が必要です。そのため、禁止された個人からのいかなる形式の直接的な貢献も受け付けていません。

間接的な貢献は、そのような貢献の完全な所有権を持つ人が許可されており、その貢献に関するコミュニティとのすべての関連する対話に責任を負います。

特定の状況でどのように行動すべきか疑問がある場合は、conduct@llvm.orgに連絡してアドバイスを求めてください。

IR後方互換性

IRフォーマットを変更する必要がある場合は、ある程度の後方互換性を維持しようとしていることに留意してください。これらのルールは、llvmユーザーの利便性とllvm開発者への大きな負担を課さないことのバランスをとることを目的としています。

• テキスト形式は後方互換性がありません。あまり頻繁に変更することはありませんが、具体的な約束はありません。

• IRへの追加と変更は、test/Bitcode/compatibility.llに反映されるべきです。

• 現在のLLVMバージョンは、バージョン3.0以降のすべてのビットコードの読み込みをサポートしています。

• 各X.Yリリース後、compatibility.llをcompatibility-X.Y.llにコピーする必要があります。対応するビットコードファイルは、X.Yビルドを使用してアセンブルし、compatibility-X.Y.ll.bcとしてコミットする必要があります。

• 新しいリリースは、古いリリースの機能を無視できますが、誤ってコンパイルすることはできません。たとえば、nswが他のものに置き換えられた場合、それを削除することはIRをアップグレードする有効な方法です.

• デバッグメタデータは、アップグレード中に削除されるという点で特殊です。

• 非デバッグメタデータは削除しても安全であると定義されているため、アップグレードする有効な方法は削除することです。それはあまりユーザーフレンドリーではなく、もう少し努力が必要ですが、約束はありません。

C APIの変更

• 安定性の保証：C APIは、一般的に、安定性のために「最善の努力」です。これは、C APIを安定させるためにあらゆる努力を払いますが、安定性はインターフェースの抽象性とそれがラップするC++ APIの安定性によって制限されることを意味します。実際には、これは「デバッグ情報の作成」や「このタイプの命令の作成」のようなものは、「このIRファイルを取得して現在のマシン用にJITコンパイルする」よりも安定性が低い可能性が高いことを意味します。

• リリースの安定性：リリースブランチに適用されるパッチによってリリースブランチのC APIを壊すことはありません。ただし、リリースを以前のリリースと次のリリースの両方と整合させるために、意図しないC APIの破損を修正する場合は例外です。

• テスト：C APIへのパッチは、他のパッチと同様にテストを伴うことが期待されます。

• APIへの新しいものの追加：LLVMサブコンポーネントにすでにC APIが含まれている場合、そのC APIを拡張することは許容されます。現在C APIを持たないサブコンポーネントにC APIを追加するには、実装前にLLVM Discourseフォーラムで設計と保守性に関するフィードバックについて話し合う必要があります。

• ドキュメント：C APIへの変更は、リリースノートに文書化する必要があります。これにより、プロジェクトをフォローしていない外部ユーザーに、C APIがどのように変化し進化しているかを明確にすることができます。

ツールチェーン要件の更新

私たちは、時間の経過とともに新しいツールチェーンを要求する予定です。これは、LLVMのコードベースが標準化されるにつれて、新しいバージョンのC++を使用できることを意味します。LLVMをビルドするために新しいツールチェーンを要求することは、LLVMをビルドする人々にとって苦痛となる可能性があります。そのため、次のプロセスを通じてのみ行われます。

• 少なくとも過去3年間のLLVMとGCCのバージョンをサポートすることを一般的な目標としています。この時間ベースのガイドラインは厳密ではありません。はるかに古いコンパイラをサポートしたり、より少ないバージョンをサポートすることを決定したりする場合があります。

• RFCがLLVM Discourseフォーラムに送信されます。

  • バージョンアップのメリットを詳細に説明します（例：LLVMが使用する新しいC++言語またはライブラリ機能、特定のコンパイラバージョンの誤ったコンパイルの回避など）。

  • 重要なプラットフォーム（例：Ubuntu LTSステータス）のデメリットを詳細に説明します。

• RFCがコンセンサスに達したら、CMakeツールチェーンのバージョンチェックと入門ガイドを更新します。CMakeフラグを使用してエラーを警告に変換できるため、LLVMをコンパイルする開発者にとって、よりスムーズな移行パスが提供されます。これは重要なステップです。LLVMはまだ新しいツールチェーンを必要とするコードを持っていませんが、すぐに必要になります。LLVMをコンパイルしてもフォーラムを読まない場合は、今後の変更について知らせる必要があります！

• 少なくとも1つのLLVMリリースでこのソフトエラーが発生していることを確認してください。すべての開発者がLLVMのトップオフトゥリーをコンパイルするわけではありません。これらのリリースバウンドの開発者にも、今後の変更について知らせる必要があります。

• 上記のLLVMリリースがブランチされた後、ソフトエラーをハードエラーに変換します。

• RFCで明示的に承認した新しい機能を許可するように、コーディング標準を更新します。

• LLVMのコードベースで新しい機能の使用を開始します。

RFCの例と対応する変更を次に示します。

CIシステムでの作業

LLVMプロジェクトの主要な継続的インテグレーション（CI）ツールは、LLVM Buildbotです。さまざまなサブプロジェクトと構成をカバーするために、異なる*ビルダー*を使用しています。ビルドは、異なる*ワーカー*で実行されます。ビルダーとワーカーは、コミュニティメンバーによって構成および提供されます。

Buildbotは、メインブランチとリリースブランチのコミットを追跡します。これは、パッチがこれらのブランチにマージされた後にビルドおよびテストされることを意味します（マージ後テストとも呼ばれます）。これは、コントリビューターがすべてのパッチをすべての可能な構成でビルドおよびテストすることを期待するのは合理的ではないため、ビルドを gelegentlich 中断しても問題ないことも意味します。

コミットがビルドを中断した場合

• 他のコントリビューターまたはダウンストリームユーザーがブロックされる可能性があるため、できるだけ早くビルドを修正してください。

• バグの分析と修正にさらに時間が必要な場合は、変更を元に戻して他のユーザーのブロックを解除してください。

他の誰かがビルドを中断し、これがあなたの仕事をブロックしている場合

• GitHubのコードレビューにコメントするか（利用可能な場合）、作成者にメールを送信し、問題とそれがあなたに与える影響を説明してください。関係者が問題を理解できるように、壊れたビルドとエラーメッセージへのリンクを追加してください。

• これがあなたの仕事をブロックしている場合は、コミットを元に戻してください。revert_policyを参照してください。

ビルド/ワーカーが恒久的に壊れている場合

• 最初のステップ：ワーカーの所有者に連絡してください。ワーカーの*管理者*の名前と連絡先情報は、ビルドのページの*ワーカー*タブにあります。

  

• 2番目のステップ：所有者が応答しない、またはワーカーを修正しない場合は、BuildBotマスターのメンテナーであるGalina Kostanovaにエスカレーションしてください。

• 3番目のステップ：Galina がお手伝いできない場合は、インフラストラクチャワーキンググループにエスカレーションしてください。

LLVMへの新しいコンポーネントの導入

LLVMコミュニティは活気に満ちた刺激的な場所で、新しいプロジェクトを取り込み、新しいコミュニティを育成し、産業界と学術界全体のコラボレーションを促進することを目指しています。

とはいえ、新しいアイデアや人材を受け入れることと、新しいコードに必要な継続的なメンテナンスのコストとのバランスを取る必要があります。そのため、LLVMの世界に主要な新しいコンポーネントを導入するための、必要な詳細度と責任の度合いに応じた、一般的なサポートポリシーがあります。*コア*プロジェクトは*周辺*プロジェクトよりも高いレベルの精査が必要であり、後者には追加の違いがある場合があります。

ただし、これは実際には発生する一般的なケースを網羅することを目的としているに過ぎません。状況はそれぞれ異なり、珍しいケースについても話し合うことができます。 LLVMディスカッションフォーラムでRFCスレッドを開始してください。

新しいターゲットの追加

LLVMは、実験的なものであっても新しいターゲットを非常に歓迎しますが、大量の新しいコードを追加すると多くの問題が発生する可能性があり、バックエンドは通常まとめて追加されます。新しいターゲットは、コンパイラの他の*コア*部分と同じレベルのサポートを必要とするため、サポートポリシーの*コア層*でカバーされます。

大量の新しいコードを導入してから、ツリー内で発生した問題を修正しようとすると、さまざまな理由で問題が発生することがわかりました。これらの理由から、新しいターゲットは安定していることが証明され、後で実験的ではないものに移行されるまで、*常に***実験的*として追加されます。

両方のクラスの違いは次のとおりです

• 実験的なターゲットはデフォルトではビルドされません（CMake時に明示的に有効にする必要があります）。

• 実験的なターゲットが有効になっている場合にのみ発生し、ターゲットとは無関係の変更によって引き起こされるテストの失敗、バグ、およびビルドの破損は、ターゲットの背後にあるコミュニティが修正する責任があります。

バックエンドが**実験的**モードでアップストリームされるための基本的なルールは次のとおりです

• すべてのターゲットにはコードオーナーが必要です。 `CODE_OWNERS.TXT`ファイルは、最初のマージの一部として更新する必要があります。コードオーナーは、ターゲットへの変更がレビューされることを確認し、全体的な取り組みを主導します。

• ターゲットの背後にはアクティブなコミュニティが必要です。このコミュニティは、ビルドボットを提供し、バグを修正し、LLVMコミュニティの質問に答え、新しいターゲットが他のターゲットや汎用コードを壊さないことを確認することにより、ターゲットの維持を支援します。この動作は、ターゲットのコードの存続期間中継続されることが期待されます。

• コードには、IRの動作方法やフロントエンドによる形成方法の大幅な変更など、議論の余地のある問題があってはなりません。ただし、IR後方互換性に従って、新しいターゲットの変更をマージする**前**に、(IR標準)のリファクタリングを通じてコミュニティの大多数が同意した場合を除きます。

• コードは、ライセンス、特許、コーディング標準など、この開発者ポリシー文書に記載されているすべてのポリシーに準拠しています。

• ターゲットには、その仕組み（ISA、ABIなど）に関する適切なドキュメント、または公開されているシミュレーター/ハードウェア（無料または十分に安価なもの）のいずれかが必要です。できれば両方です。これにより、開発者は前提条件を検証し、制約を理解し、ターゲットに影響を与える可能性のあるコードをレビューできます。

さらに、バックエンドを**公式**に昇格させるためのルールは次のとおりです

• ターゲットは、他のすべての最小要件を満たし、ツリー内で少なくとも3か月間安定している必要があります。このクールダウン期間は、バックエンドとターゲットコミュニティが予見可能な将来にわたって継続的なアップストリーム開発に耐えることができるようにするためです。

• ターゲットのコードは、このポリシーとコーディング標準に完全に適合している必要があります。実験モードに移行するために行われた例外は、公式になる**前**に修正する必要があります。

• テストカバレッジは広範囲で、適切に記述されている必要があります（小規模なテスト、適切に文書化されている）。ビルドターゲットcheck-allは、新しいターゲットがビルドされた状態で合格する必要があり、該当する場合は、test-suiteも少なくとも1つの構成でエラーなしで合格する必要があります（ビルドボットなどを介して公開デモンストレーション）。

• ターゲットに追加のビルドボットが不要な場合（例：check-allがすべてのテストをカバーする場合）を除き、パブリックビルドボットを作成し、積極的にメンテナンスする必要があります。新しいターゲットのCIインフラストラクチャが関連性が高く、公開されているほど、LLVMコミュニティはそれを受け入れます。

サポートされ、公式のターゲットとして**継続**するには

• メンテナーは、ターゲットの存続期間中、これらのルールに従い続ける必要があります。上記のルールとポリシーに継続的に違反すると、コードベースからターゲットが完全に削除される可能性があります。

• サポート、ドキュメント、またはテストカバレッジの低下は、ターゲットを他のターゲットにとって迷惑なものにし、非推奨の候補と見なされ、最終的には削除されます。

本質的に、これらのルールはターゲットがステータスを獲得して維持するために必要ですが、ビット腐敗を定義するためのマーカーでもあり、メンテナンスされていないターゲットからツリーをクリーンアップするために使用されます。

LLVMに新しいターゲットを追加したい人は、以下の手順に従う必要があります

1. このセクションを読み、ターゲットがすべての要件を満たしていることを確認してください。軽微な問題については、コミュニティは最初のマージ後すぐに必要な調整を行う責任があります。

2. LLVMディスカッションフォーラムに、ターゲットとそのすべての要件への準拠方法、および公式ターゲット要件に対応するために行われた作業と行う必要がある作業について説明する、コメントのリクエスト（RFC）を送信します。基本コード、テーブルgenなどで必要なすべての議論の余地のある問題、変更を必ず公開してください。

3. 応答が肯定的になったら、LLVMコミュニティは実際のパッチのレビューを開始できます（ただし、RFCをサポートするために事前に準備できます）。「1 / N」から「N / N」までの番号が付けられたN個のパッチのシーケンスを作成します（Nが実際の数字であり、文字「N」ではないことを確認します）。これにより、ターゲットの基本構造が完成します。

4. 最初のパッチでは、clangとLLVMにドキュメント、コードオーナー、トリプルサポートを追加する必要があります。後続のパッチは、ターゲットを記述し、命令をアセンブリに下げるためのTableGenインフラストラクチャを追加します。最後のパッチは、ターゲットが umfassende LITテスト（IRからMIR、MIRからASMなど）で正しく下げることができることを示している必要があります。

5. 一部のパッチは他のパッチの前に承認される場合がありますが、*すべて*のパッチが承認された後にのみ、セット全体を一度にマージできます。これは、すべての変更が単一のブロックとして良好であることを保証するためです。

6. 最初のマージ後、ターゲットコミュニティはパッチの番号付けを停止し、ターゲットのサポートを完了するために非同期的に作業を開始できます。進捗状況が依然として一貫していることを確認するために、初期段階で支援してくれた人からのレビューを引き続き求める必要があります。

7. すべての公式要件が満たされたら（上記のとおり）、コードオーナーは、LLVMディスカッションフォーラムに別のRFCを送信することにより、ターゲットをデフォルトで有効にすることを要求する必要があります。

既存のプロジェクトをLLVMモノレポに追加する

LLVMモノレポは、LLVMの世界における開発の中心点であり、LLVMオプティマイザーとコードジェネレーター、Clang、LLDBなどを含むすべての主要なLLVMコンポーネントを備えています。 モノレポ全般は、プロジェクトへのアトミックコミットを可能にし、CIを簡素化し、サブコミュニティのコラボレーションを容易にするため、優れています。

新しいターゲットと同様に、モノレポにすでに存在するほとんどのプロジェクトは、サポートポリシーの*コア層*にあると見なされます。LLVMモノレポにものを追加するための負担は非常に大きくなければなりません。このリポジトリに追加されたコードは、コミュニティのすべての人によってチェックアウトされます。そのため、コンポーネントを「公式ターゲット」と同様の高い基準に保ちます。それらは

• コンパイラ、言語、ツール、ランタイムなどを進化させるというLLVMプロジェクトの使命と概ね一致している必要があります。

• ライセンス、特許、コーディング標準、行動規範など、この開発者ポリシー文書に記載されているすべてのポリシーに準拠している必要があります。

• 確立されたコードオーナーを含む、コードを維持するアクティブなコミュニティが必要です。

• 高品質のREADMEファイルを含む、その仕組みに関する適切なドキュメントが必要です。

• プロジェクト自体内または基盤となるLLVMの依存関係のために破損をキャッチするためのCIが必要です。

• コミュニティが議論の余地があると感じる問題のないコード、またはそれらを解決するための明確なパス上にある必要があります。

• LLVM RFCプロセスを通じて提案され、LLVMコミュニティによって追加が承認されている必要があります。これは最終的に上記の「すべき」懸念事項の解決を仲介します。

LLVMモノレポに追加するのが理にかなっていると思われるプロジェクトがある場合は、LLVMディスカッションフォーラムでRFCトピックを開始して、ディスカッションを開始してください。このプロセスには時間がかかり、反復が必要になる場合があります。落胆したり、怖がったりしないでください！

LLVMと連携していると思われる初期段階のプロジェクトがある場合は、「新しいプロジェクトのインキュベート」セクションを参照してください。

新しいプロジェクトのインキュベート

LLVMモノレポに新しいプロジェクトを追加するための負担は意図的に非常に高くなっていますが、それは新しく革新的なプロジェクトに悪影響を与える可能性があります。このようなプロジェクトを促進するために、LLVMは、開始がはるかに簡単な「インキュベーター」プロセスをサポートしています。潜在的に価値のある新しいトップレベルおよびサブプロジェクトが、その有用性を証明し、コミュニティを成長させるのに十分なコードを持つ前に、臨界量に達するためのスペースを提供します。これにより、LLVMの傘下にあるプロジェクトにすでに貢献する権限を持っているチーム間のコラボレーションも可能になります。

LLVMインキュベーターの対象となるプロジェクトは、次の基準を満たしています

• コンパイラ、言語、ツール、ランタイムなどを進化させるというLLVMプロジェクトの使命と概ね一致している必要があります。

• この開発者ポリシー文書に記載されているライセンス、特許、および行動規範のポリシーに準拠している必要があります。

• READMEファイル、ミッションステートメント、マニフェストなどの形式で、文書化された憲章と開発計画が必要です。

• コーディング標準、段階的な開発プロセス、その他の期待に準拠する必要があります。

• 最終的に育成したいと考えているコミュニティの感覚があり、異なる所属/組織のメンバーからの関心があるはずです。

• 最終的に、LLVMモノレポ内の専用トップレベルまたはサブプロジェクトとして卒業するための実現可能なパスを持っている必要があります。

• プロジェクトが「インキュベーションステータス」にあり、LLVMリリースに含まれていないことを示す通知（例：プロジェクトのREADMEまたはWebページ）を含める必要があります（下記の推奨文言を参照）。

• LLVM RFCプロセスを通じて提案され、LLVMコミュニティによって追加が承認されている必要があります。これは最終的に上記の「すべき」懸念事項の解決を仲介します。

とはいえ、プロジェクトを開始するためにコードは必要なく、確立されたコミュニティもまったく必要ありません！さらに、インキュベーション中のプロジェクトは、上記の「推奨」ガイドラインに違反する一時的な状態、またはモノレポに直接含めるのに適さない状態（例：まだ適切に要素化されていない依存関係、まだアップストリームではない実験的なコンポーネントまたはAPIの活用など）を経ることがあります。

承認されると、llvm-adminグループは新しいプロジェクトに以下を付与できます。

• LLVM Github Organization内の新しいリポジトリ - ただしLLVMモノレポではありません。

• 他のLLVMフォーラムでホストされる新しいメーリングリスト、ディスカッションフォーラム、および/またはDiscordチャット。

• その他のインフラストラクチャの統合は、ケースバイケースで議論できます。

モノレポへの卒業は、モノレポの正式な一部になるための既存のプロセスと標準に従います。同様に、インキュベーション中のプロジェクトは最終的に廃止される場合がありますが、そのためのプロセスはまだ確立されていません。これが発生した場合、LLVMディスカッションフォーラムでRFCディスカッションを開始してください。

このプロセスは非常に新しいものです。詳細が変更されることを想定してください。この件については、LLVMディスカッションフォーラムで質問するのが常に安全です。

プロジェクトのREADMEおよびメインプロジェクトのWebページの推奨免責事項

This project is participating in the LLVM Incubator process: as such, it is
not part of any official LLVM release.  While incubation status is not
necessarily a reflection of the completeness or stability of the code, it
does indicate that the project is not yet endorsed as a component of LLVM.

著作権、ライセンス、および特許

注記

このセクションは法的問題を扱いますが、法的助言を提供するものではありません。私たちは弁護士ではありません。資格のある弁護士から法的助言を求めてください。

このセクションでは、LLVMプロジェクトの著作権、ライセンス、および特許の問題について説明します。コードの著作権は、コードの貢献者に帰属します。コードは、許可的なオープンソースライセンス条項、つまりLLVM例外付きApache-2.0ライセンスの下でライセンスされています。これには、著作権と特許ライセンスが含まれています。LLVMプロジェクトにコードを貢献すると、これらの条件の下でライセンスが付与されます。

特定の状況では、他のライセンスの下でライセンスされているコードをコードベースに追加できます。ただし、これはLLVM Foundation理事会の承認を得てのみ行うことができ、貢献者は承認プロセスに少なくとも4〜6週間かかることを計画する必要があります。別のライセンスの下でコードを貢献したい場合は、貢献したいコードを含むプルリクエストを作成し、board@llvm.orgにレビューをリクエストするメールを送信してください。

これらのトピックについて質問やコメントがある場合は、LLVMディスカッションフォーラムでお問い合わせください。ただし、ほとんどのコンパイラ開発者は弁護士ではないため、公式の法的助言を得られないことに注意してください。

著作権

LLVMプロジェクトは著作権譲渡を収集しません。つまり、プロジェクト内のコードの著作権は、それぞれの貢献者に帰属します。あなた（またはあなたの会社）は、あなたが貢献したコードの所有権を保持しているため、貢献したオープンソースライセンスの条件の下でのみ使用できることを知っています。あなたの貢献のライセンスは、あなたの承認なしに将来変更することはできません。

LLVMプロジェクトは著作権譲渡を必要としないため、LLVMライセンスを変更するには、LLVMの貢献者を追跡し、ライセンスの変更が彼らの貢献に対して受け入れられることに同意してもらう必要があります。貢献者は、自分のコードが自分が同意しない方法で使用されることを恐れる必要がないため、再ライセンスの負担が大きいことはプロジェクトにとって良いことだと考えています。

再ライセンス

前項にかかわらず、LLVMプロジェクトは、いくつかの問題を解決することを目的とした、ライセンスを変更するための大規模な取り組みの真っ最中です。

• 古いライセンスでは、ランタイムライブラリがコンパイラの残りの部分とは異なるライセンスを使用していたため、コードを（たとえば）コンパイラからランタイムライブラリに移動することが困難でした。

• プロジェクトで必要な特許付与が広すぎるとの懸念から、LLVMに提出されなかった貢献もありました。

• 特許付与はLLVMプロジェクトに固有のもので、弁護士によって書かれたものではなく、どのような保護が提供されているか（もしあれば）を判断するのが困難でした。

再ライセンスの範囲は、LLVMプロジェクトの一部と見なされるすべてのコードであり、メインのLLVMリポジトリ、ランタイムライブラリ（compiler_rt、OpenMPなど）、Polly、およびその他すべてのサブプロジェクトが含まれます。いくつかの例外があります。

• 他のプロジェクト（例：Google Test、Autoconfなど）からインポートされたコードはそのまま残ります。このコードはLLVMプロジェクトの一部として開発されたものではなく、LLVMによって使用されています。

• 一部のサブプロジェクトは、再ライセンスするには実用的でないか、興味深いものではありません（例：llvm-gccおよびdragonegg）。これらはLLVMプロジェクトから分離され（例：個別のGitHubプロジェクトに）、興味のある人が他の場所で開発を継続できるようにします。

LLVMを再ライセンスするには、リポジトリ内のコードのすべての著作権所有者から承認を求めるか、できない場合はコードを削除/書き直す可能性があります。これは、完了するまでにかなりの時間がかかる、大規模で困難なプロジェクトです。

2024年6月1日から、新しい貢献は新しいLLVMライセンス、つまりLLVM例外付きApache-2.0の対象となる必要があります。この日付より前は、プロジェクトではすべての貢献が新しいライセンスとレガシーライセンスの両方で作成される必要がありました。

2019年1月19日より前にコミットされた貢献があり、まだそうしていないLLVMの貢献者の場合は、https://foundation.llvm.org/docs/relicensing/の「個々の再ライセンス契約」セクションの手順に従って、新しいライセンスの下で貢献を再ライセンスしてください。

新しいLLVMプロジェクトライセンスフレームワーク

LLVMへの貢献は、Apache License, Version 2.0の下でライセンスされており、LLVMが非常に寛容にライセンスされていることを保証するための2つの限定的な例外があります。まとめて、このライセンスの名前は「LLVM例外付きApache 2.0ライセンス」です。例外は次のとおりです。

---- LLVM Exceptions to the Apache 2.0 License ----

As an exception, if, as a result of your compiling your source code, portions
of this Software are embedded into an Object form of such source code, you
may redistribute such embedded portions in such Object form without complying
with the conditions of Sections 4(a), 4(b) and 4(d) of the License.

In addition, if you combine or link compiled forms of this Software with
software that is licensed under the GPLv2 ("Combined Software") and if a
court of competent jurisdiction determines that the patent provision (Section
3), the indemnity provision (Section 9) or other Section of the License
conflicts with the conditions of the GPLv2, you may retroactively and
prospectively choose to deem waived or otherwise exclude such Section(s) of
the License, but only in their entirety and only with respect to the Combined
Software.

私たちは、LLVMを永続的にオープンソースとして、寛容なライセンスの下で利用できるようにすることを目指しています。これにより、**商用製品をLLVMから派生させること**をほとんど制限なく、派生物もオープンソースにする必要なく、LLVMの最も幅広い採用を促進します。特に、LLVMのライセンスは、GPLのような「コピーレフト」ライセンスではありません。

「LLVM例外付きApache 2.0ライセンス」では、以下のことができます。

• 個人、社内、または商用目的でLLVMを（全体または一部）自由にダウンロードして使用できます。

• 作成したパッケージまたは配布物にLLVMを含めることができます。

• LLVMを他のすべての主要なオープンソースライセンス（BSD、MIT、GPLv2、GPLv3…を含む）の下でライセンスされているコードと組み合わせることができます。

• プロジェクトに貢献することなくLLVMコードに変更を加えることができます - 貢献は大歓迎ですが！

ただし、以下の制限が課せられます。

• LLVMを再配布する場合は、著作権表示を保持する必要があります。著作権ヘッダーを取り除いたり、独自のヘッダーに置き換えたりすることはできません。

• LLVMを含むバイナリは、LLVMコードがコンパイルの副産物として追加された場合を除き、著作権表示を再現する必要があります（例：付属のREADMEファイルまたは「バージョン情報」ボックス）。たとえば、compiler_rtやlibc++などのLLVMランタイムライブラリがコンパイラによってアプリケーションに自動的に含まれていた場合、それを属性する必要はありません。

• 当社の名前を使用して製品（LLVM派生物かどうか）を宣伝することはできません。ただし、当社のスポンサーシップを暗示することなく、LLVMコードの使用について真実を述べることができます。

• LLVMには一切保証がありません。

私たちはLLVMコードが広く使用されることを望んでおり、これがプロジェクトの貢献者とユーザーにとって素晴らしいモデルを提供すると信じています。Apache 2.0ライセンスの詳細については、Apacheプロジェクトによって管理されているApache License FAQを参照してください。

特許

Apache 2.0ライセンスのセクション3は、プロジェクトへのコードの貢献者が、そのコードの貢献によって侵害される可能性のある特許を使用する権利を貢献する特許付与です（そのコードの使用を保護します）。さらに、LLVMのコードに関する特許訴訟を起こした人からは特許付与が取り消されます。これは、コードベースに「特許コモンズ」を提供し、特許訴訟の可能性を全般的に減らすことにより、コミュニティを保護します。

ライセンスは、コードの貢献に含まれる特許の範囲を具体的に定めています。これを説明するために、Apache License FAQでは、いくつかの質問と回答を使用してこの範囲を説明しています。便宜上、ここで再現します（参考までに、「ASF」はApache Software Foundationですが、ガイダンスは引き続き有効です）。

Q1: If I own a patent and contribute to a Work, and, at the time my
contribution is included in that Work, none of my patent's claims are subject
to Apache's Grant of Patent License, is there a way any of those claims would
later become subject to the Grant of Patent License solely due to subsequent
contributions by other parties who are not licensees of that patent.

A1: No.

Q2: If at any time after my contribution, I am able to license other patent
claims that would have been subject to Apache's Grant of Patent License if
they were licensable by me at the time of my contribution, do those other
claims become subject to the Grant of Patent License?

A2: Yes.

Q3: If I own or control a licensable patent and contribute code to a specific
Apache product, which of my patent claims are subject to Apache's Grant of
Patent License?

A3:  The only patent claims that are licensed to the ASF are those you own or
have the right to license that read on your contribution or on the
combination of your contribution with the specific Apache product to which
you contributed as it existed at the time of your contribution. No additional
patent claims become licensed as a result of subsequent combinations of your
contribution with any other software. Note, however, that licensable patent
claims include those that you acquire in the future, as long as they read on
your original contribution as made at the original time. Once a patent claim
is subject to Apache's Grant of Patent License, it is licensed under the
terms of that Grant to the ASF and to recipients of any software distributed
by the ASF for any Apache software product whatsoever.

レガシーライセンス構造

注記

コードベースは、以前にここで説明されている条件の下でライセンスされていました。私たちは、新しいアプローチ（上記で説明）への再ライセンスの真っ最中です。LLVMへのすべての貢献の99％以上は、LLVM例外付きApache-2.0ライセンスの対象となります。LLVMコードのごく一部は、レガシーライセンスの対象となっています。2024年6月1日以降の貢献は、新しいライセンスのみに基づいています。

私たちは、LLVMを永続的にオープンソースとして、寛容なオープンソースライセンスを使用することを目指しています。LLVMのコードは、イリノイ大学/NCSAオープンソースライセンスの下で利用可能です。これは、次のようになります。

• LLVMを自由に配布できます。

• LLVMを再配布する場合は、著作権表示を保持する必要があります。

• LLVMから派生したバイナリは、著作権表示を再現する必要があります（例：付属のREADMEファイル）。

• 当社の名前を使用して、LLVM派生製品を宣伝することはできません。

• LLVMには一切保証がありません。

これは、**商用製品をLLVMから派生させること**をほとんど制限なく、派生物もオープンソースにする必要なく（つまり、LLVMのライセンスはGPLのような「コピーレフト」ライセンスではありません）、LLVMの最も幅広い採用を促進すると考えています。詳細な説明が必要な場合は、ライセンスをお読みになることをお勧めします。

UIUCライセンスに加えて、LLVMのランタイムライブラリコンポーネント（compiler_rt、libc++、およびlibclc）は、バイナリ再配布条項を含まないMITライセンスでもライセンスされています。これらのランタイムライブラリのユーザーとして、あなたはどちらのライセンスの下でコードを使用するかを選択できます（そのため、バイナリ再配布条項は必要ありません）。また、コードの貢献者として、これらのライブラリへの貢献は両方のライセンスの下でライセンスされることに同意します。ランタイムライブラリはアプリケーションに暗黙的にリンクされるため、アプリケーションにバイナリ再配布条項を課すべきではないため、これは重要であると考えています。これはまた、（例えば）libc++からLLVMコアにコードを移動することは問題ありませんが、著作権所有者の許可なしにLLVMコアからlibc++にコードを移動することはできないことも意味します。