今日、Open Source Softwareに関するセミナーに参加してきました。セミナーは法務部向けの内容になっていたので、ソフトウェアの知識がなくてもOpen Source softwareを扱うときの注意点を学べました。今回はそこで学んだことの一部をシェアーします。
こんな人にお勧め
ソフトウェアを商品やサービスの一部として提供している会社の知財・法務部は、自社のソフトウェアにどのような Open Source Softwareが使われているかを把握しておく必要があります。また、社内で使っているソフトにもOpen Source Softwareが使われていると潜在的なリスクが存在します。
学んだこと
セミナー自体は大体1時間のもので、内容も濃かったのでこの記事ではすべてを紹介できません。また、たとえ紹介できても内容が膨大になるので、今回は私がセミナーで学んだものを自分の視点で理解した範囲でシェアーします。
Open Source Softwareとはライセンス契約の1つである
まず最初にコンセプトとして知っておきたいことは、Open Source Softwareはソフトウェアのライセンス契約だということです。Open Source Softwareは、Windows OSなど社外秘の独自のソフト (proprietary software) と公共の無料ソフト (Public Domain software) の中間にある存在で、使う際にロイヤルティーは発生しない(無償、タダ)だが、ライセンス契約は存在するので、使う際にさまざまな制約が発生する可能性があるということです。
Open Source Softwareには様々な種類がある
Open Source Softwareといっても様々なライセンスの種類があり、仕様するOpen Source Softwareの規約には法律的に使用するリスクが高いものやそうでないものも様々です。特に、GNUやGPL系のライセンスは制約が多く、侵略的 (invasive) なライセンスの部類なので、自社のソフトウェアにそのようなライセンスが適用されるOpen Source Softwareを使うのはリスクが高いです。反対に、BSDやMIT系のライセンス規約は制約が緩いので、同じような機能のOpen Source Softwareがあれば、代替品としてBSDやMIT系のOpen Source Softwareを使えないか検討してみるのも有効です。
規約を見るときに特に注意したいのが、各ライセンス規約のderivative worksの定義と権利(Open Source Softwareを変更した場合、その変更に対する所有権はどこにあるのか)、Copyleftに関する条項(自社ソフトのOpen Source Software化リスク。詳しくは次のセクションを参照)、Noticeと source codeに関する規約、特許ライセンス (Express and implied)、特許権利行使の放棄 (Patent non-assertion clauses)などです。そのような部分の細かいところまで確認してから、Open Source Softwareを使うべきとのアドバイスでした。その中でも一番気をつけたいのは、Copyleftのリスクです。
Copyleftのリスク
GNUやGPL系のライセンスは制約が多く、侵略的 (invasive) なライセンスが適用されるOpen Source Softwareを自社の独自ソフトに使ってしまうと、自社ソフト自体が使ったOpen Source Softwareのderivative workとみなされ、自社ソフト自体がOpen Source Software化してしまうリスクがある。つまり、自社ソフトのソースコードを公開しないといけなくなり、自社ソフトを知財で守れなくなってしまうリスクがあります。
このようやCopyleftのリスクは2008年のCisco Systemsに対する訴訟などで注目を集め、大手ソフトウェア企業は他社のソフトウェアを使用する場合、売り手側に提供されるソフトウェアにOpen Source Softwareが使われていないことを補償したり、提供されたソフトにより自社のソフトウェアがOpen Source Software化した際の損害を補償する (indemnification) を求めるような契約を押しつける場合があります。
Open Source Softwareなしでソフトウェアはつくれない
しかし、ソフトウェアの開発にはOpen Source Softwareの使用は必要不可欠です。ソフトウェアをOpen Source Softwareなしで開発するのは効率が悪いし、ほぼ不可能になってきます。また、Software Development Kit (SDK)などでソフトを開発した場合、そのようなSDKにはすでに様々なOpen Source Softwareが使われているので、Open Source Softwareは使われているという前提で自社のソフトウェアを管理していく必要があります。
社内のOpen Source Softwareマネージメントと対策方法
Open Source Softwareが使われているという前提で自社ソフトを扱うには、まずどのようなOpen Source Softwareが自社ソフトに使われているか知る必要があります。これは、開発レベルでの話になるので、実際に開発に携わったプログラマーやソフトウェアエンジニアに話しを聞く必要があります。彼らが使ったOpen Source Softwareをすべて記録してトラッキングしていればいいですが、そうとも限りません。
そのような場合は、Open Source Softwareを検出してくれるソフトウェアなどを使って自社のソフトウェアにどのようなOpen Source Softwareが使われているのかを把握し、使用されているOpen Source Softwareのライセンス規約を特定し、上記に示したderivative worksなどの定義を確認し、自社ソフトにどのようなOpen Source Softwareのリスクがあるかを把握する必要があります。
使用されているOpen Source Softwareは1つではなく、30や50にも及ぶ可能性があります。そのような場合は、制約が厳しく、侵略的なものから優先的に規約の確認をし、可能だったら、条件が緩い別のOpen Source Softwareに切り替えます。もしそれが不可能だったら、自社のソフトウェアライセンス契約が使用しているすべてのOpen Source Softwareの規約を満たすように変更を加える必要があります。
また、Open Source Softwareの問題は開発に携わるプログラマーやソフトウェアエンジニアの意識によって変わります。Open Source Softwareに関する教育を定期的に行うことで開発レベルの人材の問題意識を向上させることが大切になってきます。
最後に、定期的なソフトウェアの監査、Open Source Softwareの使用を希望する場合は、承認プロセスを導入するなどのOpen Source Softwareによるリスクを未然に回避する取り組みも考慮するべきだと学びました。
まとめ
Open Source Softwareは質も非常に高く、今日のソフトウェア開発には欠かせないものですが、同時に、法律的なリスクも大きいものです。特に、自社が提供する商品やサービスにソフトウェアが使われている場合、提供ソフトに使われているOpen Source Softwareを把握し、管理していくことは大切な法務・知財の任務です。販売先によっては、Open Source Softwareに関する補償を求めてくる場合もあるので、リスク管理の一貫としてOpen Source Softwareの管理と社内での知識向上は重要な課題です。
まとめ作成者:野口剛史
セミナー講師:David A. Cornett and Katie Bates. Meunier Carlin & Curfman LLC
2件のフィードバック
OSSを製品に搭載するのは当然のこととなっていますが、このOSSについて第三者特許のクリアランスをどうとるかを悩んでいます。
有効な策がありましたらご教示いただけるとありがたいです。
難しい問題ですね。OSSと特許の問題についてもセミナーで話されていました。OSSの提供元と特許権者が同一の場合、OSSをそのまま使えば特許侵害リスクが少ないと言っていました。しかし今回の質問は、第三者特許のクリアランスですので、また別の問題だと思います。使っているOSSにもよると思いますが、基本的にOSSの規約では特許侵害などに対する免責(Indemnification)はないので、もしOSSを使用した自社ソフトが第三者の特許を侵害していた場合、OSSの提供元に何らかの損害賠償請求をするのは難しいと思います。そうなると、OSSを使っているからといって特別なことをする必要はなく、通常おこなっている特許クリアランスをすればいいと思います。しかし、特許クリアランス自体完璧にするのは不可能なので、どこまで調査をして、問題があったときにどのような対策が取れるかはケースバイケースですね。これが特許の難しいところです。