【3/18〜】Amazon、VMwareが語る『クラウドの未来』 スラッシュドット    はてなブックマーク  Yahoo!ブックマークに登録  印刷
ライセンス

第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のサイトでも紹介されています(「フリーおよびフリーではないソフトウェアの分類」)。

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

注1:この図から分かるもう1つのことは、「フリーソフトウェア」や「オープンソース」の中には、「フリーダウンロード」のものもあればそうでないものもある、という状態が表現されていることです。つまり、これらは常に無料とは限らないわけです。その意味で、マスコミで「無料ソフト」などと表現されるのは不適切なんですね(http://www.gnu.org/philosophy/categories.ja.html)。

注2:この図では、パブリックドメインがオープンソースと フリーソフトウェアに含まれるような形になっています。しかし、著作権を放棄したものをパブリックドメインとすると、ここでは著作権を放棄していないことを前提にしたオープンソースやフリーソフトウェアに含まれることになってしまうため、私には違和感があります。

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

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

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

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

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

OSSの開発形態
図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)午前の問題としては非常に高度な気がします。

注3http://www.opensource.jp/osd/osd-japanese.html

注4http://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系列の新機能、インストール方法、国際化の現状を解説する

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

ホワイトペーパーTechTargetジャパン

Linux Square フォーラム 新着記事

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

RSSフィード

スキルアップ/キャリアアップ(JOB@IT)



- PR -
- PR -

お勧め求人情報

キャリアアップ 〜JOB@IT
@IT Special -PR-
  おばかアプリ選手権、第4弾開催中!!
ムダにカッコよくてくだらない作品求ム!

  社内ファイルサーバを“クラウド”に統合
VPN直結「クラウド型ストレージ」を紹介

  Twitterのアカウントはなぜ突破された?
メールによる新手の攻撃手法とその対策

  もう仮想化のお試しフェイズは終わりだ!
Hyper-V 2.0が基幹システムも仮想化

  美人!? まあまあ? 気になる いやし系!!
PV急増で「美人時計」がとった手段とは?

  クライアント企業から求められる人材
⇒IT技術と経営戦略を併せ持つ「戦略家」

  .NET編集長が実践する「技術情報検索術」
サンプル・コードを簡単に探す“技”は?

  業務効率と情報セキュリティ対策を両立!
手間なく確実に機密情報を守る方法とは?

  直属上司が海外にいるのエンジニアに見る
【実例】場所に捉われないワークスタイル

  「仮想化工房」のマイスターが選んだのは
VMware、Hyper-V、そしてVirtageだった!

  進化を続ける富士通ストレージETERNUS DX
製品開発者の自信を裏付けるものとは何か

  運用管理の課題を“2つの観点”から分析
ユーザー満足度の高い「仮想環境」とは?

  【CTC事例】約30の基幹システムを統合!
膨大なバッジジョブを制御した方法は?