オープンソース開発者を雇う前に解決すべき課題：マネジャーの教科書（1/2 ページ）

オープンソース開発者を雇いたい、と考えている企業は最近では珍しくないのかもしれない。ここではその前に企業として考えておくべきことを幾つか述べることとする。

[佐渡秀治，Open Tech Press]

　オープンソース開発者を雇いたい、と考えている企業は最近では珍しくないのかもしれない。その動機はさまざまだと思われるが、ここではその前に企業として考えておくべきことを幾つか述べることとする。

　本論に入る前にここで扱うオープンソース開発者の定義であるが、その対象者がオープンソースソフトウェアの作者もしくはプロジェクトに深くかかわるコミッターであり、さらに企業側はその開発者がかかわるオープンソースソフトウェアに関連した能力（単なるソフトウェア開発の技量面もあればマーケティング面もある）を買うという場合を想定する。オープンソースもしくはフリーソフトウェアに対する思想については、特に想定はしていない。

著作権の所在

　オープンソースは著作権を元にした考え方であり、オープンソースを扱う以上は著作権の問題は避けられない。オープンソースに対して強い（例えば狂信的な）思想を持っているかどうかにかかわらず、著作権の所在については開発者を雇う前に明確にポリシーを決めておく必要がある。

　一般的な感覚からすれば、対象となる開発者が採用後に勤務時間内または勤務の一環として行った作業において作成されたコードについては、採用側の企業が著作権を持つことが妥当である。ただし、オープンソースのプロジェクトにかかわる場合においては、企業側が権利を主張しない方がよい場合もあるわけであり、それは採用前に少なくともある程度のコンセンサースは取っておくべきである。また、勤務時間外に作成されたコードの権利の所在で混乱を防ぐためにも、そもそも業務の範囲外でオープンソースのコードを作成することを認めるのか、認めるならどの時間にどの社内リソースを使わせることを認めるのか、そのコードの権利はどこに帰属するのかなど、これらを明確にしておくべきである。ベストなのは、企業としてあらかじめオープンソースプロジェクトに参加する場合の指針を作成し、さらに特殊なケースが発生する場合に備えて個々の採用時において柔軟に例外を設ける仕組みと、それを常に採用する開発者の上司となる人間が把握できる環境を作っておくことである。

　わたしの考え方では、採用後に社内リソースを使用して作成されたコードについては、コードのマージなどに不都合が出るといった場合やその対象者が全面的に権利を保持しているプロジェクトを除き、基本的に著作権はひとまず企業側が持つ方が都合がよいと考えている。これはそもそも社内リソースを使用する時点で企業の研究開発活動と同一であると考えることができるということもあるが、そのような活動を認めるかわりにそこで生まれたコードをいつでも企業の戦略に応じてコントロールできる状態にしておくことができるからである。企業の戦略が変わることはよくあることであり、それによってクローズドを含めてライセンスが変更されることもあるだろう。戦略変更に際してのトラブルはなるべく少ない方が企業によっては良いことである。

　このポリシーは、開発者にとって冷たい態度と一見思われるかもしれないが、わたしはむしろこの方が開発者にとっても都合がよいと思っている。産み出されたコードをビジネスに結びつけるための強い動機づけにもつながると考えるし、そもそも権利の所在ははっきりとさせておく方がよいと考えると線の引きやすいところで線を引く方が都合がよい。このポリシーが気に入らないなら、プライベートな時間にプロジェクトに参加すればよいわけであり、また著作権を企業が保持していたとしてもオープンソースライセンスであればそのフォークも自由である。運悪くその開発者が会社を去ったとしても、オープンソースプロジェクトから開発者が退場させられるわけではないし、原作者であれば元の企業の影響を（やろうと思えば）排除することも可能である。多くの場合、企業はそのリスクを承知しているわけであり、企業はプロジェクトへの影響度を考慮した上で、その開発者を引き留めるために最大限の誠意を尽くすことになるわけである。

商標と特許

　著作権と違い商標については多少異なる対応が必要である。EtherealからWiresharkへの名称変更の事件がまだ記憶に新しいが、商標の問題は軽く見られがちにもかかわらずトラブルは意外に多い。わたしが以前Debian JP Peojectに対し、商標を取得を勧めたことがあるのもこの考えからである。

　わたしはオープンソースソフトウェアを開発/販売／サポートする企業、もしくはそれなりに大きな規模となったオープンソースソフトウェアのプロジェクトは積極的に商標登録すべきだと考えている。何故なら、商標はさほど取得が難しくなく、事実上プロジェクトにも何の関係もないような第三者にも取得が可能にもかかわらず、その取得による独占的権利の付与はかなり大きなものがあり、ビジネスへの影響どころかプロジェクトの運営にさえ影響を及ぼすことができるからである。多少金銭は多めにかかるが、インターネットドメインをとりあえず抑えておくという行為の延長ぐらいの心構えでも構わないのではないかと思う。

　話を元に戻すが、これから採用する開発者がそれなりに大きなプロジェクトを率いているような場合、もし採用側の企業がそのプロジェクトの成果物を利用したビジネスを考えているのであれば、そのプロジェクトの名称の商標登録を企業の負担で行った方がよいだろう。

　どちらが商標の所有者となるかは企業のポリシー次第であるが、商標についてはあまり企業側が所有者であることを主張しても意味がないケースが多いと考える。Etherealの件はどのような利害関係があったのか知らないので何とも言えないが、普通に考えれば、原作者に転職されてしまった企業がその後もプロジェクトを率いてさらにビジネスも行えるのであれば商標を保持しても構わないのだろうが（採用前に既に大きなプロジェクトになってるなら倫理的な問題はあるだろう）、そうでなければ持っている意味はない。やはり、いざとなれば原作者に名前を変えられてプロジェクトを継続されてしまうわけであるし、そもそも転職された時点でそのプロジェクトの成果物を利用したビジネスの継続性が失われている可能性すらあるだろう。これらのことを考えると、商標については第三者に渡さないということを第一に考え、所有権については柔軟に対応した方が得策だと考える。商標は所有権の移動が容易であり、コードのように切り分けが難しいものではないので、開発者が転職した場合に引き渡すというポリシーでもよいかもしれない。

　特許については、非常に難しい問題ではあるが、少なくとも開発者の採用時にはソフトウェア特許に対する企業としてのポリシーを示しておく必要があるだろう。日本のオープンソース界隈においてはほとんどトラブルを聞かないので実はあまり問題ではないのかもしれないが、将来的に社内で主義主張のいざこざを起こさないためにも先に説明はするべきだと考える。