Chienomi

なぜOSSするのか

プログラミング::topic

序

OSS(オープンソースソフトウェア)の語義は文脈により何通りもあるが、基本的にはソースコードが公開され、その利用が自由であるソフトウェアのことである。 この場合のソフトウェアは基本的にはプログラムのことであり、フォントやアートワークといった非プログラムのソフトウェアは、広義にそれを含めるニュアンスの文脈でない限りは通常含まない。 もちろん、辞書的な語義としては含まれるが。

ここに訪れる人の多くは既に知っているだろうが、私は継続的にOSS活動を行っている。 その成果物はGitHub, Gist, GitLabなどで公開している。

また、このChienomiの記事でも多くのコードが掲載されている。 ただし、こちらについてはライセンス不明瞭であるかもしれない。

私の意見は、OSS活動はあなたを含む多くの人の利益になる、ということだ。

経緯

現在公開されているコードを見ると、最も古いもので2014年のものになっている。 そのようになっている理由自体はシンプルで、以前はウェブサイト(Chienomiの前身から)で掲載されていたのだが、そのサイトそのものが残っていないために公開が継続されていないのだ。 そのようにされた理由だが、WordPressになる段階でリセットされ、さらにWordPressでベースプラットフォームが変わるたびにリセットされたため。

もっとも、それは「その理由だけで十分だ」ということであって、理由がそれだけということではない。 そもそも私はOSSに対して現在のように積極的な態度だったわけではなかったのだ。

昔の私の中で、OSS活動というのは「有り難いが、特異な行動」であると思っていた。 作者の利益が乏しく、潜在的なマネタイズのチャンスを失うかもしれないからだ。

この感覚は、世界の感覚にも連動している。 OSSというものは昔から存在していて、例えばLinuxやPerlがコミュニティによって開発されていることは認識していた。 だが、当時はLinuxなんてマイナーなソフトウェアであったし、広く人々が(直接に)使うソフトウェアにオープンソースというものがあまり入り込んでいなかったのだ。 Linuxディストリビューションも、多くの大手どころはコミュニティ駆動ではなかった。 Debianはもともとコミュニティだったが、Red Hat LinuxやSuSE Linux, あるいはMandrake Linuxはそうではない。

この感覚に転機が訪れたのは、やはりNetscape (Mozilla)がOSS化されたことだろう。 あれだけ大きく、なおかつ広く使われているソフトウェアが「OSSに変わる」というのはインパクトが大きかった。 それは単に先鞭をつけたというだけの意義ではなかった。Netscapeのソースコードが公開されてから、Mozillaのコミュニティが確立されるまでには相当な紆余曲折があり、コントロールされた企業から有志のコミュニティに移すことの難しさが浮き彫りになった出来事でもあった。 Mozillaの苦労と経験は、現在のOSSに大いに活かされているし、あれがなければ今ほど安定したOSSの世界にはなっていないだろう。

さて、そんな頃の私のOSSの認識は、「ソースコードが公開され、検証可能で、開発に参加することもできる」であった。 ちなみに、前二者は正しいが、最後のものは正しくはない。 開発に参加できるかどうかはプロジェクトの体制次第であり、開発するためにはforkするしかないという可能性も普通にある。

そのようなOSSの認識のもとでは、自分の書くコードをOSSにするというメリットがないように思える。 私が書いたコードは検証を必要とするほど公正を示すものではないし、他の人が開発に参加するほどメジャーなものでもない。

それに、私は「コードをパクられる」ことを嫌った。 正直その頃の私のコードというのは「なけなしの技術」であったし、コードを書ける人の希少価値が高かったから、「コードを書ける自分の地位」を守るためにソースコードの公開はしたくないという考えであったのだ。

もっとも、当時私が書いていたプログラムの多くはJavaScriptあるいはPerlであったから、ソースコードの保護というのは難しかったが、少なくともそれを「公に好きに流用して良いとする」というのは抵抗があった。

この考えを変えるのは社会的な変化と、自分の変化と両方がある。

最も大きかった理由を言うならば、私の “再起動” にあたり、現在の(以前世に姿を見せていたときとは比べ物にならないはずの)自分実力を提示するためにGitHubに公開することが有効であったからだが、実力の向上という点では、「公開しているコードをパクった程度では私の立場は脅かされない」というのもある。 実際に公開する個別のコードに含まれている私の技術なんて、私の技術全体の数パーセントもない。 その技術が身についている人ならばパクる必要もないし、私のコードをパクるような人は私のレベルでコードを書けるわけではない、ということに気づいたのだ。

そして、この頃にはOSSの恩恵にどっぷり浸かるようになっていたし、OSSになっていることが人々にとって非常に大きな恩恵になっているとも感じるようになった。 世の中がOSSに傾いたのは、社会の発展によってコードが膨張し、企業が自らでコードを維持するコストが馬鹿にならなくなっていたためだが、OSSにすることでちゃんとコードが維持されるようになるほどニーズがあるソフトウェアはOSS化はwin-winの関係を築けるといって過言ではない。

私の希望としてはオリジナルの作者が誰であるかを示してほしい、つまりCC-BYのようなライセンスを好むのだが、それはOSSの世界ではかなり厳しい部類に入る。初期はこの手のライセンス(4条項BSDライセンス)を採用していたが、現在はその点は受け入れて、自分の中で馴染みの良いApacheライセンス2.0を採用するようにしている。

さらに私の社会的な姿勢を示す上でもOSS活動には意味がある。 いつから、というのはぼかしておくが、私の社会的姿勢は「人々のコンピュータリテラシー向上に貢献し、人々がよりコンピュータと仲良くできるようにしたい」である。 その思いの結晶とも言えるものがMimir Yokohamaでもあり、またChienomiでもある。 Mimir Yokohamaの創業が2014年であることもヒントになるだろう。 このような社会的姿勢と、OSS活動というのは非常にマッチしていて、わかりやすく私のスタンスを示すことができる。

