licenses.md

ライセンスについてより正確に知る

本書では、「フィードバックは身近な小さなつまずきから始めよう」と述べてきました。なので、皆さんがする「初めてのプルリクエスト」も、おそらく、その変更箇所の著作権をわざわざ主張したいとも思わないような、ごくごく簡単な内容になっていることでしょう。

しかし、経験が増えてきて難しい課題にチャレンジし始めると、「このコードを書いたのは自分だ」とアピールしたくなってくるかもしれません。また、他のOSSのコードを参考にしたい、あるいは、そのコードをそのまま引用して使いたい、と思う場面が出てくるかもしれません。

そういうときに重要になってくるのが、ライセンスです。本章では、OSSでの著作権とライセンスについて、「とりあえずこれだけ知っていれば無駄にビクつかずに済む」という基本的な知識を解説します。

コードと著作権

著作権の基礎

文章や絵、音楽、映像、プログラムなど、「作者の思想や感情を表現したもの」を一般的に「著作物」と言います。「著作権」は、著作物の作者に固有のものとして認められる、その著作物の利用のされ方を決める権利¹のことです。

たとえば、「本を勝手にコピーして海賊版を作って販売してはいけない」のは、その本の著作権者が「著作物をコピーしたり販売する権利を、他の人には分け与えていない」からです。逆に、OSSのように著作権者が「著作権者名を明示してくれる人には、この本の内容を好きに利用できる権利を分け与える」とルールを定めていれば、そのルールに則って、本の複製を勝手に販売してもいいことになります²。

詳しくはまた後で述べますが、OSSとは、著作権者が「このソフトウェアはこういう条件のもとで自由に利用して構わない」と条件を設定したソフトウェアです。そのようにライセンスを設定してくれているお陰で、皆さんは「勝手に著作物をコピーしやがって！」と殴り込まれることもなく、安心して「リポジトリをフォークして、編集して、プルリクエストを提案する」ことができるわけです。

プルリクエストで提供するコードは誰の物？

日本の著作権法は無方式主義といって、特に役所等に届け出なくても、著作物を作った時点で著作権が発生することになっています。

ですが、場合によっては著作権が認められないこともあります。プログラムの領域でいうと、オリジナリティが無いコードがこれにあたります。

具体的には、「公知の情報そのままに書かれたコード」「誰が書いてもそうとしか書かれ得ないコード」がそれに該当します。alert("Hello, world."); のような一文は、その例としてよく挙げられます。OSSへのプルリクエストで提供されたコードの著作権について法廷で争われた事例を、筆者は寡聞にして把握していないのですが、恐らく誤記の修正程度の変更はこれと同様に扱われるのではないかと思います。

しかし、「既存のコードを変更したもの」の権利がどうなるかは、筆者も含めて素人には判断が難しいです。コードの提供者が、フィードバック時には「いいよいいよ、権利なんて気にしないで」と言っておいて、後から「この部分の権利は私が持つから使用料を払え」と主張し始める、というようなことが起こると、プロジェクトに大きな混乱を招きかねません。裁判をすれば「この提供されたコードには著作権は認められない」といった判決を得られる可能性はありますが、誰が訴訟に対応するのか、その費用は誰が出すのか、そもそもそんなことの対応に時間を取られてよいのか、といった問題があるため、実現性は低いです。

このような理由から、著作権の管理に気をつけているプロジェクトでは、コードを提供する人に貢献者ライセンス同意書（Contributor License Agreement、略してCLA）、あるいはそれに類する文書へ署名して、提供するコードの諸権利をプロジェクトに譲渡することを求めている場合があります。たとえばGNU Emacsプロジェクトでは、「変更の累積行数が15行を超えるならFree Software Foundationに対して権利を譲渡する必要がある」としています³。

「ライセンス」とは？

OSSの文脈で一般に「ライセンス」と呼ばれる物は、著作権に基づいて「こういう利用の仕方は許可する」「こういう利用の仕方は許可しない」といった利用許諾条件をあらかじめ記載しておいた物のことを言います。いちいち著作権者に許諾を求めなくとも、ライセンスに記載された通りの条件に従う限りは、勝手に二次利用して問題はありません。

ライセンスは複数種類設定される場合もあります。以下はその例です。

• プログラミング言語のRubyのC実装（いわゆるC/Ruby）は、「Rubyライセンス」と「2条項BSDライセンス」の2つのライセンスが設定されていて、利用者は「どれか1つの条件に従うか、もしくは、両方の条件に従う」という選択が可能です。
• かつてFirefoxのソースコードは「MPL1.1」「GPL2」「LGPL2.1」の3つのライセンスが設定されていて、利用者は「どれか1つの条件に従うか、もしくは、3つすべての条件に従う」という選択が可能でした。
• MySQLは「GPL2、もしくは商用ライセンス」の二者択一になっています。

