「企業で使うOSSの選び方は違う？」「OSSコミュニティーはずっと今のままじゃない？」：解決！OSSコンプライアンス（8）

OSSコンプライアンスに関するお悩みポイントと解決策を具体的に紹介する連載「解決！ OSSコンプライアンス」。8回目は、利用するOSSの選択とコンプライアンスについて解説する。

[小保田規生，OpenChain Japan Work Group]

　本連載では、オープンソースソフトウェア（OSS）の利活用に伴う「ライセンスリスク」と、それをマネジメントするための活動である「OSSコンプライアンス」について取り上げ、エンジニアの方がOSSをスムーズに利用するための実務上の勘所や、これから戦略的にOSSを活用していきたいと考えている企業の方へのヒントとなる情報を紹介しています。

　今回も前回に引き続き、ソフトウェア開発企業X社の開発者である新城くんが経験した、OSSコンプライアンス問題とその解決策を解説していきます。思わぬ落とし穴や難しい問題に直面しながらOSSコンプライアンスに対応していく新城くんのエピソードを通して、皆さんも理解を深めていってください。

　なお、本連載では、特に記載がない限り日本国内でOSSを活用する場合を前提としており、本連載の執筆チームの経験に基づいて説明を記載しています。厳密な法解釈や海外での利用など、判断に迷う場合は専門家にご相談ください。

■今回の登場人物

新城くん　日本のソフトウェア開発企業X社で働く入社2年目の開発者。OSSは、指示を受けながらソフトウェア製品やクラウドサービスで利用した経験あり。

佳美先輩　X社の先輩エンジニアで、新城くんの指導担当。OSSを活用した開発の経験が豊富。

エピソード11　OSSの選び方とコンプライアンス

　開発チームからの依頼で、彼らが自社のソフトウェアに組み込もうとしているOSSのライセンスを確認していた新城くん。どうやら開発チームは、LGPL v2.1でライセンスされているOSSを利用しているようです。このOSSを利用して開発を行い、成果物にOSSを組み込んで配布する場合には、寛容なライセンスのOSSで求められる以上の対応が必要です。調べてみると、世の中には同じような機能を持つOSSが、さまざまなライセンスで提供されていることも分かりました。 では、開発チームはなぜこのOSSを利用しようと思ったのか、不思議に思った新城くんは、先輩に問いかけます。

先輩！　開発チームが今回利用しようとしている、このOSSなんですが、ライセンスはLGPL v2.1ですよね。でも、同じような機能が実装されているOSSが他にたくさんあります。しかも、より寛容なライセンスが付いているものもあるんです。なぜ、似たようなOSSがこんなにたくさん、いろいろなライセンスで公開されてるんでしょうか？

そうね、当たり前のことなんだけど、OSSを開発しているソフトウェアエンジニアにとって、彼ら自身が必要としていたり、重要だと考えていたりする機能や性能はさまざまなの。もちろん、ライセンスに対する考え方も開発者ごとに異なっていることが多いわ。だから、さまざまな開発者が、自分自身が望む形で同じような機能を持つOSSを公開していることは割と多いわね。

でも、今回相談してきた開発チームはいつも時間が足りないと言っていますよね。それなのに、どうしてコンプライアンス対応により時間のかかる、LGPLv2.1のOSSを利用しようと思ったんでしょうか？　同じような機能と性能だったら、より寛容なライセンスで提供されているOSSの方が、手間がかからないですよね？

新城くん、「自社のビジネスに大きな影響を及ぼす可能性があるようなライセンスのOSSを利用しない」というポリシーを設定している会社もあるわ。そして、利用している他のOSSとの組み合わせ、例えば、両立できないライセンスの影響も考える必要があるわね。OSSライセンスに関するコンプライアンス対応には時間と手間がかかる場合も多いから、寛容なライセンスを積極的に採用する開発チームが多いのも確かよ。でも、使おうとするOSSを選定するチームは、それ以外の視点でOSSを調査して利用することも多いの。

えっ？　どんな観点で利用するOSSを選んでるんですか？

