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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発者の責任 : あるオープンソースの開発プロジェクトに参加したいと思っています。このプロジェクトの成果物は既に世界的に利用されているのですが、もし私が製作した部分に瑕疵があり、世界中で損害を発生させてしまった場合に、私は責任を負うのでしょうか？

オープンソースの定義には含まれていませんが、現在のオープンソースライセンスはほぼすべて、ソフトウェアの無保証、開発者の責任免除が規定されています。このような責任免除規定が法的に本当に有効なのか否かについては若干の議論があるところです。しかし仮に裁判になったとしても、開発者が故意に瑕疵を含めたという場合でもない限り、開発者が損害賠償請求を受けるということはないでしょう。

オープンソースソフトを利用した受託開発の注意点 : ソフトウェアを受託開発する際、ＧＰＬが適用されているソフトウェアを利用したいと考えています。どのような点に注意すべきですか？

まず大切なことは、新たに開発するソフトウェアに、ＧＰＬが伝搬するかどうかを検討することです。
　次にＧＰＬが伝搬する場合には、委託者に対し、開発後のソフトウェアにはＧＰＬが適用され、ソースコードの公開が要求されることとなるということの理解を得ることです。さもないと、ソースコードの公開が要求されるソフトウェアを作成したということで、瑕疵担保責任による損害賠償請求や契約解除がなされてしまう恐れがあるためです。もっとも受託開発の契約の実務において、このような理解を得ることは容易ではないでしょう。
　ＧＰＬが伝搬しない場合でも、委託者に対し、ＧＰＬが適用されるソフトウェアを使用していることは、明確に伝えておかなければなりません。受託開発においては、多くの場合、委託者に著作権を移転させることとされています。ＧＰＬが適用されているソフトウェアについては、委託者に著作権を移転させることが不可能ですので、この部分で損害賠償請求がなされてしまう恐れがあります。また後になって、「無料のソフトウェアを利用したのだからもっと安くしろ」といったクレームを受ける恐れもありますので、開発当初から理解を得ておくことは非常に重要です。

ＣＰＬの特徴 : ＣＰＬとはどんなライセンスですか？

ＣＰＬはCommon Public Licenseの略称です。ＩＢＭが初期ソースコードの提供者となっているオープンソースソフトウェアに多く適用されています。代表的なところでは、今フリーの開発ツールとして話題のEclipseもＣＰＬに準拠しています。
　ＣＰＬはＭＰＬを参考にして作られたということですので、基本的な特徴はＭＰＬと同じです。もっともＣＰＬはＭＰＬと比べて条項が大幅に簡略化されています。法律の専門家でなくてもライセンス条件を理解しやすくなっていますので、自社のソフトウェアに適用するのであれば、ＭＰＬよりもＣＰＬをおすすめします。

ＭＰＬの特徴 : ＭＰＬとはどんなライセンスですか？

ＭＰＬはMozilla Public Licenseの略称です。Ｗｅｂブラウザであるネットスケープナビゲーターがオープンソース化される際に作成されました。
　その特徴として、ＯＳＩのオープンソースの定義を満たしていることはもちろんですが、
［１］　他社がＭＰＬが適用されたソフトウェアを他のソフトウェアに組み込んで新たなソフトウェアを開発した時に、組み込まれる先のソフトウェアのソースコードの開示は要求しないものの、
［２］　他社がＭＰＬが適用されたソフトウェア自体を改変して新たなソフトウェアを開発した時に、その新たなソフトウェアのソースコードが開示されることを要求する
というところにあります。いわゆるＬＧＰＬ型のオープンソースライセンスということができるでしょう。
　またＧＰＬやＬＧＰＬで欠けている、権利者からの特許ライセンス条項、使用者が特許を主張したときの権利失効条項が加えられており、法的にも安全性が高いライセンスであるということができます

ＬＧＰＬの特徴 : ＬＧＰＬとはどんなライセンスですか？

　ＬＧＰＬはLesser General Public Licenseの略称です。ＧＰＬはいわゆる伝搬性が強く、ＧＰＬが適用されたソフトウェアを活用する際の妨げとなっていました。そこでＧＰＬの伝搬性の部分を弱めたライセンスとして、ＬＧＰＬが作成されました。
　その特徴として、
［１］　他社がＧＰＬが適用されたソフトウェアを他のソフトウェアに組み込んで新たなソフトウェアを開発した時に、組み込まれる先のソフトウェアのソースコードの開示は要求しないものの、
［２］　他社がＧＰＬが適用されたソフトウェア自体を改変して新たなソフトウェアを開発した時に、その新たなソフトウェアのソースコードが開示されることを要求する
ことがあげられます。つまりＧＰＬの「結合したときには結合先のソースコードの開示も要求する」という部分が省かれていることになります。

