１５ オープンソース・ソフトウェア・ライセンスにおけるソフトウェア特許と商標の扱いに関する研究（＊）
特別研究員

八田真行

Linuxを始めとしたオープンソース・ソフトウェアは、オープンソース・ライセンスの下で自由に利用や改変、再配布が可能とされ、日本でも浸透しつつある。ソフトウェア・ライセンスは基本的に著作権を根拠としたものだが、近年では特許報復条項
や商標に関する条項を盛り込み、著作権をてことして著作権以外の産業財産権もコントロールしようとする動きが活発になってきた。加えて最近では、従来、ソフトウェア特許自体を忌避する傾向が強かったオープンソース・コミュニティにおいても、
オープンソース向けパテント・プールの形成やオープンなパテント・ライセンスの模索など、戦略的に特許を活用することによって自由な開発を明確に保障しようとする動きも出てきている。この研究では、ソフトウェア特許に関する最新の研究動向や専門家へのヒアリングを踏まえた上で、オープンソース・ライセンスごとに異なる特許や商標に関する条項の要求内容を精査して比較するとともに、オープンソースにおける著作権以外の扱いや様々な事例に関して総合的に整理を行い、今後のソフトウェア開発にどのような影響を与え得るのかを検討した。

Ⅰ．はじめになるところも多く存在している。
そこで、オープンソース・ソフトウェアにおける、著作権以ソフトウェアは一般的にプログラム（アルゴリズム）とデータ

外に、特許、商標はどのように扱われているかを整理し、ライから構成されている。プログラムもデータも、法律的に創作性センスの在り方についても明らかにするというのが、この研究のある著作物と認められれば、著作権で保護される。このことの狙いである。

は、現在では当たり前となっているが、ソフトウェア、特にその利用については、元々経済的な価値が余り見いだされていⅡ．オープンソースとはなかった。1970年代にはソフトウェアというのは何の価値もな
いものであると思われていた。それが、80年代に入って、価Open Source Initiative3が作成した、「オープンソースの定値が見いだされ、どのような制度で保護するのが適切なのか

義(The Open Source Definition)」4が規定する、一連の要件にという議論が行われ、著作権法で著作権として保護するよう準拠したソフトウェア・ライセンスの下で公開されたソフトウェになった経緯がある。

アを、「オープンソース・ソフトウェア（Open Source Software)」

ところが、この20年ぐらいで、ソフトウェアに限らず、著作物は非常に経済的価値があるということが分かってきた。特にソと呼ぶ。オープンソース・ソフトウェアは、原則として誰でも自由に改変したり再頒布したりすることが可能である。

フトウェアにおいては、著作権の保護に加えて、特許、商標

近年目覚ましい普及を遂げたオペレーティング・システムなど、その性格が全く異なる権利で保護され得る特異な存在

GNU/Linuxを筆頭に、オープンソース・ソフトウェアは我々のであることを考慮しなければならない。もっとも、ソフトウェア

生活へ急速に浸透しつつある。多くの家電、携帯電話などそのものが特許で保護されるべきかということについは、代表には、今や何らかのオープンソース・ソフトウェアが使われて的事例として米国最高裁判所のダイアモンド対ディア判決

1

おり、我々は知らぬ間にライセンシーとなっているのである。

などがあるが、欧州などでもまだ議論が続いている。ソフトウ「オープンソース」という用語そのものが登場したのは1998

ェアについては、非常に根強い反ソフトウェア特許運動という年のことであるとされているが 5、ソフトウェアを「オープンな」のがあり、それらの運動の根底にあるものを理解しないとこの著作権ライセンスによって法的に誰でも自由に利用できる状問題はなかなか理解できない。欧州においては、欧州委員態に置くという発想そのものの由来は、1980年代のフリーソ会のソフトウェア特許指令案2の是非をめぐって、アンチパテ

フトウェア運動にさかのぼる。

ントとプロパテントの両派が非常に激しく議論し、2005年7月6オープンソース・ソフトウェアと呼ばれるソフトウェアの種類

日に欧州議会において大差で否決されたという経緯がある。

はいろいろあるが、重要なのは、ソフトウェア・ライセンスにおそのような状況の中で、オープンソース・ソフトウェアといういて、ソフトウェアが誰でも「自由に」利用できる形態になってのは、元々ライセンスされることを前提に開発されているソフいるということである。「自由に」利用できないソフトウェアはプトウェアであることから、一般のソフトウェアの権利保護とは異ロプライエタリな(proprietary)ソフトウェアと呼ばれている。