例えば、最近よく利用されているのはGitHubのStarとかForkの数ね。こういうソーシャルな指標で判断して、多くの人が良いと思って使っているOSSを利用する開発チームは多いはずよ。

解説：製品に利用するOSSを選定する際に考慮すべきポイント

　同じような機能を提供するOSSは多数存在しています。

　例えば、JSONをparseするための機能を実装したC++ライブラリには、picojson、rapidjson、cjsonなどがあります。ヘッダーだけの実装であったり、APIが違ったりしており、提供されるOSSライセンスも違っています。

　実際の開発の現場ではどのOSSを使うのがいいか判断しづらく、ニュースやブログを検索してみたり_（注1）、その技術領域に詳しい知人や同僚に尋ねたりするようなことは多いのではないでしょうか？

　今回は、OSSを選定する際に役立つ評価ポイントを紹介します。

　よくあるOSS選定の仕方には、次のようなものがあります。

1.GitHubなどでのソーシャルな統計データ

　最近よく用いられるのは、ソーシャルな統計データです。例えば、GitHubでは、分かりやすい統計データとして、Watch数、Star数、Fork数が用意されています。Watch数が多いほど注目している開発者が多く、Star数が多いほど気に入っている開発者が多く、Fork数が多いほど実際に利用、修正、コントリビューションしている開発者が多いことを示していると考えられます_（注2）。

　また、github.com/trendingには、最近話題になっているリポジトリがランキング形式で提供されており、ここでも人気の高いOSSを見ることができるでしょう_（注3）。

2.口コミ記事

　同じくよく用いられるソーシャルな評価方法として、QiitaやStack Overflowなどの口コミ記事が存在します。よく使われる有名なライブラリと、その対抗となるようなライブラリについては、多くの人が性能やAPIの使い方などを比較し、ブログなどで詳細な解析をしています。こうした記事を読みながら、自身で確認、使い勝手などを評価して組み込む開発者の方は多いのではないでしょうか。最近は開発者間のソーシャルなつながりが広がっていることもあり、有名な開発者が評価し、ブログなどで紹介しているようなOSSを優先して採用する開発者も多いはずです。

3.OSS活動の統計データ

　次に指標としてよく用いられるのは、OSS開発に関する活動の統計データです。

　コントリビューターの数、OSSの更新頻度、Issueの多さや解決までの日数などが、OSSの活動データとなります。これも、例えばGitHubやGitlabなどのソースコードホスティングサイトにはInsightsという項目が存在しており、その中で、コントリビューター数、OSSの更新頻度、追加・削除の割合などが公開されています。

　こうした統計情報はOSSコミュニティーがどの程度活発なのか、ということを表しており、「コミュニティーが活発だから、OSSのバグ修正や新たな機能追加が見込める」といった評価のための尺度として役立ちます。

4.OSS統計データの情報サイト

　統計データをOSSごとに分かりやすくまとめて提供してくれているWebサイトも存在します。

　例えば、Black Duck Open Hubがあります。

　このサイトでは、OSSプロジェクトの概要と公開場所、類似するプロジェクトなどを分類、比較でき、使われているプログラミング言語や月ごとのコミット量、コミュニティサイズの変遷などの情報が分かりやすく提供されています。

　他には、Googleが公開しているOpen Source Insights 。 ここでは、OpenSSFが公開しているScorecardsがマージされており、それぞれのOSSの活動の活発さなどが見られるようになっています。

　npmやpypi、mavenなどのパッケージ配布サイト上でも、同様の統計データが提供されていることが多いです。こういったWebサイトを活用することにより、OSSコミュニティーの活発度合いを測り、活用するOSS決定の手がかりとすることができるでしょう。

　上記のように、機能面だけでなく、さまざまな統計データや口コミを手掛かりとして、利用するOSSを選択する開発者が多いのではないでしょうか。一方で、会社内でのソフトウェア開発にOSSを利用する場合は、ライセンス面から見た場合のOSS選定の仕方、という点にも注意しておくと、後から困ることが少なくなります。

5.企業におけるOSSの利用ポリシー

　会社内に特定のOSSライセンスの利用に関する規程やポリシーがある場合があります。社内のOSSに関係するWebサイトを参照する、関連する部門に聞くなどしてみてください。

