ライセンス編1 『自由』をプログラムする - デベロッパーのための法学入門(3)

このシリーズについて

このシリーズは、三重大学サークル計算研究会の勉強会で使用した「デベロッパーのための法学入門」の資料です。
専門外なデベロッパーでも知っておくべき法学の基礎・教養から、ライセンスや情報法、知財法等のデベロッパーに深く関係のある分野までを網羅的に勉強してほしいという考え方の元執筆しています。

記事中、一部厳密でない表現等があるかもしれません。また内容の正誤には注意を払っていますが、著者はその内容について責任を取ることは出来ません。

私は法律の専門家ではありません。

シリーズ関連記事

• 基礎法学編
• 法律の読み方編
• ライセンス編1 『自由』をプログラムする
• ライセンス編2 ～Choose a open source license～(執筆中)
• 利用規約を作り込め！
• プロバイダ免責法 ～訴訟されないための投稿サービス運営法～

ライセンスを学ぶ意義

開発をしていると、他人が公開してくれているプログラムやライブラリを利用することが多々あると思います。しかし、ソースコードは著作権によって保護されうる¹ので、無断で利用すると権利侵害の恐れがあります。
そこで、権利関係と利用条件を明らかにするために、ライセンスが定められますが、プロジェクト毎にライセンスを作成していると開発者にとっても利用者にとっても負担となります。

ですので、開発者は余程のこだわりが無い限り既存の有名なライセンスを採用することが強く推奨されます。（オレオレライセンスはやめましょう！）
もちろん、利用者は策定されているライセンスを正しく守る必要があります。

利用者としても、開発者としても、ライセンスについての知識をつけておく必要があるのです。

この分野で有名な団体

• フリーソフトウェア財団 (Free Software Foundation , FSF)
  ユーザーがソフトウェアの改変・再頒布を自由に行えるフリーソフトウェア(以下自由なソフトウェア)² を広く推進する団体。
  活動内容は自由なソフトウェアの推進に関わる多岐の事業に渡っており、例として以下のような活動を行っています。
  • 自由なソフトウェアの理念を広げるための自由なソフトウェア運動
  • GNUプロジェクト(GCCやEmacsもこの成果)の資金的・法的・政治的支援
  • GNUプロジェクトで用いるライセンス(GPL, LGPL等)の策定・運用・啓発
  • GPLライセンス違反の是正勧告や交渉
• オープンソース・イニシアチブ（Open Source Initiative , OSI）
  後述「オープンソースの定義」を策定した標準化団体。様々なライセンスをレビューしたり、啓蒙活動を行ったりしてオープンソースコミュニティを支え、オープンソースの発展、促進を目指している。
  ※もちろん、ネットワークに関する「OSI参照モデル」のOSIとは関係ありません。
• オープンソースグループ・ジャパン (Open Source Group Japan , OSG-JP)
  上述のオープンソースや自由なソフトウェアの考え方を日本で広め、支援するための団体。ライセンスの日本語参考訳の作成や、商標の管理、様々な振興活動等を行っています。

自由なソフトウェアと自由なソフトウェアのライセンス

最近ではソースコードを公開して、様々な人の参画を図る開発形態として「オープンソース」をよく見かけますが、この思想をしっかりと理解するためには、歴史的に先発である「Free Software(自由なソフトウェア)」について学ぶ必要があります。

ここに言う自由なソフトウェアのフリーという言葉の意味は自由であり、無料という意味ではありません。

オープンソースという言葉が生まれるよりも先に、「ソフトウェアは自由でなければならない」と考える人々がインターネットには一定数存在していました。(もちろん今もですが)

彼らが唱える「自由なソフトウェア」の定義は後述しますが、簡単に言えば、プログラムの利用者がソースコードを手に入れることが出来て、悪意のあるコードが含まれていないかを確認したり、ソースコードの中身を研究したり、或いは修正を行って再頒布するような権利を持つソフトウェアを「自由」としています。

例えばソフトウェアが自由であるべきというのは、Microsoft OfficeやAdobeのような、ソフトウェアのソースコードを公開せずに販売する形式ではなく、Libre OfficeやGIMPのようなソースコードを利用者が完全にコントロール出来るソフトウェアが望ましいということです。

