ソースコードを開示し，不特定多数の開発者の協力を得ることにより，ソフトウエアの品質を向上させたオープンソース・ソフト――。「無料で使える」「（多くの開発者の目にさらされるので）品質が高い」「不具合を自分で修正できる」「ネット経由ですぐに手に入る」など，その利点は多い。そのため，この数年でWebシステム開発を中心に国内でも定着。有名企業が基幹系システムで活用するなど，普及が進んでいる。

　だが，オープンソース・ソフトが多用されるほど，あるいはオープンソース・ソフトの開発コミュニティに参加する開発者が増えるほど，開発の現場は，ある深刻なリスクを抱えるようになってきた。それが，「オープンソースのソースコード混入」というリスクである。

よかれと思って混入させる

　オープンソースのソースコード混入とは，オープンソースの利用が認められていない開発プロジェクトや，著作権を発注者（ユーザー企業）に譲渡しなければならない開発プロジェクトで，オープンソース・ソフトが使われることを指す。オープンソース・ソフトをそのまま使うのではなく，ソースコードの断片が混入することもある。

　オブジェクト指向開発プロジェクトの経験が豊富な豆蔵の岩崎浩文氏（ビジネスソリューション事業部 エンタープライズシステムグループリーダーチーフコンサルタント）は，「現場の開発者は契約内容など知らない。だから，手早く開発したり，（実績のあるソースを使うことで）品質を上げようとしたり，よかれと思ってソースコードを流用してしまう」と指摘する。開発者の悪意やプロジェクト・マネージャのリスク判断ミスだけでソースコードが混入するとは限らない。その点が，この問題の根深いところだ。

　これまでも，オープンソース・ソフトからオープンソース・ソフトへのソースコード混入の危険性は指摘されてきた。例えば，あるSIベンダーA社のプロジェクト・マネージャは，「BSD」と呼ぶライセンス形態で配布されているオープンソース・ソフトを開発プロジェクトで採用するかどうかを検討する段階で，ソースコードを細かくチェックした。すると，BSDライセンスのはずなのに，「GPL（GNU General Public License）」と呼ぶライセンス形態のソースコードが混入しているのに気づいた。

　ご存じの方も多いと思うが，同じオープンソース・ライセンスでも，BSDライセンスでは派生物にソースコードの公開義務が及ばないのに対して，GPLでは公開義務が生じる。同じオープンソース・ソフトとはいえ，ライセンス形態ごとに，義務や制約には大きな違いがある。A社のプロジェクト・マネージャは，GPL違反を犯しているBSDライセンスのオープンソース・ソフトの採用を見送った。

　水際で食い止められれば，まだいい。現実には，商用ソフトや委託開発システムなどにオープンソースのソースコードが混入したままリリース（出荷または納入）されてしまう“事故”も相次いでいる。ある大手企業B社の開発責任者は，某ソフトウエア・ベンダーから購入したライブラリに，GPL違反のソースコードの断片を見つけた。開発元であるソフトウエア・ベンダーに問い合わせたところ，チェック漏れで混入したままリリースされたことが分かったという。

　こうしたソースコード混入に起因するトラブルは，組み込み系システムではすでに散発している。パソコン周辺機器のエレコムは2004年，同社製ルーターの利用者からGPL違反を指摘された。このルーターのファームウエアには，GNUライセンスで配布されているLinux Kernelのソースコードが混入していた。GNUライセンスの効力は派生物にも及ぶため，エレコムは最終的にソースコードを開示せざるを得なくなった。その結果，ソースコードに含まれていたルーターのリモート保守用の“バックドア”の詳細が明らかとなり，同社の開発者はバックドアの削除に追われた。

　企業内で使われる業務システムの場合，社外からソースコードの混入を指摘される可能性は少ないかもしれない。だが，企業コンプライアンス（法令遵守）の観点で見たときには，楽観視できないし，すべきでもない。

ソースコード・レビューだけでは防ぎきれない

　ソースコード混入を防ぐための基本的な策は，ソースコードを実際に目で見てチェック（レビュー）することだ。SIベンダーA社のプロジェクト・マネージャも，大手企業B社の開発責任者も，事前にソースコード・レビューをしたから，自社システムへのソースコード混入を阻止できた。ソースコードに記述されているコメント行をチェックしたり，ソースコードの書き方の変化を見分けたりすることで，「怪しい部分はある程度まで絞り込める」（A社のプロジェクト・マネージャ）という。

　だが，オープンソース・ソフトの種類が多岐にわたり，開発者が身近にオープンソース・ソフトに接するようになった今日，「ソースコード・レビューだけで防ぐには限界があるし，コストがかかりすぎる」（A社のプロジェクト・マネージャ）という声は少なくない。ユーザー企業との契約でオープンソース・ソフトを排除する必要があったSIベンダーC社のプロジェクト・マネージャは，オープンソースのコミュニティと接点のある開発者をプロジェクトに参加させないケースも少なくないという。「（オープンソースのコミュニティに参加する開発者は）技術スキルが高いだけに，参加してもらえないのは痛手なのだが……」（C社のプロジェクト・マネージャ）と頭を抱える。

　試行錯誤を重ねる現場にあって，一つのモデル・ケースとなりそうなのが，「“入口管理”と“出口管理”の両方で対策している」というB社のアプローチ。入口管理では，（1）開発に携わる社員/スタッフに事前の誓約書または契約を求め，（2）管理職だけではなく，現場開発者への啓蒙・教育を定期的に実施し，（3）開発プロジェクトの承認稟議にはオープンソース・ソフトの利用有無を明記させて利用しない場合はどうやってソースコードが混入していないことを担保しているのかを具体的に記述させる。出口管理では，（4）ソースコード・レビューを徹底するとともに，保険として（5）オープンソース・ソフトのソースコード混入をチェックするツール「protexIP」（開発は米Black Duck，国内販売はサイオステクノロジー）で検証する。もちろん，ソースコードの混入は現場で発生することが多く，これで完璧とは言い切れないが，「ある程度の担保はできたと考えている」（B社の開発責任者）という。

　記者はオープンソース・ソフトを否定するわけでも，ソースコード混入の元凶がオープンソース・ソフトにあると思っているわけでもない。世の中にせっかくあるオープンソース・ソフトなのだから，使えるところではうまく使うべきだと思う。しかし，開発現場を取材すればするほど，最近はリスクの高まりを感じずにはいられない。皆さんは，どのようにリスクをコントロールされているのだろうか？　できれば，皆さんの取り組みを教えていただきたい。