オープンソース プログラムの作成

「オープンソース プログラム オフィス」はオープンソースをサポートし、育成し、共用し、説明し、成長させていくために企業内で中心となる組織です。その組織で、企業は明確なオープンソース戦略を確立し、それを遂行します。また、業務でオープンソース活用を成功させるために必要な手段を企業内のリーダー、開発者、マーケティング関係者などのスタッフに提供します。

このガイドは、企業内でオープンソースの活用、作成を管理するためにオープンソース プログラムを作るべき理由とその方法を理解するのに役立ちます。また、開発者が業務外のオープンソース プロジェクトに貢献をする方法を示します。このガイドは、オープンソース オフィスについて、その役割と責任、企業組織構造、オープンソース管理プログラムが含むべき要素、オープンソース プログラム マネージャーの選び方や採用方法など、オープンソース オフィスのトピックを広く扱っています。

内容

1. なぜ、オープンソース プログラム オフィスの設立が必要か
2. オープンソース プログラム オフィスの役割
3. 事例：Google社でのオープンソース
4. オープンソース オフィスの設立
5. オープンソース プログラムの構造
6. マネージメントの役割
7. ポリシーとプロセスの設定
8. 結論
9. 求人情報のテンプレート

ガイド一覧 »
GitHub上で貢献する »

オープンソース ソフトウェアは、今日、小売から金融、自動車など幅広い業界の企業で広く使用されていますが、企業を運営する経営幹部や意思決定者のすべてがオープンソース ソフトウェアを十分に理解しているわけではありません。

重要な問題は、企業が、業務や目標を定める際に伝統的なやり方でビジネスプランを作成し、それをフォローしていくなかで、オープンソース ソフトウェアがビジネス プランの遂行に影響を与える可能性があるということです。オープンソース イノベーションは独自の方法論を持ち、従来のビジネス プロセスに従わない点があるからです。最も大きな違いのひとつは、従来のソフトウェア周りのビジネス慣行は、プロプライエタリ ソフトウェアが中心で、オープンではありませんでしたが、オープンソースの開発は協業作業であるということです。多くの企業にとって、オープンソースを採用する場合に必要とされるこの哲学の転換は、簡単に、自然に起こるものではありません。

このため、オープンソース プログラムの作成が大きなメリットを与えてくれます。オープンソース プログラム オフィスを設立することで、企業は長期的なビジネス プランに合わせた形で、組織的、効率的なオープンソースの活用が可能になります。オープンソース プログラム オフィスは、企業のオープンソースの活用とその体系の中心になるように設計されおり、必要な要素のすべてをそこに集約することを促します。

これには、ソースコードの使用、配布、選択、監査、その他のポリシーの設定から、ソフトウェアの開発者のトレーニング、法令遵守の推進、オープンソース コミュニティへの参加を奨めたり、協業したりすることも含みます。オープンソース プログラム オフィスは、社内外でオープンソースに関する情報発信やコミュニケーション活動なども提供します。

上手く組織化されたオープンソース プログラム オフィスが設立できれば、企業内でのオープンソースの活用、創造、オープンソースへのコントリビューションを推進することができ、企業に戦略的優位を与えることができます。

よく機能しているオープンソース プログラム オフィスは、開発者とそのチームに確立したプロセスを提供でき、企業のオープンソース活用に大きな利益をもたらします。また、標準的なコーディング、系統化された作業慣行、プロセス、ツールセットの採用を促進します。同時に、オープンソース プログラム オフィスは、クリエイティブな開発者が無視しがちな過剰で、厳格すぎるプロセス、ただし、無視すれば、セキュリティや他の側面でプロジェクトの脅威となるプロセスを改善または除去するのに役立ちます。

オープンソース プログラム オフィスの担務には以下のようなものがあります。

