052.1 レッスン 1

フリーでオープンなソフトウェアは、かなり前から存在しています。フリーとオープンが一緒に使用されるされることが多いですが、フリーソフトウェア ならびに オープンソースソフトウェア の正式な意味とは異なる意味で使われていることも少なくありません。先に言ってしまうと、「オープンソース」は誰でもソースコードを見ることができるということだけを意味するのではありません。それは「ソース アベイラブル ソフトウェア」です。フリーでオープンなソフトウェアには、それ以上の意味があります。

フリーでオープンなソフトウェアの対極にあるソフトウェアは、プロプライエタリソフトウェア あるいは クローズドソース と呼ばれます。この章では、それらが「自由」に関してどう異なるかを説明します。

おそらく最も多く引用されるフリーソフトウェアの定義は次のものです。

以下の節では、この発言の背後にある深い事情を掘り下げます。

ソフトウェアの開発者は、自分のソフトウェアを販売する手間と利益を放棄して、ソフトウェアを無料で配布することができます。このソフトウェアは、ビール飲み放題と同じように無料だという意味で、"free"（フリー）です（訳注：英語のfreeには、「無料の」という意味と「自由な」という意味があります）。無償配布のソフトウェアを利用する場合、背後にあるライセンス条件について気を配り、自分の義務に注意を払う必要があります。例えば、ソフトウェアを無償で入手したとしても、そのソフトウェアに変更を加えて再配布することは禁止されているかもしれません。

さらに、開発者は自分のソフトウェアを、ストールマンが言う意味での「フリーソフトウェア」にすることもできます。ストールマンが1980年代に生み出した「フリーソフトウェア」という用語は、ユーザーが以下の4つの自由を持っていることを意味します。

このように定義される「フリーソフトウェア」を提唱したフリーソフトウェア財団（Free Software Foundation）は、フリーソフトウェアのライセンスの特徴を言い表す言葉として、コピーレフト （Copyleft）という用語を提唱しました。コピーレフトは法律用語ではなく、哲学的な立場を表す用語です。（訳注：コピーレフトはもちろん著作権（Copyright）のもじりでもあります。）

1990年代後半に、フリーソフトウェア運動の中から、フリーソフトウェアをわかりやすくして運動外の人たちにも普及させようとする人たちが登場して、オープンソース という呼び方を提唱しました。非営利財団として オープンソースイニシアティブ （Open Source Initiative）が1998年に設立され、Linuxカーネル開発者のリーナス・トーバルズがその理念を支持しました。オープンソースイニシアティブは、オープンソースを以下のように定義しました。（訳注：タイトルは「オープンソースの定義」ですが、内容は「オープンソースライセンスが満たすべき条件の定義」であることに注意してください。間接的に定義することで、オープンソースライセンスの多様性に資しています。）

（1〜10は、オープンソースの定義 (v1.9) 注釈無 – Open Source Group Japan – オープンソース・グループ・ジャパン https://opensource.jp/osd/osd19plain/ より引用）

フリーソフトウェア財団は、自由が目標であることが明確にならないことから「オープンソース」という用語を支持しませんでした。フリーソフトウェアとオープンソースソフトウェアの提唱者は同じ理念を追求しているように見えますが、目指すものが異なります。単純化すると、フリーソフトウェアは開発者とユーザーの権利を重視するのに対し、オープンソースソフトウェアはそのソフトウェアが普及して成功することを重視します。

ほとんどのフリーソフトウェアはオープンソースソフトウェアでもありますが、オープンソースソフトウェアがフリーソフトウェアであるとは限りません。OSIのオープンソースソフトウェアのほうが、FSFのフリーソフトウェアよりも範囲が広いからです。

フリーソフトウェアとオープンソースソフトウェアの違いは、内容よりも目標に関わるものであり、どちらも広く普及しているので、フリーでオープンなソフトウェア（FOSS）や フリーで自由でオープンなソフトウェア （Free/Libre Open Source Software）と総称する人もいます。FLOSSのLは、多くのロマンス語で自由を意味する "libre" です。

FOSSと総称されるソフトウェアとプロプライエタリなソフトウェア以外にも、いろいろなソフトウェアの配布形態が存在します。そのうちのいくつかを紹介します。

何よりもまず、あるソースコードやプロジェクトにライセンス情報が記載されていなかったとしても、著作権がないと想定することはできません。実際はその逆で、1887年来、世界中のほとんどの国が ベルヌ条約 に署名しているため、著作権が自動的に発生します。

この条約の署名国は、文学的及び美術的著作物が存在すると同時に（別の言い方をすると媒体に「固定化」されると同時に）著作権で保護されることに同意しています。著作者が著作権の登録や申請を行う必要はありません。著作権の登録や申請を行うことができる国があり、合衆国などいくつかの法域では著作権侵害訴訟を提起するためには登録が必要になります。