この「自由なソフトウェア」に関する思想と、そこから生まれた「コピーレフト」という考え方、「GPL」というライセンス等を勉強していきます。

自由な(フリー)ソフトウェアの定義

まず、自由なソフトウェア財団(以下 FSF) が定める自由なソフトウェアの定義を確認します。

http://www.gnu.org/philosophy/free-sw.ja.html
によると、

FSFによる自由なソフトウェアの定義

あるプログラムが自由ソフトウェアであるとは、そのプログラムの利用者が、以下の四つの必須の自由を有するときです
　
・どんな目的に対しても、プログラムを望むままに実行する自由 (第零の自由)。
・プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第一の自由)。ソースコードへのアクセスは、この前提条件となります。
・ほかの人を助けられるよう、コピーを再配布する自由 (第二の自由)。
・改変した版を他に配布する自由 (第三の自由)。これにより、変更がコミュニティ全体にとって利益となる機会を提供できます。ソースコードへのアクセスは、この前提条件となります。
　
利用者が以上であげた全ての自由を有していれば、そのプログラムは自由ソフトウェアです。そうでなければ、不自由です。

もう少し簡単に言い換えましょう。自由なソフトウェアとは以下の要件を満たすものです。
・バイナリと共にソースコードやドキュメントを入手出来て、(前提)
・ユーザーがどのような目的についても実行が出来て (第0の自由)
・ソースコードについて、研究・改変・再頒布を認めるものです。(第1,2,3の自由)

また、これら主要な自由を制限しない限り、一部の規制をライセンスに含めることが可能です。

例えば、後述する「コピーレフト」では、再頒布する際にも元と同じライセンスを適用して明記しなければいけませんが、これは再頒布の自由を制限しませんので、自由と言えます。

自由なソフトウェアを実現する幾つかの方法

あるプロジェクトを自由なソフトウェアとして発展させたい場合に、ライセンスに選ぶことが出来る幾つかの選択肢が用意されています。
ここでは、自由なソフトウェアとして認められるためのライセンスの選択肢について、その特徴と共に勉強していきます。

パブリックドメイン

パブリックドメインとは、著作物について著作権が存在しない/放棄されている状態のことを言います。日本語で公有と言いますが、著作者が一切の著作権の主張をしない(著作権の放棄)場合がこれに当たります。
パブリックドメインなソースコードには、そもそも著作権が存在しません³ので、このソースコードを有料で配布しても、営利目的の製品に組み込んでも、改変して別のライセンスをつけて再頒布しても問題ありません。
ある意味で、最も緩い(自由な)状態と言えます。

比較的緩いライセンス

ここに言う「比較的緩い」とは、次に述べる「コピーレフト」という概念に対して緩いという意味です。
コピーレフトは、再頒布する際に元と同じライセンス(またはそれと両立しうるライセンス)を付与することを条件としますが、比較的緩いライセンスはそれを要求しません。
詳細は後述しますが、BSDライセンスやMITライセンス等がこれに当たります。

パブリックドメインやこれらのライセンスは、再頒布する際のライセンスの指定を行いません。
これは、自由なソフトウェアの改変物が自由とは限らないことを意味しています。
自由なソフトウェアを企業が改良して、有償ソフトウェアとして販売することも全く問題ありません。
そして、その際には元のBSDライセンスやMITライセンスを付与したり、ソースコードを配布する必要もありません。
つまり、ソースコードを手に入れた人はそのソースコードを(著作権表示などをすれば)何にでも利用することが出来ます。
そのような意味で、これらのライセンスは「比較的(自由への強制度が)緩い」のです。

コピーレフト

多くの自由なソフトウェアやプロジェクトで採用されているのが、このコピーレフトなライセンスです。
コピーレフトは、考え方や概念のことで、「自由である」だけではなく、「その派生物も自由であることを強制する」という制約を追加しています。具体的には、あるソフトウェアを改変して公開する場合には、その改変物も同様のライセンスで公開しなければなりません。

具体的には、以下の制約を追加します。
・コピー、再頒布する際には、全ての情報(ソフトウェアやソースコード、ドキュメントを含む)を公開する必要がある。
・改変、翻案した物の再頒布を制限しないが、二次的著作物にも同一のライセンスを適用して、明記しなければならない。

