恋々小町シリーズのライセンスについて

 

ここでは、コンピューターソフトウェアのライセンスの仕組みについての一般的な例の紹介と、うぴょりっくソフトがどういう考え方、理由に基づいて「恋々小町」のライセンスの仕組みが導入されるのに至ったのかについて書かれています。ここでの議論の対象はPS2、GameBoyなどの家庭用ゲーム機のソフトウェアではなく、パソコン(MacintoshやPC/AT互換機)用のソフトウェアに的を絞っています。(家庭用ゲーム機はソフトウェアのメディアそれ自体で起動して遊ぶという性質のため、1ライセンスで複数台で同時に使用するという概念がないため、メディアに対する不正コピー対策がされているだけの場合がほとんどですので、ここでは議論しません。)

一般的にパーソナルコンピューター用のソフトウェアのライセンス形態にはいくつかあり、ライセンスキーの仕組みは大きく以下のようなものに分けられます。

a) ライセンスキーの仕組みを全く持たないもの
b) お客様の環境に全く依存しない単一のライセンスキーを発行するもの
c) お客様の名前に対応するライセンスキーを発行するもの
d) お客様の環境情報や名前情報など固有の情報に対応するライセンスキーを発行するもの
e) ドングルなどと呼ばれるUSB/Parallelポートなどに装着する専用ハードウェアを使用し、それが接続されていないと動作しないもの
f) キーディスクなどと呼ばれる特殊なメディアにライセンス情報を持たせておくもの
g) DRMなどと呼ばれる仕組みで都度ネットワーク認証をしないと機能しないもの

シェアウェアのほとんどはa)〜d)のいずれかの方法でライセンスの仕組みを持っているようです。e)やf)のような特殊な方法は、確かにもっとも効果的ではありますが、シェアウェアにした場合には一般的にコストとの折り合いは悪くなりますので、一部の非常に高価なソフトウェアあるいは使用することによりプロフェッショナルユースの人がビジネス可能になる(要はそれで飯を食っていく)ような価値の高いコンテンツを作成することができるソフトウェアに限定されているようです。

このようにソフトウェアのライセンスにはいくつかの仕組みがありますが、これはちょうど制作者がソフトウェア資産とライセンスシステムの信用を守るセキュリティという観点では「セキュリティを高くするほど使いにくくなる」という一般論と一致します。

また最近では(OSはあくまでもOSでありアプリケーションではなく、何かを生み出すようなものではないためOSにアクティベーション機能を実装することは個人的には反対ですが)Microsoft社のWindowsXPがd)に分類されるアクティベーション機能を実装したことをはじめ、Adobe社、Macromedia社の製品ではライセンスの不正使用を確実に防ぐために、d)のような認証が必要となる仕組みが標準的になりつつあります。

確かにライセンスの仕組みを全く持たないa)の方法は、ほとんどのフリーウェアや、一部のシェアウェアで見られる方法で、ユーザーの自己申告のあったもののみが制作者に通知あるいは還元されます。これは、制作者がソフトウェアを「できるだけ多くの人に自由に(無料で)使ってもらいたい」という考え方を持って公開されている場合がほとんどで、最も多くのユーザーにソフトウェアを楽しんでもらうことができます。その動機としてはオープンソース・GPLの精神に基づく場合もあるでしょうし、また利益を全く目的にしていない場合や、習作として作品を公開した場合、単に有名になりたい場合などいろいろあるかと思います。いずれの理由でも、このような形式の場合は、ユーザーによる「ソフトウェアの不正使用」という概念が全く成立しませんので不正使用を避けるための仕組みも方法も全く不要のものとなります※1

b)〜d)の方法は、多くのシェアウェアでとられている方法です。いずれの場合でも、代金として現金あるいは図書券などの金券、場合によってはユーザーの住む地域の特産物など、ライセンス発行の対価として何かをユーザーに求めるタイプのものがここに分類されます。その動機としては、開発環境整備にかかった費用の部分的あるいは全面的な回収※2、次期ソフトウェア開発費の調達、サイドビジネスとしてのリリース、お小遣い稼ぎなどいろいろな理由があるでしょうし、取らぬ狸の皮算用をするのもなかなか楽しいものです。実際にはビジネス的な収支という観点から見ると、ほとんどのシェアウェアや同人ソフトの場合赤字ですが、趣味と仕事という考え方の中で「趣味」である場合はソフトウェア制作の利益については過度に追求しすぎる必要はあまりないかと思われます。ほとんどの趣味というものは、たとえ何かのコレクションであっても、旅行であっても、茶道や華道も武道もそうですし、もともとお金をかけて楽しむものです。

