第5回　OSI系OSSライセンスに関する一考察

この連載では、企業がオープンソースソフトウェアとうまく付き合い、豊かにしていくために最低限必要なライセンス上の知識を説明します。（編集部）

NEC
姉崎 章博
2009/11/5

　いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。

1つではないOSSライセンスの考え方（再度おさらい）

　OSSライセンスのセミナーを実施すると、意外なことに「OSSライセンスの考え方は1つに限らないことが分かった」という感想をいただくことがあります。それを踏まえて第3回では、これまで主になされてきた「要件」に基づく分類ではなく、「考え方」に基づいて、OSSのライセンスを3つに分類して紹介しました。その内容は以下のとおりです。

OSSライセンスの タイプ ProtexやRosen氏による 2分類 考え方に基づいた 3分類 BSDタイプ Permissive（寛容な、Academic）Licenses （1）アカデミック系 MPLタイプ Reciprocal（互恵の）Licenses （3）OSI系 LGPLタイプ （2）GNU系 GPLタイプ

表1　OSSライセンスの考え方（繰り返しになりますが、現実にはこの3つに分類できないOSSライセンスもあるでしょう。中には、表面的には同じような要件を備えていても「そんな考え方で作成したライセンスではない」とお怒りになる著作権者（開発者）がいらっしゃるかもしれません。ただ、ここはあくまで入門者向けの説明として、こういう分類を許していただければと思います）

　今回は、このうちOSI系ライセンスについてご紹介します。前回のGNU系と同じく、表1では「互恵のLicense」とも分類され、著作物を受け取った受領者にもソースコードの開示を条件に第三者に著作物を頒布（譲渡）する権利を与える、つまり、「ソースを受け取ったら自らもソースを与える」という互恵の関係を求めるライセンスです。これをCopyleft（コピーレフト）とも表現します。

Open Source≒Free Software≠Free Download

　オープンソースソフトウェア（OSS）の定義OSD（Open Source Definition）については、リンク先の和訳に詳しいですが、概略を並べると以下のような項目になっています。

（1）自由な再頒布 （2）ソースコードの自由な再頒布 （3）派生ソフトウェアの自由な再頒布 （4）著者のソースコードの完全性 （5）個人やグループへの差別禁止 （6）利用分野の差別禁止 （7）追加的ライセンスの禁止 （8）特定製品への依存の禁止 （9）ほかのソフトウェアへのライセンス制限の禁止 （10）許諾の特定技術への依存禁止

　こうして並べると、実は、フリーソフトウェアの定義（第3回で紹介した「ソフトウェアの4つの自由（フリー）」）にいくつかの条項を加えた構成になっていることが分かります。つまり、ほぼ同じ領域のソフトウェアを指す言葉になっているといえます。 このことは、GNUのサイトでも紹介されています（「フリーおよびフリーではないソフトウェアの分類」）。

図1　Chao-Kueiの手によるソフトウェアのさまざまな種類の図解

注1：この図から分かるもう1つのことは、「フリーソフトウェア」や「オープンソース」の中には、「フリーダウンロード」のものもあればそうでないものもある、という状態が表現されていることです。つまり、これらは常に無料とは限らないわけです。その意味で、マスコミで「無料ソフト」などと表現されるのは不適切なんですね（http://www.gnu.org/philosophy/categories.ja.html）。 注2：この図では、パブリックドメインがオープンソースと フリーソフトウェアに含まれるような形になっています。しかし、著作権を放棄したものをパブリックドメインとすると、ここでは著作権を放棄していないことを前提にしたオープンソースやフリーソフトウェアに含まれることになってしまうため、私には違和感があります。

　ほぼ同じ領域のソフトウェアを指す言葉でも、考え方の違いが言葉の違いになって表れていることがお分かりいただけると思います。前回GNU系として紹介した「フリーソフトウェア」という言葉が「自由」を第一義と考えるのに対し、「オープンソースソフトウェア（OSS）」という言葉は、皆でプログラムを共有するかのように相互交換し、共同作業により改善していくコミュニティの形態を中心にとらえ、広めようとして考えられたものととらえると、違いが分かるかと思います。

開発形態としてのオープンソース

　OSSのことをライセンスではなく開発形態として紹介した「伽藍とバザール」では、Linuxカーネルでの開発形態を例に挙げて紹介しています。

　実際の、少なくとも現在のLinuxカーネルのコミュニティは、「伽藍とバザール」でEric S. Raymond氏が書いているような無秩序なイメージによるものではなく、パッチを受け入れるための個別のメーリングリストやメンテナなどが組織され、伽藍のような体制が構築されています。しかし、それは流動的で、固定したメンバー以外からのパッチも受け入れ可能とするための体制であって、メンバー的に閉鎖的な伽藍（体制）ではありません。

　ごく簡単にいえば、「プロジェクトを最初からバザール式で始めるのはすごく難し」いため、まず誰かが核となる基本機能を開発し、一応動くものをベースにいろいろな人が開発、改造、デバッグするというものです。

図2　OSSの開発形態の概略図

