[[151274]]

[51CTO.com クイック翻訳] ライセンスはオープンソースプロジェクトの法的基盤ですが、多くの企業はその管理方法を必ずしも把握していません。ジェフ・ルシュツ氏は、組織がアップストリームソフトウェアライセンスのコンプライアンスを確保できるよう支援するためにPalamidaを設立しました。その過程で、彼と彼のチームは、使用されているオープンソースライセンスを知らないことが、セキュリティ上の脆弱性を認識し、修正するのを怠ることにつながる可能性があることを発見しました。

All Things Openカンファレンスで、ジェフは2つのプレゼンテーションを行いました。1つはビジネスとセキュリティの観点から見たオープンソースのROI管理について、もう1つはLinuxベース製品を知的財産権侵害やセキュリティ脆弱性から保護することについてです。私は最近、ライセンスとセキュリティの交差点について彼と話しました。

一見すると、知的財産権侵害とセキュリティ脆弱性は無関係な問題のように思えます。なぜこの2つが結びついたのでしょうか？

Palamidaが2004年に設立された当時、お客様の大多数は、使用しているオープンソースソフトウェア（OSS）コンポーネントに付随するライセンス義務の遵守について非常に懸念を抱いていました。そして、典型的なケースにおいてライセンスの使用率が95%以上も低いという事実に衝撃を受けました（これは現在も変わりません）。その結果、知的財産（IP）およびライセンス違反が発生し、ポリシーに違反したコンポーネントの大幅な手直しや交換が必要となりました。

これまでの取り組みの中で、セキュリティ脆弱性は同じ根本原因から生じていることが分かりました。企業が知的財産権のコンプライアンスを確保するためにオープンソースコードを追跡していない場合、バージョンアップデート、バグレポート、パッチ適用も怠っていることになります。その結果、インストールされたソフトウェアシステムには、時には10年も前のコードベースが含まれ、既知のセキュリティ脆弱性が潜んでいることになります。

パラミダのスキャンでは、コードベースの発見とアップグレードに向けた世界的な取り組みにもかかわらず、今日でもHeartbleed（2014年にOpenSSLで発見されたセキュリティ脆弱性）が依然として検出されています。ほとんどのソフトウェア製品はスキャンやレビューが行われておらず、脆弱なソフトウェアコンポーネントは無視されています。

最前線の従業員は、オープンソース プロジェクトの使用と貢献が会社にとって有益であることを経営陣に納得させるにはどうすればよいでしょうか。

これは長く困難な作業になる可能性があります。Heartbleed以前、OpenSSLは年間数千ドルの寄付しか受け取っていませんでした。これは驚くべきことかもしれません。Heartbleed後、状況は大幅に改善されました。他のプロジェクトはそれほど幸運ではなく、寄付やソースコードの貢献は依然として低調です。

私がこれまで見てきた有益な事例の一つは、製品開発の原動力となる主要なオープンソースプロジェクトへの貢献です。これらのプロジェクトは社内コードを直接置き換え、潜在的に「コスト削減」につながる可能性があります。これらのコンポーネントを活発に活用し続けることは、会社の収益増加にも繋がります。多くの企業が行っている「手軽な」支援活動として、寄付とバグ報告・修正が挙げられます。寄付は迅速かつ簡単で、締め切りにも影響しません。少額の寄付でも大歓迎です。

もしあなたの会社のビールやコーヒーの予算がオープンソースへの寄付の予算よりも大きいなら、あなたの会社には何か問題があると言えるでしょう。

コードや時間の寄付は、より困難な場合があります。企業規模が大きければ大きいほど、法的なハードルも高くなります。バグ修正やパッチは、主要な機能や専任の開発者を寄付するよりも、議論の余地が少ない場合が多いです。これは、経営陣がオープンソースの寄付のニュアンスを理解するための良い出発点となります。

ますます多くの開発者が、職務内容にオープンソースへの貢献を盛り込み、社内での影響力を活用して、アップストリームへのコードリリースに必要なサポートを確保するようになっています。「LinuxやHadoopで働けないなら、他を探します」。これは多くの開発者には当てはまらないかもしれませんが、もしあなたがキャリアのこの段階にいる幸運な人であれば、会社に大きな影響を与える可能性があります。

プレゼンテーションでは、オープンソース企業の観点から製品管理に焦点を当てていたように思います。この点において、Software Freedom Conservation Society（SFC）やApache Foundationのような組織はどのような役割を果たせるでしょうか？