こうした中で、b)のような単一のライセンスキーによる方法は、制作者側も最小限のプログラムコーディングで試用状態制限を実装できますし、また公開後はいちいちライセンスキーを発行する手間もなくなるというメリットがあるため、多くのシェアウェアでこの方法が使用されています。この方法の欠点として、使用許諾を受けた悪意あるユーザーが、ライセンスキー情報を正規のライセンスを持たないユーザーに対して漏洩することにより、「ソフトウェアの不正使用」が容易に行われてしまう点があげられます。最近では、インターネットインフラの普及により本人にモラルさえなければ、情報の漏洩が非常に容易になっていますので、インターネットのアンダーグラウンド掲示板やファイル交換などでシリアル番号集といった形で出回ると、不正使用が不特定多数に広まり、作者の意図しないところで、実質a)の形態と全く同じレベルになってしまうこともあるでしょう。また、ライセンスのこうした仕組みを悪用して、本来ひとりにつき1ライセンス購入するべきところ、何人かで割り勘して共同購入のような形で不正使用が行われるのも防ぎようがありません。

c)の方法は、ユーザーの申告した名前に対応するライセンスキーを発行するケースが主で、プログラムコーディングの面でもb)より少し複雑になり、またソフトウェア公開後はいちいちライセンスキーを発行する手間に追われることになります。反面、名前を登録することがある程度の抑止力なり、b)で見られるようなライセンスキーの漏洩はある程度防ぐことが可能になります。しかし、それでも名前のチェックが甘かった場合などでは、「不正規ユーザー」「NoName」などの架空の申請者名とライセンスキーのセットでライセンスキー情報が漏洩してしまう場合もありますし、また極めて悪質な例では申請者名からライセンスキーを生成するジェネレーターと呼ばれるプログラムが出回ってしまうこともあります。

d)の方法はc)とほとんど同様ですが、固有の情報に基づく部分があるため、c)よりも不正使用される確率が多少は低くなるというメリットがある反面、ユーザーの環境が変化したりした場合、新しい環境では動作しなくなるため、ユーザーにとっても使いにくいソフトとなってしまうことがあることと、サポートが面倒になるなどのデメリットがあります。1999年にリリースした「恋々小町」でもd)の方法を使用しています。

g)の方法は、携帯電話などの月額課金型のゲームサービスや、最近のソフトウェアで採用が進みつつある仕組みですが、インターネットに接続して認証を受けて、使用許可が得られていない限りはソフトウェアが起動しないというものもあります。この方法はサーバー側に大がかりなデータベースを用意しておき、都度認証データを持ち更新し続けるという「運用」が必要になります。

このように見てみると、性善説的な考え方に基づけば基づくほどb)あるいはa)のような形態、性悪説的な考え方をするとc)やd)、つきつめるとe), f), g)といった方法が使用されると考えることもできます。ここでは性善説と性悪説のどちらが正しいというような不毛で無意味な議論はしませんが、少なくとも仮に性善説がまかり通るようであれば全ての人が高いモラルを持ち不正使用などの全くない理想的な世の中で、すべてのソフトウェアはライセンスの仕組みを持たなくても良くなります。しかし逆であれば少しの隙もつけ込まれ悪意のある人間やこうした不正利用をすることをゲームのように楽しむどうしようもない家畜的子供(Kiddy)がいるという現実がある以上は、性悪説を採って正規のライセンスを得ていない人には使用させないような仕組みを持たざるを得ない場合もあるでしょう。