• 企業内、企業外にオープンソース戦略を明確に伝える
• オープンソース戦略を策定し、実行する
•  製品、サービスでオープンソースを効果的に活用することを推進する
•  オープンソース コミュニティに高品質なコードを頻繁にリリースできるようにサポートする
•  開発者コミュニティと連携し、企業のコントリビューションがプロジェクトに効果的に反映されるようにする
•  組織内にオープンソース文化を育成する
•  オープンソース ライセンス コンプライアンスに関連するレビューを推進し、指導する

すべての企業で、オープンソース プログラム オフィスの役割は、ビジネス、製品、および企業の目標に基づいてカスタマイズされるでしょう。 すべての業界に適用可能な、または単一の業界であっても、すべての企業に適用可能なオープンソース プログラムを構築するための汎用的なテンプレートはありません。 オープンソース プログラムは組織に合わせたものをつくる必要がありますが、他の企業から学び、あなたの組織の要求に合わせたものにしていくことができます。

Microsoft社は、ここ数年、オープンソースに対する独自のアプローチ方法を立案し、改良するために取り組んできました。 Microsoft社は幅広いビジネス ユニットに何万人にも及ぶ従業員を擁していますが、Microsoft社内のオープンソース プログラム オフィスは、クラウド サービス、ハードウェアおよびソフトウェア製品、ゲーム、コンテンツ、メディアなどの分野でオープンソースに関わっている開発者、マーケティングチームなどを専任で支援しています。各部門は、個々のビジネス モデルとオープンソースに対する関わり方に基づいて異なる支援が必要であり、すべての組織に同一の支援を提供することは不可能です。

オープンソース プログラム オフィスの重要な役割は、ビジネス ユニットがオープンソースの採用を検討し始めたときに、採用理由、採用するとその結果はどうなるのか、そして目標を達成するために何が必要かなどについて、彼らがきちんと理解できるよう、議論に事実と内容をもたらすことです。彼らが意思決定をするときに、何から始めるべきか、何を考えるべきかなどが理解できるように、彼らとの議論を形成していくことが重要です。

オープンソース プログラム オフィスは、開発者とオープンソース ユーザーのコミュニティとの間の重要な調整役でもあり、オープンソースに関連して発生する問題や要件を理解して、解決します。 また、プログラム オフィスは、法務問題解決をサポートし、開発者を擁護する情報発信を提供し、かつ当該企業のオープンソース プロジェクトを利用している外部ユーザーに向かって発言します。 プログラム オフィスは、製品管理チームを含む社内の他部門にその情報を提供し、ソースコードをさらに改良、進歩させます。 また、オープンソース オフィスでは、プロジェクトが成長し、持続可能となるよう、専任で開発者に代わって情報発信する専門家を雇うことも増えています。

すべての企業にとって、オープンソース オフィスの設立はオープンソースに関連した個々のデシジョンが始まるところです。このデシジョンのプロセスは、トップマネジメントが肩入れしたトップダウンなものや、一部の開発者がオープンソースを使用していて、そのことが公式に承認されることを望むボトムアップのものなどから始まります。 また、法的な問題やセキュリティ関連の指針を作成したいという要望から始まったり、企業のリーダーの注目を集め、それ熟成させることによって、プロジェクトを成長させたいといった草の根活動のような取り組みから始まったりすることもあります。オープンソースに対するコミットメントを深めることで、会社の価値を増大させ、会社を発展させたいと考える、先見の明のあるCEOやCTOと共にスタートすることさえもあります。このようなオープンソースに対するコンセンサスと経営幹部のサポートは、プロジェクトを推進するための牽引力として不可欠なものです。

それでは、どのようにしてオープンソース プログラム オフィスを設立して行けば良いのでしょうか。以下にその重要なステップを示します。

1. リーダーを見つける