また、署名国は、他の署名国の著作者の著作権を尊重することに同意しています。この条約の署名国は、2022年11月現在、世界195カ国のうち181カ国に上ります。

しかし、創作物がすべて著作権で保護されるわけではありません。著作権で保護される 著作物 の資格を満たすには、いくつかの基本的な基準をクリアしなければなりません。例えば、事実やアイデアは著作権で保護されませんが、アイデアを説明する文章は、一定の オリジナリティ があれば、保護される可能性があります。必要とされるオリジナリティの度合いは国によって異なりますが、概してその基準はとても低いです。オリジナリティがあり著作権で保護される作品を制作するために人工知能（AI）をどの程度使用できるかについては、多くの法域で議論されているところです。

法域によっては、コンピュータプログラムが文学的著作物として著作権で保護されます。アイデアやアルゴリズムに著作権は発生しませんが、アイデアやアルゴリズムを「実装した」ソースコードには発生するということです。

著作権は、著作者に、著作物を複製、改変、再実施、頒布、公表する排他的な権利を与えます（訳注：Copy-rightの綴り通り、複製を印刷する権利が著作権の出発点です）。本を読んだり、音楽をラジオで聴いたりといった「著作物を鑑賞する（受け入れる）行為」に、作者の許諾（ライセンス）は不要です。

著作者の権利は登録しなくても発生しますから、著作物の複製、改変、再実施、頒布、公表を行おうとする人は、事前に著作者の許可を得なければなりません。ライセンスとは、著作者とその著作者の排他的な権利を行使することを望む別の人（たとえば出版社やレコードレーベル）との間の契約に他なりません。

FOSSライセンス自体は誰でも無料で利用できますし、別の独自のライセンスを編み出してOSIやFSFに認証してもらうこともできます。ただし、広く受け入れられていてユーザーがその内容と義務を理解している、既存のFOSSライセンスを利用することが推奨されています。実際のところ、FSFやOSIが認証しているライセンスのうち、一般的に使われているのはひと握りのライセンスだけです。

アイデアを保護しない著作権とは対照的に、特許は機械等に固定化していなくても発明（アイデア）を保護します。発明者が保護を求める国ごとに特許の出願を行って登録しなければならない点も、登録なしに自動的に発生する著作権と異なります。

このレッスンでは、特許法とその要件に深入りはせず、重要な点を指摘するにとどめます。特許で保護されるためには、アイデアが何らかの技術的側面を有していなければなりません。歴史的に見ると、新しい料理のレシピやボードゲームは特許の保護要件を満たさない一方、新しい調理器やゲーム機は特許の保護要件を満たし得ます。

コンピュータプログラミングの文脈では、ソフトウェアが特許で保護されるかどうかが問題になります。その答えは法域とアプリケーションの両方によって変わります。例えば、ドイツでは、コンピュータプログラム自体は特許の保護対象から全般的に除外されています。それでも、車の自動ブレーキシステム制御ソフトウェアのようにプログラムが物体と一体化されると、ソフトウェア自体ではなくブレーキという物理的な構成要素を含むアプリケーション（応用）が特許の保護対象になり得ます。

アメリカ合衆国のような別の法域では、判例法の展開次第で、コンピュータプログラム自体に特許が認められる可能性があります。

日本の特許法では、プログラムが特許保護の対象となる物に含まれると明記されています。

特許の保護という概念は、FOSSライセンスにも関係します。たとえばGPLv3は、ソフトウェアを安心して使用できるように、特許の実施権をユーザーに明示的に与えることを求めているライセンスです。他方で、BSD3項ライセンスのように、特許への言及がまったくないライセンスもあります。また、クリエイティブコモンズライセンスのように、特許を明示的に除外しているライセンスもあります。状況によっては、特許実施許諾が暗黙のうちにライセンスに含まれていることがあるかもしれません。

オーディオデバイスのソフトウェアのように、装置に組み込まれたソフトウェアを扱う際には、そのソフトウェア作成者の特許を確認するなどして、特に特許に注意してください。

先に述べたように、ライセンスは、著作者とその著作者が有する排他的権利を行使することを望む人との間の契約です。GPLv2やGPLv3のような広範囲に及ぶFOSSライセンスでは、契約の終了についても規定されています。FOSSライセンスでは、中心となる使用や頒布などの自由に関する権利が、必ず認められています。通常、以下のような権利が明記されています。

ライセンススチュワード（License stewards）とは、ライセンスのバージョンを管理する人または組織です（個人のこともありますが、FSFのような組織であることが多いです）。例えば、GPLv2の第9条では、FSFがライセンススチュワードであると規定されています。

