10.3 調達、オープンソース、ライセンス

概要と動機

現代のほぼすべてのソフトウェアシステムは、ほとんどが誰か他の人が書いたコンポーネントから組み立てられています。オープンソースソフトウェアは、オペレーティングシステム、言語、フレームワーク、データベース、クラウドインフラストラクチャの基礎を成しています。それは二つの道で企業に入ってきます。意図した調達を通じて、そして個々の開発者の何気ないimport文を通じて。この章は、その消費(そして適する場合は貢献)を、意図して行うことについてです。つまり、戦略、ライセンスのコンプライアンス、義務とコピーレフトのリスクの理解、そして依存するコンポーネントが避けられずに迎える寿命の終わりへの計画です。

大きなチームにとって、賭け金は法的、運用的、戦略的に同時に存在します。法的には、オープンソースのライセンスは、本物の義務を伴う、強制力のある契約です。コピーレフト(派生物を同じ条件で共有することを要求しうるライセンス)を誤ると、最悪の場合、独自のソースの開示を強制されたり、訴訟を招いたりしえます。ライセンス違反は、デューデリジェンスの際に、買収や株式公開を妨げることさえありえます。運用的には、管理されない依存関係は腐ります。コンポーネントは保守されなくなり、脆弱性を蓄積し、本番の奥深くに埋まったまま寿命の終わりに達します。戦略的には、オープンソースは単なるコスト削減の入力ではありません。ロックインを避け、人材を引きつけ、依存するエコシステムを形づくる方法で、意図して関与する場合にのみ得られる利点です。

政府には、さらに次元が加わります。多くの法域が今や、オープンソース、オープン標準、機関間のコード共有を好む明示的な方針を持っています。これらはしばしば「公金には公開コード」として表現されます。納税者が資金を出したソフトウェアは、既定で公衆が利用できるべきだという原則です。したがって公共部門のエンジニアは、ライセンスのコンプライアンスと、オープンソースを好み、公開し、再利用するという積極的な義務づけの両方を乗りこなさなければなりません。この章は、そのすべてを規模で管理可能にすることを目指します。

主要原則

オープンソースは無料の品ではなく、サプライチェーンである。 消費するコンポーネントを、他のあらゆる重要なサプライヤーと同じ厳密さで扱います。
ライセンスは無視してよい許可ではなく、義務である。 すべての依存関係は条件を伴います。出荷する前にそれを知ります。
コピーレフトはタブーではなく、設計上の制約である。 コピーレフトのライセンスは使えて価値があります。ソフトウェアをどう組み合わせて配布するかを理解することが必要なだけです。
意図して消費し、戦略的に貢献する。 何を取り込むかを決め、役立つ所では、フォークするのではなくアップストリームへの貢献に投資します。
すべてを目録にする。 見えないものには準拠も、保護も、更新もできません。SBOM(ソフトウェア部品表、ソフトウェアのコンポーネントの完全な目録)は最低条件です。
最初から寿命の終わりを計画する。 すべての依存関係はいつか保守されなくなります。強いられる前に出口を知ります。
政府では、既定でオープンにする。 オープン標準とオープンソースを好み、特定の理由がない限り、公金のコードを公開します。

推奨事項

オープンソースの戦略と消費の方針を設定する

開発者がオープンソースを組織に取り込める方法について、明確な方針を公表します。どのライセンスが事前承認され、どれがレビューを要し、どれがあなたのユースケースで禁止されるか。速く摩擦の少ない承認の経路を用意します。コードをコピーするより遅い方針は、単に無視されます。文脈を区別してください。同じライセンスでも、コンポーネントがサービスとして内部で使われる場合、配布される製品に埋め込まれる場合、独自のアプリケーションにリンクされる場合で、振る舞いが異なるからです。容易な道を準拠した道にします。審査済みコンポーネントの選り抜きの内部リポジトリ、パイプラインでの自動スキャン、日常的なケースで弁護士に電話せずに開発者が従える明確な指針。