ＧＰＬ適用の要否 : ＧＰＬが適用されたソフトウェアを、自社の業務に適合させるため、若干修正の上利用しようと考えています。この場合でも改変後のソースコードを公開する必要はありますか？

著作権者には同一性保持権という権利があります（著作権法第２０条１項）。これは著作物を勝手に改変するなと要求できる権利です。もっとも同条２項には、同一性保持権を行使できない場合が規定されています。その中で同項３号は次のように規定しています。
「特定の電子計算機においては利用し得ないプログラムの著作物を当該電子計算機において利用し得るようにするため、又はプログラムの著作物を電子計算機においてより効果的に利用し得るようにするために必要な改変」
　つまり、いわゆる移植（ポーティング）のためのプログラム改変や、バージョンアップ、バグ修正のためのプログラム改変に対しては、著作権者は同一性保持権を行使できないということになります。
　そうすると、これらの行為を行うために、そもそも著作権者の許諾（ライセンス）を受けている必要は無いわけです。そしてＧＰＬが適用されたソフトウェアについては、単に使用するだけであればもともとライセンスを受諾する必要がありません。
　結果、ＧＰＬが適用されたソフトウェアを企業内部で使用し、内部での目的のためにのみ改変するのであれば、ＧＰＬを受諾する必要が無く、当然、ＧＰＬ上の義務であるソースコード公開等の義務を負わなくてもよいことになります。
　もっともソフトウェアを使用する際にはインストール、つまり複製することになりますが、改変したソフトウェアの利用のための複製行為については、ＧＰＬは何も言及していません。そのため、法的な権利の安定性には若干不安が残るところです。

ＧＰＬの特徴 : ＧＰＬの特徴は何ですか？

ＧＰＬはＯＳＩによってオープンソースライセンスとして認められており、まず前提として、上記の質問のオープンソースライセンスとしての特徴を有しています。
　さらに一歩進めて、それぞれのオープンソースラインセンスの特徴・違いを理解しようとする際には、以下の要素から比較検討するのが有益です。
・オープンソースライセンスが適用されたプログラムを改変して配布する場合に、当該改変部分のソースコードの開示が必要か否か？
・自らが著作権を有するソフトウェアと、一定のオープンソースライセンスが適用されたプログラムとを結合させた時に、自分が著作権を有しているソフトウェアにもオープンソースライセンスを適用しなければならないか否か？
・オープンソースライセンスが適用されたプログラムを改変した際、この改変されたプログラムのソースコードを開示する必要があるか否か？この改変されたプログラムをさらに改変することを禁止できるか否か？
ＧＰＬは
・ＧＰＬが適用されたプログラムを改変して配布する場合に、当該改変部分のソースコードを開示しなければならない。
・自らが著作権を有するソフトウェアと、ＧＰＬが適用されたプログラムとを結合させた時に、自分が著作権を有しているソフトウェアにもＧＰＬを適用しなければならない。
・ＧＰＬが適用されたプログラムを改変した際、この改変されたプログラムのソースコードを開示しなければならない。この改変されたプログラムをさらに改変することを禁止でききない。
という特徴を有しています。

ＧＰＬとは？ : 最近、ＧＰＬという言葉をよく耳にします。これはいったい何ですか？

ＧＰＬはFree Software Foundation(FSF)が提唱しているオープンソースライセンスです。歴史が古く、多くのオープンソースソフトウェアがＧＰＬをライセンスとして採用しています。

ライセンス本文
http://www.gnu.org/copyleft/gpl.html
非公式日本語訳
http://www.opensource.jp/gpl/gpl.ja.html

オープンソースとは？ : オープンソースとはＧＰＬライセンスを適用することですか？

一般的には、オープンソースの定義に該当するようなライセンスが適用されているプログラムであれば、それはオープンソースソフトウェアであるということができるでしょう。OSIのページにはオープンソースの定義に該当するとされる多くのライセンスが紹介されています。

法律 : オープンソースに関する法律は存在しているのですか？

オープンソースそのものを主題とした法律は、現在のところ日本には存在していません。どちらかといえば、オープンソースライセンスは、現行の著作権法、特許法等のソフトウェアに関わる権利に対抗するために生まれてきたという側面があります。

法律 : オープンソースに関する法律は存在しているのですか？

オープンソースそのものを主題とした法律は、現在のところ日本には存在していません。どちらかといえば、オープンソースライセンスは、現行の著作権法、特許法等のソフトウェアに関わる権利に対抗するために生まれてきたという側面があります。

