おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

ソフトウェアエンジニアと法務

さて二日続けて法律関係の本をレビューしてきましたが*1、なんで基本的には技術ブログであるはずのここで法律の話をしているかってことをちょっとだけ書いておきます。

結論からいってしまうと、これからのソフト屋は法律と無縁ではいられないというか、法律に関して嗅覚が働くエンジニアは色々と必要になると思うからです。

なんて話は「法務系LT」の飛び込みLTでもしたんですが、なぜか書いたはずの参加レポートが行方不明なので詳しくはそちらで。まぁ、繰り返しになりますけどね。

新しいソフトウェア・サービスの提供のために

例えばですね、よく言われることなんですけど、Google さんって「法律上、グレーだったらやっちゃう」的な所があるじゃないですか。クレームがついたり訴えられたりしたら考えればいいやみたいな。でもそれって、別に蛮勇なわけじゃなくて、「このグレーはどれぐらいリスクがあるグレーで、それに対してこのサービスを提供する価値はこれだけあるから、じゃあ GO」って判断を「会社として」してると思うんですよね。多分だけど。

でも、大抵の日本の会社組織では、法務・知財担当者は事業部門にいるわけではないので、基本的には事業判断ができないんですよね。ので「リスクがありますよ」としかいえない(それが「あります」なのか、もっとブレークダウンしてくれてるかはそれぞれの事情で違うだろうけど)。じゃあサービスを開発する側が判断を下せるかっていうと、あるリーガルリスクが顕現する可能性はどれぐらいあるのか、起きたときの損害はどれぐらいなのか、それを回避する方法はないのか、ってことがわかんないとどうしようもないですよね。ので、サービスを開発する側と法務面でのリスクをチェックする側ががっちり組んでいかないと、世界とは戦っていけないわけですよ。となると、せめて法務担当者と共通言語を持ってないと色々と辛い。

内作マンセー主義との決別のために―利用するためのライセンスの理解―

他の例として、ライセンスの問題がありますよね。

あるサービスを提供するためのソフトウェアのサイズが極度に肥大化している昨今、今や一から十までぜんぶ自社開発ってことは多分なくて、誰かが作った OS の上で誰かが作った言語処理系を使い誰かが作ったライブラリとリンクして誰かが公開してる Web API を叩いてサービスを提供するのが普通ですよね。それら一つ一つに「ライセンス」があるわけで、それらをちゃんと理解して使わないといけない。というか、使うものを選定する際に、ライセンスの理解は本来ならば必須なんです。が、それを「めんどくさいから」といって放置してると、いつか地雷を踏みかねません。

逆に、自身がなんか新しいサービスやライブラリや FLOSS を提供するとき、どういうライセンス、どういう使用許諾にするのがいいか。自社に法務担当がいれば相談してもいいですが、自社内に前例がないサービスの場合、自社の法務担当が必ずしもベストな解を持ってるかっていうと分からない。そういうときに、提供するものを知り尽くしている自分たちから「このライセンスをそのまま使ったほうがいいんじゃないか」*2 とか「こういう条件を付けたいんだけどどういう条項を盛り込めばいいか」とか「他社だとこういう内容になっているが参考にならないか」とか提案できたほうがいいですよね。

ユーザーとしてのライセンスの理解

これは「契約の教科書」にちゃんと取り上げられてるので、詳しくはそこ読んでって話になりますが。

ソフト業界の人というのはさまざまなネットサービスのヘビーユーザーであることがしばしばだと思います。そしてネットサービスを利用する際にもやっぱりそのサービスの利用規約に「同意する」ボタンをクリックするってことをしょっちゅうしてるわけじゃないですか。それをどれだけ真剣に読んだことがありますか? というお話もある。

使用許諾も広い意味での契約行為*3 なので、「自分が何に同意しているのか」を知らないというのはやっぱちょっとマズいわけで、やっぱそーゆー意識はもってないとねって話です。T先生が問題にしないと気づかない、ってのはしょうがないと思うんだけど、自分では気づかなかったくせに、T先生が吊るすと一緒になって吊るし上げるのはカッコ悪いと私は思う。

アウトソースにおける契約とか

さっきのライセンスの話でも書いたのだけど、やっぱりソフトウェアの規模が膨大になってくる昨今、一から十まで自社でやりきるのはしんどい。で、外からもらってきたり買ったりする以外に、当然「外に委託する」って話が出てくるわけじゃないですか。そうなると当然、これは契約交渉という話になる。