(＊)

これは特許庁委託平成 21 年度産業財産権研究推進事業（平成 21～23 年度）報告書の要約である。

● 15-1 ●

知財研紀要

2011

Vol.20例えば、GNUプロジェクトの創設者であり、フリーソフトウェーションはイノベーションの促進に非常に有益であり、それにア財団(Free Software Foundation)の代表者でもあるRichard

立脚したビジネス・モデルを考えていくべきだということを述

Stallmanによるフリーソフトウェアの定義なども広く使われていべている。これは影響力が非常に強い考え方となり、それ以るが、簡単に言えば、オープンソース・ソフトウェアは、多くの来、オープン・イノベーション、又はオープン・ビジネス・モデ

場合、無料で誰もが自由に使えるソフトウェアである。そのよルなどの考え方が出てきた。

うなソフトウェアの代表例としては、Linuxとか、ウェブ・ブラウ

Katz & Allen (1982) が 論 じ て い る Not-Invented-Here

ザのMozilla Firefoxとか、最近では、携帯電話のOSなどにも(NIH) 症候群という考え方があるが、その打破ということも主使われているGoogleのAndroidなどが存在している。

要な研究テーマである。すなわちオープン・イノベーションのこの研究を通じて、オープンソースという表現が二つの異場合、開発形態としてのオープンソースを考えると、開発人なる意味で使われているような印象を持った。上述したような材を含む開発資源等は、外部にもあるので、組織外部との法的側面と並んで、開発形態としてのオープンソースに注目

協働を可能にするためにはどうしたらよいかということを考えが集まっているという印象がある。具体的には、一般に、バザる必要がある。一つの在り方としては、ライセンスを工夫して、ール型開発といわれるものであり、ヒエラルキーや指令系統

外部との協働をスムーズに行うというようなやり方を考えるべのようなものがなく、多くの人数が一つソフトウェアを誰もが自きではないかという議論が経営学の分野でも出てきている。

由に開発できる。このような開発形態について、オープンソ

これが、NIHのような研究と組み合わさって、オープン・ライセースという表現が使われる場合も多いと思われる。法的状態

ンシング戦略とか、標準化戦略という議論において、いろいとしてのオープンソースは、開発形態としてのオープンソース

ろ影響が及んでいるところである。

を支え、開発を非常に円滑にしていると考えられる。この研究で、オープンソース・ソフトウェア・ライセンスを扱っているのは、それがバザール型開発にどのような影響を与えている

Ⅳ．オープンソース・ソフトウェア・ライセンスの特徴と分類かという見地からである。
開発形態としてのオープンソースに類似した発想をソフト

オープンソース・ソフトウェアは著作権で保護され得るので、ウェア開発以外にも応用する動きが出てきている。有名なも第三者が当該ソフトウェアを使用する場合には一般的に著のとしては、Lawrence Lessig教授が提唱した、書籍やテキス

作権ライセンスが設定されることとなる。著作権者は、多くのトなどの著作物を誰でも使えるような条件の下で公開し、そ場合はソフトウェアの制作者であるが、一定のライセンス条件

れによって、著作物の再利用や二次利用、イノベーションのの下で再利用するための許可を出す。代表的な、よく使用さ推進等を行おうというCreative Commons6がある。

れているオープン・ソフトウェア・ライセンス契約書の雛形のさらに、最近では、オープン・ハードウェアという考え方も非常に注目されている。例 えば「Open Source Hardware
7(OSHW) Statement of Principles and Definition v1.0.」 等ができつつある。

幾つかの中から最適な契約書を一つ選んで適用するということが慣行として一般的に広く行われている。
オープンソース・ソフトウェアのライセンスの形態は幾つかあるが、多くの場合は、「オープンソースの定義」に規定されまた、オープンソースの原則のようなものに影響を受けたている条件を満たしている又は違反していないと考えられる活動として、各国の特許庁が行っている発明の特許性審査

ソフトウェア・ライセンスであるといわれることが多い。これにも8を誰でも参加できる形態で行おうという、Peer-To-Patent と議論があるところではあろうが、オープンソース・ソフトウェア・

いうコミュニティ活動がある。

ライセンスの形態の非常に有名な例としては、GNU GPL(General Public License) 9 がある。これは、Linux カーネル

Ⅲ．オープンソースに関連する先行研究(Kernel)に適用されているライセンスである。その他には、
BSD (Berkeley Software Distribution) License 、 Apache