もちろん、ライセンスで許諾されていない使い方でも、著作権者の特別の許可を得られれば、得られた許可の範囲でそのOSSを使うことはできます。

[column] コラム：「ライセンス」の綴り

アメリカ英語ではライセンスはlicenseという綴りしかありませんが、イギリス英語ではlicenceという別の綴りの単語があります。licenseの誤記ではないので注意が必要です。

それぞれの使い分けは以下の通りです。

• license：動詞としてのライセンス（許諾を与える行為）
• licence：名詞としてのライセンス（与えられた許諾そのもの）

誤記だと思って勝手に「licence」を「license」に変更するプルリクエストを出すと、恐らくイギリス人に叱られますので、気をつけてください。

[/column]

オープンソースの定義って？

「自由に使っていいよ」と言っていれば「オープンソース」、とは限らない

OSSは、著作権者が「このソフトウェアはこういう条件のもとで自由に利用して構わない」と条件を設定したソフトウェアだ、と述べました。ですが、これは非常に雑な説明で、実際にはもっと厳密な定義があります。

「オープンソース」という言葉は、1998年にアメリカのパロアルトで作られました。以降2020年現在に至るまで、オープンソースという言葉の意味は*オープンソースイニシアティブ（OSI）*という団体によって明確に定義されています。

OSIによるオープンソースの定義は、要約すると以下のようになります。

1. 再配布の自由：元の作者でもそうでなくても、そのソフトウェアを自由に販売したり無償配布したりできること。
2. ソースコードの入手性：誰でもソースコードを入手できること。製品にソースコードを添付できない場合は、別途入手できる手段を提供すること。
3. 派生ソフトウェアの容認：誰でもそのソフトウェアを改造できて、同じ条件のもとで再配布できること。
4. 作者のソースコードの完全性：元のソースコードを改変した物を直接再配布することを許可しない場合、「元のソースコード」と「それに対して変更を反映するパッチ」をセットにして再配布できること⁴。
5. 個人やグループに対する差別の禁止：特定の人や集団・組織を問わず、誰でもそのソフトウェアを利用できること。
6. 利用する分野に対する差別の禁止：平和のためでも、戦争のためでも、学術のためでも、営利のためでも、目的を問わず何のためにでもそのソフトウェアを利用できること。
7. ライセンスの分配：機密保持契約を結ばなければいけない、といった追加の制限なしに、そのソフトウェアを受け取れること⁵。
8. 特定製品でのみ有効なライセンスの禁止：そのソフトウェアが何らかの製品の一部としてのみ使えるという形ではなく、取り出して単独でも使えること。
9. 他のソフトウェアを制限するライセンスの禁止：そのソフトウェアを、他の条件の下で配布されるソフトウェアと共に配布できること。
10. ライセンスの技術中立的性：利用許諾条件それ自体を、PCやスマートフォンやウェアラブルデバイスなどのハードウェア、画像や音声などのメディアを問わず、誰でも容易に確認できること。

これらの条件を満たす利用許諾条件を「オープンソースライセンス」、そのような利用許諾条件が設定されたソフトウェアを「オープンソースソフトウェア（OSS）」と呼びます。

OSIでは、OSIが「確かにこのライセンスはオープンソースの定義に合致している」と認定したライセンスの一覧をWebサイト上に掲載しています。

実は「OSS」ではないケース

ソフトウェアや電子データのライセンスには、「OSSに似ているけれどもOSSとは言えない」例がいくつかあります。

たとえば、Unityちゃんライセンス2.00には「公序良俗に反する行為や目的、反社会的な行為や目的、特定の信条や宗教、政治的発言のために利用しないこと」という条件がありますが、これは前述の条件の6番目に合致しません。著作物を宣伝や広告に利用することや、キャラクターの価値を下げる利用の仕方を禁止しているピアプロ・キャラクター・ライセンス、あるいは、RedisやMongoDBなどが商用クラウドベンダーによるソフトウェアの使用を制限するようとに設定したライセンスにも、同じことが言えます。

では、上記の「オープンソースの定義」を満たすようにライセンスを定義すれば、それでもう「オープンソースライセンス」を名乗ってもいいのでしょうか？

実は、それも早計です。というのも、OSIはOSIがオープンソースライセンスだと認定してWebサイト上の一覧に記載した物以外をオープンソースとは呼ばないように求めているからです。これは、オープンソースの定義に合致しない可能性がある物が広まってしまうと「オープンソース」という言葉の意味が揺らいでしまうためです。

そういう意味で厳密には「OSS」ではない（かもしれない）物の例としては、HTTPサーバーのNginxが挙げられます。Nginxの公式サイトには、トップページ上に「The sources and documentation are distributed under the 2-clause BSD-like license.（ソース及びドキュメントは2条項BSDライクライセンスで配布されます。）」と書かれていますが、2条項BSDライクライセンスはOSIのオープンソースライセンス一覧に記載されていません⁶。

