#はじめに
こんにちは。あるいは、はじめまして。二度目ましての方も、おいででしょうかね。
オープンソース（OSS）の利活用コンサルをしています、渡邊歩です。好きなOSSライセンスは、Beerware Licenseです。
今回は本業のテーマで、「OSS管理のベストプラクティス」の必須要素である「組織」、「ポリシー」、「（正しい）知識」、「ツール」について書かせていただこうと思います。
OSSコンプライアンスって何から始めればいいの？OSS管理ツールってたくさんあるけどそれぞれどう違うの？というような方のお役に立てれば幸いです。
#組織（Open Source Program Office/OSPO）について
Linux Foundation TODOグループのオープンソースプログラムの作成では、OSPOは「オープンソースをサポートし、育成し、共用し、説明し、成長させていくために企業内で中心となる組織」と定義されています。組織、というととても専門的で大規模なものを想像するかもしれませんが、少人数だったり他の業務との兼務だったりと、その形態は企業・組織によって様々です。
これまで多くの企業・組織のOSPOの設立をご支援してきた中で、その成立ちを大きく分類すると下図のようになります。どのモデルにもそれぞれメリット・デメリットがありますので、それらを意識しながら推進していくことが重要です。
成功するOSPOの共通点というと、必要であれば会社の規則を変えたり製品の出荷を止めたりできるような「権限」があることと、企業・組織としてコンプライアンスを推進するのだという「使命」があることでしょうか。また、ルール主導にならないよう、開発チームと密に連携して無理のないプロセスを構築していくことも、成功の秘訣です。
#ポリシーについて
OSS管理って何から手をつければ良いんですか？という質問をいただくことがありますが、私はまず「OSSポリシーを作りましょう」とご提案します。OSSポリシーとは、企業または組織がOSSとどのように関わっていくかという指針を定めたもので、様々なシーンで判断をする際の拠り所になります。
OSSポリシーにも色々な形式、粒度がありますが、私が一般的におすすめしているのは下記の形式です。
ポリシーで定めた内容を詳細化し読み物の形にした「ガイドライン」や、組織のメンバーに理解・浸透させるための「教育資料」の形に転用することもできます。
#正しい知識について
今年は、たくさんの会社様からOSS教育のご依頼をいただきました。OSSの活用そのものが増えてきていることに加え、「正しく基礎的な知識を全員が持っていること」が重要視されてきているように思います。
OpenChain Japan WGでは、関係する方々全員に正しい理解をしていただくためのリーフレット「オープンソースソフトウェアライセンス遵守のための一般公衆ガイド」を作成しました。（詳しくは12月8日のSat_Uさんの記事をご覧ください！）
このガイドは、日本語版が作成された後、英語や中国語などに翻訳されています。海外の取引先にOSSコンプライアンスについて知って貰いたい方は是非この翻訳版のガイドを活用してください。
#ツール（OSS管理ツール）について
ここでは、ソフトウェアを解析し、内包するOSSを検出するツールのことをOSS管理ツールと呼びます。
OSS管理ツールも様々なものがありますよね。結局のところ、どれがいいの？と迷われる方も多いと思いますので、選ぶ際の観点とおすすめツールを纏めてみました。
- 観点その1：OSSを改変して使っているか
- OSS管理ツールの基本的なアプローチは、解析対象ファイルから算出したハッシュ値と、予め算出して蓄えてあるOSSのハッシュ値とを比較する「**ファイルマッチング**」という方法です。ほとんどのツールには「あいまいマッチ検出」の機能があるので、軽微な改変であれば検出することができますが、改変の度合いと検出率は相反関係になります。 改変されたOSSの検出を可能にするため、いくつかのOSS管理ツールでは「**スニペットマッチング**」というアプローチをとっています。これは、ファイルの一部分だけが似ているようなOSSを特定することができ、OSSの意図しない混入（コンタミネーション）を検出することができます。 as-isのOSSのライブラリを参照しているだけ、というような方であればファイルマッチングができるOSS管理ツールで十分ですし、組込み開発などでOSSの改変が必須の方であれば、スニペットマッチングができるOSS管理ツールを選んでください。 このカテゴリのおすすめツール： ・[Black Duck](https://www.synopsys.com/ja-jp/software-integrity/security-testing/software-composition-analysis.html)（ファイルマッチング・スニペットマッチング） ・[White Source](https://www.whitesourcesoftware.com/)（ファイルマッチング）
- 観点その2：独自ビルドのバイナリファイルを解析する必要があるか
- OSSのバイナリファイルをas-isで使用している場合であれば、上述の「ファイルマッチング」でカバーできますが、独自ビルドのバイナリファイルは、ビルド環境やオプション等によりハッシュ値が変わりますので、特別なアプローチが必要です。元にしたソースファイルが手元にある場合はもちろん、ソースファイルを解析すれば良いのですが、外部からの購入品などでバイナリファイルしか手元にない場合もありますので、そのような方は独自ビルドのバイナリファイルを解析する機能を持ったツールを選んでください。 このカテゴリのおすすめツール： ・[Black Duck](https://www.synopsys.com/ja-jp/software-integrity/security-testing/software-composition-analysis.html) ・[Insignary Clarity](https://www.insignary.com/)
- 観点その3：依存関係の解析
- 取り込んだOSSが更に別のOSSを取り込んでいて、突き詰めていくとGPLライセンスのライブラリが入っていた・・・という「あるある」を経験したことのある方も多いのではないでしょうか。このような「入れ子構造」になっているライセンスのことを「**Deep License**」と呼びます。このようなDeep Licenseを調べるには、パッケージ毎の依存関係（どのパッケージが、どのパッケージを内包しているか）を調べなければなりません。 Deep Licenseを詳しく調べたい方は、パッケージマネージャの依存関係を示すファイルを解析しパッケージの依存関係を可視化してくれる機能を持ったツールを選んでください。 このカテゴリのおすすめツール： ・[FOSSA](https://fossa.com/)
#明日のテーマは・・・
明日の担当は、tech_nomad_さん。「OSSと特許侵害」という、とても気になる！でも難しくて解らない！というテーマを語ってくださいます。控えめに言ってもめっちゃためになります。明日もお楽しみに！！
#お役立ちリンク
この投稿を読んでくださった方から「これも参考になるよ！」と教えていただいた情報を載せておきます。こういうやりとりもコミュニティの良さですよね！
・Open Source Program Offices: The Primer on Organizational Structures, Roles and Responsibilities, and Challenges