どのように計画を進めるにしても、会社内で新しくプログラム オフィスを設立して、運営していくことに適したリーダーを見つけることがまずは重要になります。 まず候補者として相応しい人は、オープンソースはどのようにして機能しているのかなど、オープンソースについて詳しく理解していて、かつ、いくつかのオープンソース プロジェクトの開発者、コントリビューター、コミッターとして活躍し、その分野である程度の技術的なスキルを持っている人です。 またリーダーはビジネス ユニットにまたがった戦略や計画を発信するために必要なビジネスの見識と管理スキルを備えていて、企業のビジネスを幅広く理解している必要があります。 リーダーは、熱意、知識、情報を他の人に伝え、また、オープンソースのイニシアティブが、いかに会社の利益のために物事を変革し、改革していくかを他の人が理解できるようにするためのコミュニケーション能力を持っている必要があります。 プログラム オフィスの長は、高度なテクノロジー関連の話題についても人々と議論できる必要がありますが、オープンソースでは、マスターするにはあまりにも多くのものがあるため、すべてのテクノロジーについて詳細を知る必要はありません。

オープンソースのコラボレーションの精神のもと、ベストな候補者を見つけることを支援してくれる豊富なオンライン リソースが公開されています。オープンソースのプログラム マネージャーや、既にオープンソース オフィスのような組織を確立しているさまざまな企業がオープンソースのプログラム マネージャーやその他のリーダーのための詳細な、ジョブ ディスクリプション、職務内容の例（detailed sample job description postings）をオンライン上で公開しています。 VMware社、Microsoft社、Twitter社、Yahoo社などです。

2. オペレーションを定義する

新しいプログラム オフィスによって必要とされる予算、人員、ツールおよびシステムもまた、オペレーションを確立するために解決すべき重要な課題です。 一部の企業は非常勤マネージャーから始めますが、そのアプローチでは不十分なことをやがて理解するでしょう。作業を迅速に進めるための支援スタッフと併せ、常勤のマネージャーを採用することは、このプログラムを確実にスタートさせるための第一歩になります。

プログラム オフィスがあまりに大きな組織になると、そこに集中化され過ぎる危険性があります。そのような組織は、会社内の開発者やオープンソース コミュニティをできるだけ多く、プログラム オフィスのプロセスに関わらせたいと考えるはずです。 また、大きすぎるプログラム オフィスがあると、オフィス外の人は問題を自身で解決するのではなく、プログラム オフィスに問題解決をまかせるようになります。

例えば、職務を明確に定義したオープンソース プログラム オフィスは、必要とされるポリシー、プロセス、ツールを単に運用するだけでなく、自動化ツールを提供したり、業務の委譲を進めたりすることにより、オーバーヘッドをできるだけ除去していきます。以下のセクションで、ポリシーとプロセスの設定方法を詳細に説明します。

プログラム オフィスは、体系化されたポリシーとプロセスを提供する必要がありますが、また柔軟性も持っていなければなりません。 オープンソースのユーザーやコントリビューターが助けを必要とするとき、オフィスはコンサルタントのように指針を与え、業務に関連した個人またはグループのビジネス上の決定は、従業員自身で行うようにさせます。 最終的には、企業とそのオープンソース  ユーザーのニーズを満たしつつ義務と責任の適切なバランスを確立することがプログラム オフィスの目標です。

3. フィードバックと同意を求める

オープンソース プログラム オフィスを設立する作業は他の部門と関わりを持ってなされるべきです。 オフィスは企業のビジネスにおいて中心的な役割を担うので、それを成功裏に設立するためには、企業内のすべての関係者からのオープンで偽りのない意見やそのフィードバックが必要です。 経営幹部から開発者までのすべての人にオフィスの設立に関する発言権を与えるようにすることは、設立されたオフィスが幅広い支持を得るのに役立ちます。

オープンソース プログラム オフィスは会社の組織構造のどこに、どのように設立されるべきなのでしょうか？ エンジニアリング部門の内にあるべきでしょうか？ または、法務部門、CTOオフィス、または別の事業部門におくべきでしょうか？ これは、あなたの会社の主要ビジネスやオープンソースの戦略によって異なってきます。

法務部門