OSSではない物をOSSと誤認して二次利用すると、もしかしたら訴訟を起こされたり賠償を求められたりするかもしれません。ライセンスに関する情報を見つけられない場合は安全側に倒して、OSSではないと判断することを筆者はお勧めします。

なお、Free Software Foundation（FSF）が提唱する「自由なソフトウェア」については特にそのような認定は行われていない様子⁷で、後述するの4つの条件を満たしていれば自由なソフトウェアと呼んでよいらしく、Nginxはこちらの条件を満たしています。なので、「Nginxは自由なソフトウェアだ」と言うことには問題はありません。

オープンソースと特許権

ところで、ソフトウェアは著作物ですが、特許の影響を受ける場合があります。

特許権とは、「発明」をした人（発明者）に与えられる独占的な権利で、著作権とは独立しています。そのため、著作権の範囲では自由に利用していいけれども、特許料の支払いは別途求める、ということも理論上は可能です。OSSでも同じことは言えて、あるOSSに特許に抵触する内容が含まれていたときに、その派生物を作った人が、元のソフトウェアの作者から（かってに他人の特許を使った製品を配っている、と）特許権の侵害で訴えられる、という可能性はあることになります。

そのためオープンソースライセンスの中には、「そのライセンスに従ってソフトウェアを利用する人に対しては特許の使用を許可し、特許料の支払いを求めない」ことを条件の中に明確に盛り込んでいる物もあります。MPLやGPLバージョン3、Apacheライセンスのバージョン2などはこれにあたります。

ただ、これはあくまで、ソフトウェアの著作権者が特許権者でもある場合に有効な話です。全く無関係の別の人が特許権を持つ機能をソフトウェアに含めてしまった場合、普通にその権利者から特許使用料を請求されたり、訴訟を起こされたりすることも考えられるので、「このオープンソースライセンスなら特許を気にしなくてもいい」といった早合点は禁物です。

その他にも、「第三者相手に特許訴訟を起こした場合、そのOSSに元々含まれていた他の人の特許について使用権を剥奪される」「特許で保護された部分の改変には特許権者の許諾が必要」など、特許に関する条件はライセンスによって異なる部分があり、素人判断は危険と言わざるを得ません。自社で特許権を持つ技術を、既存のOSSに提供したりOSSとして公開したりする場合は、知財部門や顧問弁護士などによるチェックを必ず受けるように注意してください。

オープンソースと商標権

企業によって運営されているOSSプロジェクトでは、商標が問題となる場合もあります。

商標とは、数ある商品の中からその商品を識別するための目印のことです。たとえば「Firefox」という名前やロゴタイプ、アイコンなどによって、ユーザーはそのソフトウェアが「これはGoogleのChromeでもAppleのSafariでもなく、MozillaのFirefoxという商品だ」と識別できます。

商標権もまた、著作権とは別の権利で、商標権を持つ者にその商標の独占的な使用権があります。商標の取り扱いはオープンソースライセンスとは独立しているため、「オープンソースライセンスに基づいてソフトウェアの改造や再配布はしても問題無いが、元のソフトウェアに含まれている商標は使用できない」場合があります。

例に挙げたFirefoxは、その典型的な例です。「Firefox」という名前やロゴマーク、アイコンなどは、すべてMozillaという組織が商標権を保持していて、Mozillaがオフィシャルに認めた物以外の物に、第三者が勝手にそれらを使ってはいけないことになっています。そのため、Firefoxに改造を施した物を配布するときは、「IceWeasel」や「Waterfox」、「Pale Moon」のように全く別の名前を付けないといけませんし、アイコンも別の画像に変えなくてはいけません。

コピーレフト型のライセンスで気をつけること

コピーレフトと非コピーレフト

オープンソースライセンスには大別して、コピーレフト型と非コピーレフト型の2種類があります。

コピーレフト（Copyleft）とはコピーライト（Copyright：著作権）をもじって作られた言葉で、ある著作物について、その派生物についても同じ条件での利用を許諾することを、利用の条件とするという概念です。平たく言えば、「私の作ったこのソフトウェアを自由に改造して使っていいですよ。ただし、改造した結果のソースコードを、そのユーザーにも自由に使わせてくれるならね」というような話です。この性質を持つライセンスをコピーレフト型と言う場合があり、GPL（GNU General Public License）はその代表例です。

それに対して、コピーレフト性を持たないオープンソースライセンスは非コピーレフト型と言います。平たく言えば「改造結果を完全に秘匿して構いませんよ」ということで、BSDライセンスやMITライセンス、Apacheライセンスなどがこれにあたります。

