検索
連載

訴訟が増えている!? OSSライセンス違反企業技術者のためのOSSライセンス入門(1)(1/2 ページ)

この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。(編集部)

Share
Tweet
LINE
Hatena

 いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア(OSS)との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。

「使えるんだから、勝手に使っていいんでしょう」!?

 お客さまとお話ししていると、中には、何ら悪びれることなくこんな発言をする方に出くわし、ビックリします。

 このケースでは、OEM販売するプログラムを海外から導入するに当たって、「Black Duck Protex」でコードを検査したところ、OSSやサードパーティ製プログラムが多く検出されたので、「おかしなプログラムが含まれていないか、普通に使われているOSSか」、そういう観点で問い合わせをいただきました。

 しかし、話をする中で気になる点がいくつか出てきたため、「これらのOSSのライセンスは順守されていますか?」とお聞きしたところ、返ってきた答えは「えっ、使えるんだから勝手に使っていいんでしょ?」というものでした。

 こういう方には、以下のようにお話しして、OSSライセンスを理解してもらいます。

  • OSSには、パブリックドメインソフトウェア(PDS)と違い、著作権があります。
  • OSSも著作権者がライセンスを設定して、それに従った使い方を指定しており、その結果ソースプログラムの公開などがされているものです。

 そもそも、プログラムには著作権があり、保護されていることは、あまり理解されていないようです。

 多くのパッケージプログラムの使用許諾がよりどころにしているのが、著作権法よりも、むしろ利用者との契約という形態が一般的なことも一因かもしれません。

 また、ハードウェア製品を開発している方は、昔のように「ソフトウェアはハードウェアのおまけ」という考え方は少なくなってきたものの、まだ、ソフトウェアを軽視している方もおられ、ハードウェアにはある「特許権」や「商標権」などの知的財産権については気にしていても、ハードウェアでは想像しにくい「著作権」まで意識が至っていないようです。

 だからでしょうか。「OSSのソースプログラムを開示しなかったために、提訴」された事例は、圧倒的にハードウェア製品ばかりという状態が目立ちます。

ソースプログラム非開示を理由とした提訴の事例

 Linuxなどで適用されているライセンスであるGNU GPL(GNU General Public License)version 2などは、再頒布の際の条件として、ソースプログラムの開示を挙げています。

 「再頒布」とは聞き慣れない言葉かもしれませんが、その行為の1つとして、GPLのOSSを利用して製品を開発し、その製品を一般に販売するなどして第三者に頒布することなどを表します。

 まだ誤解している方もいらっしゃるようですが、この要件が付くのは、製品として販売している場合に限りません。研究機関や学生がOSSを利用した研究成果として公開する場合、あるいは自治体がOSSを利用した電子自治体システムとして公開する場合でも、同じ「再頒布」であり、ライセンスの順守、つまりGPLならばソースプログラムの開示などが再頒布の条件です。

 「ソースプログラムの開示」とは、GPLのライセンスでは、主に以下の2つの手段のいずれかで実施することが求められています。

  • (バイナリプログラムを含む製品とともに)ソースプログラムを添付
  • ソースプログラムを提供する旨を記載した書面の(製品への)添付
画面1 BusyBoxのHall of Shame!!!サイトの例
画面1 BusyBoxのHall of Shame!!!サイトの例

 開発者によっては、ソースプログラムを開示していなかった製品をWebページなどで非難したりします(画面1)。

 OSSの著作権者である開発者は個人であることが多いため、企業を提訴しづらいものです。そのため従来、訴訟に至るのは、MySQLなど著作権者が企業であるOSSの場合などと見られていました。

 しかし、昨年から米国のSoftware Freedom Law Center(SFLC)が活発に訴訟を起こしています。

 SFLCは、昨年リリースされたGPLv3策定の中心的人物、エベン・モグレン(Eben Moglen)教授が中心となった組織です。

 もちろん、SFLCはOSSの著作権者ではないため、一連の訴訟は、GPLv2でライセンスされている「BusyBox」の主要な2人の著作権者の代理人として提訴したものです。

 最後の訴訟以外は和解が成立しています。4件とも似た条件で和解しています。

a)利用したBusyBoxのソースコードをWebサイト上に公開する
b)ユーザーに対してライセンスを告知する
c)OSSライセンス順守に関する責任者を社内に設置する
d)各社が、和解金を支払う

 a)とb)はGPLでのライセンス条件そのものですが、c)は、継続的なコプライアンス強化体制の確立を目的にしているようです。d)はペナルティでしょうか。

 元々のライセンスにはなかったc)d)の追加条件は、今後、「訴訟が起きてからソース公開すればいいや」という風潮にならないように付け加えられたものといわれています。

 コンプライアンスを気にする企業でしたら、訴訟が起きること自体、企業価値の損失と考えるでしょうし、Webで非難されることでさえ企業価値の損失につながると考えると思います。

「機器に組み込まれてしまえば分からない」?

 Intellectual Property(知的財産)は、IPと略します。そして、自社の事業をプログラムの保護やライセンスに準拠させていく活動を「IPコンプライアンス」ということがあります。

 OSSライセンス違反によって訴訟を起こされたり、Webで非難されるような事態に至る背景に、このIPコンプライアンスにかかわるリテラシー教育の不足があるのではないかと思います。

 IPには、だいたい以下のような種類の権利があります。

図1 知的財産権
図1 知的財産権

 技術者にはこういう話を好まれない方が多いのではないでしょうか。10月28日のIPA Forum 2008 オープンソフトウェアセッション特別講演で、OW2 Consortium CEOのセドリック・トーマス(Cedric Thomas)氏も「OSSにかかわるまで、こんなにIPについて勉強することはなかった」と語っていました。

 「前世紀のLinux:飛翔編」で生越氏が述べていますが、日本Linux協会(JLA)の設立目的の1つに、商標権の問題がありました。協会設立後も、コンピュータに関係ない類で「Linux」という商標を乱獲する人がいたため、Linux商標調査ワーキンググループ(WG)を設けて調査に乗り出したことがあります。

 このように、OSSを利用するにはIPの知識は必須だと思います。

 そのことを認識せず放置しておけば、ライセンス違反のリスクをより多く抱えることになってしまいます。前述した訴訟の例からも分かるように、デジタル家電製品や無線LANなどの通信機器でのOSSライセンス違反が多く指摘されているのも、ハードウェア製品の開発者の方の多くは、特許権や商標権にかかわる教育は十分でも、著作権にかかわる教育が不足しており、著作権を前提としたOSSライセンス順守の意識が低いのではないかと推測します。

 例えば、ある技術者から「機器に組み込まれてしまえば、『OSSを使っている』といわなければ分からないでしょう?」といわれたことがあります。むしろ組み込み機器でこそソースプログラムの非開示が見つかり、提訴されている現実をきちんと認識する必要があります。

 セミナーでお会いする一部の良識ある技術者の方の中には、著作権違反を気にして、同僚や会社の意識の低さを憂えている方もいらっしゃいます。そして、同僚の多くに好まれないリテラシー教育をいかに実践していくか、なかなか手を打てないでいるともお聞きします。この状況は、やはり事業責任者、経営層の方が組織的にIPコンプライアンス強化のリーダーシップを取っていただき、リテラシー教育から実践することが求められていると思います。

Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ
ページトップに戻る