ライセンスに関するよくある質問（FAQ）を公表しているライセンススチュワードもあります。ライセンシー（被許諾者）がライセンサー（許諾者）にコンタクトを取る糸口として有用でしょう。

開発者が別のプロジェクトからコードを借用して自分のプロジェクトに組み込むと、派生作品 が誕生します。コードを組み込むには何らかのソフトウェア開発技術を用いることになり、全体がどうなるかはプロジェクトとライセンスによってさまざまですが、ライセンスに適合するようにコードを組み込む必要があります。

派生作品に関して最も重要な点は、GPLのようなコピーレフトのライセンスでは、派生作品も同じライセンスで公開しなければならないことです。そのようなライセンスを 互恵的（reciprocal）な ライセンスと呼ぶことがあります（訳注：この言い方は日本ではほとんど使われていません）。

自分のプロジェクトにGPLのコードを組み込んだ派生作品を公開する場合は、ソースコード全体を公開しなければならないので、ほかの人はそのソースコードからソフトウェアをビルドできるようになります。コピーレフトライセンスが直接的に要求するのはこういうことです。自由なライセンスを広めたい開発者にとっては非常に好都合です。しかし、コピーレフトライセンスであるが故にGPLを避ける開発者も少なくありません。

ほかの多くのオープンソースライセンスは、派生作品を同じライセンスで公開することを求めません。そうしたライセンスを パーミッシブ（permissive、許容的）な ライセンスと呼びます。

もしも頒布時にライセンス条件を満たしていなければ（例えば、GPLv3ライセンスのソフトウェアをソースコードを公開せずバイナリ形式で頒布することはライセンス条件を満たしていません）、ライセンス契約に違反することになります。その結果どうなるかはライセンスにより異なります。例えば、GPLv3ライセンスに違反すると、ライセンス契約が終了します。そうすると、ソフトウェアの頒布など、著作者の許可が必要な行為は、著作権侵害になってしまいます。

ある会社がGPLv3ライセンスのソフトウェアを自社製品に使い、ライセンスに違反すれば、その製品の回収を請求する民事訴訟が起こされるかもしれません。故意による著作権侵害には刑事罰が課される可能性もあります。

ライセンシーに違反状態を是正するために30日の猶予を与える特別な条項を備えているライセンスがあります。猶予期間内にライセンスの条件を満たすことができればライセンスは回復します。

大規模なソフトウェアプロジェクトでは、要件が異なるライセンスのソフトウェアを組み合わせることがよくあります。そうしたプロジェクトで、派生作品に同じライセンスを要求するコピーレフトのソフトウェアを使うと、困難に直面する可能性があります。コピーレフトライセンス間で条件に違いがあり、互換性がないことがあるのです。互換性のない複数のコピーレフトライセンスのソフトウェアを組み合わせた場合、それを公開または頒布すると必然的にどれかのライセンスに違反してしまうのです。

別のコピーレフトライセンスと統合する際の便宜を図るために、FSFはGPLと互換性のあるライセンスのリストを公表しています（さまざまなライセンスとそれらについての解説 https://www.gnu.org/licenses/license-list.html ）。

たいていのパーミッシブなライセンスは、ほかのライセンスと互換性があります。例えば、MITライセンスをGPLv3ライセンスのプロジェクトに統合しても、ライセンス違反について心配する必要はありません。しかし、GPLv3ライセンスをMITライセンスのプロジェクトに統合すると、GPLv3の条項に違反するでしょう。このように、互換性が双方向的であるとは限りません。

開発者と法律顧問は、ソフトウェア製品を市場に投入する前にライセンスの互換性を綿密に調査して、ライセンス違反を避けなければなりません。オープンソースのコンプライアンス管理は、あとでライセンスに互換性がないことが判明してプロジェクトを遅延させることのないように、ソフトウェア開発の初期の段階で実施すべきです。ソフトウェアコンポーネントのライセンス互換性チェックするツールなどを使用するとよいでしょう。

同じソフトウェアが異なる複数のライセンスで提供されていることがあります。例えば、ライセンサーが、あるプロジェクトを、GPLv3とプロプライエタリの両方のライセンスで提供していることがあります（デュアルライセンス）。ライセンシーがそのプロジェクトのコードを自分が開発するプロプライエタリな製品に統合するのであれば、プロプライエタリ版を利用します。このプロジェクトのコードを利用する開発者は、GPLv3によって課される条件を守るか、それとも（多くの場合ライセンス料を支払って）プロプライエタリ版を入手するかを決めます。

先ほど述べたように、一つのソフトウェアにライセンス条件が異なる複数のコンポーネントが含まれることがあります。互換性が問題とならないライセンスが多いですが、ソフトウェアの部分ごとに要件の異なるライセンスが付されていることがあることに注意しましょう。