ライセンスのコンプライアンス、義務、コピーレフトのリスクを管理する

ライセンスの系統とその義務に親しみます。寛容なライセンス(MIT、BSD、Apache 2.0など)は、主に帰属と告知の保持を要求し、Apache 2.0は明示的な特許の許諾を加えます。弱いコピーレフト(LGPLやMPLなど)は、対象のファイルへの変更の共有を要求しますが、一般に独自のコードとの組み合わせを許します。強いコピーレフト(GPLなど)は、配布される作品全体を同じ条件で提供することを要求しえます。ネットワークコピーレフト(AGPL)は、その義務を、バイナリとして配布されるだけでなく、ネットワーク越しに提供されるソフトウェアにまで広げます。最も重要な義務は二つのことにかかっています。ソフトウェアを配布するかどうかと、コンポーネントをどれだけ緊密に組み合わせるか。コンプライアンスを自動化します。依存関係のライセンスをスキャンし、必要な帰属と告知のファイルを生成して出荷し、禁止されたライセンスが静かに本番に入れないよう、方針でビルドをゲートします。

オープンソースプログラムオフィス(OSPO)を設立する

規模でオープンソースを消費するなら、オープンソースの戦略、方針、コンプライアンスのツール、貢献のガバナンス、コミュニティとの関係を所有する、焦点となる存在、OSPOを作ります。OSPOは、すべてのチームが独自に決める混沌を抑えます。個々のチームが維持できない専門性を提供します。そして戦略的な価値を捉えます。どのプロジェクトに投資するか、いつアップストリームに貢献するか、自社のオープンソースプロジェクトをどううまく公開するかを決める。小さなOSPO(時に一人に部門横断のワーキンググループを加えたもの)でも、野放しの状態に比べて、一貫性を劇的に改善し、法的リスクを減らします。

貢献と、適する場合の公開を統治する

いつ貢献を還元するかを意図して決めます。依存するプロジェクトに修正と機能をアップストリームすることは、私的なパッチを抱えるのをやめるので、保守の負担を減らします。また、善意と影響力を築き、自分にとって重要なコンポーネントを強化します。知的財産と貢献者の合意がどう扱われるかを含め、承認された貢献のための明確で速いプロセスを開発者に与えます。自社のオープンソースプロジェクトを公開するときは、きちんと行います。適切なライセンスを選び、ガバナンスを文書化し、スチュワードシップにコミットします。放棄されたプロジェクトは、プロジェクトがないより評判を傷つけます。

政府のオープンソースと「公金には公開コード」の義務づけに応える

公共部門のチームは、オープンさを既定として扱うべきです。ロックインを避け、機関とベンダーにまたがって働くために、オープン標準を好みます。セキュリティに敏感なコンポーネント、第三者の権利、プライバシーの懸念といった、特定の文書化された免除が適用されない限り、公的資金で開発されたソースコードを公開します。築く前に再利用します。別の機関が、適したコードをすでに公開していないかを確認します。これらの期待を調達に組み込み、ベンダーが、機関が保守も共有もできない独自のブラックボックスではなく、政府が適切な権利を保持した、オープンで再利用可能で、よく文書化されたコードを届けるようにします。

依存関係と寿命の終わりのソフトウェアを管理する

すべてのコンポーネントとそのバージョン、ライセンス、保守の状況の生きた目録(SBOM)を保ちます。依存関係を合理的に最新に保ちます。小さく頻繁な更新は、まれで巨大な飛躍よりはるかに安く安全です。アップストリームのプロジェクトの寿命の終わりの告知とセキュリティサポートの窓を見張り、脆弱性が大慌てを強いた後ではなく、サポートが終わる前に移行を計画します。放棄のリスクがある重要なコンポーネントについては、メンテナーに資金を出すか、自分で保守に貢献するか、フォークするか、置き換えるかを事前に決めます。商用とオープンソースのソフトウェアの両方で寿命の終わりを追跡し、サポートが切れることを、他のあらゆる運用上のリスクと同じ基準で扱います。

トレードオフ: 長所と短所

