Apacheライセンスと特許の関係を考えてみる~その3~その2では、Apacheライセンスのコントリビューションを改変して利用する場合の一例として、コントリビューションに新たな要素を追加する場合を対象として特許リスクを検討してみました。今回は、コントリビューションを改変して利用する場合の一例として、コントリビューションに含まれる要素の一部を他の要素に置換する場合を検討してみます。・a1~a4を含むコントリビューションであるOSS(A)のコントリビューターαさんが、a1~a4を構成要件とする特許権Aを有している。・αさんは、OSS(A)の構成要件のうちa4をa6に置換した特許権Cも有している。・OSS利用者βさんは、OSS(A)を独自に改変して技術的要素a4をa6に相当するものに置換し、特許権Cに抵触する形で実施している。・a6はa4と実質同一でなく、a4の下位概念でもない。下位概念の場合、特許権Aと同様にApacheライセンスに基づいて簡単に解決される)この場合、特許権Cの使用権はどうなのでしょう?結論から言えば、今回は前回よりもApacheライセンスに基づいて特許の使用権が付与される点には争いが少ないと思います。前回のような「追加」ではなく「改変」というところで、細かく突き詰めていくとOSSとしての議論というよりも、著作権法の本質的な議論に繋がっていく可能性を秘めています。そのような議論は、OSSについて世間一般でよく目にする議論で「抜け落ちている」と感じる部分です。・・・コントリビューターによってライセンス可能な特許申請のうち、当該コントリビューターのコントリビューションを単独または該当する成果物と組み合わせて用いることで必然的に侵害されるもの・・・https://ja.osdn.net/projects/opensource/wiki/licenses/Apache_License_2.0です。「コントリビューション」とは、a1~a4によって構成されるOSS(A)であるのに対して、特許権Cは構成要素a6を構成要件としますので、「コントリビューションを単独で用いることで必然的に侵害されるもの」ではありません。従って前回の記事と同様に、「コントリビューションを該当する成果物と組み合わせて用いることで必然的に侵害されるもの」に該当するのか否かを検討する事になります。・要素a4が抜けたa1~a3の部分だけで「コントリビューション」に該当するか否か・要素a6が「該当する成果物」に該当するか否かこの2点が満たされれば、βさんの実施態様は問題なく「コントリビューションを該当する成果物と組み合わせて用いることで必然的に侵害されるもの」に該当し、特許権Cの使用権がApacheライセンスに基づいて付与されることになるでしょう。要素a4が抜けたa1~a3の部分が「コントリビューション」に該当するか否かこれについては、要素a4がa6に改変されたとは言え、実施しているプログラムのソースコードの元がOSS(A)であり、a1~a3に該当する部分が残っているのであれば基本的には問題ないと思います。a4の部分を他の要素に改変したとは言え、「コントリビューションを利用」している事には変わりないと言えるでしょう。「改変」という点を突き詰めると、一筋縄ではいかなくなります。これについては後述します。要素a6が「該当する成果物」に該当するか否かこれについては、前回の議論でコントリビューションに追加された要素a5の該当性よりも問題が少ないと思います。前回のa5は、a1~a4がすべて残っている状況において新たに追加された要素でした。従って、OSS(A)に対する「成果物」と呼べるかという点で疑問がありました。対して、今回のa6は、a4の代替として追加されているものですので、機能としてa4との間に何らかのつながりを持っている場合が多いと思われるからです。・a4の機能を向上させたものに置換した・a4に存在したエラーや脆弱性を改善したものに置換した・具体的なアプリケーションに対応して必要な機能を有するものに置換した・その他、実施環境に応じて必要な改修を行ったものに置換した等といった場合が考えられます。※但し、a6はa4と実質同一でなく、a4の下位概念でもないという前提です。a6がa4と実質同一、若しくはa4の下位概念であれば、「コントリビューションを単独で用いることで必然的に侵害されるもの」に該当します。このような場合であれば、新たな要素a6はコントリビューションであるOSS(A)を元にして作成、若しくはカスタマイズされたものであることが大半でしょうから、「該当する成果物」への該当性が問題になる事は少ないでしょう。ApacheライセンスのOSSを「改変」することのリスクと、ここまでであれば前回よりも簡単に話が終わるのですが、Apacheライセンスに基づく特許使用権を検討する上で、OSSの改変にはリスクがあると感じている部分があります。Apacheライセンスにおける特許使用権付与の基本的な流れについて再確認します。図2図2の通り、利用者βさんはApacheライセンスの基で公開されているOSS(A)を利用します。すると、1まずはOSS(A)の著作物としての使用がApacheライセンスに基づいて許可される2すると、OSS(A)のコントリビューターであるαさんが有する特許権のうち、OSS(A)を利用する事により必然的に侵害となるものである特許権AがApacheライセンスの基で使用許諾されるものとして対象となる。3Apacheライセンスに基づき、特許権Aの使用権がβさんに付与される。前回および今回の記事では、上記のフローのうち2の部分が議論の対象となっていました。OSS(A)を改変して利用した場合に、何が起こり得るか検討します。図3βさんがOSS(A)を改変して利用した結果、「著作物」としてOSS(A)とは別物と言える程度にまで変化してしまった場合はどうでしょう?この場合、著作物として別物ですので、αさんやその他のOSS活動への参加者が有するOSS(A)に関しての著作権はβさんの実施行為には及ばず、βさんはαさんやその他のOSS活動への参加者が有する著作権を気にすることなく、作成したプログラムを使用することが可能です。βさんの行為はApacheライセンスとは無関係となります。するとどうでしょう?そもそも、βさんは「コントリビューションを利用している」と言えるでしょうか?Apacheライセンスに基づいて特許権Aの使用権が付与される大前提、といういか、Apacheライセンスの各条項が効果を発揮する大前提は、「Apacheライセンスの基で提供されているコントリビューションの利用」です。従って、「コントリビューションを利用している」と言えなければ、ライセンスの各条項は効果を発揮せず、特許権Aの使用権も付与されません。図3の条件の場合、改変のベースとしてOSS(A)を利用しているとしても、「著作物」として利用してはいません。改変のベースとしてOSS(A)を利用しているという前提があるため、ややこしくなっている部分があるので、状況を一度単純化します。図4図4の通り、OSS(A)とは無関係に独自にコーディングを行ってサービスを提供しているγさんがいたとします。そのγさんのサービスには技術的な要素として特許権Aの侵害になるような要素、つまりa1~a4が含まれていたとします。この場合、αさんはγさんに対して特許権Aに基づく権利行使が可能です。αさんはApacheライセンスの基でOSS(A)を公開していて、Apacheライセンスに基づいてOSS(A)の利用に対する特許権Aの非行使を宣言していますが、OSS(A)とは完全に無関係な相手にまで特許権Aの非行使を宣言するものではありません。OSS(A)を利用し、OSS(A)の活性化に一役買う主体を対象として特許権Aを非行使とするものでしかありません。OSS(A)とは無関係なγさんは、Apacheライセンスに基づく特許権Aの使用権が付与される対象とはならないのです。?βさんとγさんとの間にどんな違いがあるでしょうか?違いがあるとすれば、「サービスとて実施するプログラムのベースにOSS(A)を利用したか否か」です。これは、OSSライセンスの条項における「利用」が「著作物としての利用」を意味するのか、それとも「より広義での利用」を意味するのかという問題です。OSSライセンスにおける「利用」とは、「著作物としての利用」か?それとも「より広義での利用」か?OSSライセンスにおける「利用」が、「より広義での利用」であり、図3のβさんの行為も「OSS(A)を利用している」と言えるのであれば、βさんにはApacheライセンスに基づいて特許権Aの使用権が付与される事になります。これは、Apacheライセンスの理念に照らせば好ましい結論とも言えます。個人的にOSSライセンスは、前提として「プログラムの著作物」に関してのライセンスであると考えています。従って、OSSライセンスにおける「利用」とは、「著作物としての利用」を前提として考えるべきだと思います。すると、図4のγさんの場合は当然ですが、図3のβさんの場合であっても特許権Aの使用権はApacheライセンスの基では許諾されなくなってしまいます。この結論は、Apacheライセンスの理念に照らして必ずしも好ましい結論ではないとも言えます。プログラムの「著作物としての利用」とは?このような問題をより詳しく検討するに当たっては、プログラムの「著作物としての利用」が具体的にどのような場合かを、判例も含めて検討する必要があります。その点について、次回検討します。コメントをキャンセルメールアドレスが公開されることはありません。