　このやり方には、OSSという考え方が生まれる前からの開発者でも共感し、賛同する部分が多々あります。例えば、たとえウォーターフォールモデルの開発方式を採用していても、基本動作の実現可能性を確認するために、基本設計の工程であろうとも、基本機能を実装して動作確認し、続いてそれにどう機能を付加して目的の機能まで拡張するかを設計していく……というプロトタイピングな開発では、ユーザーインターフェイスの場面以外でも、こうしたやり方は当然のように取り入れられていたと思います。

　また、「伽藍とバザール」でいうところの「はやめのリリース、しょっちゅうリリース」（Release Early, Release Often）の効用として、「ユーザーが増えると見つかるバグも増える」が挙げられます。これは、「多くの目により、より多くのバグを発見することができる」ということですが、従来からプログラマーがデバッグで苦労していた点を「はやめのリリース、しょっちゅうリリース」で解決してしまっていることに、私は目から鱗の思いでした。

　つまり、デバッグを1人または少人数で実施していても、プログラムを見る視点が同じだと、同じ思考回路にしかなりません。そのため、プログラマが想定したロジックしかたどらない（＝バグを見逃す）リスクに常に悩まされます。こうした問題を解決するため、プログラマ本人としては（原稿を見直すときと同じように）プログラムを「寝かせて」おいたり、第三者レビューを実施したりと、あれこれ工夫を凝らします。しかし、寝かせておいても思考回路が変わらなければ寝かせた意味がありませんし、興味のない人にとっては第三者レビューは苦痛でしかありません。

　それを「はやめのリリース、しょっちゅうリリース」を行うことにより、興味のある第三者という新たな思考回路の持ち主が、デバッグや開発、改造に参加することを前提にしました。つまり、この開発形態では、新しい視点からのロジックのチェックが容易になされてしまうわけです。

図3　OSSにおいて「多くの目で見る」ことによるメリット

　実にうまいやり方だと私には思えたものです。

コラム■情報処理技術者試験での出題

今週日曜日に行われた情報処理技術者試験の中に、OSIの定義を問う問題がありました。ちょっと紹介してみましょう。 問21 OSI（Open Source Initiative）が定義しているOSSの性質はどれか。 ア　OSSとともに頒布される、ほかのソフトウェアのソースコードも公開しなければならない。 イ　OSSを再頒布する場合は、無料にしなければならない。 ウ　営利目的の企業での使用や、研究分野での使用も許可される。 エ　ソースコードを改変した場合の再頒布条件に、制約があってはならない。 解答：ウ 応用情報技術者試験（AP）午前　（スペシャリスト共通の午前�Tの問7にも同じ問題） http://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2009h21.html#21aki 解説： 　OSIのオープンソースソフトウェア（OSS）の定義（OSD）の日本語訳は、前述したURLで参照できます（注3）。 　この第6項で、「6. 利用する分野（fields of endeavor）に対する差別の禁止」が定義されており、「ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはなりません」と定義されているので、ウが正解となります。このことは、たとえ「平和目的に限る」という制限でさえ、ライセンスに付けると、OSIに認定されないということを意味しています。 　アは、GPL固有の派生物に対するGPLの伝播について説明したものでしょう。ですが、単に「ともに頒布される」だけでは、GPLv2の第2項の「一部を含む著作物」となるわけではないので、GPLの説明としても正しくありません（注4）。 　イは、OSSに対するよくある誤解です。OSSライセンス全般に「無料にしなければならない」という性質はありません。OSIの第1項でも「ソフトウェアを販売あるいは無料で頒布することを制限してはなりません」とあり、販売は認められているので、無料であることが条件ではありません（注3）。 　エは、GPL固有の制約です。GPLv2の第6項の「あなたは、受領者がここで認められた権利を行使することに関してこれ以上他のいかなる制限も課してはならない」とある条件です（注4）。 　GPLの条文は、GPLのOSSが存在するので、OSS利用者が実際に遵守しなければならない条件ですが、OSIのOSDはメタなライセンス条文なので、遵守しなければならないOSSは存在していません。 　OSDに留意する必要があるのは、主に、OSIの認定を受けたいOSSライセンスを新たに作成する人です。しかも、OSIとしてはライセンスが増えすぎた現状から、似て非なるライセンスの新設は歓迎していません。そのOSDについて問う問題は、応用情報技術者試験（AP）午前の問題としては非常に高度な気がします。 注3：http://www.opensource.jp/osd/osd-japanese.html 注4：http://www.opensource.jp/gpl/gpl.ja.html

第4回へ

1/2

Index 技術者による技術者のためのOSSライセンス入門 　第5回　OSI系OSSライセンスに関する一考察

Page 1 1つではないOSSライセンスの考え方（再度おさらい） Open Source≒Free Software≠Free Download 開発形態としてのオープンソース コラム　情報処理技術者試験での出題 　 Page 2 LinuxカーネルはGPLでもOSI系？ OSI系ライセンスの特徴 OSI系ライセンス利用時のちょっとした注意点

Linux Square全記事インデックス

---

Linux Squareフォーラム サーバ構築・運用関連記事

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）