私の前職のようなところだと契約ってだいたい雛型が用意されてて、あとは社名の部分だけ差し替えて終わりみたいになってることが多い。逆に相手が MS とか Adobe とか Apple だと、向こうの雛型をまるっと受け入れる以上のことができないことが多い。ので、担当してる人自身は「自分が相手とどういう契約を結んでるのかどうか」ってあんまり把握してない気がする。私だけかしら?

まぁここらへんは「契約の教科書」に詳しいので繰り返さないですけど、やっぱり「自分はビジネスパートナーとなにを約束したのか」「トラブルが起きたときにはどういう風に問題解決することになるのか」「プロジェクトの遂行の武器として契約をどう使っていくのか」みたいなことを考えたほうがいいと思うんですよねー。

就業規則との付き合い方

こんなところを読んでくれてる方には、IT 系イベントとかお好きな方も多いかと思います。ただ聞くだけでなく、積極的に登壇されてるかたも少なからずいるでしょう。それはとても素晴らしいことだと思います。

ところが企業によっては、就業規則守秘義務規定を盾にとって、「対外発表を行う際には必ず上司の許可を得ること」とかいう決まりがあることがあるんですよね。発表内容が明らかに公知性があるものであったとしても、「公知性があるかどうか判断するのは会社だから」とか言われたらどう反論するか。

あるいは、自社で開発に使っている FLOSS があった。例えばサービス基盤が Linux だったりとか、MySQL とかのミドルウェアだったり、Ruby とか PHP みたいな言語処理系自体とか、Rails みたいなフレームワークとか、そういうののバグが自社のテストケースで見つかった。けど、「テストケースは自社の知的財産だからそのまま BTS するのは罷りならん」とか言われたらどうしましょう?

もうちょっとブラックな話として、不当な残業であったりとか、残業禁止を命ぜられたけど結局在宅で仕事しないと間に合わないとか、そういう労基にひっかかりそうな話とか。これは前に @kwappa さんが勉強会したりしてたなぁ。

人事に目を付けられるリスクを無視しつつこーゆーことを知らん顔してやっちゃうってマッチョなやり方を否定するつもりはないんですが、仮に上司を飛び越えて人事から話が来た場合、穏当に解決する方法を探るために理論武装したりとかってことも必要になったりするのかもしれませんね。

……え、そんな会社やめちゃえばいい? ま、それは一つの見識ですね。

そんなわけで

ソフト屋が法律とコンニチワするケースってすごくたくさんあるわけで、それを「我が身のものとして」考えることがますます求められていくと思うのですね。だから「リーガルマインド」とでも呼べるようなものをちょっとでも持ったソフト屋ってこれから重要性を増してくるんじゃないかと。

ただし、これは法務系LTのときに言われたんだけど、エンジニアがうっかり法律をかじると、「これは法律的にヤバイかもしれないからやめとこう」って勝手にアイディアを引っ込めちゃうことがあるんだって。さもありなん。

ので、単に自力で勉強するだけじゃなくて、勉強した結果として法務な人、知財な人とお話できるぐらいになって、仲良しを増やして、面白いことをやるときに「ねえねえ、この新しいアイディア、面白そうでしょ? でも自分の感覚だとこういうリスクがあるように思うんだけど、どうだろ? 回避できる方法とか一緒に考えてくれない?」みたいにカジュアルに相談を持ちかけて、協力してもらえるようになったりすると楽しいんじゃないかなーって。

明日は特にネタがないのですが、できれば技術ネタに戻りたいなぁ*4

おまけ

なお当方、えらそーなこと書いてますが、例えば MicrosoftWindows Driver Kit に同梱しているサンプルソースを元にしつつもりもり書き換えたモジュールを同梱したプリンタードライバーの About 画面に MS の portion copyright が必要かどうか分からないぐらいには知識はありません(^^; サンプルコードの権利関係については規定があったよーな記憶がありをりはべりいまそかり。

*1:と、ここで書いている今現在、レビュー自体は書きあげてないわけですが orz

*2:自社で FLOSS をリリースするならこれ以外の選択肢は考えたくないですよねー。

*3:法律用語としての契約と約款の違いとかはよく分かってないです ^^;

*4:と書いたエントリが公開が遅れてしまったので、なんかアレですが。