オープンソースプロジェクトのはじめかた

昨日なんとなくそんな話になったので、私の考えをまとめて置きます。
これは私が会社でもしオープンソースプロダクトをやるとしたらここまでやりたいという妄想も含まれていますが、まあ適当に。

定番ですが

もうしつこいよ！ と思われるかもしれませんが、こんなエントリ読んでるんだったら：

オープンソースソフトウェアの育て方

を読む方がよっぽど意味があります。
Web 版もありますが、もしこれを通読して価値があると思ってお金に余裕があればぜひ買いましょう。

さあ始めよう

ぶっちゃけぼくが書くようなことは前掲書に全部書いてあります。なおこの章タイトルからしてパクリだし(笑)

名前重要

これもまるっきりパクリですが、プロジェクト名はプロジェクトの顔となるものです。そのプロジェクトを端的に象徴するもので、できれば皆の求心力になるカッコいい名前にしたいですよね。

ここで問題になるのが商標権です。他の人の商標を踏んだら名前変えなきゃいけなくなるし、後追いで取られちゃうことだってある。
けど、私の考えであれば、企業としてやるならここらへんちゃんと考えた方がいいですが、プライベートなプロジェクトなら「文句言われたら、もっといい名前に変えちゃおう！」ぐらいの気持ちでいるのがいいんじゃないかなって思います。それよりもいかにもな商標にぶつかりにくく、親しみやすいコードネームを選んで、いざそれでなんか違う展開、たとえば最初に世の中にリリースするとか、お金儲けを考えるとか、そういうときにちゃんとした名前を考えればいいんじゃないかなー。

ライセンス

プロジェクトの構成要素（ソースコードその他）をあげる前に、ライセンスを明確にする方がいいと思います。でないと、あなたの大事なソースコードがどんなことになるか分かりませんからね。

絶対にやってはならないことは、「自分たちのライセンスを作る」ことです。
ソフトウェアが組み合わせで使われる限り、ライセンスは他のライセンスとの整合性をチェックされる運命にあります。その場合、あなたのライセンスが法務文書として有効か、組み合わせて使用するソフトウェアの知財部門が外国にあったら、だれが法務文書として正しさを保証して翻訳するのか、などなど、考えると頭が痛いです。
ということで、ライセンスを作るのはダメな行為ナンバーワンです。

ではどうするか。
まあ、普通は Open Source Initiative の定めている オープンソースライセンス (日本語訳) から選ぶことになると思います。

個人的には次の三つ（実質二つ）から選ぶことになるんじゃないかなと。

• MIT
• 修正BSD
• GPL

今更説明の必要もないですが、MIT も修正 BSD もほぼ同じです。「無保証だから勝手に使ってね、好きにしていいよ」というもの。

GPL は「ソフトの修正、改変、再配布の自由を守るため、ソースコードの入手の権利を守ろう」という意図のもの作られたライセンス。

どちらを選ぶかははっきり言えば、あなたのプロジェクトを元に他人に商売されてしまって構いませんか？ というその一点につきるかと。
ライセンスでよく問題になるのは「GPL互換性」と呼ばれるもので、これはGPLソフトウェアと組み合わせて使うことができるかということを意味するのですが、上述の三つはすべてその条件を満たしていますから大丈夫です。

どれを使うか悩んだら既存の自分の分野に近いオープンソースのライセンスを参考にするのがいいんではないでしょうか。
たとえば会社でやる場合であれば他社動向とか、自分の専門から遠い話を選ぶと(笑) CMS なら WordPress は GPL なので、GPL にしても問題ないんだろうなぁと思います。

あと GPL のばあいは v2、v3 どっち？ という問題がありますが、現状は v2 or later かなあと思います。詳しくは省略*1。

なおライセンスのアナウンスについてはオープンソースソフトウェアの育て方に説明があるので、と書いて逃げる。

著作権譲渡ってすべきなの？

詳しくはオープンソースソフトウェアの育て方の「著作権の保有と譲渡」をこれまた参照いただくとして。

この手の議論は考え出すと切りがありませんが、少なくともプロジェクトのスタートアップのときにはライセンスを後で変えられるように手は打っておいた方がいい著作権は集約しておいた方がいいような気がします。最初のときに関わってくれた人が疎遠になったとしても、その人は立派な著作者なので、例えばライセンス変更などには許可を取る必要が出てきます。そこで「貢献者ライセンス同意書 (Contributor License Agreement)」をあらかじめ取り交わして置けば、このような場合でも安心できます。CLA については上記リンク参照。
著作権譲渡はわりと厳密な法務処理になるので、相談できる弁護士などがいない場合は、プライベートプロジェクトの場合は CLA だけで処理するのが望ましい気がします（と、Karl Fogel も言っています）。
(注：プライベートなプロジェクトについてもっとも適した方法と思われる CLA について記載がなかったので追記しました。2010.03.24)

企業の場合は多分企業で書いたコードは会社に著作権が移るよう雇用契約に入っていると思うので、開始時はそれでいいでしょう。

その後、例えばパッチなどの修正をもらった場合の話ですが、ぶっちゃけた話、よっぽどクールなプロジェクトでもないかぎり、すぐに貢献者が押し寄せることは少ないので、それまでにじっくり考えて結論を出せばいいと思います。

サイト

もちろん専用サイトを立ててもいいですが、Github か SourceForge といったオープンソースをたくさんホスティングしているサービスを利用した方がいいと思います。

必要なサービスとしては

• ソースコード管理システム
• バグ追跡システム
• メーリングリスト（アーカイブ機能付き）
• Web フォーラム（オプション）

などがあるでしょう。これらを提供しているサービスがおすすめです。

サイトのトップページにはプロジェクトの概要、プロジェクトへの参加の仕方、先に書いたライセンス、などなどの情報が必要です。

ただソースをぽんと乗っけるだけでなく、最低でも手元で動かして試してみるまでの方法ぐらいのドキュメントは用意しておきましょう。手元で動かないものに人は関心を持ちません*2。

てなわけで

結局「オープンソースソフトウェアの育て方」読め！ で終わってしまう内容でしたが、スタートアップとしちゃこんなもんですかねえ。

まあ、企業で始める場合、ここまで持ってくのもけっこう大変だとおもいますけどね。自社サイトで tarball を公開するのですら相当のハードルがあるでしょうからねえ。
でもここまではできればやりたいなあ*3。

*1:質問いただいたのでコメント欄に書いておきました。

*2:もちろん、OSSとしていきなり公開するというより、まずは元の仲間内のソースコード置き場がみんなの見えるところにある、ということから始めるのが悪いとはいえません。その場合、ドキュメントは二の次でもいいと思います。でもその場合はその旨をちゃんと謳い、ライセンス面ははっきりさせたほうがいいとは思います。

*3:これは個人の見解であり私の所属企業とは何ら関係が……いい加減書くの疲れた。