　なぜなら、特定のライセンスで許諾されるOSSを、社内ポリシーをよく理解しないまま利用した場合、使い方によっては、例えば自社の公開できないソフトウェアのソースコードを一般に公開しなければいけなくなるなどの事態に陥り、自社のビジネスや知的財産に大きな影響が出る可能性があるためです。

　例えばGoogleでは、Google Open SourceというWebサイト上で「AGPLを一切利用しないこと」というポリシーを公開しています。

6.ライセンスの両立性

　ライセンスの両立性にも注意してください。例えばフリーソフトウェアファウンデーションは、GPLと両立するライセンス、両立しないライセンス、といったFAQをWeb上で公開しています（正式には英語のオリジナル版を参照してください）。

　こういった両立性の問題は、OSS同士の利用構造などを含めてライセンス間に矛盾がないかを検討しなければならず、法務部門だけでは解決しにくいことが多いです。安易にOSSを組み合わせた結果、ライセンスを順守できなくなり、解決までに長い時間がかかることがあります。

　まとめますと、開発者がどのOSSを使うかを判断する場合、StarやFork、紹介記事などによるソーシャルな評価と、コントリビューター数や更新頻度などといった統計データを見て評価し、採択することが多いと思います。

　一方で、OSSを選定する段階から社内のOSSポリシーやOSSライセンスを考慮しておくことにより、リリース段階で求められるOSSライセンス順守への対応がスムーズになることも多いです。今後、OSSを選択する際に、評価ポイントの一つとして加えてみてはいかがでしょうか。

注1：実際に検索をしてみると、「OSS名称A vs OSS名称B」などといった検索サジェスチョンが多く見られます。OSS名称AというOSSの代替を探す場合には、OSS名の後に vsと付けてみるというのは、ライフハックの1つかもしれませんね。
注2：なおStarは、作者に対して称賛を送るだけではなく、自分のアカウントでリポジトリを覚えておくとか、お勧めに使われるという機能があります。
https://docs.github.com/en/get-started/exploring-projects-on-github/saving-repositories-with-stars
注3：どのように測定しているかについては、筆者の知る限り、公式回答はされていません。
https://github.community/t/how-github-detect-trending-repositories/824/21

エピソード12　長い目で見たOSS選択とコンプライアンス

　活用するOSSを選択する際には、ソーシャルな情報や統計データが用いられることが多いが、会社のポリシーやOSSライセンスにも注意しておく必要がある、と理解した新城くん。でも佳美先輩は、もう少し伝えたいことがあるようです。

　佳美先輩は、OSS活動の統計データを見るだけではなく、実際にそのOSSで公開されているその他のドキュメントを確認することの大切さや、OSSの開発に参加している開発者たちのメーリングリストやIssuesなどのやり取りに注目し、OSSコミュニティーを理解することの大切さについて話します。

新城くん、OSSコミュニティーの活動に関する統計データも大切なんだけど、OSSを継続して活用していこうという場合には、使おうとしているOSSのコミュニティーをより深く理解したほうがいいの。

コミュニティーの活動が活発で、多くの人が勧めているだけじゃだめなんですか？

ソーシャルな情報とか統計データは、コミュニティーの特定時点のスナップショットでしかないの。長い年月でどうなっていくか、それを考えに入れておくと安定したソフトウェア開発ができるのよ。

解説：OSSコミュニティーは移り変わるもの

　OSSを活用して自社の製品を開発する場合、製品によっては非常に長い期間、そのOSSを活用していくことになります。すると、OSS選定時には活発だったコミュニティーも、長い年月を経て変わってしまうことがあります。

　どのように変わっていくのか、未来を予測することは難しいですが、幾つかのポイントを押さえておくと、活用するOSSの入れ替えや、ソフトウェアの再設計といった事態の回避に少し役立ちます。

　Linux Foundation主催のOpen Source Summit Europe 2021のOSPOConにおいて、「Navigating Open Source Project Risk」という発表がありました。下記ではこれを紹介します。講演の録画は、YouTubeで見られます。