文献 : オープンソースのことを勉強したいのですが、良い資料はないですか？

現時点においていちばん水準が高いと思われるのは、ＳＯＦＴＩＣの特別委員会がまとめた「オープンソースソフトウエアの利用状況調査／導入検討ガイドライン」です。経済産業省のサイトから無料でダウンロードできます。

http://www.meti.go.jp/kohosys/press/0004397/

この報告書は若干大部ですので、気軽に入門したい方には、

オープンソースがビジネスになる理由―勝ち組企業は何をしたか
米持 幸寿 (著),

をお勧めします。

意味 : オープンソースとは何ですか？

オープンソースとはいったい何かとう問題については、OSI(Open Source Initiative)の定義が参考になります。

http://www.opensource.jp/osd/osd-japanese.html

あえて要約するとすれば、コンピュータプログラムの
１　自由な再配布を認め
２　配布の際にはソースコードを一緒に頒布し、
３　ソースコードの自由な改変を許容する
ライセンスということができます。

ＢＳＤライセンスの特徴：ＢＳＤライセンスが適用されたソフトウェアを商用利用する場合の注意点を教えてください。またＭＩＴライセンスとの違いも教えてください。

ＢＳＤライセンスの趣旨は、①イニシャルコントリビュータの名義を示し、②関係者の免責を確実する限りにおいては、適用対象ソフトウェアの制限のない利用を認めようというものです。そのため、名義と免責事項については、最終使用者が使用にあたって確認しようと思えば確認しうる状態となっている必要があります。最終使用者が実際に確認するかどうか問いません）。ＢＳＤライセンスのライセンス条件の第２項で、バイナリ配布の際にドキュメントに、ライセンス条件と免責事項を記載するよう要求しているのもその趣旨と言えます。
ＢＳＤライセンスが適用されたソフトウェアを組み込んだソフトウェアを頒布する場合、何らかのドキュメント（最終顧客が読もうと思えば特別、格段の作業を要することなく閲覧できる状態のもの）にＢＳＤライセンスを記載していただく必要があります。これをしない場合には、頒布者がＢＳＤライセンス違反を犯したこととなり、著作権法における複製権を侵害することになります。
最近多い表示しかたとしては、配布の際にＢＳＤライセンスを記載した紙片を添えたり、マニュアルの扉裏の部分やに記載したりするという例が多いと思われます。
なお初期のＢＳＤライセンスでは、当該ソフトウェアの機能に言及する広告にもライセンス文を挿入することを要求しているものがありますので注意が必要です。

ＭＩＴライセンスは、ＢＳＤライセンスと似通ってはいますが、若干構成が異なるライセンスです。自由（無制限）な利用の条件として、ライセンス文を当該ソフトウェアの全ての構成物（バイナリを除く）に表示することを要求しています。ポイントは、①当該ソフトウェアの構成物については全て（バイナリ以外）に表示をすることが要求されているが（ＢＳＤライセンスであればどれかでよい）、②当該ソフトウェアを利用する側のマテリアルへの表示は、明示的には要求していない点です。もっともライセンスの趣旨（免責）から言えば、ライセンスの表示はＢＳＤライセンスと同様の形態で行う方が望ましいと思われます。
またソフトウェアごとに条項が若干異なるケースがあり、当該ソフトウェアの全ての複製物か、「または」、主要部分にライセンス文を表示すれば良いとしているものもあります。す。些細なファイルにまで表示しなくても構わないという趣旨でしょう。

輸出の可否：オープンソースのアプリケーションサーバーを搭載したハードウェアを海外に輸出して販売したいと考えています。このような製品の輸出は規制されていますか？

ただしオープンソースのＯＳディストリビューションの多くはＳＳＨなどの高度な暗号化ソフトウェアを標準で搭載しています。そのため外為法上、戦略物資として取り扱われ、一定の国々に対する輸出に際しては、国から許可を得る必要があります（ただし法律改正により許可が必要となる大分減少しています）。また同じく相手先国においてかかる暗号化ソフトウェアの国内への持ち込みが規制されている可能性があります。この点現地法の事前調査が必要でしょう。オープンソースＯＳは標準で添付されるパッケージが多く、開発者の気づかないうちに実装されているケースもあると思われます。
また規制の問題ではありませんが、慎重を期するのであれば、オープンソースライセンスがそもそも有効な国内法体系となっているかの確認も行っておいた方が良いでしょう。この点ベルヌ条約加盟国であれば通常問題にはならないと思われます。