1.3 レッスン 1

フリーソフトウェアといった場合の “フリー” は、 “無料” とは何の関係もありませんと、Free Software Foundation（FSF）の創設者であるRichard Stallmanは、簡素に述べています:

支払いが必要かどうかは関係なく、フリーソフトウェアを定義する4つの基準があります。Richard Stallmanは、これらの基準をゼロから数える “4つの基本的な自由” と表現しています。

この「ソフトウェアの自由」という考え方は、ソフトウェアを独占して閉じ込めておくために、想定される自由を制限することに対して、一貫して反対するものです。フリーソフトウェアとは対照的に、そのようなソフトウェアを プロプライエタリ （proprietary/独占的）と呼びます。

多くの場合、フリーソフトウェア と オープンソースソフトウェア は同義語です。頻繁に使用される略語 FOSS （Free and Open Source Software）は、この同義性を強調しています。 FLOSS （Free/Libre and Open Source Software）は、英語以外の言語でも自由の概念を間違いなく強調する、もう1つのポピュラーな用語です。ただし、両方の用語の起源と推移を考えると、両者を区別する価値があります。

フリーソフトウェア という用語は、Linuxが登場するほぼ10年前に、Richard Stallmanと彼が1985年に設立したGNUプロジェクトが述べるところの「4つの自由」に由来します。“GNUはUnixではない” というスローガンは、GNUプロジェクトの目的を明確に説明します。GNUは、技術的に説得力のあるソリューション、つまりUnixオペレーティングシステムをスクラッチから開発し、公共のものとして公開することと、継続的に公共のものとしてと維持することを目指して始まりました。ソースコードの公開は、技術的および組織的に、この目標のために必要な事柄です、しかしながら、フリーソフトウェア運動は、そのイメージから、社会的 かつ 政治的、時にはイデオロギー的な運動でもありました。

Linuxの成功、インターネットおけるコラボレーションの可能性、そしてこの新しいソフトウェアコスモスに出現したたくさんの企業やプロジェクトなどから、（フリーソフトウェアの）社会的側面は背景へと後退しました。ソースコード自体のオープン性は、技術的な必要なことから特徴のひとつに変化し、ソースコードが閲覧できるソフトウェアは “オープンソース” と呼ばれるようになりました。社会的な動機は、ソフトウェア開発の実用的なアプローチに道を譲ったのです。（訳注：ソースコードを公開してプロジェクトへの参加者を広く募ることが、ソフトウェアの開発と普及に有用であるという考え方が登場して広く受け入れられたため、GNUのイデオロギー的な側面は2次的なものと考えられるようになったということである。）

世界中の個人やプロジェクト、企業による運用という点において、フリーソフトウェアとオープンソースソフトウェアは同じ方法を取ります。しかしながら、前者は社会的な方向性を、後者は技術的な実用性を目指しているため、時には対立が生じる場合があります。これらの矛盾は、共同作業の結果が両方の運動の本来の目的に対応していない場合に発生します。これは特に、ソフトウェアがソースを公開しているけれどもフリーソフトウェアの4つの自由を尊重しない場合、たとえば、開示、変更、または他のソフトウェアコンポーネントとの接続に制限がある場合に発生します。

ソフトウェアを使用、配布、変更するに当たって、どのような条件に従う必要があるかを決定するのが ライセンス です。要件と動機が大きく異なることががあるため、FOSS領域では無数のさまざまなライセンスが作成されています。フリーソフトウェア運動の原理主義的なアプローチにより、多くのオープンソースライセンスが “自由” とは認められず、拒否されたことは驚くに当たりません。逆にいえば、はるかに実用的なオープンソースのアプローチでは、原理的なアプローチを受け入れることができません。

では、ライセンスの非常に複雑な側面について概観していきましょう。

すでに述べた Free Software Foundation （FSF）が、自由ソフトウェアの最も重要なライセンスの1つとして策定した GNU一般公衆ライセンス （GNU General Public License/GPL）は、Linuxカーネルなどの多くのプロジェクトで使用されています。FSFはまた、特定の場合に応じたカスタマイズを行ったライセンスをリリースしました。GNU Lesser General Public License（LGPL）は、変更点を一般に公開する必要がないソースコードと、コードを変更した自由ソフトウェアとの組み合わせを管理します。 GNUアフェロー一般公衆ライセンス（GNU Affero General Public License/AGPL）は、ホスティングされたソフトウェアへのアクセスを販売する場合をカバーします。 GNU自由文書ライセンス（GNU Free Documentation License/FDL）は、自由の概念をソフトウェアのドキュメント向けに拡張します。また、FSFは、第三者によるライセンスに対する推奨や反対を表明すると共に、GPL-Violations.orgのような関連プロジェクトで、自由ライセンスへの違反を調査しています。

FSFは、改変版のソフトウェアにも自由ライセンスが適用されるという原則を コピーレフト（copyleft）と呼ぶことで、自らが拒否する著作権（copyright）による制限と逆であることを強調しています。将来の改変されたソフトウェアについても、可能な限り自由が制限されることがないように、ソフトウェアライセンスのリベラルな原則が引き継がれるというアイディアです。

これは単純で明快に聞こえますが、その後のバージョンに引き継がれることによって、実際にはかなりの複雑化を招きます。評論家がコピーレフトの原則をしばしば “バイラル” （viral: ウイルスのように広まるの意）と呼ぶ理由です。