選択	長所	短所
オープンソースを自由に消費する	速いデリバリー。巨大なてこ。ライセンス料なし	いま自分が負うライセンス、セキュリティ、保守の義務
厳格なライセンスの許可リスト	低い法的リスク。予測可能	チームを遅くする。本当に有用なコンポーネントを除外しうる
寛容なライセンスのみ	最小の義務。組み合わせが容易	価値あるコピーレフトのプロジェクトを諦める。互恵が少ない
適する所ではコピーレフトを受け入れる	強いエコシステムへのアクセス。互恵の利益	組み合わせと配布に注意が必要
アップストリームに貢献する	私的パッチの負担が少ない。影響力。善意	継続的な労力。知的財産とプロセスのオーバーヘッド
代わりに独自のものを築く	完全な制御。外部の義務なし	高いコスト。コモディティを再発明。永遠に自分が保守する
政府の既定での公開	透明性。再利用。ロックインを避ける	公開の労力。セキュリティレビュー。持続的なスチュワードシップ

中心的な緊張は、開発者の速度と制御の間にあります。すべてを重いレビューの背後に閉じ込めれば、開発者は方針を迂回します。それは、寛容だが可視のアプローチよりも悪い、管理されない影の依存関係を生みます。完全に制御せずに放置すれば、法的負債とセキュリティ負債を目に見えずに蓄積します。解決は自動化と選り抜きです。事前に審査済みのコンポーネント、パイプラインのスキャン、明確な既定を通じて、準拠した道を最も速い道にし、摩擦なしに制御を得ます。コピーレフトについては、トレードオフは「危険対安全」ではなく、「理解しているかいないか」です。コピーレフトは、どう組み合わせて配布するかがわかれば、完全に使えます。

チームで議論すべき問い

