-
- いいね！0
Yusuke SATO
@satob
情報システムの受託開発で、OSSに依存するアプリを開発したとしよう。さらに、そのアプリの開発中に、当該OSSのバグを見つけたとしよう。この場合、条件によっては、発見者はパッチの投稿も、バグの報告もできず、そのバグの情報は永遠にお蔵入りになるのでは？という思考実験。
2017-05-25 09:54:57
Yusuke SATO
@satob
(続き)まず、あなたの会社では、知財管理の関係から、「業務情報」の社外提供には役員レベルの判子が必要だとしよう（大きな会社の場合、これは非常にハードルが高い）。また、あなたの作業に対する支出はすべて、あなたが現在作業中のプロジェクトの財布から出るとしよう。
2017-05-25 09:55:22
Yusuke SATO
@satob
(続き)また、このバグは、OSS自体の修正なしに（ラッパーを書くとかで）回避可能であるとしよう。プロマネからは、OSS自体の品質保証の責任を負わないように、OSS本体に手を入れるのは避けること、という指示も来ているとしよう。
2017-05-25 11:14:33
Yusuke SATO
@satob
(続き)そんなに無茶な前提ではないと思うが、どうだろう？「OSSは利用上問題となるバグがないのを精査してから利用すること」「バグはそのうち誰かが直すか、過去に誰かが回避策を見つけてるだろ」みたいな考え方の会社なら、この程度は普通なんじゃないか？
2017-05-25 11:15:22
Yusuke SATO
@satob
(続き)さて、あなたはこのバグを業務アプリの開発中に見つけたので、このバグの情報は業務時間中に得られた業務情報と判断され得る。業務情報であれば、まず「これってバグかな？」という質問をそのOSSのフォーラムとかに投げることは、個人的な活動としては行えない。
2017-05-25 20:07:25
Yusuke SATO
@satob
(続き)「業務情報であれば」というより、公開されているソフトウェアの挙動に関する知識を「業務情報である」と判断している相手が社内にいた場合、「それは業務情報には当たらないのでは」という合意を形成するのが困難、という方が実態に近いな。
2017-05-25 20:07:52
Yusuke SATO
@satob
(続き)さて、ここで既に自分で当該バグの回避策を見つけていたとしよう。この場合、プロジェクトの職務上の作業として、同様の質問を当該OSSのフォーラムに投げる（で、誰かにBTSに登録してもらう）ことはできない。これは、プロジェクトの財布に影響があることに起因する。
2017-05-25 21:28:13
Yusuke SATO
@satob
(続き)すでに回避策があるのだから、その作業はプロジェクトの財布に対して追加の支出にしかならない。そのため、フォーラムへ投げるという作業内容について、プロジェクトの作業として妥当であるという説明責任が果たせない（プロジェクトの金を関係ない作業に流用したことになってしまう）。
2017-05-25 21:29:59
Yusuke SATO
@satob
(続き)では未解決の問題なら質問ができるかというと、そうでもない。開発用ツールのサポート契約に「提供した情報は問題の原因調査以外に使わない」等の条項があるケースなら、業務としての開発元への問い合わせにもOKが出やすいが、サポート契約のないOSSではそうはいかない。
2017-05-25 23:43:27
Yusuke SATO
@satob
(続き)じゃあいきなりパッチ書いて送り付けたらいいじゃないか、となるが、そうもいかない。バグの回避策としてラッパーを書いてたりすると、ラッパーの内容とパッチの内容がどうしても似通ってしまう。知財部門に「このソース社外に持ち出したでしょ、社則違反ね」と言われると切り返せない。
2017-05-26 06:45:25
Yusuke SATO
@satob
(続き)幸運にも知財部門がOSSにある程度理解があって「パッチ出すなら業務としてやりなさい（そこから生まれるうまみを期待してる）」と言ってたとしよう。今度は、開発作業の認可を出す部署が問題になる。
2017-05-26 06:46:01
Yusuke SATO
@satob
(続き)開発作業認可を出す部門の目標に「不要不急の開発は避ける」とかがあったりすると不幸で、知財部門は「出すなら業務として出せ」と言ってるのに、開発作業の認可をする部署は原価低減のために「じゃあそもそも出さなきゃいいじゃん」と言ったりする。
2017-05-26 20:05:48
Yusuke SATO
@satob
(続き)社内に緊縮財政が敷かれてたりすると、そういう目標が設定されがちですね。で、その結果、プロマネはパッチの作成と投稿に必要な工数をプロジェクトに積むことができず、「そのパッチの公開に必要な作業、誰のお金でやるの？」ということになる。
2017-05-26 20:06:18
Yusuke SATO
@satob
(続き)さて、幸運にもプロジェクトの財布に余裕があり、知財部門もプロマネもOSSへのコントリビュートに対して理解があったとしよう。かなり幸せな環境だが、それでもパッチの提供はできない可能性がある。
2017-05-26 22:13:57
Yusuke SATO
@satob
(続き)業務アプリの受託開発では、お客様へソースを納品する際に「成果物の著作権はお客様へ譲渡する、開発元は著作者人格権を行使しない」という契約になってることがよくある。
2017-05-26 22:14:20
Yusuke SATO
@satob
(続き)そのため、問題のバグの対策用ラッパーを含むアプリをお客様へ納品した後では、パッチの提供可否の判断は自社では行えず、お客様の組織の役員レベルの判子が必要になるという、かなりな無理ゲーになってしまう。
2017-05-26 23:34:03
Yusuke SATO
@satob
(続き)また、お客様に納品する前にパッチをOSS本体へ組み込めたとしても、結果としてお客様に納めるソースにはOSSの一部によく似たコードが含まれることになる。お客様が自己監査でそのコードを見つけたときにどうなるかを考えると、パッチの提供はためらわれる。
2017-05-26 23:34:28
Yusuke SATO
@satob
(続き)開発の初期にOSSのバグを発見し、パッチを提供して、それが取り込まれた最新バージョンのOSSを使ってアプリの再テストを消化し納品、とトントン拍子で行けば、これまで挙げた条件をクリアできなくもない。
2017-05-27 08:47:56
Yusuke SATO
@satob
(続き)ただ実際には、そもそも開発初期に利用にあたって致命的なバグの見つかったOSSは「利用しない」という判断がされるだろうし、それにバグが見つかる頻度はテストケースの消化が本格化する開発中期以降の方が高いから、これは成立するケースの方が少ないだろう。
2017-05-27 08:48:15
Yusuke SATO
@satob
(続き)実際は、開発の初期にOSSに軽微なバグが見つかり、パッチをupstreamへ提供したらラッパーは削除、テスト環境は古いバージョンのOSSのままでテスト消化を継続。件のバグが再現するテストケースの消化は後工程まで保留するのが現実的かな。
2017-05-27 11:41:54
Yusuke SATO
@satob
(続き)その上で、パッチが取り込まれた最新バージョンのOSSがリリースされたら、正式なテスト環境は古いバージョンのOSSのまま、別に新しいバージョンのOSSを入れたテスト環境を立ち上げ、保留にしてたテストケースは但し書きつきでそっちで実行する、とかかなぁ。
2017-05-27 11:42:16
Yusuke SATO
@satob
(続き)新しいバージョンのOSSには、提供したパッチ以外の変更も入ってるだろうから、これまで積み上げたテスト結果について「新しいバージョンのOSSでも大丈夫です」とは言いにくい。修正箇所が限定される保証もないしね。
2017-05-27 14:52:33
Yusuke SATO
@satob
(続き)他にも、そのOSSへのコントリビュートって、プロジェクトの財布で賄うもんなの？という問題もある。アプリをお客様に納めるか、自社資産になるかで、プロジェクトにかけるお金は税制上の扱いが違うと思うのだけど、どうなってるんだろうね？ここは専門外なので、よく分からない。
2017-05-27 14:53:56
Yusuke SATO
@satob
(続き)とにかく、業務で使ってるOSSのバグ修正には、かようにややこしいハードルを色々クリアする必要がある、という話。じゃあどうしたらいいか、というと、各社どうしてるんだろうね？（投げっぱなしでおしまい）
2017-05-27 17:45:41