オープンソースという考え方は経営学にも影響を与えていLicenseなどが存在し、これらのライセンスが実際に使用される。Linux、GNU/Linuxが非常に成功を収めたため、そのようている普及の割合は、GPLが5、6割で、BSD Licenseが1、2なオープンソースの方法論はうまくいく、少なくともある種の割、Apache Licenseが1、2割といったところであろう。最近で条件がそろえばうまくいくであろうという議論が広まった。そうはApache Licenseが非常に伸びている。

すると、それから何か知見が得られるのではないかという動きが出てきたのは当然のことである。

これらのオープンソース・ソフトウェア・ライセンスは、ソフトウェア業界、実際の開発現場でも注目されており、法律的にそれらのうち、Chesbrough(2006)は、開発形態としてオーも注目されている。オープンソース・ソフトウェア・ライセンスに

プンソース、法的状態としてもオープンな、オープン・イノベ

ついては、2000年代に入ってから、様々な分野で研究が進● 15-2 ●知財研紀要 2011 Vol.20

んでいる。先行研究をレビューした結果、ソフトウェアが著作われているライセンスは七つである。この中で、特許関係条

物として保護可能であることから、当然ながら。従来の学術項 が 全 く 含 ま れ て い な い の は BSD License だ け で あ り 、研究、又は法曹実務家の関心は、主に著作権ライセンスに