コピーレフトなライセンスとして代表的なものに、GPLがあります。
GPLは、FSFの支援するGNU プロジェクトで用いられるライセンスでもあり、これはLinuxカーネルやその周辺の主要なソフトウェアにも用いられています。

これは世の中のソフトウェアを可能な限り自由なものにしたいというFSFの理念の表れでもあります。
あるソフトウェアがコピーレフトなライセンスを適用して発表された場合、このソフトウェアが様々な人によって改良され、工夫され、保守されていったとしても、その成果物もまた自由なソフトウェアとなります。まさに、自由なソフトウェアが発展すればするほど、自由が広がっていくというロジックこそが、コピーレフトの真骨頂なのです。

実際、Linuxへの関与を強めるMicrosoftに対して「金でLinuxの統制権を得ようとしているのではないか」といった意見がありましたが、Linusを始めとするLinuxカーネルの開発者達はこれを懸念していないと述べているそうです。

その理由こそ「Linuxカーネルには、コピーレフトなライセンスであるGPLが適用されているから」でした。その派生物までもを自由なソフトウェアにしてしまうGPLの適用によって、企業によるLinuxの統制を不可能なものとしているのです。

著作権の放棄と行使による自由

このように、自由なソフトウェアを達成するためには、著作権の放棄(パブリックドメイン)による方法と、行使(ライセンス)による方法が存在します。

しかし、先程述べた通りFSFは著作権を行使すること(ライセンスを適用すること)、特にコピーレフトなライセンスの適用によって自由なソフトウェアを達成する方が望ましいと考えています。コピーレフトなライセンスは自由を広げる効果があるからです。

このように、FSFは自由なソフトウェアを広めることに重きを置いています。ソースコードの公開はその前提なのです。
また、あくまで「自由であること」が重要であり、ただソースコードを公開するだけでは不十分である、ということも抑えておきましょう。

オープンソースとオープンソースライセンス

このように、FSFが提唱する「自由なソフトウェア」は、理念としては素晴らしいものだと私は思いますが、これに対する資本家達の印象は必ずしも良いものではありませんでした。

そもそも、ソースコードが自由に再頒布されていくという考え方は、お金を稼がなければいけない営利目的のビジネスには馴染みません。また、英語の"Free"という言葉は"無償"という意味も含んでいて、これもビジネス的な視点から見ると良くない印象を与えていました。

他にも、比較的急進的なFSFが自らの理念とは異なる「自由でないソフトウェア」に対して攻撃的で、相容れようとしなかったこともビジネス側からの印象を下げる一つの要因となりました。⁴

そこで、このような「自由なソフトウェア」の概念とは一線を画しながらも、「技術者が誰でも開発に参加出来て、再頒布の自由を有するもの」という理念と用語が必要となり、検討されました。
そして、その中で生まれた概念こそが「オープンソース (open source)」なのです。
語弊を恐れずに言うと、自由なソフトウェアから、「自由であること」への執着を捨て、よりビジネスにとって受け入れやすい印象を与え、ソフトウェアの発展を目的とする理念として生まれたのが「オープンソース」なのです。

オープンソースの定義

オープンソースイニシアチブ(以下 OSI) が定め、オープンソースグループ・ジャパン (以下 OSG-JP) が公開している「オープンソースの定義の日本語訳」を一部引用して、紹介しましょう。

なお、内容を纏めるために筆者の責任でそこそこ内容を削っていますので、注意してください。

1. 再頒布の自由
   ライセンスは、ソフトウェア頒布物を販売または無料で頒布することを制限してはなりません。
2. ソースコードの添付
   配布するプログラムにはソースコードを含まなければなりません。又はソースコードを手に入れる方法を公表し、複製に要する妥当な額のコストで入手出来なければなりません。また、難読化した状態や、中間形式では認められません。
3. 派生ソフトウェア
   ライセンスは、改変した派生ソフトウェアの作成及び、元と同じライセンスの下での頒布を許可しなければなりません。