つまり、以前は「パクられたくない」だったが、今はむしろ「全然パクってくれていい。それで学んでほしい」なのだ。

OSS活動の意義

あなたが超有名なソフトウェアの作者、あるいは超有名なソフトウェア開発者になることがないという仮定のもと、つまり「一般のプログラマ」のレベルの話であるとすれば、私はその意義を次のように考える。

  • あなたの実力を示すことができる
  • あなたの社会貢献の姿勢を示すことができる
  • あなたの開発したソフトウェアが世に残りやすくなる
  • あなたの開発したソフトウェアが利用されやすくなる

アートワークというものは権利や法律に対して蒙昧で、非常に不明瞭な利用条件で配布されていることが非常に多い。 大抵はその文面を法的に妥当に解釈すれば、決して利用することができないものになっている。 特に、「常識」やら「作者の感覚」に依存する条項が含まれていたら、それはどうがんばっても法的リスクを回避できないものだ。

そして、そうした専門知識なしに「こうしてほしい」「こうしてほしくない」を利用許諾条件として提示したら、ほぼ間違いなくそのようなものになる。

そのようなものは、皆がとても利用できるものではない。 少なくとも、「適正に利用しよう」という意思を持つ人はそのようなソフトウェアを利用することは避けるだろう。 そのために使われない。

さらに、そのようなソフトウェアを世の中に残すには、あなたがメンテナンスし、公開し続けるしかない。 かつて一斉を風靡したような「フリーウェア」、いわゆる「無料アプリ」はその多くが今や入手不能であり、昔話に名前が出てくる代物に過ぎない。 例えば、私のウェブサイトで使っていた掲示板ソフトウェア、Nicole Boardは今や失われてしまっている。

そして、OSSは検証可能であり、あなたという人物に着目したとき、あなたがどのような関心を持って、どのような活動をし、どのような実力を持っているのかを確認することができる。 それはあなたというブランドを高めることにもなるはずで、あなたの社会的人生に利益を与えるだろう。

OSS活動を行うポイント

あなたが自分で考えて、自分が使う、動くコードを書けるレベルにあるのであれば、自分の実力を恥じて活動を控える必要などない。 なぜならば、それができない人はいっぱいいるので、誰かの役には立つかもしれない。

将来的に自分がそれを書き直すときに役に立ったり、自分の歴史として意味があるかもしれない。

そして、公開するときに対価を期待すべきではない。 「誰かの役に立ったらいいな」くらいの感覚がよく、誰も見ない前提で公開すべきではないが、公開したことで成果が得られると思うべきでもない。 まぁ、Chienomiもはるかみ☆でぃじっと(YouTubeチャンネル)もそんな感じだし。

OSSにする上で、自分の中で折り合えるライセンスを見つけるというのは結構大事なことかもしれない。 「OSS活動をすることは長期的に見て良いことだ」と思えることは大事だ。

すべてを公開しなくて良い

私も開発したもののすべてを公開しているわけではない。

私が開発したもので公開していないものの代表はERINA the Emotional AI、及びその発展形のSurtrである。

これを公開しない理由はシンプルで、このプログラムは非常に多くのデータを内包し、そのデータベースの内容物は配布可能ものでないからだ。 「データベースを空の状態で公開する」ということが考えられるプログラムもあるだろうが、ERINAに関してはコード自体がそのデータを内包して書かれているため、分離することができず、将来的にも配布される可能性は全くない。

また、その問題が解決されたとしても、ERINAのロジックは私にとって秘奥義に属するものであるため、公開するかどうかにはもう一考を必要とする。

そのERINAの基盤のひとつになっているコンポーネントであるMedia Meta FileSystem (=Guardian Valkyrie FS)は、明らかに脆弱であり、その脆弱性が修正される予定もないため公開できない。 公開しないことを前提とした完全な力技なのだ。

一部は開発カテゴリで公開されているものではあるが、私が手元で作って、個人的に使っている小さなコードも公開していないものが結構ある。

これらを公開しない理由はみっつある。

1つ目は、汎化する手間をかける気にならないからだ。 自分の環境に依存したコードをかけば手間はだいぶ減るので、公開するとなるとだいぶコストがかかる。

2つ目は、1つ目と連動した理由だが、データが内包されていたりするからだ。 自分の環境で動作させるためのコードだと、値はハードコーディングするほうが話が早く、配置としてもデータのあるディレクトリに直に置いたりするから、結構な割合でコードの中に「見せてはいけないもの」が含まれてしまっている。

最後は、生活が透けてしまうからだ。 例えばmmfft9に力が入ってることをもって、「結構ゲームしてるんだなぁ」とか見えたりするのだが、その程度なら全然構わない。 だが、日常コードは正直、「何をいつ買ったか」とか「どこで暮らしているか」とかまで見えてしまうようなものがあったりするので、こういうのも公開できない。さすがに私生活を晒すのは嫌なので。

また記事中でのみ書かれているコードは公開自体は支障はないのだが、コードだけ公開するわけにもいかないというものがあったりする。 つまり、背景事情、目的、注意点などかなりの情報を入れなくてはならず、そうなるとGitHubで公開するとなると膨大なREADMEを書かざるを得ないのだ。 こうしたものは記事中で公開するには問題ないが、GitHubでの公開は労力に見合わないから避けたりする。

こういった理由で「公開しない」という選択も普通にするものだから、「OSS活動しているから、全部公開しなきゃ」みたいなプレッシャーに苛まれる必要は全くない。