コミュニティのしきたりによるOSSプロジェクトの違い

あるいはオープンソースといいつつ、同じライセンスでもそのオープンさには差があるということ。
OSSプロジェクトと言えば、

• ソースコードに自由にアクセスできて
• プロジェクトへの参加も自由である

というイメージですが（個人的には）、いくらライセンスがOSS互換ライセンスでも、実は後者はプロジェクトコミュニティの性質によってえらく変わってしまうなあ、という気がしています。

1. OSSライセンスだが、プロジェクトに参加しにくい、あるいは出来ない。

私が知っている限り、この様な状態のプロジェクトは3種類あります。

• 一つは企業などがGPLでソースコードだけ公開しているけれども、そもそも開発コミュニティが存在しないケース。Linux向けドライバではよくあるケースですね。
• もう一つは、開発コミュニティが存在しているけれど、開発はさらに内輪の限られた人しかしないケース。外部からのパッチは、ほとんどが無視されてしまうし、プロジェクトの方向性も、内輪の面々が勝手に決めてしまう。レアですが、LinuxでいうとL○Mとかがいい例ですね。
• 最後の一つは、開発コミュニティが存在していて、パッチは投げれるけれど、主要開発者が書き換えた上でコミットしてしまうケース。これはMySQLなど後々ライセンスが気になる企業がやっている（やっていた？）例を聞いたことがあります。GPLでも、著作権者はパッチ作成者になってしまうので、後々ライセンス変更したい場合大変なことになります。（GNUのツールもそうなんだっけ）

2. OSSライセンスで、プロジェクトへの参加もオープン

これは一般的なOSSプロジェクトの形態ですね。コミュニティの構成人員によっては、参加しにくい例もあるのかもしれませんが、だいたいは、バグ修正パッチなどを投げると、喜んで取り入れてくれるし、それを利用した別のプロジェクトがあっても、特に気にはしません。

3. OSSライセンスで、プロジェクトへの参加が強制的

LKMLでメンテナの意見などを見ていると、Linuxカーネルコミュニティというのは、out-of-treeのコード（たとえそれがGPLであれ）を極端に嫌う傾向があります。nouveauドライバの話も、ツリー外部で作らず、マージしてくれという要望に応えたケースですし、Androidの話は、これに応えられなかったケースですね。もちろん、これにはドライバAPIが流動的なので、out-of-treeのコードはすぐ陳腐化してしまうという、きちんとした理由があるのですが。
ただ、このタイプのコミュニティでの開発は、時として非常に難しくなります。他のメンバに機能の必要性や、コードレビューなどを通してから採用されることになるし、機能の実装方法やデザインが議論の結果によって変わってしまったりすることもざらです。機能自体否定されることだって考えられます。一定期間内に予想した成果を挙げていかなければならない企業にとっては、非常にやっかいなケースですね。

AndroidはGoogleが進めているOSSプロジェクトと言っても、やはり彼らのビジネススケジュールにしたがってリリースすることが求められるので、Linuxカーネルコミュニティと折り合いをつけてやっていけるようになるには、しばらく時間がかかることになると予想します。