コピーレフト型のライセンスでも、ライセンスによってコピーレフト性の強さには違いがあります。以下にいくつか例を挙げます。

• *コピーレフト性が弱いMPL（Mozilla Public License）*では、MPLだったファイルの派生物はMPLとする必要がありますが、後から追加したファイルまでMPLとする必要はありません。
• *コピーレフト性が中程度のLGPL（GNU Lesser General Public License）*では、そのソフトウェア自体の派生物はLGPLとする必要がありますが、ライブラリとしてLGPLのソフトウェアを使う場合⁸、その呼び出し元のソフトウェアまでLGPLとする必要はありません。
• コピーレフト性が強いGPLでは、そのソフトウェアに追加されたすべてのコードをGPLとする必要があります。ただし、そのソフトウェアによって提供されているサービス（SaaS）のユーザーにまでは、ソースコードを提供する必要はありません。
• *最もコピーレフト性が強いAGPL（Affero GPL）*では、SaaSのユーザーにもソースコードを提供する必要があります。

「GPL汚染」って何？

コピーレフト性を持つライセンスでは、派生物にも同じライセンスを設定することが求められます。これは一般的には、「GPLのソフトウェアを改変したら、改変後のソフトウェアもGPLになる」というようなことを意味しています。

ただ、場合によっては、この*「改変部分」の大きさが主従逆転する*ことがあります。

たとえば、自社のプロプライエタリな製品の中にGPLのソフトウェアの一部を引用したとします。すると、これはコード量としては「プロプライエタリな部分が主、GPLの部分が従」です。著作権法では、分量や文脈から主従関係が明白な場合を「引用」と定義していて、著作物の権利は主となる著作物の権利者の方が持つことになります。

しかし、GPLのソフトウェア側から見た場合は、あくまで「全体がGPLのソフトウェアの派生物」ということになります。そのため、このプロプライエタリな製品全体にGPLを適用する必要が生じます。

このような、「一部でもGPLのコードが混入すればGPLでなかったほかの部分まですべてGPLになってしまう」様子をウィルス感染や放射能汚染のようにたとえて言った言葉が、「GPL汚染」です。OSSにフィードバックする場面でも、ライセンスがApacheライセンスやBSDライセンスなどの非コピーレフト型であるOSSに対して、GPLのソフトウェアから一部を引用したり全体を組み込んだりすると、この「GPL汚染」が起こることになります。そのため、このようなプルリクエストは却下されると思っておいたほうがいいです⁹。

また、明確に「この部分はGPLです」と宣言してプルリクエストされればそのような判断もできるのですが、その変更がGPLのソフトウェア由来であることを提案者が隠していた場合、さらに問題は深刻化します。ともすれば、プロジェクトは対応に追われることとなり、その間、通常の開発はストップしてしまう、ということもあり得ます。皆さんがコードを提供するときは、くれぐれもこういった「汚染」を引き起こさないように気をつけてください。

なお、コピーレフト性の有無・コピーレフト性の強さが異なるライセンスのコードを組み合わせる場合の注意点について、CC（Creative Commons）との関係も含めて述べた記事が筆者のブログにあります。本章と合わせてご覧いただくと、ライセンスの組み合わせへの理解がより深まるかもしれません。

オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた

より確実なことを把握したい場合は、GNUプロジェクト自身による解説を参照するのがおすすめです。

さまざまなライセンスとそれらについての解説 - GNUプロジェクト - フリーソフトウェアファウンデーション

ソースコードを「公開しないといけない」ということはない

誤解されていることが多いのですが、コピーレフトは、派生物を「万人に向けて同じ条件で公開しなければならない」ということを、必ずしも意味しません。現に、強いコピーレフト性を持つGPLやAGPLでも、そのような条項は存在していません。これらのライセンスは、あくまでそのソフトウェアやサービスのユーザーに対するコピーレフト性のみを持っているからです。

ですから、たとえば以下のようなことが言えます。

• あるGPLのソフトウェアを改造した物をあなたが個人的に使っている場合、その改造箇所のソースコードを他人に開示する必要は、全くありません。
• GPLのソフトウェアを改造して顧客に提供した場合、それを使用する顧客に対してはソースコードを開示する必要がありますが、無関係の第三者に対してまで開示する必要はありません。
• 社内でのみ使うツールやサービスにGPLやAGPL由来のコードを混入しても、それを外部の人が使うことがないなら、ツールやサービス全体のソースコードを、万人に向けて公開する必要も、GPLやAGPL部分のコードの作者にわざわざ提供する必要もありません。

ただし、そのユーザーが手に入れたソースコードを他の人に公開することは、これだけだと防げません。ソースコードの無用な拡散を防ぎたい場合、ライセンスが定める「配布」の条件に該当しない形態に限定してソフトウェアを使用したり、ソフトウェアの使用とは無関係の所で契約を結んだり¹⁰、ソースコードを公開しないことがその人の得になるようなインセンティブを設けたりする必要があるでしょう。たとえば、以下の要領です。