内部、配布、ネットワーク提供の文脈にわたる、強いコピーレフトとネットワークコピーレフトについての明示的なルールは何ですか。 コピーレフトはタブーではなく設計上の制約で、義務はソフトウェアを配布するかどうかと、コンポーネントをどれだけ緊密に組み合わせるかの二つにかかっています。内部ツールの中のGPLは、出荷する製品にリンクされたGPLとはまったく異なる振る舞いをし、AGPLは、単にネットワーク越しに提供するだけのソフトウェアにまで開示の義務を広げるので、サービスとして動かすものについての、築くか採用するかの計算を変えます。開発者が弁護士に電話せずにわかるよう、文脈ごとにルールを書き出してください。たとえば、寛容はどこでも事前承認され、強いコピーレフトは内部では構わないが出荷される製品からはブロックされ、AGPLはネットワークサービスに触れる前にレビューが必要。証拠を持ち込んでください。現在の依存関係の木をスキャンし、コピーレフトのコンポーネントが、すでに配布の境界に対してどこにあるかを見つけます。それから、そのルールでビルドをゲートしてください。スキャナーが徹底しないルールは、開発者が偶然破るルールだからです。
オープンソースプログラムオフィスは必要ですか。そして今日、ライセンスの方針、スキャン、貢献の決定を誰が所有していますか。 誠実な答えが「誰も」あるいは「各チームが決める」なら、法的負債とセキュリティ負債を目に見えずに蓄積する野放しの状態を運営しています。OSPOは、一人に部門横断のワーキンググループを加えたものでも、その混沌を抑え、戦略的な価値を捉えます。どのアップストリームのプロジェクトに投資するか、いつ貢献するか、自社のプロジェクトをどううまく公開するか。会議に証拠を持ち込んでください。現在の承認済みライセンスの一覧、SBOM、買収のデューデリジェンスの間にコピーレフトの質問を受ける人の名前を、誰か出せますか。答えは、明確な所有を割り当て、事前に審査済みのコンポーネントとパイプラインのスキャンを通じて準拠した道を最も速い道にし、開発者が摩擦なしに制御を得られるようにすべきです。コードをコピーするより遅い方針は、単に無視されます。
明日放棄されたら最も痛手となる依存関係はどれで、それぞれについて事前に決めた対応は何ですか。 すべての依存関係はいずれ寿命の終わりに達し、その高価な版は、脆弱性が注意を強いたときになって初めて、中核のコンポーネントが数か月前にサポートを失っていたと発見することです。放棄のリスクがある重要なコンポーネントについて、メンテナーに資金を出すか、自分で保守に貢献するか、フォークするか、置き換えるかを事前に決めます。証拠を持ち込んでください。SBOMから、失敗すれば収益や使命に不可欠なサービスを止めるコンポーネントを列挙し、それぞれの保守の状況とセキュリティサポートの窓に注意します。答えは、寿命の終わりを、驚きから、計画された移行を伴う追跡される運用上のリスクに変え、他のあらゆるリスクと同じ基準で扱うべきです。依存関係を小さく頻繁なステップで最新に保つことは、まれで巨大な強制された飛躍よりはるかに安いのです。
推移的な依存関係の木の奥底まで届く、完全で最新のSBOMを作れますか。そしてどれだけ速くですか。 広く使われるライブラリに大きく報じられた脆弱性が着地したとき、リーダーシップが最初に尋ねるのは「私たちは影響を受けるか、どこが」です。数時間以内に答えられないチームはすでに遅れています。本物のリスクは、通常、誰も意図して選ばなかった数層奥の依存関係に隠れているからです。相反する考慮はコストと雑音です。多くのサービスにわたる推移的な完全な目録は、大きく変動する一覧を生み、過剰なアラートは人々に無視するよう訓練するので、どの深さとどの深刻度が実際に行動を引き起こすかを決める必要があります。議論に証拠を持ち込んでください。いま一つの本番サービスの新しいSBOMを生成し、コンポーネントのうち直接と推移的がいくつあるかを数え、どれだけかかったかを計ってください。企業や政府機関では、これを具体的なインシデント対応の目標と、影響を受けるコンポーネントを開示する規制上の義務に結びつけてください。列挙できない露出を報告するという義務づけは、あなたが違反することになる義務づけだからです。
重要な依存関係に、無料として扱うのではなく、資金を出し、貢献し、スチュワードシップを担う価値があるのはいつですか。 ほとんどの組織はオープンソースをライフラインのように消費し、それから、収益のサービスを支えるコンポーネントが、無給のボランティア一人だったと知って衝撃を受けます。メンテナーに資金を出す、修正をアップストリームする、あるいは自社のプロジェクトを公開してスチュワードシップを担うことを意図して決めることは、脆い無料の入力を、持続的で影響を及ぼせるものに変え、エンジニアがあらゆるアップグレードを通じて私的なパッチを抱えるのをやめさせます。緊張は、貢献とスチュワードシップが本物の継続的なエンジニアリングの時間を費やし、知的財産とプロセスのオーバーヘッドを伴うので、すべてについてはできないことです。証拠を持ち込んでください。SBOMから、失敗すれば使命に不可欠なサービスを止める少数のコンポーネントに印を付け、それぞれのメンテナーの数、資金、すでにそれに対して抱えている私的パッチの数に注意します。大きなあるいは公的な組織では、大々的に公開して放棄したオープンソースのリリースの評判上のコストを量ってください。政府では、公開された公金のコードの持続的なスチュワードシップを、任意の追加ではなく、デリバリーの一部として扱ってください。
調達は実際に、必要な権利を伴うオープンで再利用可能で、よく文書化されたコードを届けていますか。それとも保守も出口もできない独自のブラックボックスですか。オープンソースの専門性なしに書かれた契約は、日常的にベンダーに、後悔する制御を渡します。閉じた形式、公開や変更の権利なし、ベンダーが去ったときに機関がパッチを当てられない依存関係。これを早期に正しく得ることは、更新の時に離れられないと発見するよりはるかに安いです。相反する考慮は、速度とベンダーの選択です。オープンな成果物と可搬性を求めることは、候補を狭めて発注を遅らせえ、本当に有用な供給者の一部は抵抗します。証拠を持ち込んでください。最近の契約を二つ引き、ライセンス条件、ソースコードの納品、文書化の標準、SBOMの提供、組織が保持する権利を規定しているかを確認します。企業の調達では、これをロックインと総コストの分析に結びつけ、政府では、既定でのオープンと「公金には公開コード」の義務づけ、そしてシステム全体ではなくセキュリティに敏感な部分だけを閉じることを許す、文書化された免除のプロセスに結びつけてください。