4. 作者のソースコードの完全性(integrity)
   ここだけ少し難解なので要約しますが、この項目の目的は「作者(オリジナルの作者)の書いたソースコードが、その後に改変されるソースコードと明確に見分けられるようにする権利」を認めることです。その手段として、
   (1) オリジナルの改変物の再頒布を拒否するかわりに、オリジナルのソースコード + バッチファイルでの頒布を許可する
   (2) オリジナルの改変したものの再頒布を許可するかわりに、改変物の名前・バージョンを変更することを強制する。
   この2つのどちらかを、改変者に対して選ばせることが出来るというものです。(作者が選べるわけではない)
5. 個人やグループに対する差別の禁止
   ライセンスは特定の個人やグループを差別してはなりません。（それはそう）
6. 利用する分野(fields of endeavor)に対する差別の禁止
   ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。 例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはいけません。
7. ライセンスの分配(distribution)
   プログラムに付随する権利は、そのプログラムが再頒布された者全てに等しく認められなければならず、彼らが何らかの追加歴ライセンスに同意することを必要としてはなりません。例えば機密保持契約への同意を要求するなどして、間接的に囲い込んだりしてはいけません。
8. 特定製品でのみ有効なライセンスの禁止
   プログラムに付与された権利は、それが他のあるソフトウェア頒布物の一部であることに依存するものであってはいけません。例えば、「ある製品の一部である時にオープンソースライセンスが有効化される」などといった条項で囲い込んではいけません。オープンソースなソフトウェアは、他の製品に組み込まれていようがいまいが、オープンソースなソフトウェアとして利用可能です。
9. 他のソフトウェアを制限するライセンスの禁止
   例えば、ライセンスは同じ媒体で頒布される他のプログラムが全てオープンソースソフトウェアであることを要求してはなりません。
10. ライセンスは技術的中立でなければならない
    例えば、ライセンスは利用時に「同意します」ボタンを作ることを要求してはいけません。これでは、「同意します」ボタンが作成出来ない環境において、頒布することが出来なくなってしまいます。

オープンソースライセンス

OSIがオープンソースであると認めたライセンスのことを、オープンソースライセンスと言います。
OSIは、OSIが認めたオープンソースライセンスについて区分をして公表しています。

終わり

今回は自由なソフトウェアと、オープンソースソフトウェアの歴史的経緯や価値観的な違いを解説しました。

社会に構築・実装された法律というアーキテクチャの上で、『自由』をプログラムする。GPL等のライセンスはその作品の一部なのだと考えると、他の法学の勉強には無い面白さを感じることが出来ました。

本来、この章はさらっとライセンスの紹介をして終わらせるつもりでしたが、FSFやOSIの理念等を書いているうちに筆がのってしまいました。(汗)

次回は、FSFが認めた(または整備している)ライセンスや、OSIが整備しているオープンソースライセンスを具体的に見ていきます。また、その選び方等についてもお話していきたいと思います。

1. プログラムが著作物として保護されるかどうかという問題について、著作物は「思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するもの」(著作権法第2条第1項第1号)と定められています。そして著作権法第10条には「プログラムの著作物」が著作物の具体例として例示されていますので、プログラムも著作物として保護されます。しかし、アルゴリズム等は「思想又は感情を創作的に表現」するものではないので、著作物としては保護されないと解されています。なお、特許等を始めとする他の知的財産権等によって保護出来る場合もあります。 ↩

2. FSFの創設者Richard Stallmanが、フリーソフトウェアでは「無料」と「自由」のどちらを指すか曖昧であり、せっかく日本語には「自由」という明朗な意味の単語があるのだからそれを用いてほしいという趣旨の発言を講演で行っています。(https://www.rieti.go.jp/jp/events/03042101/speech.html) ↩

3. なお、日本(を含む多くの国)においては、著作権は財産権的著作権(譲渡、相続可能)と著作者人格権(譲渡、相続不可能)に分類することが出来ます。本来、パブリックドメインである著作物は著作者人格権も消滅していることが望ましい(そうでなければ改変等が難しい)のですが、学説では、人格権の放棄は出来ないと解されています(人格に関わる権利であるので)。つまり、財産権的著作権と著作者人格権の両方が消滅した完全なパブリックドメインを宣言しうるかどうかという点については議論のある問題です。 ↩

4. 「Proprietary Software Is Often Malware(プロプライエタリなソフトウェアはしばしばマルウェアである)」 - などにも、その理念に基づいた(ある意味少し過激な)主張が表れています。 ↩