• 「社内で使うWebベースの業務システム」にGPLのコードが含まれる場合、そのシステムを動作させるサーバーの管理者にはソースコードを開示する必要はありません。これは、組織内での私的改造版の使用は「配布」にはあたらず¹¹、GPLの条文が適用されないためです。また、ソフトウェアの開発に関わった人がソースコードを公開することは、雇用契約の中の守秘義務に基づいて防げると考えられます。
• 「社内で使うWebベースの業務システム」にAGPLのコードが含まれる場合、システムを利用する一般社員にソースコードを開示する必要はありません。これも、前項同様に、組織内での使用にはライセンスが適用されないためです¹²。開発に関わった人がソースコードを公開することも、やはり雇用契約の中の守秘義務に基づいて防ぐことになるでしょう。
• 一般消費者向けに販売する製品にGPLのコードが含まれる場合、開示されたソースコードを公開しないように消費者に求めることは、GPLの条文により禁止されています。この場合は、公開されると製品をメンテナンスしたり次の製品を作ったりするのが困難になるので公開しないで欲しい、と「お願い」することしかできません。

やろうとしていることに対して、本来避けなくてもよいGPLやAGPLのソフトウェアの利用を避けてしまうと、余計な遠回りになります。どういう場合には安全と言えるかを見極めて、適切に接することが大事です。

GPLなソフトウェアにコードを提供するときの一工夫

コピーレフト性を持つライセンスのソフトウェアにコードを提供した場合でも、提供した部分のコードの元々の権利は、依然として作者に帰属しています。なので、作者はGPLなソフトウェアに提供したコードを、別のライセンスで配布したり販売したりすることができます。

ただ、あなたが元々の権利者であっても、GPLなソフトウェアのほうだけを知っている人が、あなたがそのコードを非コピーレフトなライセンスのソフトウェアに組み込んだ物を見たときに、「GPL違反だ」と誤解してしまう恐れはあります。

そのような誤解を避けるよい方法としては、コピーレフトなライセンスのソフトウェアにコードを提供する前に、一旦非コピーレフトなライセンスで公開しておく方法があります。たとえば、ライブラリを一旦MITライセンスで公開して、GPLのソフトウェアに組み込む、という順番を踏めば、誰憚ることなく安心して、そのライブラリをプロプライエタリな製品でも使えます。

この方法は、「既存のOSSに対してフィードバックする」ことと同時に*「自分で管理するOSSを持つ」*ことにもつながります。プロジェクトオーナーになって初めて得られる経験はたくさんあるので、皆さんもぜひチャレンジしてみてください。

[column] コラム：受託開発とGPL

受託開発においては、新規に自社開発したソフトウェアを既存のソフトウェアに組み合わせて納品する場合がありますが、GPLでは、このような場面では自社開発部分のソフトウェアのソースコードを依頼主に開示しなくてもよい場合があります。

例として、ある特殊なハードウェアXがあり、GPLが設定されたソフトウェアYをそれに対応させるためには、Aシステム社の社外秘の独自技術に基づくライブラリZを使う必要がある、という場合を考えてみます。

　

仮に、B工業という会社が、自社の特殊な生産設備の制御のためにハードウェアXとソフトウェアYを組み合わせて使いたいと考えて、ソフトウェアYの改修をAシステム社に依頼したとします。

このとき、Aシステム社はソフトウェアY（の改造版）とライブラリZを組み合わせた物を、B工業社に納品することになります。 ここまでの解説を当てはめると、コピーレフトの性質により、「ソフトウェアY＋ライブラリZ」という1つのソフトウェア製品全体にはGPLが適用され、Aシステム社はB工業社に対してライブラリZのソースコードを開示する義務が生じるように思えます。

ですがGPLv3では、この場合にはAシステム社にはライブラリZのB工業社へのソースコード開示義務は無いとされています¹³。 B工業社はAシステム社に対して、B工業社専用の変更または実行を依頼し、且つ、その成果物を外部に漏らさないことを条件とする場合に限り、GPLの許諾条件に囚われずソフトウェアYを引き渡す¹⁴ことができます。 端的に言えば、これは「B工業社がAシステム社の助けを借りて、ソフトウェアYを私的に改造し、私的に社内で使っているだけ」というのと同じ扱いになるわけです。

GPLv2においては、そのような例外規定がありません¹⁵。 そのため、Aシステム社はB工業社に対して、「ソフトウェアYの改造版のソースコード」と「ライブラリZのバイナリ」を別々に納品し、ユーザーであるB工業社がそれらを組み合わせてビルドして使う¹⁶、という形を取る必要があるでしょう。

　