セクター別の視点

スタートアップ。 ほとんどすべてをオープンソースから組み立てていて弁護士もいないので、ルールを1ページに収めてください。MITやApache 2.0のような寛容なライセンスは事前承認され、強いコピーレフトは内部ツールには構わないが出荷される製品からはブロックされ、変わったものは創業者が素早くレビューする。パイプラインにライセンスと脆弱性のスキャンを加え、初日からSBOMを保ちます。これを正しく得る最も安い瞬間は、買収者のデューデリジェンスが依存関係の木を梳く前だからです。恐れからコピーレフトを禁止しないでください。理解して、先へ進みます。

小規模事業者。 オープンソースの専門家はおらず予算も厳しいので、人員ではなくツールに頼ってください。ビルドのスキャナーと短い承認済みライセンスの一覧が、人がするはずの仕事の多くをこなします。消費を築くか買うかとして誠実に枠づけてください。よく保守されたオープンなコンポーネントを再発明するのは通常高価な選択ですが、目録にしないまま一つに依存するのも同じです。顧客のセキュリティ質問票や脆弱性のアラートが大慌てにならないよう、何をどのライセンスで使っているかの単純な記録を保ちます。

大企業。 規模での問題は、多くのチームにわたる一貫性なので、方針、自動スキャン、帰属の生成、貢献のガバナンスを所有するOSPOを立ち上げ、選り抜きの事前審査済みコンポーネントを通じて準拠した道を最も速い道にしてください。パイプラインで文脈ごとにコピーレフトのルールを徹底し、サービスにわたってSBOMを保守し、依存関係の鮮度と寿命の終わりを追跡される運用上のリスクとして管理します。オープンソースを、コードベースの大半のためのサプライチェーン管理として扱い、買収のデューデリジェンスのために監査に即応できる証拠を用意します。

政府。 オープンさはしばしば任意ではなく義務づけられているので、セキュリティ、第三者の権利、プライバシーについて文書化された免除が適用されない限り、既定でオープン標準を採用し、公金のコードを公開してください。政府横断のカタログを確認して築く前に再利用し、保守可能なコードを受け取れるよう、オープンで再利用可能でよく文書化された成果物と保持される権利を調達に組み込みます。公開されたコードを本物のスチュワードシップのもとに置き、免除のプロセスを、閉じなければならないものだけを閉じるよう、狭く透明に保ちます。

事例

スタートアップ。 モバイルアプリを築く4人のスタートアップは、ほとんどすべてをオープンソースから組み立てていて、弁護士もいません。恐れからコピーレフトを禁止する代わりに、創業者たちは1ページの方針を書きます。MITやApache 2.0のような寛容なライセンスは事前承認され、GPLのような強いコピーレフトは内部ツールには構わないが、開示の義務を避けるために出荷されるアプリからはブロックされ、変わったものは創業者が素早くレビューします。禁止されたライセンスがリリースにすり抜けないよう、パイプラインにライセンスと脆弱性のスキャンを加え、初日からSBOMを保ち、アップグレードのたびに私的パッチを抱えるのをやめるために、重要なライブラリに小さな修正をアップストリームします。これを早期に正しく得ることは、買収者のデューデリジェンスがいずれ依存関係の木を梳くときの、痛みを伴う驚きも免れさせます。

