@@ -64,10 +64,10 @@ Instead edit toc_template.md
     * [Communication Tooling](../translation/japanese/patterns/communication-tooling.md) - InnerSourceのプロジェクトは、元の開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取るのに苦労しています。このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
     * [Contracted Contributor](../translation/japanese/patterns/contracted-contributor.md) - InnerSourceにコントリビュートしたいアソシエイツは、彼らのライン管理によってそうすることから落胆しています。救済は、正式な契約や協定によって提供されています。
     * [Gig Marketplace](../translation/japanese/patterns/gig-marketplace.md) - マネージャーと従業員のどちらも、彼らはInnerSourceプロジェクトに関与して得ることから利益を得るかもしれない方法を理解しています。  それは従業員のために彼らはInnerSourceプロジェクトにする必要がありますどのような時間のコミットメントを彼らの経営にcomamunicateすることは困難である。
-    * [InnerSource License](../translation/japanese/patterns/innersource-license.md) - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいが、法的責任や会社間の会計処理の観点からの影響を懸念している。
     * [InnerSource Portal](../translation/japanese/patterns/innersource-portal.md) - 潜在的なコントリビューターは、彼らが興味を持っているInnerSourceプロジェクトを簡単に見つけることができません。すべての利用可能なInnerSourceプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて学ぶことができ、InnerSourceプロジェクトの所有者は、外部の聴衆を引き付けることができます。
     * [Issue Tracker Use Cases](../translation/japanese/patterns/issue-tracker.md) - InnerSourceのホストチームは、計画や進捗だけでなく、変更の背景も透明化できていません。これは、プロジェクトの課題トラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決されます。
     * [RFCを用いたチーム横断的な意思決定の透明化](../translation/japanese/patterns/transparent-cross-team-decision-making-using-rfcs.md) - 高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいInnerSourceプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC（Requests for Comments）ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。
+    * [インナーソースライセンス](../translation/japanese/patterns/innersource-license.md) - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。
     * [クロスチーム プロジェクト評価](../translation/japanese/patterns/crossteam-project-valuation.md) - 会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します
     * [コアチーム](../translation/japanese/patterns/core-team.md) - インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
     * [サービス vs. ライブラリー](../translation/japanese/patterns/service-vs-library.md) - DevOps環境のチームは、サービスのダウンタイムに誰が対応するのかが曖昧なため、チームの境界を越えて共通のコードベースで作業することに消極的かもしれません。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーションを別々に行うか、多くの共有コードを1つのライブラリにまとめて、その上でコラボレーションすることが可能な場合が多いことを認識することです。