その一方で、Cシステムという会社が、顧客に売り込む自社製品の一部としてハードウェアXとソフトウェアYを組み合わせて使いたいと考えて、ソフトウェアYの改修をAシステム社に依頼した場合には、先の例外規定は当てはまりません。

このような場合は「ソフトウェアYの改造版を顧客に配布している」ことになるので、その一部として含まれるライブラリZにもGPLが適用されます。 そのためAシステム社には、Cシステム社の顧客に対してライブラリZのソースコードを開示する義務が生じてしまいます。

あなたが受託開発の会社で働いている場合、納品した最終成果物を誰が使うのかには十分に注意しましょう。

[/column]

オープンソースと自由なソフトウェア

自由なソフトウェアの定義

最後に、GPLなどのライセンスとセットで語られることの多い*「自由なソフトウェア」*という考え方についても簡単にご紹介しておきます。

自由なソフトウェア（Free Software）は、「オープンソース」の元になった考え方です。日本語圏では「自由ソフトウェア」や「フリーソフトウェア」とも表記されますが、「フリーソフトウェア」と書くと「無料のソフトウェア」という意味の「フリーソフト」と混同されかねないので、本書では「自由なソフトウェア」で統一することにします。

どういう物を自由なソフトウェアと呼ぶかについては、Free Software Foundation（FSF）が主宰するGNUプロジェクトのWebサイトに記載があり、以下の4つの必須条件を備えるものとして定義されています。

• ソフトウェアを目的を問わず使える自由があること。（第0の自由）
• ソフトウェアを研究し、改造する自由があること。（第1の自由）
• ソフトウェアの複製を再配布する自由があること。（第2の自由）
• ソフトウェアの改変版を再配布する自由があること。（第3の自由）

第1と第3を実現するためには、ソフトウェアのソースコードが必要です。そのため、これらの条件から演繹的に「ソースコードが提供されること」という条件も導かれます。

条文には「オープンソースの定義」と似通った部分があると感じる人もいるでしょう。これは、オープンソースの定義の元になっている「Debian Free Software Guideline（DFSG）」という文書が、自由なソフトウェアの概念を参考に書かれたためです¹⁷。

オープンソースと自由なソフトウェアの違い

定義の内容から、ほとんどのOSSは自由なソフトウェアの条件を満たします¹⁸し、自由なソフトウェアの多くはOSSでもあると言えます¹⁹。どちらも「ソースが公開される」点は共通しており、見方によってはほとんど違いが無いようにも見えます。

ただし、両者は目的がまったく異なっています。比較しやすいように対置すると、以下のようにまとめられます。

• オープンソース：ソフトウェアの品質を高めるために、ソースを公開する。
• 自由なソフトウェア：ユーザーの自由を高めるために、ソースを公開する。

目的が異なるため、それぞれの立場を極端に突き詰めると、次のようにも言うことができます。

• オープンソース：品質を高めることが第一なので、ユーザーが不自由を強いられることがあっても仕方ない。（これは市場経済ではありふれたこと。）
• 自由なソフトウェア：ユーザーの自由を高めることが第一²⁰なので、ソフトウェアの品質が今ひとつでも仕方ない。（ただし、品質の悪いソフトウェアは魅力的でなく、ユーザーに使われないことになり、自由が保障された世界の実現が遠のくので、品質は可能な限り高いに越したことはない。）

この2つを比較したとき、自由なソフトウェアという考え方は、短期的な・経済的なメリットよりは、中～長期的な・文化的なメリットのほうに重点を置くもので、より社会運動的な性質が強いと言えるでしょう。

自由の意義

ここまでの本書の語り口と照らし合わせて気が付いた方もいらっしゃるかもしれませんが、実のところ筆者は、「オープンソース」だけよりは、「自由なソフトウェア」として語られるものまでを含めて推進したい²¹立場と言えます。

筆者自身は、当初は「みんなで製品の改善に協力できるって素晴らしい！」と考えて（まさに上記の「オープンソース」の理念に価値を感じて）、MozillaやFirefoxに関わっていました。そうして自分が感じた細かな不満・つまずきを、自分の努力で解消する経験を重ねる中で、筆者は徐々に、自分の手で物事を良い方向に変えられる自由があること自体に意義を感じるようになってきました。

そして冷静に振り返ってみると、身のまわりにこの分野の知識を持つ人がおらず、教えてくれる人に接触する術も無かった筆者にとって、学びはソフトウェアそのものから得るしかなかったのは事実です。ソフトウェアのソースコードを自由に触れなければ、筆者は「学ぶこと」すらままならなかったと言えます。

　

*「ソフトウェアから学びを得る自由」*をくれた人達がいたおかげで、筆者は、「自分で物事を変えていける自由」を手に入れられました。そのような体験を持つ筆者にとって、DRMやクラウドによって重要なことが手の届かないところに隠され、自由がどんどん遠のいていくことには、残念な思いを抱かずにはおれません。