　この講演では、OSSの活用で自社の製品開発やサービスの継続に支障が出る可能性があり、企業はそれをOSSのリスクとして認識しておく必要がある、という話をしています。では、どのようなリスクがあるのでしょうか。

ライセンスが変わるというリスク

　例えば、1つの企業だけで管理されているようなOSSは、その企業の方針によって、ある日突然、商用ライセンスに切り替わってしまうリスクがあります。ライセンスが変わってしまうと、製品によってはそのOSSを継続して活用するのが難しくなってしまうことがあります。

OSSコミュニティーのガバナンスが効かなくなるリスク

　ガバナンスが効かなくなると、OSSのコミュニティー内の意思決定がうまく回らなくなることがあります。このようなOSSではforkが起こりやすくなる傾向があることも分かっています。つまり開発者コミュニティーが分裂し、利用していたOSSが幾つにも分かれて開発されることになります。

　forkが起こってしまった場合、そのOSSを活用していた企業としては、どのforkを使うべきか、コントリビューションはどこに行うべきか、などの課題が出てくることになり、安定したOSSの管理ができなくなってしまいます。

　また、コミュニティーが分断され、forkが起きてしまうと、元の活動レベルに戻るまでに長い時間がかかることがあります_（注4）。

　活用しているOSSが長い時間、安定した開発やメンテナンスがされないというのは、それを使って製品開発を続けている企業にとって、大きなリスクとなります。

　この講演では、このようなリスクを完全に避けることはできないが、幾つか気をつけておくべきポイントがあるとしています。以下に、そのポイントを列挙します。

1.OSSがニュートラルな組織で管理されているか

　競争関係にある多くの企業などによってボードメンバーが構成されているようなOSSは、突然ライセンスが変わることもなく、コミュニティー全体の利益になる方向で議論を進められるので理想的です。

2.OSSコミュニティーが正しくガバナンスされているか

　ここでいうガバナンスとは、人と人のコミュニケーションについて規定することです。OSSコミュニティーでは、議論をどのように進め、決定するかを明文化しておくべきです。また、誰をリーダーとするかも非常に重要です。リーダー選出プロセスには透明性を持たせ、OSSに貢献してくれる人なら誰でもリーダーとなれる機会が広く提供されていることが大切です。

3.リリース、ホットフィックスが頻繁にされているか

　ソフトウェアが頻繁に更新されており、コミュニティーが活発であることは、多くの人によって開発、管理されている証拠であり、そのOSSを活用する際のセキュリティリスクを低減することにもつながります。

4.ライセンス、Code of Conductとコントリビューション方法が適切に提示されているか

　新規にコミュニティーに貢献してくれる人だけでなく、既にコミュニティーに属している人にとっても、「どのように貢献すればよいのか」「どのような条件で利用できるのか」「どのように振る舞うべきなのか」が明らかになっていることは重要です。これらが明確に示されていると、コミュニケーションでフラストレーションがたまらず、コミュニティーが円滑に運営されることとなります。それは、コントリビューター、コントリビューションを増やすことにつながり、そのOSSの質を上げることになるでしょう。

5.コミュニティーの雰囲気と参加している人たちの多様性

　コミュニティーに参加している人々がお互いに助け合い、優しく、互いにリスペクトしていることが感じられて、参加しやすいコミュニティーから提供されているOSSは、継続してメンテナンスされていくことでしょう。また、さまざまな視点を持つ多くの人々から貢献されているOSSは、そのコミュニティーをより良いものにしていきます。

6.そのOSSの利用者は十分に多いか

　やはり、さまざまな個人や企業に多く利用されているOSSほど、開発が続いていく可能性は高くなります。

　この講演からも分かる通り、安定した製品やサービスを継続して提供するためにも、OSSを活用する場合は活用時点の機能や性能だけを重視するのではなく、そのコミュニティーと一緒に進めていけるかを考えるのがいいのではないでしょうか。

注4：過去、node.jsの分裂もありましたね。
https://yosuke-furukawa.hatenablog.com/entry/2015/08/24/152147

次回は……

　次回の「解決！ OSSコンプライアンス」では、協力会社を巻き込んだ大規模な開発に話が発展します。お楽しみに！