Linux（オープンソース）を組み込み機器に活用～その壁と自社ノウハウや知的財産を流出させないための勘所～

Linuxなどのオープンソースソフトウェア（以降OSS）には、利用するためのルールとしてライセンスがあります。

Linuxの大部分はGNU GPL（以降GPL）というライセンスを適用しているため、Linuxで動くソフトウェアや製品をリリースする場合でもライセンスに注意する必要があります。

気を付けないと、自社ノウハウや知的財産が含まれた大事なソースを開示しなければならなくなってしまいます。

これが怖いので、LinuxなどのOSSの採用を躊躇している、という話をよく聞きます。

一方で、そういったことを気にせず会社の上の方で採用を決めてしまって、開発現場の人間が混乱している、というケースも聞きます。

しかし、必要以上に恐れる必要はありません。

ちゃんと理解して臨めば、OSSの恩恵を享受しつつ、自身を守ることができます。
逆に、理解を後回しにしてささやかな手間を惜しんだり、ましてや、OSSを利用していることを隠したりすると、後からどうしようもなくなってしまいかねません。

守らなければならない約束や準備をしっかりと抑え、その上で、自社のノウハウや知的財産を守るためのコツを知ってうまく立ち回りましょう。

こういったことは、OSSの理念と対立する物でもありませんし、狡猾に利用しようとするものでもありません。
直接OSSをリリースするわけでなくても、これを活用することは、その利点をアピールし、利用価値を高めることにもつながることだと思うのです。
それに、OSSの利用者でいると、なんだかんだとOSSの提供者になってたりするものです。

一番困るのはソース公開

さて、約束事やコツの話は少し細かくなってくるので、その前にざっくりと「こんな感じ」という話をしましょう。
アプリや製品の開発者から見て、何がGPLで、何がソース開示につながるのか、と言う部分です。

まず、Linux（OS）自体のプログラムのライセンスがGPLです。GPLなので、全てソースが開示されています。

OSとアプリの間で動くソフトウェア≒ライブラリやミドルウェアのライセンスは、GPLやLGPLなど（GPLと両立するライセンスなど）です。
これらは、プログラムの構造上GPLであるOSと切り離せないため、GPLやLGPLを採用しています。その為、GPLの条項に基づき、ソースを開示しています。

アプリは、ライブラリを使わなければ、GPLの条項に縛られることは無いので、ソースを開示する必要はありません。
しかし、多くの場合、ライブラリなどを利用しますので、そのライブラリのライセンス形態が重要になってきます。

アプリのソースを公開できない場合は、GPLのライブラリではなく、LGPLのライブラリを使いましょう。
使用するライブラリなどがGPLの場合、アプリもGPLの条項に基づき（GPLなどにする必要があるため）ソースを開示する必要があります。
使用するライブラリなどがLGPLの場合、アプリのソースは開示する必要はありません。

実際はここまで単純ではありませんが、なんとなくソフトウェア同士のつながりがライセンスのつながりでもある、ということが分かるかと思います。

具体例

では、守るべき条件と対応のコツを具体的に見ていきましょう。
状況や解釈の違い、グレーゾーンなどもあり、全てを網羅するのは難しいので、次の状況において私ならどうするか、私の解釈と経験からお話しします。

状況

OSとしてLinuxを採用した製品を開発/販売する。
ハードウェアドライバを作る、あるいはカスタマイズする。
既存のGPLライブラリやミドルウェアを活用。
アプリを作る。開示できない重要な部分が含まれている。

対応例

アプリはGPLにせず、ソースは提供しない。製品に入れるアプリは、バイナリ、オブジェクトコードだけ。アプリで使用するライブラリは、LGPLの物を使用。
LinuxのOS部分やライブラリ群がGPLなので、これらのソースをストレージに格納。WEBサイトからダウンロードする形にしても良いが、製品のストレージに余裕があったので、その中に入れることにした。
自作したLGPLライブラリやGPLドライバも、ソースをストレージに格納。
自作したGPL/LGPLのプログラムと、追加したGPL/LGPLのプログラムの一覧をソースと一緒にストレージに格納。Linuxのソースに付いてきた一覧表もそのままストレージに残す。
マニュアルにGPLやLGPLのプログラムを利用している旨を記載。

具体的な守るべき条件や権利と対策

