ソフトウェア開発において、もはやOSS（オープンソースソフトウェア）の利用はほぼ必須と呼べると思われるが、OSSライセンスについて問題ないかを確認する作業は開発者にとってかなりの負担になっているかと思う。
世の中にはOSSの管理を支援するツールも普及しているものの、一部の言語には対応していなかったり、完全に人のチェックを手離れさせるのはまだ難しいという印象である。
知財部の立場から言えば、自社のプロプライエタリなコードの開示義務が生じたり特許権の許諾義務が生じる可能性もあるので、口酸っぱく注意喚起するしかないのが辛いところである。
ところで、パッケージにちょいちょいOSSのデュアルライセンスが含まれるケースを見かけるのだが、自分の勉強も兼ねてデュアルライセンスについてこの記事で整理しておきたい。
デュアルライセンスの概要
OSSのデュアルライセンスとは、同じソフトウェアに２つのライセンスを重ねて適用するものではなく、２つの異なるライセンス形態で選択的に提供される仕組みである。
ユーザーは、その中からいずれかのライセンス条件を選んで配布することができる。
デュアルライセンスは、いずれもOSSライセンスの場合と、商用ライセンスとOSSライセンス（コピーレフト条項が付いていることが多い）を選択可能なデュアルライセンスの場合とがある。
ちなみに、３つになればトリプルライセンスと呼び、こういった複数ライセンスのうちいずれか１つを選択可能な場合をマルチライセンスと呼ぶらしい。
いずれもOSSライセンスの場合
この場合であれば、企業としてはより条件の緩いライセンスを選択することが普通であろう。
ソースコード開示義務や、特許権の許諾義務を極力回避したいからである。
例えば、GPLとMITのデュアルライセンスの場合は、通常はMIT Licenseを選択する。
商用ライセンスとOSSライセンスとを選択させる場合
例えば、GPLと商用ライセンスとGPLのデュアルライセンスの場合について考えてみる。
商用ライセンスの実務上の位置づけとしては、OSSライセンスの制限を避けたい企業向けの「ライセンス回避の選択肢」として設計されている。
この場合、商用ライセンスでは、OSS版で義務付けられているソース開示や特許ライセンスを免除する旨を明記していることが多い。
したがって、企業が独自の製品に組み込んで販売するなら、対価を支払うことで商用ライセンスを選択し、クローズドな利用とすることが可能である。
一方、対価を払わない場合はGPL条件を遵守する必要があるが、オープンソースプロジェクトならGPLを選択するということもできる。
デュアルライセンスにおける誤解
OSSのソースコードのパッケージには幾つかのコンポーネントが含まれており、それぞれのコンポーネントのライセンスが異なる場合もある。
OSSの勉強をし始めたときはこれがデュアルライセンスかと思っていたが、これはデュアルライセンスではない。
パッケージとして見ると、一部のコンポーネントはその他のコンポーネントとは異なるOSSライセンスが適用されているだけであって、別なライセンスが選択可能というわけではないからである。
開発から「このパッケージのOSSライセンスはこれです」と出された後、開示されているURL先を見に行ったときにOSSライセンスが聞いていたのと違う場合、このパターンであることが多い。
この場合、パッケージから手作業でライセンスの明記されているテキストを漁ったりする必要があり、かなり面倒である。
OSS検知ツールである程度は把握できるとはいえ、たまにこういう事例があるので、なかなか人の目を完全に無くすのは難しいという印象である。
まとめ
デュアルライセンスは便利な柔軟性を持つ一方で、「同じコードに複数のライセンスが重なっている」と誤解されやすい。
実務では、著作権者、ライセンス内容、選択の影響を整理した上で運用することが重要である。