1998年の「恋々小町」の開発時に、b)〜d)のうち、どの方法にしようかという議論がありました。ライセンスキー発行の手間などを考えるとb)があとあとも楽になるためb)の方法で行きたいと考えましたが、そうした場合にどの程度の確率で「不正使用」される可能性があるのか調査を行いました。やはりインターネットの世界は善し悪しや価値を問わず、ただひたすら情報が大量にある世界だけのことはあり、シリアル番号を集めたテキストファイルをいくつも見つけることができました。ほとんどは同一の情報源にもとづいてコピーされているものであったことから、たとえ一人でもこうしたライセンスキーの漏洩を行えば、簡単に世の中に出回ってしまうということがよく理解できました。

しかも、こうした不正利用に使用可能なシリアル番号集などを公開しているサイトでは、本来「ライセンスキーはライセンスを受けた本人のみが管理する責任を持つ」べきものであるのにも関わらず、「ライセンスを忘れたとき用のバックアップにどうぞ」というような幼稚な論理で自己の犯罪行為を正当化し、良いことをしているなどと勘違いしていたりもします。これはちょうど無防備なproxyサーバーを不正に利用しながら「自分の身を守るためにやった」と少しも悪いことをしたという自覚のない驚くべき輩もいるのに似ています。驚いたことに、某T大学の修士課程の人間ですら、大学のネットワークを使用して不正使用をしながらもこうしたことを主張していたのには、あきれ果てました。(もっともインターネット上に他人に踏み台にされるような状態でサーバーを設置する側の責任も問われるべきですが) こうした程度の低い人間にモラルを説いて正しい教育をしていくだけの暇もありませんし、豚に真珠でほとんど無駄でしょう。1しか理解できない人に10を教えるのも無理な話です。

せっかく作ったプログラム作品を、まじめにシェアウェア代金を支払って利用いただいている「お客様」がいる中で、こうした不正使用がまかりとおると、作者にとって大変腹が立つことになる※3だけではなく、正規のお客様に対しても実に申し訳ないという事態になります。たとえば、いくらか支払って入手できるライセンスキーでシェアウェアを使用することと、そのへんのアンダーグラウンドサイトやファイル交換で盗んだり拾ったりした誰かのライセンスキーでシェアウェアを不正使用することに何か違いがあるとすれば、精神論になりますが良心がとがめるかそうでないか、どれくらい良識を持っているか試されるような違いになります。

人によってはひねくれた理由、訳の分からない理由、GPL・PDSなどの間違った解釈から全く良心がとがめないと主張するでしょう。しかし、少しうがった見方をしますと、人間は弱いもので、わざわざ面倒な手間をかけて代金を支払わなくても、拾ったライセンス情報で有料のシェアウェアを利用できるのなら、当然利用してしまった方が得であるという誘惑にたやすく負けてしまうでしょう。不正使用していても、ほとんどの場合は作者にはばれることはないのですから。そして正規に料金を支払ってそのソフトウェアを利用すること自体がばかばかしくなってしまうこともあるでしょう。

うぴょりっくソフトでは、ソフトウェアのライセンスは「善良なお客様に対する信頼でもある」という立場から、少なくともb)のような方法はまずあり得ないという結論にいたりました。「恋々小町」のライセンスキーの生成方法は機密事項のため明かせませんが、少なくともリリース後4年たった現在でも、不正使用を試みて失敗し誰かに依頼したという記録は見つけられましたが、少なくとも今のところ不正利用された形跡はなく信頼は守られていると考えることができました。

2003年に新しくMac OS X用に開発していた「恋々小町X」のライセンスの仕組みもどうしようかと考え、b)の方法でリリース可能かどうかも同様に調査しました。仮にMac OSプラットフォームでのソフトウェアのシリアル番号集のような不正使用を勧めるようなものがなく、性善説を取れるのであれば、b)の方法でと考えていました。しかし、期待は裏切られ、シリアル番号集はあちこちで見つけられました。その結果「恋々小町X」でもd)の方法でライセンスを発行することに決定しました。また「恋々小町」公開後、最も面倒な作業だったライセンスキーの再発行はもうしたくないという反省から、「1台につき1ライセンス」「ライセンスキーの再発行はいかなる理由でも一切行わない」というポリシーをあらかじめ決めておくことで、公開後の事務処理の軽減させることにしました。