大きな知的財産ポートフォリオを持っている企業では、オープンソース プログラム オフィスは法務部門に設立することが完璧に適合しているでしょう。法務部門に置くことにより、発生した問題について、開発者が法務チームと緊密に取り組むことができます。 これは、知的財産関連の法的問題に陥る可能性が常に懸念されるハードウェア会社には適しているかもしれません。

エンジニアリング部門

エンジニアリング主導の企業であれば、エンジニアリング部門にオープンソース プログラム オフィスを設置するのが良いでしょう。 これにより、オープンソース オフィスは、開発者の作業を、より効率的、生産的なものにすることに直接集中できるような形でサポートできます。

開発者との関わり、マーケティング、またはコミュニケーション

他のケースでは、組織のマーケティング部門の中にオープンソース オフィスを設置しているケースもあります。オープンソースを活用した製品を販売する時、顧客に近いところでマーケティングにオープンソースを利用するためです。

オープンソースの活用が企業の成功に欠かせなかったTwitter社でも、法務部門がコードのライセンスや関連する問題について深刻な懸念を抱いていたため、開発者は2010年から開始していた社内のオープンソース プロジェクトからコミュニティへのコード コントリビューションが難しいと感じていました。 開発者とソフトウェア エンジニアは、ライセンス コンプライアンス プロセスを自動化する方法を考え出して、法務部門とエンジニアリング部門の懸念を大きく緩和させました。 これがきっかけとなり、オープンソースのプログラム マネージャーを雇用し、オープンソース プログラム オフィスを設立しました。同オフィスは、プロセスを修正し、手順を合理化し、関連業務を自動化するツールを導入し、その他必要な変更を行いました。

興味深いことに、ストリーミング映画、エンターテイメントの企業Netflix社は異なるアプローチをとり、集中型組織としてオープンソース プログラム オフィスを設立したり、使用したりしない方法を選択していますと、同社のコンテナ方式クラウドのマネージャーであるAndrew Spykerは述べています。 代わりに、内部のメーリングリストを使って議論を行い、相互にオープンソースの問題を解決するために、月に一度、非公式に打合せを持つ程度の小規模でクロスファンクショナルな（small, cross-functional working group）ワーキング グループでオープンソースの利用を管理しています。 ボランティアのワーキング グループ メンバーは、分散して配置された他チームを支援し、彼らが法的問題、ツール、モニタリング、コミュニティ プロモーションなどの管理業務的な作業に時間をさくことを低減させるようにサポートします。Netflix社はエンターテイメント企業であり、ソフトウェア会社ではないため、これが実行可能なアプローチなのです。

Microsoft社では、エンジニアリング部門内に設置されたオープンソース プログラム オフィスは、社内の約6万人のソフトウェア エンジニアをサポートするという点でユニークです。そのように大きな数の開発者が存在するので、すべてのオープンソース プロジェクトの些細な件でもオープンソース プログラム オフィスを通さなければならないという考えは捨てることが求められます。それは膨大な作業となり、上手くいかなかったことでしょう。代わりに、自動化できないものについて、オープンソース プログラム オフィスは、エンジニアが自身のプロジェクトに関するものに対して自ら決定することを可能にしています。すべての問題をオープンソース オフィスに上げると、作業の集中化によるボトルネックで、業務に支障がでてきます。

Microsoft社のエンジニアは、オープンソース プログラム オフィスのプロセスのもとで、オープンソース ワークフローに従って動くことができ、特定のコードを使用するとか、オープンソース コミュニティにコードをリリースするといったことを情報共有でき、さらには、コードに対するフィードバックをレビュアーから受け取ったりすることができます。 高度に専門化されたプロセスには、約300の異なるビジネス グループおよび法務関係のレビュアーが参加して構成されており、一般的でない要求に対してもその専門知識を使って実行可能なアプローチを提供することができます。

オープンソース プログラム オフィスを設立する際には、オープンソース プログラム マネージャー、会社の法務チーム、および、エンジニアと経営幹部で構成されたレビュー ボード（審査委員会）の役割と責任を明確に規定しなければなりません。

