法務ネット　Ｑ＆Ａ

昨日はかなり酔っていたようで甲子園を乗り過ごしてしまい西宮で慌てて降りてタクシーで帰宅。が、昨日は三宮で飲んでいたので実は乗り過ごしていなかったことに今頃気付く。やはり相当酔っていたようです。三木さん、昨日はお付き合いいただいてありがとうございました！“””

西宮のケーキはここが最強だと思う。“””

キーボードを打つと小指がビリビリ痺れるので整形で診てもらったら、尺骨神経障害という診断名が付いた。タイピングできないと仕事も開発もできないので早く治さねば！ちなみにバイクには全く支障無し。仕事休んででも練習しろというお告げか？

“””

オープンソースライセンスが適用されたソフトウェアを使用していますが、先日知らない会社から通知書が届き、このソフトウェアはこの会社の特許権を侵害しているからライセンス料を請求されました。オープンソースソフトウェアの利用料はタダではないのですか？

オープンソースソフトウェアライセンスは、開発者自身が有する著作権、特許権、その他の知的財産権について、これを行使しないことを約束することをその本質としています。それ故に、開発に参画した者から、知的財産権の侵害について主張されることはありません。あるソフトウェアについてのソースコードは、それが盗用されたものでない限り、関わったすべての開発者はオープンソースライセンスの適用に同意していますので、著作権侵害が問題となることはありません。しかしながら、ソフトウェア特許は、「一定の効果を実現するソフトウェア技術」について権利が発生するものです。そのため、全く新たにかかれたソースコードであっても、開発者ではない第三者が特許権を保有している技術を利用してしまったのであれば、その特許を侵害することになります。 　あるオープンソースソフトウェアが本当に第三者の特許権を侵害しているのであれば、特許権者から利用者に対する損害賠償請求権が発生します。そのため、この場合は、特許権者に対してライセンス料を支払って使用許諾を得るか、利用をやめるかのどちらかを選択することになります。なおＣＰＬやＭＰＬではこの旨がライセンス条項内にも明記されています。

当社はあるオープンソースプロジェクトに参画していますが、他のある企業が、このプロジェクトの成果物であるプログラムをプロジェクトメンバーに了解を取らずにパッケージ化して販売を開始しました。どのような対策を取るべきでしょうか？

まずはそのプロジェクトにおいて使用されているライセンスの種別を確認し、その企業が行っている行為が法的に許容されているかどうかを正確に検討することが必要です。 　その上でライセンス違反であると判断できるのであれば、プロジェクトに参画している者は、参画して作成したソースコードの著作権を有していますので、法律上、差止請求、損害賠償請求等が可能です。通常はプロジェクト参画者が連名で警告書を発送し、違反行為をやめさせることになるでしょう。

あるオープンソースソフトウェアにＧＰＬを適用して公開していましたが、やはりＣＰＬに変更したいと思っています。法律的に可能でしょうか。

結論としては、オープンソースソフトウェアに適用するライセンスを、ある一定の時点以降、別のライセンスに変更することは法的には可能です。 ライセンスというのは結局のところ、ソフトウェアの著作権保有者と利用者との利用許諾契約です。利用許諾の時点で著作権保有者が提案している条項を受諾することによって契約が成立しますから、その時点で従前とは異なるライセンス条項が提案されていれば、その新たな条項を元にして利用許諾契約が成立します。 逆にすでに成立した契約を一方当事者の意志で変更することはできません。そのためすでに利用を開始したソフトウェアについては、その当時の利用許諾条件ですでに契約が成立しており、その条件が存続することとなります。 また過去にリリースされたバージョンについては過去のライセンス条件が添付されて配布されていますので、過去のバージョンについては、たとえ利用開始（利用許諾）以前であっても、ライセンス条件を変更することは難しいでしょう。 一方、新しいバージョンであれば、その新しいバージョンに添付するライセンス条項を別のものにすれば、そのバージョン以降のライセンスを別のものに変更できることになります。 なおライセンス条件を別のものに変更する場合には、対象となっているソフトウェアの著作権者全員が、ライセンスをその別のライセンスに変更することに同意していることが必要です。そのため、リナックスカーネルのように、無数のプログラマーがコミットしている場合には、全員の同意を取り付けるのは非常に難しいですから、ライセンスの変更は事実上不可能でしょう。 ご質問の件であれば、ソースコードを書いたすべてのプログラマー又はその著作権の承継人が同意しているのであれば、ＣＰＬはもちろん、他のオープンソースライセンスや、クローズドライセンスにも変更できます。

