オープンソース三つ巴

オープンソースソフトウェアセミナー

2004/09/11

日本Linux協会

野首貴嗣

knok@linux.or.jp

takatsugu.nokubi@toppan.co.jp

Agenda

なぜ「三つ巴」?

オープンソースの背景

オープンソースのメリット

オープンソースの例

オープンソースは常に善か?

「三つ巴」

オープンソースソフトウェアにおけるプレイヤー

開発者

利用者

配布者

これら三者間のバランスをとったものが「オープンソースソフトウェア」(OSS)

関係図

歴史的背景

ディストリビューション Debian GNU/Linux

Debian Free Software Guidelines(DFSG)を策定

Bruce Perens による

「配布者」としての立場から、三者のバランスを考えた「フリーソフトウェア」のガイドライン

どんなバランスをとっているのか

利用者はできるだけ自由に使いたい

配布者はできるだけ制限なく配布をしたい

開発者は思惑がさまざまなので後述

DFSGからオープンソースへ

ビジネスプロモーションの必要性

「フリーソフトウェア」はFSFが定義している

FSFとは異なる概念に基づく造語「オープンソースソフトウェア」を作った

Open Source Initiative (OSI)発足

Bruce Perens, Eric Raymond等が初期メンバー

DFSGを踏襲したThe Open Source Definition (OSD)を策定

「オープンソースソフトウェア」の定義

http://www.opensource.org/docs/definition.php

http://opensource.jp/osd/osd-japanese.html

The Open Source Definition

定義の概要

自由な再頒布

ソースコードを含む再頒布

派生の許可

作者によるソースコードの完全性を認める

個人、グループ、利用分野による制限の禁止

利用分野による制限の禁止

再配布時に新たなライセンス追加を禁止

特定製品でのみ有効なライセンスの禁止

他のソフトウェアを制限するライセンスの禁止

特定のインターフェースに依存したライセンス表示の禁止

開発者の思惑

広く使われて欲しい

自由に改変したい

ソースコードをみて学習したい

開発に積極的に協力して欲しい

クレジットをきちんと残して欲しい

ソースの同一性を保持したい

これらのバランスをとるのに苦労(OSD 3,4)

その他いろいろ

利用者のメリット

他人から譲り受けられる(OSD 1)

どんな人でも利用できる(OSD 5,6,10)

人種、宗教などを問わない

商業活動に使ってもよい

シュリンクラップ契約のような形態のみでのライセンス表示はだめ(OSD 10)

音声合成など、ライセンスを別の形態に変換可能

ポップアップなどのような特定のインターフェースに依存することも禁止

開発者のメリット

ソースコードを請求できる(OSD 2)

中身をみて学習できる

ソースコードの修正、再配布ができる(OSD 1,3)

自力でセキュリティホールを修正できる

それをさらに再配布できる

機能追加、削除ができる

ソースコードの完全性を維持できる(OSD 4)

ただしパッチの存在、配布は認める

これにより(3)と矛盾しない

配布者のメリット

再配布が容易(OSD 1,5,6,7,8,9)

as-is な配布ができる

それをさらに第三者が自由に配布できる

販売することもできる

配布することに責任を課せられない

修正したものが配布できる(3)

セキュリティ対応が可能

フリーソフトウェアとの違い

Free Software Foundation

Richard Stallman 率いる団体

フリーソフトウェアの定義

目的を問わずプログラムを実行する自由

プログラムを研究する自由

プログラムを再配布する自由

プログラムの改良部分を発表する自由

定義に基づくライセンスの規定

GNU General Public License (GPL)

GNU Lesser General Public License (LGPL)

OSDに合致するライセンス

OSI自身はライセンスを規定していない

OSDに合致するものに対して承認をあたえる

OSD Certificated License の例

GPL

LGPL

BSD License

http://www.opensource.org/licenses/

http://opensource.jp/licenses/

これらに掲載されているライセンスであれば、先に述べたメリットを享受できる

OSSの例

Linux

GPL - 利用者は自らもソースコード公開を求められる

FreeBSD, NetBSD, OpenBSD

BSD License - 著作権表示のみを行えばよい

Apache

The Apache License (BSDLの一種)

Perl

Artistic license - 単独で販売しないならよい

プレイヤーの境界

利用者、開発者、配布者の境目は現実的には不明確

オープンソース開発者は通常利用者でもある

自分が使わないソフトをわざわざ開発しない

LinusはもちろんLinuxを使っている

ソリューションプロバイダ

OSSを用いた開発(利用者、開発者)

OSSに不足した機能を追加、修正

顧客への提供(配布者)

バグ、セキュリティ修正が自由にできることが重要

OSSは万能か

もちろんそうではない

目的、メリット、デメリットをみてOSSを用いるかどうかを選択

OSSを選択しない例

Java

仕様を完全にコントロールしたい

一般的な市販ソフトウェア

そもそもソースコードを公開したくない

開発モデル

OSSと開発モデルは直接は関係しない

バザールと呼ばれる開発モデルとの親和性は高い

誰もが改良、再配布できる

開発のサイクルが早い

伽藍モデルで開発している場合もある

QTはTrollTechでのみ開発している

第三者のパッチは受領することこもあるが、その際に著作権の完全譲渡を書面で求められる

参考:「伽藍とバザール」

http://cruel.org/freeware/cathedral.html

まとめ

OSSのプレイヤーは3者

利用者、開発者、配布者

3者のバランスをとったものがOSS

OSSの特性を理解した上で採用するか否かを決定

ライセンスによっては自らの開発したソースコードも公開しなければならない

責任は利用者にある

リファレンス

Open Source Initiative	http://www.opensource.org/

Debian Project http://www.debian.org/

DFSG http://www.debian.org/social_contract#guidelines

Free Software Foundation http://www.fsf.org/

GPL, LGPL http://www.gnu.org/licenses/licenses.html

Open Source Group Japan http://opensource.jp/

2004-06-29T18:26:53