プログラム マネージャー

オープンソース プログラム オフィスが最大限の効果を出すためには、プログラム マネージャーは、オープンソース関連活動における企業利益を直接管理し、かつ実務レベルのマネージメントができる経営幹部レベルの権限を与えられていなければなりません。 そうすることで、企業オープンソース活動の目標とビジョンに向かって企業内を牽引するために必要となるあらゆる手段をプログラム マネージャーに提供できるようになります。

Microsoft社は、「オープンソース評議会」（Open Source Executive Council : OSEC）を活用していますが、レビュー ボード（審査委員会）に似た組織です。 これは、社内のすべての主要事業部門のバイスプレジデントから構成され、取締役会形式の方法でポリシーの変更と導入、オープンソース プログラムの優先順位を定め、行動変化の促進を助けています。

法務部門

法務チームは、企業内の他の組織と同様に、法律、オープンソース ライセンス契約、およびその他の法務的な事項の遵守を確実にするために、オープンソース プログラム オフィスの運営に関わらなければなりません。 特に、オープンソースにおいて、法務チームは、受け入れ可能な条件で企業が内部的にコードを使用し、そのオープンソース プロジェクトにコントリビューションできるようにする責任があります。 大規模な組織では、オープンソース プログラムにアドバイスできる専任の弁護士を雇うか、育成することを検討する必要があります。 しかし、知識を持っている内部のスタッフを非常勤で活用したり、外部の弁護士に依頼したりこともできます。 この分野は、商業的な契約や規範と比較すると、専門的で、時には困惑させる法律上の領域であるため、オープンソース ライセンスや知的財産権関連の知識、経験を持つ弁護士と仕事をすることは、しばしば有益です。

コンプライアンス チーム

オープンソース コンプライアンス チームは、オープンソースのコンプライアンスのために、様々な分野の専門知識を持つ人で構成されます。 コア チームは、オープンソース レビュー委員会（Open Source Review Board: OSRB）と呼ばれることが多く、エンジニアリング チームとプロダクト チームの代表、一名以上の法務部門メンバー、コンプライアンス  オフィサー（オープンソース プログラム マネージャーである場合が多い）で構成されています。

拡張チームは、コンプライアンスの取り組みに継続的に貢献している複数部門のさまざまな個人で構成されています。 ドキュメント関連部門、サプライチェーン関連部門、経営企画部門、IT、ローカライゼーション、オープンソース評議会（OSEC）などがあります。 ただし、コア チームとは異なり、拡張チームのメンバーは、OSRBから依頼されたタスクに基づいて、非常勤で、コンプライアンス関連作業を行います。 Samsung社のプログラム マネージャー、Ibrahim Haddadが著作した「Open Source Compliance in the Enterprise」では、オープンソース コンプライアンスを実現するために携わる人の役割と責任について詳細な議論を行っています。

開発者担当、アドボカシー、エバンジェリスト

オープンソースの開発者担当とオープンソースのエバンジェリストは、設立されたばかりのオープンソース プログラム オフィスにとって重要な役割となる可能性があります。なぜなら、開発者コミュニティに特定のプロジェクトに対する興味や熱意を持たせることを促進し、エンジニアの取り組みやチームワークを助成することができからです。 エバンジェリストは会議や技術イベントに出席し、オープンソース コミュニティとの協調経験を会議参加者と共有し、オープンソースがどのような活用されるのか、オープンソース利用方法、その課題、それが与えてくれる機会などを理解するのを支援することができます。

その他

さらに、オープンソース プログラム オフィスが成功するためには、ツール管理者、トレーニング マネージャー、ツールとシステムの統合を進める開発者、デプロイメント支援スタッフ、実装プロジェクトのリーダー、オープンソース エバンジェリストなどの仕事をきちんと作ることが重要です。 たとえば、ツール管理者は、オープンソース プロジェクトで作業するエンジニアに必要なツールの選択、提供、統合を支援するとともに、ツールがライセンス上の要件やその他の企業の要件を満たしていることを確認します。

