Placebo Effect > OpenOffice.org
自作ソフトの利用条件をどう決める?
ソフトの配布とライセンス
可知 豊
この文書は、SOFTBANK Cマガジン2004年8月号にて、「特別記事:自作ソフトの利用条件をどう決める?
ソフトの配布とライセンス」として掲載された記事の一部を加筆訂正したものです。このような記事を執筆する機会を与えてくれた C
マガジン編集部に感謝します。
なお、この文書は、ソフトウェアを利用する上で一般的な理解を助けるためのもので、法律的なアドバイスを与えるものではありません。ソフトウェアを利用・
配布する際には、自社の法務担当者に相談することをお勧めします。
自分で作ったソフトウェアを、他の誰かに使って欲しいと
思ったことはありませんか? そのような、ソフトウェアの公開にあたって気をつけなければならないのが、そのソフトウェアをいったいどんな条件で使っても
らうか、です。本稿では、ソフトウェアを公開/配布するときの利用条件（ライセンス）について、具体的にどんなライセンスにしたらよいか、わかりやすく解
説します。
ソフトウェアのライセンスについて
インターネット上には、多くのソフトが公開されています。あなたもフリーウェアを利用したり、商用ソフトをダウンロード購入したことがあ
るでしょう。
こういったソフトを利用するとき、無料か有料かといった利用条件が気になりませんか?
フリーウェアかと思ったら、後から商用ソフトと分かったなんて、そんなトラブルは避けたいところです。
あなたがソフトを公開/配布する場合も同じです。ソフトの利用条件を明確にしておけば、ユーザーにとっても、もっと利用しやすいものになるでしょう。
このようなソフトの利用条件を｢ソフトウェアライセンス｣と呼びます(以下ライセンス)。ソフトの作者は、ライセンスを決める権利を持っています。
なお本稿では、商用ソフトの販売も、配布の一種と考えます。また、オンラインソフトとパッケージソフトの違いも考慮していません。配布形式が違うだけ
で、利用条件の考え方は同じだからです。
どのようにソフトを公開/配布するのか
ライセンスは、ソフトをどのような目的で公開するかで大きく変わってきます。目的がはっきりすれば、利用条件の骨格も明確になるでしょ
う。
まずは、どのようにソフトを公開/配布するのか、具体的な例を考えてみましょう。
ソフトの公開
/配布例
ユーザー向け->バイナリー
- ユーザーに使って欲しい (フリーウェア、シェアウェア、商用ソフトの販売)
- ユーザーに試して欲しい (体験版、試用版)
- 開発ツールだけ無償/割引販売
- 教育機関向けに無料/割引販売
開発者向け->ソースコード
- サンプルコード
- リファレンス実装
- オープンソース
- シェアードソース
バイナリーを配布する
最も一般的なのは、ソフトウェアをユーザーに使って欲しいという場合でしょう。無料で使ってもらう、有料で使ってもらう、料金前払い/後
払いなど色んなバリエーションがありますが、使ってもらうという点では同じです。
本格的に使う前に試したいという場合もあるでしょう。体験版や試用版のソフトがこれにあたります。無料で利用できるが、使用期限が決まっていたり、一部
の機能が制限されていたりします。とはいえ、本稿では体験版の使用制限を技術的にどう実現するかは取り上げません。
これ以外に、他の開発者や教育機関を対象にする場合があります。たとえば、プラグインソフトを開発する人向けに、一般ユーザーと異なる条件で配布した
り、開発ツールだけを無料で配布するといった場合があります。また、教育機関向けに、無料または割引価格で販売する場合があります。
これらは、販売や普及のためのマーケティング戦略として、ユーザーごとに配布する条件を変えているのです。
ソースコードを公開する
さらに、コンパイル/ビルドしたバイナリーだけではなく、ソースコードも公開されています。たとえば、プログラミング言語や開発環境に
は、大量のサンプルコードが付いてくるのが一般的です。
また、技術規格を定義するため、その機能を実現するソースコードを公開する場合があります。これは、リファレンス実装と呼ばれるもので、動作しますが十
分な性能が出るとは限りません。
そして、ソースコード公開の代表的な例が、オープンソースです。ただし、ソースコードを公開するだけでは、オープンソースとは呼べません。
Microsoftも「シェアードソース」により、一部の開発者にソースコードを公開しています。
オープンソースと「ソースコードを公開するだけ」の一番の違いは、コードの再利用性にあります。
他の開発者が、ソースコードを読むことができれば、そのプログラムを利用するプラグインなどを開発しやすくなるでしょう。しかし、そのソースコード自体
の再利用が許されていないと、バグを直したり、改良することはできません。
再利用が許可されていれば、独自の改良を盛り込んだり、それをオリジナルの作者にフィードバックして、開発作業を手助けできます。オープンソースでは、
このような再利用が、ライセンス中で認められています。
ライセンスの細部
このほかに、ライセンスとして次のような項目が盛り込まれています。
・商用利用の条件
・再配布の条件
・保証/サポートの有無など
このように、ソフトの公開/配布では、いろいろな条件を組み合わせることで、ユーザーの使いやすさを確保しながら、自分たちのメリットも確保します。
コラム：規制のための4つの制約条件
アメリカの法律学者ローレンス・レッシグは、著書「CODE
インターネットの合法・違法・プライバシー」(翔泳社)の中で、何かを規制する場合、その制約となるのは次の4つの条件だと述べています。
ソフトの場合も、この4つの制約条件を考えることができます。
市場は、ソフトの価格です。どんなに使いたくても、ソフトが高価格では入手できません。
アーキテクチャは、ソフトに組み込まれたメカニズムです。体験版の試用期限といった仕組みがこれにあたります。これには、コンピュータ室に鍵をかけるな
どの物理的なセキュリティも含まれます。
社会の規範は、マナーです。会社や学校で、美少女ゲームで遊ぶのは、かなり勇気がいるでしょう。
そして、ソフトの利用を規制する法が、ライセンスです。ライセンスは、ユーザーとソフト作者の間の利用契約です。
本稿では、このライセンスに絞って解説しています。 |
ライセンスを設定する
では、なぜライセンスにより、ソフトウェアの利用が制限できるのでしょう。これを理解するには、著作権とライセンスについて知る必要があ
ります。
著作権とライセンス
ご存じのとおり、プログラムは著作権によって保護されています。そのため、プログラムを利用するには、著作権者の利用許可(許諾)が必要
になると、著作権法で定められています。そのための利用許諾契約が、ソフトウェアライセンスの実体です。
契約なので、ユーザーごとに異なる条件で契約を結ぶことが可能です。しかし、個別の利用契約を結ぶのは大変なので、あらかじめ定形の利用許諾契約書を用
意し、利用者がこれに同意した場合のみ、プログラムを利用できるとするのが一般的です。プログラムのインストール時に表示される利用許諾画面は、この契約
の確認です。
使用と利用
ここで注意したいのは、著作物の「利用」が、一般的な「使用」と異なる点です。書籍であれば、本を読むのは「使用」にあたります。「使
用」には著作権者の許可はいりません。書店で本誌を立ち読みしても、著作権法違反にはなりません。許可が必要なのは、本を複製したり翻訳するといった「利
用」のときです。
著作物の利用の範囲は、文書・映像・音楽といったメディアの種類によって違ってきますが、プログラムでは複製・配布・修正に利用許諾が必要になります。
多くの商用ソフトウェアのライセンスでは、本来著作権で制限できない条項をユーザーが承諾した場合だけ、限られた数のプログラムの複製を認めています。
たとえば、リバースエンジニアリング・逆コンパイルの禁止などは、著作権では制限されなませんが、この追加の項目により制限されます。
ライセンスの
仕組み
コラム：著作権の有効期限
著作権には、保護期間が設定されています。著作権の保護期間は，原則として著作者の生存年間及びその死後50年間です。これを過ぎた著作物は、著作権者
の許可無く自由に利用できます。夏目漱石や宮沢賢治の作品は、保護期間が過ぎているので、自由に利用できます。
アメリカでは、この保護期間が何度も延長されてきました。ディズニーが持つミッキーマウスの著作権が切れそうになると延長されるので、「ミッキーマウス
法案」と呼ばれています。 |
ライセンス文書を書く
では、実際のライセンス文書を考えてみましょう。一番シンプルな雛形は、次のようになります。
ライセンスの
雛形
---
プログラム名
Copyright (C) 制作年 著作権者 ##----A項
下記の条項のいずれかに従う場合に限り、複製・配布を許可する。##----B項
(具体的な利用条件) ##----C項
---
ソフトの利用は、著作権者が許可するものです。そこでまず最初に、そのソフトの著作権者が誰なのかを宣言します(A項)。多くのフリーウェアの
readme.txtには、これが抜けている場合が多いようです。
それに続いて、許可する利用の範囲を明記します。ここでは、複製と配布を許可しています(B項)。
そして、具体的な利用条件を記述します(C項)。プログラミング風に言えば、C項がifコマンドの条件で、B項がthenコマンドの実行する内容になり
ます。シンプルな条件であれば、B項とC項を一文にまとめても構いません。
著作権者
ここで、重要なのは、著作権者は誰かということです。個人で開発したフリーウェアであれば簡単ですが、共同で開発するソフトの場合には、
誰に著作権が帰
属するのか、明確にしておいたほうがいいでしょう。
ここには、複数名の名前を明記することができます。その場合、利用条件を変更するには、著作権者全員の同意が必要になります。
多くの開発者の貢献で成立しているオープンソースプロジェクトでは、最初のバージョンを開発した人を「第一著作権者」としてライセンスに掲載し、それ以
外の人は「貢献者」というリストに掲載する場合があります。
企業の場合には、雇用契約を結ぶ際に、業務中に開発したソフトの帰属についての条項を盛り込んでおくのが一般的です。
なお、著作権は、著作権者を明記しなくても自動的に権利として発生します。しかし、著作権者名がないと、ユーザーは誰に許可をもらえばいいのか分からな
いので、著作権者を明記しましょう。
用途を制限する
いくつかのフリーウェアでは、商用利用禁止といった条件を盛り込む場合があるでしょう。また、個人利用は無料だけど、商用利用時は有料に
したいという場
合もあります。
このような条件は、C項に盛り込みます。
有料にする場合は、1ユーザーごとなのか、何台のPCまで許すのか明確にしておきましょう。
商用利用については、具体的に何を商用利用と見なすのか明らかにしておきましょう。販売を禁止するのか、業務中に使うのも禁止するのかといった具合で
す。
・個人利用の場合は、無料で使用できる
・商用利用の場合は、決められた対価を著作権者に払って、1PC・1ユーザーのみ使用する
再配布を制限する
「雑誌に収録する場合には連絡すること」といった条件は、配布を制限していることになります。
このような条件は、B項を次のように2つに分け、配布の条件として盛り込むといいでしょう。
単純に、商用利用禁止としてしまうと、商業雑誌で付録CD-ROMに収録できないことになるかも知れません。
下記の条項に従う場合に限り、複製を許可する。##----B1項
(具体的な複製条件) ##----C1項
下記の条項に従う場合に限り、配布を許可する。##----B2項
(具体的な配布条件) ##----C2項
デュアルライセンス
ライセンスは、ひとつだけにする必要はありません。
複数のライセンスを提示して、ユーザーにそれを選択させることもできます。これを「デュアルライセンス」と呼びます。
たとえば、オープンソースのデータベースMySQLでは、GPLというオープンソースライセンスと商用ライセンスのいずれかを選べるようになっていま
す。これは、オープンソースライセンスでは使いにくいという企業の便宜を図ったものです。
ライセンスをユーザーに示す
このようなライセンスは、使用する前にユーザーに読んでもらう必要があります。アーカイブの中にreadme.txtファイルを入れるだ
けでなく、イン
ストール時に表示されるようにしておくといいでしょう。
また、オンラインヘルプやバージョン情報でも参照できると便利です。
著作権者はライセンスを変更できる
ライセンスは、著作権者による許可なので、あとから別のライセンスを設定することができます。たとえば、最初は無料で公開しておいて、十
分に普及したら
商用ソフトに切り替えても構いません。
ただし、すでに許可済みのライセンスを変更するのは、契約相手との交渉が必要になります。
このようにソフトには、ライセンスとその運用によって、非常に多くの制限を課すことができます。より多くの人に自由に使ってもらうためには、できるだけ
ゆるいライセンスを用意するといいでしょう。
実績のあるライセンス
では、具体的にどんなライセンス文書を使うといいのでしょう。一番のお勧めは、新しいライセンス文書を作るのではなく、既存のライセンス
を流用すること
です。実績のあるライセンスを流用すれば、ユーザーにとっても、その内容を簡単に理解できます。
パブリックドメインは使えない
「パブリック・ドメイン・ソフト」は、「公共の領域」(public
domain)に置かれたソフトのことで、著作権が切れたり放棄されたソフトを指します。
ソフト以外の例で言うと、公共機関が作成した資料は、税金で作られているということで著作権が発生しません。また、作者の没後50年が過ぎた小説は、著
作権が消滅します。このような著作物は、パブリックドメインに置かれることになります。
使用条件のゆるいライセンスを考えるとき、パブリックドメインソフトが上げられます。これは、アメリカなどでよく利用される手法で、著作権者が著作権を
放棄することで、パブリックドメインに置くことができます。
しかし、日本の著作権法では、著作権のうち著作者の人格的利益を保護する権利(著作人格権)を放棄できません。そのため、著作権の放棄を宣言しても、ソ
フトをパブリックドメインに置くことができません。
制限のゆるいいBSDライセンスがお勧め
できるだけ多くの人に自由に使ってもらうには、次のBSDライセンスがお勧めです。これは、ソースコードとバイナリーの配布に使えます。
BSDライセ
ンス
------
プログラム名
Copyright (C) 制作年 著作権者
1.ソースコード形式であれバイナリ形式であれ、変更の有無に関わらず、以下の条件を満たす限りにおいて、再配布および利用を許可します。
1-1.ソースコード形式で再配布する場合、上記著作権表示、 本条件書および第2項の責任限定規定を必ず含めてください。
1-2.バイナリ形式で再配布する場合、上記著作権表示、 本条件書および下記責任限定規定を、配布物とともに提供される文書
および/または
他の資料に必ず含めてください。
2.本ソフトウェアは無保証です。自己責任で使用してください。
3.著作権者の名前を、広告や宣伝に勝手に使用しないでください。
-------
これは、BSDライセンスと呼ばれるライセンスで、日本語参考訳を元にして、読者の理解を助けるため一部書き換えを行ったものです。
初期のBSDライセンスには、1-3項として広告条項が含まれていましたが、現在は削除されています。広告条項を削除したライセンスを、修正BSDライ
センスと呼ぶ場合があります。
読んでみると分かるように、内容はとてもシンプルです。つまり、再配布時に著作権表示を残すこと(1項)、無保証であること(2項)、というたった2つ
の条件になっています。
このようなライセンスであれば、個人/商用のどちらでも自由に使えます。また、無料/有料のどちらでも配布できます。著作権表示が残っているので、日本
の著作権法にも合致します。さらに、"利用を許可します"となっているので、改良も自由に行えます。改良したソフトは、BSDライセンスと異なる条件で公
開/配布できます。
このBSDライセンスは、アメリカのカリフォルニア大学バークリー校で開発されたバークレー版Unixを配布するために作られました。現在も、
FreeBSDやApacheなど数多くのソフトに適用されています。
バイナリーだけ配布する場合
フリーウェアとしてバイナリーだけ配布する場合の例として、既存のソフトのライセンスを紹介しましょう。
これは、曽田
純さんが開発したWindowsの定番FTPクライアントFFFTPの使用許諾文書です。著作権表示やバージョン情報といっしょに、FFFTP.txt
ファイルに掲載されています。
使用許諾
・FFFTPはフリー・ソフトウエアです。個人使用、業務使用に関わらず自由に使用してかまいません。
・FFFTPの動作に必要なファイルが含まれた形であれば、自由に複製し、頒布してかまいません。
・ソフトウエアは十分にテストをしていますが、お使いのパソコン環境や、プログラムの不具合などによって問題が生じる場合があります。それ
により損害が生
じても、損害に対する保証は出来かねますので、あらかじめご了承ください。
シンプルな内容ですが、BSDライセンスと同じような項目が盛り込まれていることが分かると思います。ただし、改良は許可されていません。FFFTPは、こ
れとは別にソースコードがBSDライセンスで公開されています。つまり、BSDライセンスでは、バイナリーコードを異なるライセンスで配布できるのです。
GPLとLGPL
BSDライセンスは、オープンソースの定義に合致するライセンスです。そして、このオープンソースの定義に合致するライセンスとして、
GPL(GNU
一般公衆利用許諾契約書)とLGPL(GNU 劣等一般公衆利用許諾契約書)があります。
GPLでは、用途を問わず誰でも自由にソフトを利用できます。複製・配布も自由です。そして、次の場合には、ソースコードを再公開する義務があります。
・ソースコードを改良/追加した場合
・ソースコードの一部を流用した場合
・GPLなソフトとリンクした場合
このような条件は、CopyRightをもじって、CopyLeftと呼ばれています。このCopyLeftのおかげで、GPLなソフトを改良しても、
GPLのままになります。BSDライセンスの場合は、改良版をBSDライセンスとは異なるライセンスで公開/配布できるので、改良版は自由に入手できない
かも知れません。しかし、GPLなソフトであれば、その改良版も自由に利用できます。
LGPLは、GPLの条件を少しゆるめたライセンスで、リンクしたソフトはCopyLeftの対象外になります。
なお、GPL/LGPLは、BSDライセンスと比べて条項が複雑なので、利用者が理解しにくいという欠点を持っています。
しかし、Linuxをはじめ、多くのソフトがGPLを適用しています。
コラム：無料のFreeと自由のFree
本稿では、無料で配布されるソフトとして「フリーウェア」という言葉を使ってきました。これは「フリーソフト」と呼ばれるこ
ともあります。この場合のフ
リーは、無料(Free)という意味になります。
一方、GPL/LGPLを推進するフリーソフトウェア財団(FSF)は、誰でも自由に使えるソフトを「フリーソフトウェア」と呼ぶことを提唱していま
す。そのため、BSDライセンスやGPL/LGPLなどのオープンソースソフトウェアは、自由(Free)という意味でフリーソフトウェアと呼ばれる場合
があります。 |
もうひとつのオープンソースライセンス
オープンソースライセンスには、大きく3つの系統があります。このうち、BSDライセンスと、GPL/LGPLは、すでに紹介しました。
最後のライセンスは、Mozilla Public Licence(MPL)です。また、利用条件のよく似たライセンスとして、Common
Public Licence(CPL)があります。
MPLは、オープンソースなブラウザであるMozillaのために、Netscape社によって作成されました。ソースコードの変更部分は公開する必要
がありますが、追加やリンクした部分は公開する必要がありません。 CPLは、当初IBM Public
Licence(IPL)と呼ばれて、Eclipseプロジェクトに適用されていました。そこから、IBM社の名前を削除し、より一般的な利用条件にした
のが、CPLです。
Microsoftがオープンソース化したWindowsインストール・パッケージ構築用のツールセット「Windows Installer
Xml(WiX)」と軽量のアプリケーションツールキット「Windows Template Library
(WTL)」は、このCPLによって公開されています。
MPLとCPLは、BSDライセンスとGPLの中間に位置することになります。
商用ソフトのライセンス
商用ソフトの例として、Windowsのライセンスを読んでみるといいでしょう。難しい用語が並んでいますが、著作権の考え方が分かれ
ば、決して難しく
ありません。Windows XPでは、次の操作で利用許諾契約書を表示できます。
1."マイコンピュータ"アイコンをダブルクリック
2.メニューから[ヘルプ(H)]→[バージョン情報(A)]を選択
3.「Windowsのバージョン情報」ダイアログボックスが表示されたら、"使用許諾契約書"のリンクをクリック
Windows XPのライセンスを表示する
使用許諾契約書の冒頭にある「重要」という項目の後半に、次の文章が掲載されています。ここでは、ソフトウェアを使おうとする人に対して、どんな時に利
用許諾に同意したことになるか、書いてあります。
『本製品をインストール、複製、または使用することによって、お客様は本契約書の条項に拘束される
ことに承諾されたものとします。本契約書の条項に同意されない場合、マイ クロソフトは、お客様に本製品のインストール、使用または複製のいずれも
許諾できません。そのような場合、未使用の本製品を直ちに購入店へご返品 いただければ、お支払いいただいた金額を全額払戻しいたします。 』
一般的には、インストール作業の<同意>ボタンをクリックすることで、利用許諾契約を結んだと見なしますが、それ以外にも複製・ダウンロー
ド・アクセス・使用によっても、同意したことになると書いてあります。
このほかにも、手近なライセンスをいろいろと読んでみるといいでしょう。本誌の付録CD-ROMの裏側にも、「使用に関する注意」が掲載されています。
なお、企業が商用ソフトのライセンスを用意する場合には、法務担当者に相談することをお忘れなく。
「勝手に自由にどうぞ」は困ります
でも、本当にここまでややこしいものが必要なのでしょうか。単純に「勝手に自由に使ってください」では、いけないのでしょうか。
これは、使うユーザーの立場によって違ってくると思います。
個人ユーザーが、自分の生活の範囲内で利用するのであれば、「勝手に自由に使ってください」で十分でしょう。
しかし、企業ユーザーやライセンスをしっかりしたいと思っている人たちは、これでは責任が持てません。他の人が権利を持っているはずのソフトを、利用許
可を受けずに使わないはずです。つまり「勝手に自由にどうぞ」だけでは、ユーザー層をせばめてしまうのです。
あなたが、ソフトをどんなふうに使って欲しいか、そこでライセンスは決まります。
オープンソースの意義
ソフトの公開手法としてオープンソースが注目を集めています。冒頭でも書いたとおり、ソースコードを公開するだけでは、オープンソースに
はなりません。
ソースコードの再利用性が重要になります。
再利用性を重視してソースコードを公開するのは、ソフトの共同開発を促進するためです。ソースコードが公開されると、インターネットを介した柔軟な共同
開発が行われ、それが高品質なソフトにつながっていきます。
オープンソースの成り立ち
オープンソースは、1997年にエリック・レイモンドらによって提唱されました。
それ以前にも、ソースコードを公開する手法は取られてきました。BSDライセンスもGPLも1980年代から使われています。しかし、注目を集めるきっ
かけとなったのは、GPLを適用したLinuxの成功です。
このような開発手法をビジネス界に売り込むため、いわばマーケティングキャンペーンとして「オープンソース」が提唱されました。このために、「オープン
ソースイニシアティブ」(OSI)という組織が作られました。
オープンソースの定義
OSIのWebサイトには「オープンソースの定義」が掲載されています。これは、オープンソースの手法に合致するライセンスについて説明
したものです。
Debianプロジェクトのリーダーを務めていたブルース・ペレンスによって書かれ、インターネット上の多くの議論を経て公開されました。
「オープンソース」が具体的にどのようなものか、
提案者であるブルース・ペレンス自身が、「「オープンソースの定義」について」の中で、オープンソース発足の経緯、定義の解説、各ライセンスの特徴など
を解説しています。これは「オープンソースソフトウェア」(オライリー)に収録されており、Web上でも読むことができます(http:
//www.oreilly.co.jp/BOOK/osp/)。
オープンソースの定義には10個の条件がありますが、最初の3つがオープンソースの基本となる考え方を述べています。ブルース・ペレンスは、前述の
「「オープンソースの定義」について」で、この条件を次のように要約しています。
・プログラムのコピーを自由に作り、それを配布する権利。
・ソフトウェアのソースコードを入手する権利−ソフトウェアに変更を加えるためには、ソースコードが不可欠である。
・プログラムを改良する権利。
これらの権利を保障することにより、誰でも自由にソフトウェアを開発することができ、それが開発コミュニティを中心にしたプログラム開発を促進するので
す。
参考リンク
2004-11-15：新規公開