大企業。 配布される製品を出荷するソフトウェアベンダーが、OSPOを運営します。OSPOは、承認済みライセンスの一覧、選り抜きの内部コンポーネントリポジトリ、すべてのパイプラインでの自動のライセンスと脆弱性のスキャンを保守します。開発者が新しい依存関係を取り込むと、パイプラインはそのライセンスを方針に照らしてチェックし、製品とともに出荷される帰属の告知を生成し、レビューを要するものに旗を立てます。強いコピーレフトのコンポーネントは、開示の義務を避けるために、内部ツールには許され、配布される製品からはブロックされます。会社は、少数の重要な依存関係に修正をアップストリームします。それが、エンジニアがかつてアップグレードのたびに抱えていた私的パッチの積み残しを解消しました。

政府。 国のデジタルサービスは、「公金には公開コード」の方針のもとで運営されます。新しいサービスはオープン標準の上に築かれ、既定で公開のコードリポジトリで公然と開発され、機関間で再利用されます。調達のテンプレートは、政府が公開と変更の権利を保持したまま、ベンダーにオープンでよく文書化された再利用可能なコードを届けるよう要求します。新しいコンポーネントを始める前に、チームは既存の再利用可能なコードを政府横断のカタログで検索します。セキュリティに敏感なモジュールは、システム全体を閉じるのではなく、文書化されたプロセスを通じて公開を免除されます。

ビジネスケース: 動機、ROI、TCO

オープンソースをうまく管理することは、その莫大なてこを捉えることと、隠れたコストを払うことの違いです。オープンソースは、大きな組織が、自分では決して築く余裕のない基盤の上に立てるようにします。しかし総所有コストには、コンプライアンス、セキュリティパッチ、最終的な移行が含まれ、計画するかどうかにかかわらず到来するコストです。意図した管理は、予測できず高価な危機を、小さく安定した計画されたコストに変えます。それらの危機には、買収のデューデリジェンスで見つかるコピーレフト違反、放棄されたコンポーネントからの緊急移行、誰も存在を知らなかった依存関係の脆弱性が含まれます。

採用のコストは、露出に比べて控えめです。OSPOあるいはワーキンググループ、スキャンのツール、目録を保つ規律。採用しないコストは、法的責任、失敗したデューデリジェンス、パッチの当たっていない依存関係にたどれるセキュリティインシデント、そして最終的に痛みを伴う一斉の移行を強いる、先送りされたアップグレードの複合する費用として現れます。リーダーシップに論拠を示すときは、オープンソースの管理を、コードベースの大半のためのサプライチェーン管理として枠づけてください。戦略的な上振れにも注意してください。避けられたロックイン、より速いデリバリー、人材の誘引、依存するエコシステムへの影響力。政府では、義務づけの次元を加えます。オープンさはしばしば任意ではなく要求されており、うまく行えば、不遵守と重複した公的支出の両方を避けられます。

アンチパターンと落とし穴

コピー&ペーストのライセンス。 開発者がライセンスの確認なしにコンポーネントを取り込み、監査や買収の時に初めて義務を発見すること。
目録がない。 脆弱性やライセンスの質問が飛び込んできたとき、「何を、どのライセンスで使っているか」に答えられないこと。
コピーレフトのパニック。 理解ではなく恐れからすべてのコピーレフトを禁止し、価値あるエコシステムを諦めること。
放棄されたオープンソースのリリース。 大々的にプロジェクトを公開して、その後保守せず、評判を傷つけること。
推移的な依存関係の無視。 直接の依存関係を審査する一方で、本物のリスクが数層奥に隠れていること。
寿命の終わりの驚き。 脆弱性が注意を強いたときになって初めて、中核のコンポーネントが数か月前にサポートを失っていたと発見すること。
コピーより遅い方針。 開発者が迂回するほど重いコンプライアンスのプロセスで、目に見えない影の依存関係を作ること。
政府のブラックボックス。 機関が保守も共有も出口もできない独自のシステムを調達し、既定でオープンの原則に違反すること。

成熟度モデル

レベル1: 開始。 開発者は方針も目録もなく自由にオープンソースを追加します。ライセンスは検討されず、コピーレフトの義務は知られていません。寿命の終わりは偶然に発見され、通常は脆弱性が注意を強いたときです。誰もオープンソースの戦略を所有していません。