組織構成から、要員配置まで、オープンソース プログラム オフィスのために計画、構築された重要なものに続いて、次になすべきものは、企業のオープンソース戦略の一貫した実装を可能にするための明確なポリシーとプロセスを作成することです。

ポリシーには、企業全部門で、オープンソース活用することができるための要件とルールとともに、日々、ルールが遵守されていることを確実にするための実行可能なプロセスが文書化され、提示されていなければなりません。

重要な点は、ポリシーやプロセスは最小限のオーバーヘッドしか要求しないことです。 Microsoft社は、オープンソース プログラム オフィスのポリシーとプロセスを、開発者や他のチーム メンバーにとってできるだけオーバーヘッドにならないものにすることを目標にしています。 このため、既存のオープンソースのポリシーとプロセスを見直す際に、繰り返して、オーバーヘッドの削減、自動化の推進、権限委任を行っています。従って、ルールは、手順の合理化のために常に審議され、改版されていま。 これは、ポリシーがなぜそこで必要なのか、ポリシーをユーザーのためにどのように改善できるのか、を問うことです。

これらのルールがオープンソース プログラム オフィスのために慎重に作成されているとしても、企業はビジネスの変化や、オープンソースの取り組みの成熟、拡大に合わせて、それらのルール、手順を改良、改訂させていくことが必要になります。

これはあまり気の進まないステップがプロセスの中に一つ追加されたように思われるかもしれませんが、オープンソース コード自体と同様に、サンプルとして利用可能なルールとプロセスはオープンソースの情報コンテンツとして公開されているので、あなたの仕事がやり易いように、それを企業向けにカスタマイズし、導入するが良いでしょう。

このようなルールの事例集の中で、最も良い例は、2017年の初めにGoogle社がレビューと自由な使用を目的に公開したオープンソース ポリシー（open source policies）で、オープンソースの使用方法、リリース方法、サポート方法、プロジェクトやコミュニティへの参加方法などを学ぶことができます。 コンテンツの中には、セキュリティとプライバシーの理由から削除された部分もありますが、Google社がオープンソースで学んだ多くの教訓が含まれています。

オープンソース ポリシーを作成する際に、たくさんのトピックの中には議論する必要のあるものがあります。

• あなたの会社のオープンソース プロジェクトにどのようにして外部からのコントリビューションを受け入れるか
• どのようにしてオープンソースをリリースするのか
• どのように承認を得るのか
• 開発者がGitHubやその他のソースコード リポジトリで見つけたオープンソース コードをどのようにして社内で使用できるようになるのか
• オープンソース コードをあなたの会社に導入するための手順やルールの説明
• 他の人が導入されたコードを知ることができるように、導入されたコードをどのように目録化するか
• 同じ目的を持って活発に活動している外部開発者のコミュニティをどのように発展させていくことができるか
• コードをオープンソースとしてリリースするか、プロプライエタリ、知的財産として保持しておくのかを決定するためのルール

コードのリリースに関するポリシー

あなたは、開発者がオープンソース プロジェクトにコントリビューションし、また、彼ら自身プロジェクトをリリースすることを成功させるのをサポートしたいと考えるでしょう。 ガイドラインとチェックリストは、開発者がライセンスの問題や企業の機密保持の問題に陥ることなく、コードをオープンソースとしてリリースするために必要なものすべてを確実に提供します。 特に新しいコントリビューターにとっては、外部にコントリビューションを行う前にフィードバックを得るための場として内部レビュー プロセスを利用することができるようになります（オープンソース コミュニティへの参加についてのガイド: 「オープンソース コミュニティへの参加」を参照してください）。

あなたの組織はまた、「アップストリームを優先 (upstream first)」という開発ポリシーを採用するよう努めるべきです。 最初にアップストリームのオープンソース プロジェクトにパッチを提出し、それを自分の製品、すなわちダウンストリームに組み込むことで、改版のリリースの都度発生するリエンジニアリングの膨大な時間と費用を費やすことがなくなります。

