本論に入る前にここで扱うオープンソース開発者の定義であるが、その対象者がオープンソースソフトウェアの作者もしくはプロジェクトに深く関わるコミッターであり、さらに企業側はその開発者が関わるオープンソースソフトウェアに関連した能力(単なるソフトウェア開発の技量面もあればマーケティング面もある)を買うという場合を想定する。オープンソースもしくはフリーソフトウェアに対する思想については、特に想定はしていない。
著作権の所在
オープンソースは著作権を元にした考え方であり、オープンソースを扱う以上は著作権の問題は避けられない。オープンソースに対して強い(例えば狂信的な)思想を持っているかどうかに関わらず、著作権の所在については開発者を雇う前に明確にポリシーを決めておく必要がある。
一般的な感覚からすれば、対象となる開発者が採用後に勤務時間内または勤務の一環として行った作業において作成されたコードについては、採用側の企業が著作権を持つことが妥当である。ただし、オープンソースのプロジェクトに関わる場合においては、企業側が権利を主張しないほうがよい場合もあるわけであり、それは採用前に少なくともある程度のコンセンサスは取っておくべきである。また、勤務時間外に作成されたコードの権利の所在で混乱を防ぐためにも、そもそも業務の範囲外でオープンソースのコードを作成することを認めるのか、認めるならどの時間にどの社内リソースを使わせることを認めるのか、そのコードの権利はどこに帰属するのか等、これらを明確にしておくべきである。ベストなのは、企業としてあらかじめオープンソースプロジェクトに参加する場合の指針を作成し、さらに特殊なケースが発生する場合に備えて個々の採用時において柔軟に例外を設ける仕組みと、それを常に採用する開発者の上司となる人間が把握できる環境を作っておくことである。
私の考え方では、採用後に社内リソースを使用して作成されたコードについては、コードのマージ等に不都合が出るといった場合やその対象者が全面的に権利を保持しているプロジェクトを除き、基本的に著作権はひとまず企業側が持つほうが都合がよいと考えている。これはそもそも社内リソースを使用する時点で企業の研究開発活動と同一であると考えることができるということもあるが、そのような活動を認めるかわりにそこで生まれたコードをいつでも企業の戦略に応じてコントロールできる状態にしておくことができるからである。企業の戦略が変わることはよくあることであり、それによってクローズドを含めてライセンスが変更されることもあるだろう。戦略変更に際してのトラブルはなるべく少ないほうが企業によっては良いことである。
このポリシーは、開発者にとって冷たい態度と一見思われるかもしれないが、私はむしろこのほうが開発者にとっても都合がよいと思っている。産み出されたコードをビジネスに結びつけるための強い動機付けにもつながると考えるし、そもそも権利の所在ははっきりとさせておくほうがよいと考えると線の引きやすいところで線を引く方が都合がよい。このポリシーが気に入らないなら、プライベートな時間にプロジェクトに参加すればよいわけであり、また著作権を企業が保持していたとしてもオープンソースライセンスであればそのフォークも自由である。運悪くその開発者が会社を去ったとしても、オープンソースプロジェクトから開発者が退場させられるわけではないし、原作者であれば元の企業の影響を(やろうと思えば)排除することも可能である。多くの場合、企業はそのリスクを承知しているわけであり、企業はプロジェクトへの影響度を考慮した上で、その開発者を引き留めるために最大限の誠意を尽くすことになるわけである。
商標と特許
著作権と違い商標については多少異なる対応が必要である。EtherealからWiresharkへの名称変更の事件がまだ記憶に新しいが、商標の問題は軽く見られがちにも関わらずトラブルは意外に多い。私が以前Debian JP Peojectに対し、商標を取得を勧めたことがあるのもこの考えからである。
私はオープンソースソフトウェアを開発/販売/サポートする企業、もしくはそれなりに大きな規模となったオープンソースソフトウェアのプロジェクトは積極的に商標登録すべきだと考えている。何故なら、商標はさほど取得が難しくなく、事実上プロジェクトにも何の関係もないような第三者にも取得が可能にも関わらず、その取得による独占的権利の付与はかなり大きなものがあり、ビジネスへの影響どころかプロジェクトの運営にさえ影響を及ぼすことができるからである。多少金銭は多めにかかるが、インターネットドメインをとりあえず押さえておくという行為の延長ぐらいの心構えでも構わないのではないかと思う。
話を元に戻すが、これから採用する開発者がそれなりに大きなプロジェクトを率いているような場合、もし採用側の企業がそのプロジェクトの成果物を利用したビジネスを考えているのであれば、そのプロジェクトの名称の商標登録を企業の負担で行ったほうがよいだろう。
どちらが商標の所有者となるかは企業のポリシー次第であるが、商標についてはあまり企業側が所有者であることを主張しても意味がないケースが多いと考える。Etherealの件はどのような利害関係があったのか知らないので何とも言えないが、普通に考えれば、原作者に転職されてしまった企業がその後もプロジェクトを率いてさらにビジネスも行えるのであれば商標を保持しても構わないのだろうが(採用前に既に大きなプロジェクトになってるなら倫理的な問題はあるだろう)、そうでなければ持っている意味はない。やはり、いざとなれば原作者に名前を変えられてプロジェクトを継続されてしまうわけであるし、そもそも転職された時点でそのプロジェクトの成果物を利用したビジネスの継続性が失われている可能性すらあるだろう。これらのことを考えると、商標については第三者に渡さない ということを第一に考え、所有権については柔軟に対応したほうが得策だと考える。 商標は所有権の移動が容易であり、コードのように切り分けが難しいものではないので、 開発者が転職した場合に引き渡すというポリシーでもよいかもしれない。
特許については、非常に難しい問題ではあるが、少なくとも開発者の採用時にはソフトウェア特許に対する企業としてのポリシーを示しておく必要があるだろう。日本のオープンソース界隈においてはほとんどトラブルを聞かないので実はあまり問題ではないのかもしれないが、将来的に社内で主義主張のいざこざを起こさないためにも先に説明はするべきだと考える。
プロジェクト活動の保証
著作権の項で勤務時間内もしくは社内リソースを使用したオープンソースプロジェクト活動を認めるかどうか、といった点について触れたが、実際のところオープンソース開発者を雇い、そのプロジェクトの成果物を利用したビジネスを行っている場合は、それが業務の一環なのかそうでないのか区別が付かない場合が往々にして発生するだろう。バグやセキュリティホールが発見されれば修正するべきだし、ユーザへの対応もあるはずである。また、プロジェクトの性質によっては、競合となる企業との協力を余儀なくされるケースも出てくる。
このようなことを見越した上で、コードの権利だけでなく企業外のプロジェクトでの活動をどのような行為とどの程度の時間行えるのかといった指針を採用時に示し、その上司が 行動を把握できるようにしておくほうがよい。それが行われてなければ、雇われた側の開発者からすれば一生懸命働いているという認識であるにも関わらず、社内では全く働いていないという見方が広まるだけになってしまうだろう。これはせっかく雇った開発者の入社後の評価に影響することなので、細かく定めておくに越したことはない。
この行動の事前の定義と行動把握については、企業の内部統制という意味でも重要かもしれない。これは主観ではあるが、昨今の日本版SOX法をはじめとする企業の内部統制への世の中の動きを漠然と見ていると、きちんとプロジェクトへの関わりを定義しておかなければ、後で面倒なトラブルの発生に繋がりそうな気がしてならないのである。
他には、プロジェクトの参加に関わる費用についても考えておくべきかもしれない。 オープンソース開発者が企業活動の一環として所属するオープンソースプロジェクトに関連する何らかの活動を行えば、その費用は企業の負担となる。開発行為の場合であれば、研究開発費とするのかあるいは市場販売目的として無形固定資産と扱うのかといったことで償却に違いがでてくる。また、企業がオープンソース開発者を雇う理由には単なるプログラミング等の能力だけでなく、プロジェクトでの立場を踏まえたビジネス面への影響を考慮する場合も往々にしてあると思われるが、そうであれば広告宣伝費としてマーケティング費用から活動の種類によっては出せる費用もあるだろう。
これらは企業によって事情は異なるだろうが、オープンソースプロジェクトを運営していくにはそれなりに費用がかかるものであり、プロジェクトに関わりを持つことでビジネスに役立てていこうとするのであればプロジェクトの運営にそれなりの費用をかけることを見越した予算化を行わなければならない。もちろんこの予算化は企業としてそのプロジェクトのどのような面を強化したいのかといったことで項目も金額も異なってくる。また、突発的に会合費等が発生する場合にも備えておいたほうがよいが、この場合はマーケティング費用である程度カバーできるようにしておくほうがよいだろう。
そもそも何のためにオープンソース開発者？
一般的に多くのIT企業は社員である開発者の成果を全て企業に属させ、その成果を販売することで利益を上げている。穿った見方をすればオープンソースプロジェクトに社員に関わることはその成果の流出と見ることもできるし、外部組織とのコラボレーションによる コスト削減、開発と普及促進、はたまたもっと高尚な言葉を使えばイノベーションの促進と考えることもできる。
企業がオープンソースのビジネスを進める場合には必ずビジネスモデルを定めているわけだが、その戦略にオープンソースはどのように絡みどのような影響を及ぼすのか企業はよく考える必要がある。さらにそのために採用に踏み切る開発者がいるのであれば、その開発者に対し、その大きな戦略を最初に理解させる必要がある。そうしなければ、開発者は何のために企業に属している意味を見失い、企業から制御が難しい状態となってしまうだろう。
また、開発者に対しては心のケアも重要である。元々オープンソースの開発に関わってきたものであれば大なり小なりそのプロジェクトへの忠誠心というものを持っている。これが企業に属すれば企業への忠誠も必要になり、これがある時にはほんのちょっとしたことであっても板挟み状態が重荷となってしまうだろう。逆に企業内でずっと過ごしてきた開発者にとっても突然オープンソースのコミットを求められるようになると、外部組織とのコミュニケーションに慣れていないために過大なストレスが生じる場合もあるだろう。これを防ぐ意味でも企業には開発者に戦略の意味を理解させ、それを十分に納得させる土壌を作っておくことが重要なのである。
終わりに
さて、本稿ではオープンソース開発者を雇う前に企業が事前に考えておくべきことを経験も踏まえた上で思いついたままにずらずらと列挙してみた。特にオープンソース開発者という枠に捕われない事項もあると思うし、逆に足りない事項も多いだろう。コメントは歓迎するし、まとまった意見であれば記事として投稿してもらえると嬉しい。
佐渡秀治
OSDNの責任者。担当する職務が年々増えるが、管理する人間が増えないという典型的なしがない管理職。