たとえば、2つのソフトウェアコンポーネントが、それぞれ異なるコピーレフトライセンスに基づく場合、両方のライセンスを同時に後続のソフトウェアに引き継ぐことができないため、それらのコンポーネントを組み合わせることができない場合があると言われています。これは、あるライセンスの異なるバージョンにもあてはまります。

このため、新しいライセンスまたはライセンスバージョンでは、コピーレフトをそれほど厳密に適用していないことがよくあります。すでに述べた GNU劣等一般公衆ライセンス （LGPL）は、自由なソフトウェアと、 “不自由な” コンポーネントを含むソフトウェアを、 ライブラリ化 と呼ばれる方法によって組み合わられるようにするための譲歩です。ライブラリには、他のさまざまなプログラムから呼び出して使用される、ルーチンやサブルーチンが含まれています。プロプライエタリなソフトウェアが、自由なライブラリからそのようなサブルーチンを呼び出すという状況は、ごく一般的です。

ライセンスの競合を回避するもう1つの方法は、 デュアルライセンス と言って、1つのソフトウェアを、自由なライセンスと、プロプラエタリなどの異なるライセンスで提供することです。典型的な使用例は、コピーレフトの制限を尊重する場合にのみ使用できる無料バージョンのソフトウェアと、開発費用に充てる料金と引き換えにある種の制限を解除する別のライセンスの下で入手できるソフトウェア（訳注: つまり有料版）を提供することです。

したがって、他のプロジェクトとの連携、他のコンポーネントとの組み合わせ、製品がいずれ依存するであろう設計などを考慮して、ソフトウェアプロジェクトにおけるライセンス選択には、十分な注意が必要です。コピーレフトは、この点において、開発者に特別な課題を提示します。

オープンソース側では、1998年にEric S. RaymondとBruce Perensによって設立された オープンソースイニシアティブ（Open Source Initiative/OSI）が、主にライセンスの問題を扱っています。ソフトウェアライセンスが、オープンソースの定義 に準拠しているかをチェックするための標準的な手順も定めました。現在、80を超えるオープンソースライセンスが、OSIのWebサイトに掲示されています。

ここでは、 “OSI承認済み” のラインセンスとして、コピーレフトの原則とは相容れないライセンス、特に BSDライセンス グループのものを掲示しています。 BSD （Berkeley Software Distribution）とは、もともとはカリフォルニア大学バークレー校で開発されたUnixオペレーティングシステムの一種で、後に NetBSD、FreeBSD、OpenBSD などの無料プロジェクトに繋がるものです（訳注: より幅広く、同校のComputer Systems Research Group (CSRG) が開発・配布したソフトウェア全体を指すこともある）。これらのプロジェクトの基礎となるライセンスは、しばしば パーミッシブ （permissive: 寛容な）と呼ばれます。コピーレフトライセンスとは異なり、改変版の使用条件を定めることを目的としていません。むしろ、ソフトウェアの改変者自身が改変後のライセンスを定めることができるといったように、自由を最大化することこそが、ソフトウェアの普及を促進するという考えです。例えば、ソースコードを公開せず、商業的に配布できるものとして扱うこともできます。

二条項BSDライセンス （ FreeBSDライセンス ないし Simplified BSDライセンス とも言う）は、ライセンスをどこまでパーミッシブにできるかを示しています。ソフトウェア利用による損害請求から開発者を守るための標準的な免責条項に加えて、わずか2つの規則のみで構成されます。

FLOSSの開発コンセプトの成功とそれに関連する技術の進歩は、非技術的な他の分野にもオープンソースの原則を移転しようとする試みに繋がりました。複雑なタスクを解決するために創造的に協力しあい、知識を統合して提供することは、オープンソースの原則をコンテンツ関連に拡張したものと考えられています。

そのために、作業結果を共有して加工できるように、これらの領域において信頼できる基盤を作成する必要が生じました。既存のソフトウェアライセンスはこの分野にはほとんど適していませんでしたから、“オープンソースの精神” に基づく科学的作業を、デジタル化された創作作業に当てはめるための手軽なライセンスにまとめるたくさんの試みが登場しました。

今日、この領域においては、クリエイティブ・コモンズ（Creative Commons/CC）が主導権を得ていて、その任務を次のように説明しています。

クリエイティブ・コモンズでは、権利の割り当ての中心は、配布者（ディストリビューター）から作者に戻ります。例えば、従来の出版では、作者は通常すべての出版権（印刷、翻訳など）を出版社に譲渡し、出版社は作品の配布にベストを尽くします。インターネットによる販売チャンネルの大幅な変更により、作者はこれらの出版権の多くを自分で行使し、自分の作品をどのように使用するかを自分自身で決定することができるようになりました。クリエイティブ・コモンズは、これを行う簡単かつ法的に有効な機会を提供しますが、それだけではありません。作者に対して、交流と協力のプロセスに作品を提供することを推奨します。旧来の著作権では、作者にすべての権利が与えられて、必要があればそれを他の人に譲渡することができますが、クリエイティブ・コモンズのアプローチは対照的なものです。作者は、作品をコミュニティに提供しますが、作品を使用する際の条件を、いくつかの中から選択します。多くの条件を選択するほど、ライセンスは制限的なものになります。

CCの “ライセンスを選択する” 方法は、個々の権利について段階的に作者に尋ねて、推奨されるライセンスを提示します。作者は、アイコンとテキストを使って、そのライセンスを作品に割り当てます。

正しく理解するために、CCが提供する6つの組み合わせとライセンスの概要を以下に示します。