コントリビューションの受け容れに関するポリシー

あなたのオープンソース プロジェクトが中立的なファウンデーションで運営されていない場合は、あなたの会社が外部開発者からあなたのオープンソース プロジェクトへのコントリビューションを受け容れるための手順の設定が必要になります。

もちろん、他の開発者を勧誘して、自分のプロジェクトに興味を持たせること、これこそが会社のコードをオープンソースとして他のコミュニティに公開するメリットのひとつです。 大きな枠組みで見れば、正式な従業員でもない世界各地の優秀な人材がコードを改善したり、機能拡張したりするためにコントリビューションしてくれるようになるということです。この種のコラボレーションは企業にとって重要であり、各社のオープンソース プログラム オフィス共通の狙いです。

適用推進のポリシー

また、あなたは、他の人々も製品やサービスであなたのコードを使用することを奨励したいと考えるでしょう。 それが、エコシステムを構築するためのキーとなり、オープンソース プロジェクトの維持、成長の助けになります。 オープンソースの適用推進のためのポリシーは、さまざまな革新的な形で登場する可能性があります。

Red Hat社は、新しく作成されたコードは、ほとんどの場合、最初からオープンソースにするといった独特のポリシーを持っています。 つまり、会社内でソフトウェアを開発する場合、将来的にはそれはオープンソースとしてリリースされることになります。 これは興味深いことです。なぜなら、一般に、オープンソースとしてコードをリリースするエンジニアは、他の人から見られることを意識した、少し異なった行動をとるからです。 他の人に見られるということで、オープンソースのコードを書くときには、彼らは、よりクリーンなコード、他のコードとの依存性を少なくし、より改良されたコードを提供するなど、より良い方法でコードを提供する傾向があります。

内部で活用する場合のポリシー

その他の必要なポリシーには、オープンソース ソフトウェアの使用と作成のための信頼できるソースコードがどこにあり、どのように取り出すかを定めたルール、および、コード管理と保守手順の確立やあなたのプロジェクトとコミュニティ間のやり取りの方法を定めたポリシーが含まれています （オープンソース コードの使用に関するガイド: 「オープンソース コードの使用」を参照してください）。

オープンソース活用のためのポリシーに従えば、製品を構成するすべてのソフトウェア（プロプライエタリ、サードパーティ、オープンソースの何れについても）の監査、レビュー、承認が確実に行われるようになります。 また、製品が顧客に提供される前に、さまざまなソフトウェア コンポーネントを使用することにより発生する多様なライセンス義務履行を確実に行うことができるようになります。

たとえば、ポリシーによって、すべてのオープンソース コードは製品に統合される前に、オープンソース レビュー ボード（OSRB: open source review board）などの監査スタッフから承認を受ける必要があると規定することもできるでしょう。 また、サードパーティから提供されるソフトウェアは、含まれているオープンソース コードをすべて特定するために監査され、製品出荷前にライセンス義務が満たされていることを検証する必要があると規定するでしょう。

コンプライアンスのためのポリシー

また、法的コンプライアンスのための手順を規定して、確立し、経営幹部が実施状況を管理できるようなポリシーの策定が求められます （詳細なコンプライアンス プログラムについては、電子ブック: Open Source Compliance in the Enterpriseを参照してください）。

コンプライアンスとコード チェックの作業の多くを自動化と手順の簡素化により、開発者やコントリビューターに代わって実施することができるソフトウェア ツールについて、それらをどのように使用すればよいかを説明すべきでしょう。 たとえば、Linux FoundationのSPDXおよびOpenChainのツールを利用し、社内のサプライチェーン関連部門と協力して、サードパーティから提供されたコードもコンプライアンスを徹底させることができます。