囲い込み戦略には、それによって莫大な利益を上げるプレイヤーが生まれ、その利益を元に先進的な研究開発がなされることで、より文化や技術が発展する、という側面があることは事実です。

しかし、それが行き過ぎると、世の中を良くすることに関わりたければ大プレイヤーの一員になるしかなく、その選別に漏れた人には下働きしか道がない、ということにもなりかねません。そのような時代に生まれていたら、さして頭の出来が優秀でもない筆者は、恐らく「選別に漏れた側」にしかなり得ず、今のように自由を謳歌できはしなかったでしょう。

本書を読まれた方の中には、OSSといえばGAFA²²のような大企業や、そうでなくとも大いに儲かっている先進企業が作ってくれる物をありがたく使うものだ、という認識を持っていた人もいるのではないでしょうか。実際にそのような声を見かけたことが、実は筆者にとっての、本書執筆の最大の動機でした。

筆者は、このような状況の中で敢えて自由なソフトウェアを推進することが、後に続く人達への*「恩送り」*だと考えています。ですので、本書をご覧になったあなたにとって、もしこれが自由の価値に目を向ける機会となり、さらなる自由を手に入れるきっかけとなってくれれば、それに勝る喜びはありません。

そして、あなたが自由を手に入れて「つよいエンジニア」になられたときには、ぜひとも、後に続く人へも自由のバトンを渡して頂ければと思います。

Footnotes

1. 日本の著作権法上は、単純に消費者として本を読んだり絵を見たりする「使用」と、商売として本を売ったり新たな表現として絵を別の絵に貼り込んだりする「利用」とを区別して考えます。 ↩

2. ただ、それを買ってもらえるかどうかは別の話です。あなたが高値を付けて販売している横で、別の人が無料で同じ物をばら撒いていたら、恐らく多くの人は無料のほうに行くでしょう。買ってもらうためには、「こっちで売ってる物は綺麗な装丁になってますよ」「こっちで買ったら読み上げ音声も付けますよ」といった風に、お金を出してでも手に入れたくなるような付加価値が必要になってきます。「OSSのサポートビジネス」は、まさにその付加価値を売る商売と言えます。 ↩

3. 日本語訳 https://ayatakesi.github.io/emacs/26.2/html/Copyright-Assignment.html 、原文 https://www.gnu.org/software/emacs/manual/html_node/emacs/Copyright-Assignment.html ↩

4. これは、「改変したソースの配布は禁止するが、元のままのソースと、改変するための差分（パッチ）の配布は認める」というソフトウェアを想定しています。具体的には、TeXの実装がこれにあたります。 ↩

5. これを厳密に解釈すると、後述する「雇用契約の中の守秘義務によってソースコードの拡散を防ぐ」運用も問題になりそうなのですが、この条文自体は「そのソフトウェアを使いたいがために追加の契約を結ばされる」ケースを想定したものと考えられますので、ソフトウェアの存在を知るより前に雇用契約が存在するケースは対象外になるのではないか、と筆者は考えています。 ↩

6. 「ライク」が付かない「2条項BSDライセンス」は載っています。なお、実際のライセンスの内容を確認すると、「文面は2条項BSDライセンスとほぼ同じで、一部のみ記述が異なる」という物になっており、許諾されている内容には、ほぼ違いは無い様子でした。そもそも「BSDライセンス」とされているライセンス文は、OSIのWebサイトで確認できる物と細かい文言が異なるバリエーションが多数出回っていることから、これらのバリエーションやBSDライクライセンスについて、BSDライセンスと同一と見なす考え方を取る人もいます。 ↩

7. FSFは、さまざまな既知のライセンスについて、FSFの自由なソフトウェアの定義に合致するかどうかの見解を公表しており（ http://www.gnu.org/licenses/license-list.html ）、いくつかのライセンスは「これは自由なソフトウェアのライセンスではない」と明記されています。しかし、OSIの「オープンソース」とは異なり、「このリストに記載が無いライセンスが設定された物を自由なソフトウェアとは呼ばないように」とまでは求めていないようです。 ↩

8. LGPLはC言語などのコンパイル型の言語を想定して策定されているため、ここでの想定は「DLLや.soのように、実行時に動的に読み込む場合は、ライブラリとしての呼び出しにあたる。配布される1つのバイナリの中に静的に組み込む場合は、派生物にあたる」ということになっています。 ↩

9. そのプロジェクトが非コピーレフトなライセンスをわざわざ選択していることには、非コピーレフトでないといけない理由がある、と考えられるからです。たとえば、Appleは自社製品にソフトウェアを組み込む上で都合がいいという理由もあって、非コピーレフトなライセンスのプロジェクトに色々とコントリビュートしていますが、それらがコピーレフトになってしまうと、Appleのような企業からの支援を受けられなくなってしまうでしょう。 ↩