この場合の問題点として、もしコンピューターを買い足したのではなく買い換えた場合に、ライセンスの移行の処理ができないため、厳密に「1台につき1ライセンス」という解釈に矛盾してしまうという点があげられます。こうしたライセンス移行の仕組みまで実現しようとするとg)のようなDRMのようなシステムで大がかりなネットワーク認証のような仕組みが必要になるため、1ライセンスの価格を低く抑えて買い換えた場合にもライセンスを追加購入する必要があるとあらかじめ決めておくことで対応しております。

「恋々小町X」は、ソフトウェアのライセンスの仕組みとしてはアクティベーションと同程度の制約を持つソフトウェアなのにもかかわらず、非常に多くのお客様にご好評いただいており、またこのライセンスの仕組みに関する反対意見や苦情もほとんどなく、このような仕組みでの使用許諾の仕組みも理解いただいているものと確信しております。今後のソフトウェアでも同程度のライセンスの仕組み、「恋々小町X」のライセンスの仕組みで得た良い点と悪い点を反省して、より分かりやすい仕組みにする方向で開発を進める予定ですが、万一「恋々小町X」が不心得者によってクラックされてライセンス情報なしでも遊べるようになってしまった場合は、認証をより複雑にしネットワーク認証も視野に入れて開発していく予定です(より複雑な認証の技術的テストはすでに行っております)。


※1) GPLのような場合、ソフトウェア制作者がソフトウェア制作時に一部のコンポーネントとしてGPLのプログラムを使用した場合はGPLに基づいて、ソースを公開するあるいはソースを入手可能にする義務が発生します。(GPL規約に違反しても罰則はないので、これが本当に企業で守られているかは大いに疑問の余地がありますが) あるライブラリにオープンソースの製品で見つかった脆弱性の問題がMicrosoft製品でも同時に見つかったことがあったという理由から、Microsoftがソースを公開しない理由として、GPLのプログラムを無断で使用していることや、NSA用のものなどをはじめとするさまざまな裏口やスパイウェアが仕込まれていることがばれてしまうというのもあるのではないかと疑っています。

※2) ソフトウェア開発に必要となるものはプログラムのコーディングをするために必要な統合開発環境だけではありません。グラフィックデザインにはたとえばAdobe PhotoShopなどのソフトウェア、イメージスキャナやタブレット、3Dレンダリングソフト、デジタルカメラ、音楽の制作にはレコンポーザやDigital PerformerなどのソフトウェアとMIDI I/Fやモニタスピーカー、音源モジュールやキーボード、音声の収録にはHDD MTRなどのレコーディング機器やオーディオインターフェース、専用マイク、効果音の作成にはシンセサイザーや波形編集ソフトなどを使用する必要がある場合もあります。最近の家庭用ゲーム専用機などで見られる3Dがメインとなるような大がかりなソフトウェアは、もはや個人〜数人レベルで制作できるものではなく、映画と同じように巨額の投資が必要になっている傾向も見受けられます。

※3) アンダーグラウンドで出回っているライセンスキーをバージョンアップしたときに無効にするという方法で作者も対応し、こうした悪意ある子供の輩との間でのいたちごっこになっているケースもあります。あるシェアウェアでは、作者が激高してアンダーグラウンドで出回っているライセンスキーで登録すると、ハードディスクの破壊などウイルス的行為を行うようにしくんだ例もありましたが、これは一つの哀れな実例でしょう。(個人的には作者の気持ちも理解できますし、不正入手したライセンスを使用した時点で違法なのですから、ハードディスクを破壊されたりディスク上のあらゆる個人情報がネットワークに発信され漏洩しても自業自得だと思います。もちろん、うぴょりっくソフトの作品にはそうした仕組みは実装しておりませんが。)いずれにしても、一度このように「対抗する」ようなところを見せてしまうと、子供は「かまってもらうことができた」と大喜びして、また別のライセンスキーをアンダーグラウンドに流してしまうこともあるでしょう。こうした幼稚な子供を相手に余計かつ不快な手間をかけることを考えるとb)のライセンス形態よりもc),d)の方が手間はかからないのかも知れません。