これらの重要な作業を支援するために、オープンソース（例：FOSSology）や有料のプロプライエタリ ソフトとして提供されるツールが広く存在しています。高品質で、機能も豊富なこれらのツールを活用できるので、 多くのオープンソース プログラム オフィスでは、自身で独自のツールを開発したり、構築したりする必要がありません。 この分野でも、オープンソース プロセスのコラボレーションが良い作用をもたらしており、コントリビューターが多くの企業のためにこれらの作業を処理できるツールを作成し、改良を続けています。 また、ツールがプロジェクトに必要なものを提供していない場合は、ユーザーがコードを修正、改善して、求めている機能を実現し、それをコントリビューションすることができます。 エンタープライズ ツール関連のオープンソース コミュニティに関わることに対してもオープンソース プログラム オフィスはサポートするとよいでしょう。

公開されているオープンソース関連情報は、コントリビューター ライセンス契約書（CLAs: contributor license agreements）を含めて、オープンソース プロジェクトに必要な資料を見つけるための宝の山です。 CLAsは、知的財産をオープンソース ソフトウェアとしてコントリビュートにする場合の条件を定義します。 CLAsを使用するプロジェクトでは、コントリビューションをプロジェクトで受け容れる前に、コントリビューター、および、多くの場合、その所属企業がCLA契約に署名することを要求します。

多くの企業は独自にCLAsを作成していますが、オープンソース契約書として利用可能な汎用的に利用可能なものは既に存在しており、ゼロから作成する必要はありません。ほとんどの必要な情報はテンプレートで見つけることができ、残りの問題をカバーするようにCLAsをカスタマイズすることができます。 コントリビューションを行おうと考えている企業の法務担当は、そこで使用されている標準用語と条件を再利用できるので、助かっています。

Google社内では、カスタム フィルターのような機能を使用して自動的にコード チェックを行うさまざまなツールが定期的に実行されており、コードベースをスキャンしてライセンス、ライセンスの両立性などをチェックしています。Google社が新しいAndroidやその他のアプリケーションをリリースするたびに、ライセンスの準拠状況を確認するための自動化されたプロセスが実行され、会社内の手順を簡素化しています。 また、自動化されているため、プロセスがシンプルでシームレスであり、エンジニアはこの作業を実施するための負担が少ないことを簡単に理解してくれます。

Google社に新たに入社したエンジニアはすべて、ビジネスを進める上で、ライセンスとコンプライアンスがいかに重要かについて教える、1時間のオープンソース クラスを受講する必要があります。 同社内で共有されている重要な教訓は、Google社が法に基づいてライセンスの義務を遵守しているだけでなく、それがコミュニティにとっても正しいことだという理解からです。 ライセンスやコードの使用に明らかな間違いがある場合、Google社の弁護士はGoogle社を代表して対応することができます。しかし、コミュニティの立場を損なう可能性のあるコードを提出することに対してもGoogle社は非常にセンシティブに考えています。

あなたの会社がオープンソース プログラム オフィスをつくることを決定した場合、なさねばならない作業、考えなければならないことは多数あります。しかし、オープンソース オフィスの価値はその設立に向けた努力を上回るでしょう。 プログラム オフィスのイニシアティブを推進する正しいリーダーを見つけることは、プロセスを成功させるための重要なステップです。

これらのリソースは、TODO (Talk Openly, Develop Openly) グループとの協力により作成されました。TODOグループは、The Linux Foundation傘下のプロフェッショナル オープンソース プログラム ネットワーキング グループです。 このような包括的なガイドを作成するために時間を割き、豊富な知識を提供してくれたオープンソース プログラム マネージャーのみなさんに感謝します。TODOグループの参加企業は、Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath (Yahoo + AOL)、Red Hat、Salesforce、Samsung、およびVMwareです。
詳細については、todogroup.orgを参照してください。

この資料は、Creative Commons Attribution ShareAlike 4.0 International License (CC BY-SA 4.0：クリエイティブ・コモンズ 表示 – 継承 4.0 国際ライセンス) の下でライセンスされています。