製品の中に格納されているOSはバイナリ形式ですが、その実態はLinuxであり、そのライセンスはGPLなので、ユーザから求めがあった場合は、そのソースを提供する義務があります。
ソースの入手方法を提示する形でも構いません。
ソースの提供は有償で構わないし、その上限もありませんが、多くのメーカは手数料程度しか請求しないか、WEBサイトから無償でダウンロードできるようにしています。GPLの条項により、ソースを入手したユーザもそれを無償配布する権利を有するからです。（吹っ掛けても悪評しか得られない）

ハードウェアドライバを作った場合、そのライセンスはGPLになっているはずです。なぜなら、ドライバと一緒にコンパイル、あるいは密接な構造でコンパイルされたドライバもまた、OSという大きな1つのソフトウェアの一部であり、ドライバの中でもOS（カーネル）のソフトウェアが実行されるからです。
従ってドライバのソース、あるいは（既存ドライバを改変した場合は）元のソース＋改変パッチを提供する義務があります。

GPLのソフトウェア（カーネルやドライバ）を改変してリリースすことも自由です。ただし、その改変したソフトウェアのライセンスもGPLにする必要があります。そのソースと元のソース（あるいは元のソースの入手方法と改変差分のパッチ）を提供する義務があります。

GPLのライブラリやミドルウェアを活用したい場合ですが、そのままリンクして使う（アプリからCallや参照する）と、アプリまでGPLにして公開しなければならなくなります。
対策として、ファイルやストリームを挟む方法が考えられます。
例えば、データAをフォーマットBに変換するGPLプログラムを使いたい場合。
データAをアプリがファイルやストリーム、パイプ経由でGPLプログラムに渡し、変換結果をファイルやストリーム、パイプ経由で受け取ります。
ファイル入出力の無いライブラリなどの場合は、ファイル入出力のみ担当するLGPLのプログラムを作ってしまいます。
注意しなければならないのは、構造体やプロセスをそのままスルーするだけのものを作ってもダメと言うことです。
そんな方法では、アプリでGPLのプログラムを実行しているのと変わらないので、ライセンス違反になってしまいます。
しかし、ファイルやストリーム経由の場合は、アプリとは別にGPLプログラムを使っているだけなので、アプリはGPLに縛られません。

LGPLのライブラリは、そのままリンクして使ってOKです。

LGPLのプログラムを自作した場合は、当然LGPLに従ってソースを提供する必要がありますので、この中には公開できない様な技術や秘密を置かない様にします。

GPLやLGPLにするプログラムのソースには、目立つところ（ソースの頭）にライセンスの定型文を載せます。

既存のGPL/LGPLプログラムを改変する場合は、元のライセンス文や著作者名を消さないように注意し、自分やメーカの名前と日付、改変の概要を追記します。細かく書く必要はありません。新旧ソースまたは旧ソース＋パッチを提供しますので。

GPLもフリーソフトウェアの思想に基づくものですが、ここでいうフリーは無料と言う意味ではなく自由と言う意味です。
つまり、自由に活用できるように様々な条項が設けられていますが、有償で販売することも自由です。
その為、製品の中にGPLの物と独自ライセンスの物が混在していても、自由に価格を付けて販売できます。

GPLなどのソフトウェアも、著作権は放棄されていません。
開発者の著作権を守ったまま、ユーザにも改変/再配布を許諾する、懐の深いライセンスなのです。

ソース提供方法はいくつか選択できますので、自分に都合の良い方法を選択すれば良いでしょう。
WEBサイトからダウンロードする形でも、問い合わせしてもらってから送付する形でも、機器（現物）からダウンロードする形でもOKです。
ソース抜きでバイナリのみ（製品のみ）販売して「別途ソースコードを配布する」という書面を発行、という方法もありますが、この場合、ユーザから第三者にバイナリが渡ったケースであっても第三者からのソース要求に応える義務が生じ、負担になりますので、できれば避けたいですね。
私としては、製品の空きストレージに入れてしまって「そこからダウンロードしてね」という形が一番手離れ良く、楽だと思います。

マニュアルや画面にGPLやLGPLのプログラムを利用している旨を記載する義務があります。
マニュアルがベストですが、マニュアルが同梱できないなど都合が悪い場合は、ヘルプ画面などでも良いでしょう。
GPLの本文は、ソースなどと一緒に入れておけばOKです。