10. 前述のオープンソースの定義において、機密保持契約などライセンス外の契約と引き替えにソフトウェアを提供するような契約形態は、オープンソースとは呼べないとされています。そのため、このこと自体を条文に含めているOSSライセンスもあります。ただし、守秘義務を含む雇用契約を結んだ後で、業務の一環としてOSSを受領した場合には、「ライセンス外の契約と引き替えにソフトウェアを提供している」わけではないため、この制約の影響を受けないと考えられます。 ↩

11. GNUライセンスに関してよく聞かれる質問 https://www.gnu.org/licenses/gpl-faq.html#InternalDistribution ↩

12. Understanding the AGPL: The Most Misunderstood License https://medium.com/swlh/understanding-the-agpl-the-most-misunderstood-license-86fd1fe91275 ↩

13. IPAによるGPLv3逐条解説 4.2.2.（42ページ） https://www.ipa.go.jp/files/000028320.pdf ↩

14. このようなケースをGPLv3の条文では「convey」と呼び、「distribute（配布）」と区別しています。 ↩

15. IPAによるGPLv3逐条解説には「GPLに関するFAQにおいて、上記のような（略）納品行為は配付（略）に当たらないとの解釈を公開することで対処していた」と記載されていますが、筆者が当該文書（日本語訳 https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html 、原文 https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html ）を確認した限りでは、2021年10月現在、そのように読める記述は見つけられませんでした。 ↩

16. この場合も、B工業社はあくまで「ソフトウェアYの私的な改造版（ライブラリZを含む）を、社内で私的に使っている」だけなので、ソースコードの開示義務が生じる「配布」にはあたらないことがFAQで明記されています。（日本語訳 https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#InternalDistribution 、原文 https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#InternalDistribution ） ↩

17. FSFは1986年の設立時点ですでに、第1から第3までの自由を含む「自由なソフトウェア」という概念を公表していました。しかし、少なくとも1996年頃までの間は、このことはFSFの活動趣意書（ http://www.gnu.org/bulletins/bull1.txt ）などで「FSFの名前に含まれる自由という言葉の意味は～」とさりげなく語られているに留まっていたようです。そのような状況下で、Debianプロジェクトがこの概念を条文形式に整理しつつ、さらに「使用の自由（使用者の属性や分野による差別の禁止）」も明記する形で1997年に作成したのがDFSGで、オープンソースの定義はDFSGをほぼそのまま引き写した内容となっています。その一方で、FSFも少なくとも1997年頃には、改めて第1から第3の自由を定義文として参照しやすい形式にした「自由なソフトウェアの定義」という文書を公表し、さらに1999年には「第0の自由」の項目を追加する改訂を行いました。この改訂は、DFSGやオープンソースの定義で先に明文化されていた「使用の自由」の概念を、自由なソフトウェアの定義においても明文化することで、ソフトウェア開発者達に、自由なソフトウェアをオープンソースと並ぶ選択肢として見てもらいやすくする意図があったようです。 ↩

18. 例外の具体例としては、Artistic License 1.0があります。OSIはこれをOSSライセンスと認定していますが、FSFは自由なソフトウェアのライセンスとは呼べないとしています。なお、改訂されたArtistic License 2.0であれば、FSFも自由なソフトウェアのライセンスと認めています。 ↩

19. 例外の具体例としては、パブリックドメイン相当のライセンスであるCC0やWTFPLがあります。FSFはこれらを自由なソフトウェアのライセンスと認めていますが、OSIはこのどちらもOSSライセンスとは認定していません。 ↩

20. GPLなどのライセンスのコピーレフト性は、あくまで、人や企業は自身の利益のために情報を秘匿したがるものだという悲観論を前提に、ユーザーの自由を保証するための「手段」として設定された物です。よって、ユーザーの自由が阻害されない限りにおいては、非コピーレフトなライセンスでも問題はない、というのが自由なソフトウェアの考え方です。 ↩

21. 筆者は今のところ、ソフトウェアについては、あらゆる場面でユーザーの自由が最優先されなくてはならないとまでは考えていません。そのため、自分が関わるある程度の規模のソフトウェアについては、コピーレフト性のあるライセンスを選択するよう努めつつも、細かいライブラリでは、組み合わせで悩まれないよう非コピーレフトなライセンスを選択し、また、すでに他の人によって非コピーレフトなライセンスでOSSとして公開されている物については、敢えてコピーレフトにしていくよう求めるほどではない、という立場を取っています。 ↩

22. Google、Amazon、Facebook、AppleというIT業界のビッグプレーヤー4社をまとめた呼び方。ここにMicrosoftを加えた「GAFMA」という呼び方も使われることがある。 ↩