自社のソフトウェアをオープンソースにする場合にどのライセンスを適用すればいいですか？

オープンソースライセンス選択の際に考慮すべき要素は ［１］　他社がそのソフトウェアを他のソフトウェアに組み込んで新たなソフトウェアを開発した時に、組み込まれる先のソフトウェアのソースコードが開示されることを望むのか？ ［２］　他社がそのソフトウェア自体を改変して新たなソフトウェアを開発した時に、その新たなソフトウェアのソースコードが開示されることを望むのか？ の２つです。 　他社がそのソフトウェアを他のソフトウェアに組み込んで新たなソフトウェアを開発した時［１］に、その他のソフトウェアのソースコードが開示されることを望むのであれば、ＧＰＬを適用することになります。ただしＧＰＬを適用してしまうと、いわゆる商用ソフトウェア開発に利用することはほぼ不可能になりますので、ソフトウェアを利用する側にとっては不便なものとなり、結果、ソフトウェアが利用される頻度が下がってしまう可能性があります。 　これに対し、他のソフトウェアと結合された時にその他のソフトウェアのソースコードまで公開させようとは思わないが[1]、開発したソフトウェア自体が改変された時には、その改変部分の公開を望むという時[2]には、ＬＧＰＬ型のライセンスを適用することになります。 　他のソフトウェアと結合されても、そのソフトウェア自体が改変されても、結合先のソフトウェア、改変部分のソースコードの開示を望まない[2]のであれば、ＢＳＤ型のライセンスを適用することになります。ただしこのライセンスを適用すると他社の開発行為による恩恵を受けることができなくなる恐れがあります。

顧客にオープンソースソフトウェアを利用したシステムを提案していますが、「保証をつけて欲しい」と頼まれています。オープンソースソフトウェアは無保証のはずですが、当社が独自に保証をつけることは出来ますか？

オープンソースライセンスによる無保証の規定は、あくまでも不特定の開発者と、不特定のソフトウェア利用者との間の原則にすぎません。そのため、一個人、一企業が、特定のソフトウェアの利用者に対して保証を提供することは、ライセンスでは禁じられていません。このとき、保証の提供者が、当該オープンソースソフトウェアの開発に参加していようとも、参加していなくても、保証を提供することができます。

オープンソースソフトウェアは無償で利用出来るわけですが、インストールやメンテナンスサービスを有償で提供することはできますか？

多くのオープンソースライセンスはソフトウェアそのもののライセンスは無償で無ければならないことを規定しているものの、サポートの対価については規定がありません。そのため、サポートを有償で提供したとしても、ライセンス契約に違反するわけではありません。またＧＰＬはライセンス中で、サポートが有償で提供されることを是認しています。

自社で開発したソフトウェアとオープンソースソフトウェアを組み合わせて、新しいソフトウェアを開発することを企画しています。この開発成果物はパッケージソフトとして販売可能ですか？

この問題を検討する場合には利用しようとするオープンソフトソフトウェアに適用されているライセンスの種類を判別することが重要です。 　ライセンスがＧＰＬの場合で、ＧＰＬが伝搬する場合には、新たなソフトウェアの使用許諾は無償でこれを行わなければならず、利用者から徴収できるのはソフト配布の際の実費のみということになります。そのため販売によって利益を得ることができませんので、パッケージソフトへの利用は事実上不可能です。もっとも販売によって利益を得るのではなく、ソフトウェアのサポートによって利益を得るビジネスモデルであれば、特に問題はありません。 　これに対しＧＰＬが伝搬しない場合には、新たなソフトウェアに、従来型のソフトウェアライセンス条項を付すことができますので、特に問題はありません。 　ＬＧＰＬ型のライセンスの場合で、利用するソフトウェアに改変を加えている場合には、そのライセンスを承継（パッケージの購入者に引き続き適用する）し、改変部分についてのみソースコードの公開等の制限を適用した上で、新たなソフトウェアをパッケージソフトウェアとして販売することができます。利用するソフトウェアに改変を加えない場合には、ライセンスを承継する限り、パッケージソフトウェアとして販売する際に特に大きな制限はありません。 　いわゆるＢＳＤ型のライセンスが適用されたソフトウェアを利用する場合には、ライセンスを承継すること以外には制限がありません。さらに一般的には、改変後のソフトウェア全体（もともともＢＳＤ型ライセンス適用部分も含む）について、ソースコードを非開示とし、改変を禁止することが可能です。