これらの組織はオープンソースプロジェクトの有力な創設者であり、オープンソースの作成と利用に関する期待を定義する上で貢献しています。私たちはクライアントに対し、ライセンス上の義務だけでなく、コード作成者の哲学や記述方法も考慮するようよくアドバイスしています。ライセンスの法的遵守は重要ですが、関わるコミュニティの文化への準拠は全く別の問題です。企業がライセンス条項に関して「法的に正確」であろうとしながらも、ライセンスの精神に完全に違反しているケースがあります。コミュニティはすぐに、これは受け入れられないと指摘するでしょう。

オープンソースを正しく利用する責任はオープンソースユーザーにありますが、正しい行動を奨励することは、このような組織にとって最大の利益となります。多くの企業は正しい行動を取りたいと願っていますが、何をすべきか、どのように始めればよいかがわからないことがよくあります。

こうしたタイプのコミュニティは、トレーニングを提供したり、コミュニティ内外の開発者と協力したり、企業が業界団体とコミュニケーションをとることを容易にしたりすることで、多くの企業がオープンソース ソフトウェアをより簡単に使用できるようにします。

オープンソースの原則を遵守する上で最大の課題は何だと思いますか?また、この分野の将来の見通しはどうですか?

実際に大量のオープンソースソフトウェアを使っていると信じている人はいません。多くの企業と取引する際、私たちはオープンソースソフトウェアをどれだけ使っているかを尋ねます。最もよくある答えは、「オープンソースを使っていることは分かっているが、どこで使っているかは分からない」というものです。さらに問い詰めると、企業は実際に使っているオープンソースソフトウェアの5%程度しか挙げられないのが普通です。コードを調査すると、何百、時には何千ものコードリポジトリが、自分が使っていることに気づいていないことが明らかになります。これらの忘れられたリポジトリは、どれもライセンスに違反しています。

コードレビューの結果を確認しない限り、技術管理チームにコンプライアンスを理解してもらい、それに応じた予算を準備してもらうことは難しい場合があります。チームが多数のコードベースを削除し、数百のコードベースについてライセンス開示を確立・公開し、必要に応じてアップグレードやパッチを適用して潜在的なセキュリティ脆弱性を修正することで初めて、「最初から正しく行う」ことが容易になります。コストと評判の観点から言えば、システムをゼロから正しく構築する方が、後から修正するよりも常に安価です。

時間は極めて重要です。多くの企業は、オープンソースの活用に関する知識の少なさに気づき、コンプライアンスへの取り組みに圧倒されています。かつてはCEOが数ヶ月かけて迅速に行う、リソースを集中的に投入する分析作業が、プロジェクトチームが着手するよりも早く、コストのかかる作業へとエスカレートしました。Heartbleed事件は、多くの企業のコンプライアンスへの取り組みを根本的に変えました。なぜなら、この分野における自社の理解がいかに真実からかけ離れていたかを認識させたからです。

今年の Embrace Open Source カンファレンスで、見逃せない基調講演はどれだと思いますか?

私はオープンソース ライセンスに非常に興味があり、今年の Embrace Open Source カンファレンスではこのトピックに関する優れたプレゼンテーションがいくつか行われました。

Heather Meekerさんとは長年一緒に仕事をしてきましたが、彼女の講演「コードを自由にする（弁護士を怖がらせることなく）：コードのデプロイと貢献におけるライセンスと知的財産権の考慮」を心待ちにしています。Heatherさんはこのテーマについて多くの研究を行っており、このプロセスで得られた教訓を明確かつ簡潔に解説してくれるでしょう。彼女の講演からは、いつも何か新しいことを学べます。

さらに、ブラッドリー・クーンの講演「GPLは企業に利益をもたらす」も強くお勧めします。オープンソースにGPLを採用しているコミュニティの目標と動機を理解するのに役立ちます。残念ながら、私の講演と同じ時間に予定されているため、今年は直接聞くことができない可能性があります。

最後に、「商用ソフトウェアをオープンソース化するための技術的、ビジネス的、そして法的選択肢」と「オープンソースライセンスの理解」という2つのプレゼンテーションはどちらも有望に思えました。残念ながら私は直接参加することができなかったので、もし参加できていれば両方ともぜひ参加したかったのですが。

元のタイトル: あなたの会社はオープンソースをどれだけ使用しているか知っていますか?、著者: Ben Cotton

[この記事は51CTOによって翻訳されました。提携サイトへの転載の際は、元の翻訳者と出典を51CTO.comとして明記してください。]