レベル2: 発展。 基本的な方針と承認済みライセンスの一覧が存在し、一部のチームがそれに従います。スキャンは行われますが、しばしば手作業で、遅く、少数のプロジェクトだけです。主要なシステムには目録が保たれ、推移的な依存関係は地図にされません。貢献と寿命の終わりの扱いはその場しのぎで、チーム間で一貫していません。

レベル3: 標準化。 OSPOあるいは同等のものが、戦略、方針、ツールを組織全体で所有します。ライセンスと脆弱性のスキャンがすべてのパイプラインで自動化され、帰属と告知のファイルが自動的に生成され、禁止されたライセンスが入れないようビルドがゲートされます。SBOMは推移的な木の下まで保守され、貢献は文書化されたプロセスに従い、寿命の終わりは計画された移行とともに追跡され、政府のチームは既定で公開します。

レベル4: 管理。 プログラムが、ベースラインに対して測定され制御されます。サービスにわたる方針スキャンのカバレッジ、公表された依存関係の脆弱性にパッチを当てる平均時間、セキュリティサポートの窓の内側にあるコンポーネントの割合、ライセンス違反のすり抜け率、依存関係の鮮度の遅れ、アップストリームに還元された私的パッチの数を追跡します。配布の境界に対するコピーレフトの配置は監視され、目標に対する指標が、意見ではなく各実行か中止かの決定を駆動します。

レベル5: オーケストレーション。 オープンソースは、継続的に改善され、組織全体に統合された戦略的資産です。コンプライアンスは完全に自動化され、不適合なコンポーネントは本番に届きません。重要なアップストリームのプロジェクトに意図して投資し、日常的に貢献し、よく運営される自社のプロジェクトのスチュワードシップを担います。依存関係の鮮度と寿命の終わりは、リスクと指標が移るにつれて適応的に管理され、オープンさは本物の競争上と市民にとっての利点になります。

議論のためのアイデア

速い寛容な既定と、法的負債とセキュリティ負債を避けるのに必要な制御の間の、正しい線はどこにありますか。
組織が、重要なアップストリームの依存関係を、無料として扱うのではなく資金を出したり保守したりすべきなのはいつですか。
自社のコンポーネントのうち、オープンソースとして公開してスチュワードシップを担う価値があるものを、どう決めますか。
政府にとって、原則を損なわずに、既定での公開からコンポーネントを免除する、擁護できるプロセスは何ですか。
ライセンスとセキュリティのレビューは、現実的に推移的な依存関係のどこまで深く行く必要がありますか。
ネットワークコピーレフト(AGPL)は、サービスとして提供するソフトウェアについての、築くか採用するかの計算を変えますか。

要点

オープンソースはほとんどのコードベースの大半であり、無料で結果のないものとして扱うのではなく、サプライチェーンとして管理しなければなりません。
ライセンスは本物の義務を伴います。寛容、弱いコピーレフト、強いコピーレフト、ネットワークコピーレフトの系統と、配布と組み合わせがどう義務を引き起こすかを理解します。
選り抜き、自動スキャン、明確な既定を通じて準拠した道を最も速い道にします。さもなければ開発者は方針を迂回します。
戦略、コンプライアンス、貢献、スチュワードシップを規模で所有するOSPOを立ち上げます。
SBOMを保ち、依存関係を小さなステップで最新に保ち、危機を強いられる前に寿命の終わりを計画します。
政府では、既定でオープン標準を採用し、公金のコードを公開し、築く前に再利用します。

参考文献とさらなる読み物

Heather Meeker, Open (Source) for Business and Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source Licence Compliance
Software Package Data Exchange (SPDX, ISO/IEC 5962) specification
CycloneDX SBOM specification
Free Software Foundation, GNU General Public Licence and GPL FAQ
Open Source Initiative, The Open Source Definition and approved licence list
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy and Code.gov guidance
UK Government, Technology Code of Practice and open-standards principles