Apache License 、 GPL 、 LGPL (Lesser General Public

注がれていたということができる。中でも従来非常に注目されLicense)、CDDL (Common Development and Distributionていたのは、コピーレフト(Copy left)性である。コピーレフト性

License)、MPL (Mozilla Public License）、Artistic Licenseにと は 、 Copyright の 逆 と い う 意 味 の 造 語 で あ り 、 互 恵 性は 特 許 関 係 条 項 が 含 ま れ て い る 。 特 に 、 GPL は 11 条 、(reciprocity)があるという意味であり、幾つかのオープン・ソフ

Artistic Licenseについては13条である。

トウェア・ライセンスにおいて、ライセンスされている当該ソフト
ウェアに何らかの改変を加えた場合、改変を加えたライセン

２．特許条項の有効性

シーはそのソースコードを開示しなければならないというよう

しかし、そもそも特許条項は法的に有効といえるのだろう

な条項が設けられていることを意味し、これは一般にGNUか。特許条項について直接争われた例は見当たらないが、GPLのライセンスの特徴的なものだと思われているが、実はオープンソース・ライセンスの法的有効性に関して、法廷に似たような条項は他のライセンスにも含まれている。これに注おいて正面から争われた例として著名なのが、いわゆる目した代表的な研究としては、Lerner & Tirole (2002) の論

Jacobsen v. Katzer訴訟である。
カリフォルニア大学バークレー校Robert Jacobsen教授は、文などがある。

オープンソース・ソフトウェアJMRI（A Java Model Raiload

Ⅴ．オープンソース・ソフトウェアとソフトウェア
特許Interface ） の 主 要 開 発 者 の 一 人 で あ る 。 JMRI は 、 Artistic
Licenseの下で公開されていた。
一方、オレゴン州でKAMIND Associates Inc.なる企業を経

１．オープンソース・ソフトウェア・ライセンスにおけるソフトウェア特許の扱い

営していたMatthew Katzerは、JMRIのコードの一部をコピー

オープンソース・ソフトウェア・ライセンスとは、誰でも自由を許可する条件として提示していた条項に従わなかった。

し、自らの製品に使用したが、その際、Jacobsenがライセンスにソフトウェアを利用できるということを、著作権を根拠としてそのため、Jacobsenは、Katzerを、契約不履行とともに、著

法的に保証しようとする試みに他ならない。一方、ソフトウェ

作権侵害で仮差止めを求め、米国カリフォルニア北部連邦

アに限らず、特許とは、発明者に排他的独占権を付与し、い地栽に提訴した。2007年、連邦地栽は、問題となったライセ

わば誰でも自由に利用「させない」ことによって、発明者に利ンスの条項はライセンスの範囲を制限するものではないとし益を還元する法的な仕組みを用意し、発明公開のインセンて、著作権侵害による仮差止請求を却下した。Jacobsenはこ

ティヴを高めようとする施策である。すなわち、オープンソーの判決を不服として米国連邦巡回控訴裁判所(CAFC)に控スと特許は本質的に相容れない部分がある。このことは、オ訴した。

ープンソース・ソフトウェアが大きな経済的価値を持つように

CAFCは、オープンソース・ライセンスの法的強制力を認なり、大規模な特許ポートフォリオを持つ営利企業がオープ

め、Jacobsenのライセンス条件は、当該ソフトウェアの著作権

ンソース・ソフトウェアの開発に参加するようになると、無視でを許可する条件であるとし、当該ソフトウェアの使用者がこのきない問題となってきた。

条件に従っていなければ、ライセンスで許可された範囲を外問題の複雑化に更に拍車を掛けるのは、ソフトウェアの法れるとみなされるため、著作権侵害になるとして、Jacobsen側

的保護手段として、著作権と特許権が完全に独立だというこの本件勝訴の可能性と回復不能な損害につき審理するようとである。すなわち、著作権ライセンスとしてはオープンソーに連邦地裁に差し戻した10。

ス・ソフトウェアでありながら、ソフトウェア特許が成立した技

地栽の差戻し判決では、Jacobsenが仮差止めされなけれ術を実装しているため、特許ライセンスを別途取得しない限ば、回復不可能な損害を被ることを立証していないとして、り、誰でも自由に利用できるとはいえないソフトウェアが存在

仮差止請求を再度却下した。
最終的は、この事件は、2010年、和解によって解決されたする。
オープンソースの文脈で、ソフトウェア特許の問題に対処

が、CAFCの判断として、オープンソース・ソフトウエア・ライセ

するための現時点で最も一般的な手段は、オープンソース・

ンスの法的な有効性が肯定され、特許関係条項も恐らく有ソフトウェア・ライセンスに特許の扱いを規定した「特許条項」

効であろうというのが筆者の考えである。

（Patent Clause）を含めることである。
オープンソース・ソフトウェア・ライセンスの種類は数多くあるが、使用が余り推奨されていないものも多く、比較的多く使

３．特許条項の二類型
オープンソース・ソフトウェア・ライセンスには特許関連条● 15-3 ●

知財研紀要

2011

Vol.20項が含まれている場合がある。典型的なものとしては、スの定義に準拠しているということは、事実上、全てのライセ

Apache License 2.0の第3条「特許実施権許諾」であり、このンスにおいて黙示的許諾が有効であるとみなすべきだという特許関連条項には、大きく分けて二つの規定が存在する。

議論もある。BSD Licenseには特許に関して全く触れられて（１）自動ライセンシング

いなが、BSD Licenseがオープンソースの定義に準拠してい第3条「特許実施権許諾」第1文は、Apache License 2.0がるのであれば、黙示的許諾が与えられているのではないかと適用されたソフトウェア又はその一部の著作権者は、ライセいう議論もある。オープンソースの定義6条、7条において11、ンシー（You）にそのソフトウェアの利用（改変や販売を含む）

利用分野による差別禁止、権利の分散の禁止が規定されてに対して永続的（perpetual）、全世界的（worldwide）、非排他

おり、利用の目的やライセンシーによって権利を制限するこ的（non-exclusive）、無料（no-charge）、ロイヤルティフリーとは、オープンソースの定義に違反することになり、そのよう（royalty-free）、取消不能（irrevocable）な特許ライセンスをなオープンソース・ソフトウエア・ライセンスはオープンソース

与えるという構成になっている。

の定義に準拠しているとはいえないのではないかという議論（２）特許報復がある。

特許報復（Patent Retaliation）は、最近では多くのオープ

MXM (MPEG eXtensible Middleware) Licenseがオープン

ンソース・ソフトウェア・ライセンスに導入されているメカニズム

ソースの定義に準拠しているか否かということがかつて議論である。

されたことがある。これは、特許の存在する技術標準をオー

第3条「特許実施権許諾」第2文は、ライセンシーが、ライセ

プンソース・ソフトウェアによって実装する場合に、どのようなン ス が 適 用 さ れ た ソ フ ト ウ ェ ア や そ の 一 部 （ Work 又 はライセンス形態を用いるかという議論であり、MPLから特許関Contribution）が特許の寄与侵害又は直接侵害を構成すると係条項を削除して、特許ライセンスは別に取得する必要があ

主張して特許訴訟を提起した場合、Apache License 2.0の下るようにするというライセンスを作ろうとして議論になったことでライセンシーに与えられた当該ソフトウェアに関する特許ラがある。

イセンスは打ち切られる旨規定している。打ち切りの後は逆その他の論点として、ライセンス間の差異はそれなりにあにライセンサーからの特許侵害訴訟を受ける可能性が出てくる。例えば、Artistic Licenseの場合、ライセンシーが当該ソフる。同様の条項はGPLv.3などでも採用されている。

トウェア及び派生ソフトウェアに関して特許訴訟を提起した場合は、ライセンスは終了すると規定されている12。この条項は４．特許関連条項に関する議論範囲が広い。Apache LicenseやGPLv3では何らかの形で特特許関連条項に関する議論の一つに黙示的許諾

許クレームの範囲が限定されている。

（Implied license）に関する議論がある。これは禁反言（Legal

特許ライセンスによる直接コントロールが、今後の方向性とestoppel）の関する議論ともいえる。自動ライセンシングのしてあり得る。これを考える上で注目すべき事例として、

元々の発想は、黙示的許諾である。オープンソース・ソフトウ

Googleが、オープンな形で公開した、Webで使用される動画ェアである以上、ライセンス相手に明示的に(explicitly）許可

フォーマットWebMのライセンシングの方法が挙げられる。

を与えているわけではないとしても、ライセンシーには自由な

H.264というWebにおける動画の別の技術標準があり、これ利用を認めているはずである。事実上実施を許諾した事項

はGoogleの一存で何とかなる部分ではない。MPEG LAが行を、その有効性を後から否定することは許されない。それをっているパテント・プールがこれらに関係するいろいろな特許

特許ライセンスによって阻害するのは、法的な禁反言を扱っているので、本来ならばGoogleはMPEG LAに参加し（estoppel）となる。

なければならないが、そうすると、非排他的で無償というオー

GPLv2ライセンスにおいては、上述の自動ライセンスのよう

プンソース・ソフトウェアのライセンス条件を満すことができなな明示的な記載はなく、黙示的許諾になっている。これに関い可能性が出てくるということで、その点を何とか解決するた

して様々な議論があり、元々のソフトウェアが改変されていなめに考えたのが、WebMライセンシングではないかと思われい場合は、黙示的許諾は有効であるとされている。ライセンる。

サーが誰かにソフトウェアを渡した場合、ライセンサーが渡し

このライセンスの非常に特徴的な点は、Googleが、著作権たソフトウェアがそのままの状態であるときは、後から何か追ライセンスと特許ライセンスを完全に分離し、それを一まとめ

加的な制約は許されないであろう。ただし、ライセンシーが当に提供しようとしている点である。Googleは、ソースコードに

該ソフトウェアに何らかの改変を加えた場合にも、黙示的許関 し て は BSD ラ イ セ ン ス を 適 用 し 、 Google が 開 発 し た諾が認められるかという点に関しては非常に議論がある。

JavaScriptV8の実装に関しては、Additional IP Right Grantとオープンソースの定義に準拠しているのがオープンソー

いう形で、特許ライセンスを与えている。第三者がWebMといス・ソフトウエア・ライセンスという定義であるが、オープンソー

う技術標準を自分で再実装した場合にも、その技術に関して● 15-4 ●知財研紀要 2011 Vol.20

Specification Licenseという形でライセンスしていくという点は団体Mozilla Foundationは、ディストリビュータ向けMozilla商

非常に興味深い。

標 ポ リ シ ー （ Mozilla Trademark Policy for Distribution

Googleは、WebMを使用するライセンシーがH.264に関しPartners）を策定している。このポリシーによれば、MozillaてMPEGLAとそれぞれライセンスを結ばなければならないとFoundation自身が用意した無改変のオフィシャル・バイナリいう事態を避けたいということから、結局、YouTubeという非常（ Unaltered Official Binary ） を 配 布 し な い 限 り 、 「 Mozillaに普及したサービスが存在していることを前提に、WebMにFirefox」という名称やロゴ、アートワークなどの利用を禁じて関して、第三者が特許侵害でライセンシーを訴えたら、いる。これは、公式にはMozilla Foundation自らによる品質保Googleが第三者に提供している様々なライセンスを終了する

証によりMozillaのブランド・イメージを維持、向上させることがという、ある種の脅しをかけることによって、オープンソース・目的とされているが、一方でMozilla FoundationはFirefoxブ

ソフトウェア・ライセンスを維持しようとしていると考えられる。

ラ ウ ザ の デ フ ォ ル ト 検 索 エ ン ジ ン を Google と す る こ と で 、
Googleから年間6000万ドルにも及ぶ資金提供を受けており、

Ⅵ．オープンソース・ソフトウェア・ライセンス
における商標オープンソースではあるが、ある部分に関しては変えられたく

オープンソースという文脈において、商標によるコントローの商標ポリシーは受け入れられないとし、Debianの独自の改ないという狙いがあるといわれている。
この点に関し、LinuxディストリビュータのDebianは、Mozilla

ルという発想は比較的新しく導入されたものである。

良が行われていて、Debianが配布するFirefoxは、ロゴやアー

オープンソースにおける商標のライセンスは、基本的に、

ト ワ ー ク 、 フ ァ イ ル 名 に 至 る ま で 全 て の 名 称 を Iceweasel

特許同様、著作権ライセンス以外のコントロール手段であり、（Firefox「火のキツネ」に対する「氷のイタチ」）へ変更すること

より直接的には、ある種の品質の維持のために使用されてい

となった。

る。

このようなことは商標においては当然のことではあるが、改例えば、代表的なオープンソース・ソフトウェアであるLinux

変は自由だが、Firefoxを名乗ってはいけないということは、

カーネルに関して、1994年まで「Linux」やそれに類似した商改変が自由であるはずのオープンソースにおいて逆に不思標はどこの国でも取得されていなかった。1994年8月15日、

議な感じがする。Mozillaの商標ポリシーの機能と限界ともい

ボストン在住の弁護士William R. Della Croce, Jr.なる人物がえる。上記Debianの例は名前を変えれば解決できる問題で米国においてコンピュータOSの分野で「LINUX」なる商標をあるが、最近の商標を含む訴訟になった事例としては、Sun出願し（出願番号74560867）、1995年9月5日にこの商標はMicrosystemsを買収したOracleが、Googleが、携帯端末用プ登録された（商標番号1916230）13。Della Croce, Jr.はLinuxとラットフォームのAndroidにJavaが利用されているため、直接は全く無縁の人物である。以降、この人物がRed Hat等の複製したと主張している注目すべき事案がある。この事例でLinux関連企業からロイヤルティ（製品売上げの10％）の徴収

は、著作権、特許、商標など様々な争点が挙げられているが、を図ったため、1996年からLinuxの開発者リーナス・トーヴァ

注目すべきは、Javaの商標は、OracleがJavaという技術に対ルズを始めとする業界関係者が商標無効を求めて訴訟を起して及ぼそうとしているコントロールの一つの手段でもある。

こし、1997年にはDella Croce, Jr.からトーヴァルズへ特許のGoogleは、アンドロイドでJavaを使いたいが、アンドロイドに移転が行われることで和解となった。以来、米国、ドイツ、EU、JavaＭＥJava ME(Java Platform, Micro Edition)というOracle

日本における「Linux」関連商標はトーヴァルズが保有しておの実装を乗せることがいろいろな事情でできないので、

り 、 Linux 振 興 団 体 Linux Foundation 内 に 置 か れ た Linux

Dalvikという別のJavaの実装を作ったが。Dalvikは、オラクル

Trademark Institute(LMI)が実際の管理を行っている。LMIが Java の 処 理 を 使 う と き の 条 件 と し て い る JCP (Javaは、トーヴァルズの商標権を脅かさないことと適切に商標表

Community Process)というJavaの標準化団体のチェックを受示を行うことを条件に、無料、永続的、全世界的なサブライセ

け入れたくないため、Javaと名乗ることができない。

ンスを行うとしている。
Linux商標のケースは、いわば「商標のオープンソース化」

Ⅶ．オープンソースにおけるその他の対策ともいえるケースであったが、オープンソース開発において、商標を用いて何らかの制約を設け、影響力を及ぼそうとする

近年では、ライセンスの外部に何らかの制度や組織を作り、それによってオープンソース・ソフトウェアの開発を守ろうといケースも存在する。
オープンソースのウェブ・ブラウザとして著名なFirefoxの場う動きも出てきている。こういった状況の中、協同ライセンシン

合、ソフトウェアのライセンスはMPLというオープンソース・ソグ(Collaborating Licensing)と呼ばれる形態で研究活動を行フトウェアのライセンス形態をとっているが、開発を統括するうという動きが出てきている。共同ライセンシングとは、皆で何● 15-5 ●

知財研紀要

2011

Vol.20かを研究開発するときに、著作権、特許、商標などを一つ一って特に条件を指定しなければ、当然提供されたコードの著

つ、ライセンスし合っていると、工数が掛るので、これをもう少作権はそのコードを書いた人物に帰属したままとなる。例えしうまくやる方法はないかということで、いろいろ検討されていばLinuxカーネルはコードのマージに関して（コードの品質がる。ここでは、大きく分けて、弱い協同ライセンシングと強い良いという以外に）特に要件を指定していないので、Linuxカ

協同ライセンシングの二つに分類する。

ーネルは膨大な数の著作者による共同著作物と考えることが出来る。この場合、Linuxカーネルという著作物全体に関

１．パテント・プール

わる意思決定（ライセンスの変更等）においては、理論的に弱い方は例えばパテント・プールである。パテント・プール

は著作権者全員の意思確認が必要となる。また、後になって、は、基本的に参加者の自発性が求められるが、参加者が、「真の」著作権者（と名乗る主体）が登場し、自らの同意なく持っている権利のうち、余り重要でない一部の特許だけをパ勝手に著作物をマージされてしまったと主張する場合もあ

テント・プールに提供することがあり得る。

る。

パテント・プールは家電やソフトウェアの業界において普これに対し、一部の開発プロジェクトではコードの提供に及した対策となっているが、オープンソースにおいて導入さ際し著作権譲渡証書（copyright assignment）の提出を要件とれ た の も 比 較 的 最 近 で あ る 。 代 表 的 な も の と し て Patent

している。著作権の譲渡に関しては、近年になって普及しつ

Commons Projectがある。2005年11月15日、Open Source

つ あ る の が 貢 献 者 ラ イ セ ン ス 協 約 （ Contributor License

Development Labs (OSDL)によって開始されたプロジェクトでAgreements、CLA）である。CLAは、コードを提供しようとするあり、現在ではOSDLが発展的に解消して創立されたLinux

元々の著作権者が、著作権を譲渡する代わりに、提供される

Foundationの下にある。

側に対してコードの無制限な利用を認めるという形式を取る。

２．ディフェンシブ・パテント・ライセンシング
強 い 協 同 ラ イ セ ン シ ン グ の 具 体 例 と し て は 、 DPL

Ⅷ．おわりに(Defensive Patent License)がある。
DPLは、カリフォルニア大学バークレー校(University of

以上、オープンソース・ソフトウェア・ライセンスにおける特California, Berkeley)のJason Schultz)とJennifer Urbanが、最許・商標の扱いについて述べてきたが、オープンソース・ソフ

近提唱している考え方であり、これは特許ライセンスにGPL

トウェアについて、なぜここまで特許を制限しようとしているのの考え方を入れたものである。著作権ライセンスによる間接かという疑問があると思う。この研究において、欧州に行きいコントロールというようなことではなく、直接的に特許ライセン

ろいろな関係者と話をすると、元々オープンソースとも関係な

スでコントロールしようという動きが出てきたのが、DPLの注目

く、根強い反ソフトウェア特許感情というのがエンジニアの間すべきことである。

にはある。しかも、反ソフトウェア特許を奉じる人たちが始めたオープンソースは非常にうまくいっているということもあって、

３．貢献者協定

彼らも非常に力付けられる部分があって、ソフトウェア特許の既存のオープンソース・ソフトウェアを改変するとき、自分が書いたソースコード等を公開するには大きく分けて二つの存在意義が近年大きく揺らいでいるというのが背景としてあるということが分かってきた。

方法がある。一つは、自分が書いた部分のみを単に公開す経済学や経営学において、特許の正当性を主張する研ることであり14、もう一つは、現在そのソフトウェアの開発を主究というのは実はほとんど存在しないということも分かってき

導的に担っている主体（開発プロジェクト等）にコードを提供た。代表的な研究としては、Boldrin & Levine (2008)、Bessen

し、彼らが管理するソースコード（メインラインのコードベース）& Meurer (2008)、これはPatent Failureという標題が付けられの一部として統合（マージ merge）してもらうことである。例えており、特許制度自体がだめだという議論である。

ばLinuxカーネル向けに新たなデバイスドライバを書いたとしこの議論について、典型的な例として、よく挙げられるのはて、単に自分のウェブサイト等でデバイスドライバのソースコ

ジェームズ・ワット(James Watt)の蒸気機関の開発に関するもードを公開するのが前者であり、Linuxカーネルメーリングリスのである。ワットは、特許913号を取得し、資金も有していた。

ト等に連絡し、リーナス・トーヴァルズ以下主要な開発者の同特許の支持者から見れば、蒸気機関の研究開発には、そも意を得てLinuxカーネルの標準的配布物の一部として受けそも元手として高額な資金が必要であり、莫大な初期投資を15入れてもらうことを目指すのが後者に当たる 。

後で回収するためには特許が必要であるという議論である。

後者の場合、提供を受けた部分の著作権の扱いが問題と

ただ、逆に、Boldrin & Levine (2008)によれば、ワットは、特許なることが多い。開発プロジェクト側がコードのマージに当たを取得したが、結局、特許で他人から金を得ることに尽力し● 15-6 ●知財研紀要 2011 Vol.20

てしまい、ワット自身が、特許権が満了するまで蒸気機関を作っていたわけではない。むしろ、ワットの特許は、社会全体
から見れば技術発展を妨げただけだったのではないかという議論がある。これは特許一般の話であるが、ソフトウェア特許の有用性を主張する研究というのは更に少ない。
日本の特許庁では、ソフトウェア特許、特に、ビジネス・モ
デル特許に関しては、開示要件や実施可能要件などについて審査をかなり厳格にしているというようにいわれている。

license to make, have made, use, offer to sell, sell, import and otherwisetransfer the Package with respect to any patent claims licensable by the
Copyright Holder that are necessarily infringed by the Package. If you institutepatent litigation (including a cross-claim or counterclaim) against any party
alleging that the Package constitutes direct or contributory patent
infringement, then this Artistic License to you shall terminate on the date thatsuch litigation is filed.
13
USPTO Assignments on the Web(http://assignments.uspto.gov/assignments/q?db=tm&rno=1916230) 2011
年3月25日閲覧。
14
この場合、コードはユーザが手元で自ら本体に追加（典型的にはパッチを当ててビルド）することとなる。
15
Linuxカーネル本体にマージされた日本由来のコードとしては、2009年にマージされたTOMOYO Linux等がある。

オープンソース・ソフトウェア・ライセンスにおける特許の扱いについて、基調として常にネガティブな方向になっているのは、元々、反ソフトウェア特許という考えがあって、それがオープンソース・ソフトウエア・ライセンスに影響を与えているからだということは理解するべきである。コピーレフト条項が、著作権をてこに著作権を実質的に無力化するものだったのと同じように、特許権をてこにソフトウェア特許の問題を解決するための工夫としてとらえられるであろう。
誰にも差別せず、無償でライセンスするというのがオープ
ンソースの原則であるので、特許の独占的排他性とどのように平仄を合わせていくかというのが難しくなってくる。それを、このような形で何とかつじつまを合わせることができるであろうかというのが、オープンソース・ライセンスにおける特許の扱いであると思われる。
商標に関しても同様で、オープンソース・ライセンスを維持しながら、実質的にコントロールする手段として考えられている。これらの点を理解しないと、今後、ソフトウェアをライセンスするとか、オープンソース・ソフトウェアを特に経済的な利益を求める形で利用したいという場合には、非常に問題になるのではないかと思われる。この研究がこういった需要に応えることができるものと考える。

1

DIAMOND v. DIEHR, 450 U.S. 175 (1981).
The proposed directive on the patentability of computer implemented inventions,
Commission proposal COM(2002) 92.
3
Open Source Initiativeについては公式ウェブサイト
http://www.opensource.org/osd.html参照。
4
オープンソースの定義については、Open Source Initiative のウェブページ
http://opensource.org/docs/osd 参照。
5
オープンソース・イニシアティブのウェブサイト
http://opensource.org/history 参照。
6
クリエイティブ・コモンズのウェブサイト http://creativecommons.org/参照。
7
http://freedomdefined.org/OSHW
8
当研究所ウェブページ http://peertopatent.jp/参照。
9
GNU GPLv3 の原文テキストは、GNU のウェブサイト
http://www.gnu.org/licenses/gpl-3.0.html に掲載されている。また、この原文テキストの仮和訳は、独立行政法人情報処理推進機構(IPA)のウェブサイト
http://ossipedia.ipa.go.jp/legalinfo/gpl-3.0J.html に掲載されている。
10
CAFC の判決文は、
http://www.cafc.uscourts.gov/images/stories/opinions-orders/08-1001.pdf
から入手可能。
11
The Open Source Definition
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a
specific field of endeavor. For example, it may not restrict the program frombeing used in a business, or from being used for genetic research.
7. Distribution of License
The rights attached to the program must apply to all to whom the program isredistributed without the need for execution of an additional license by thoseparties.
12
Artistic License 2.0(13) This license includes the non-exclusive, worldwide, free-of-charge patent2● 15-7 ●

知財研紀要

2011

Vol.20