ソース

プロフィール等にも載せておりますが、私は、長らくコンピュータープログラムを経験しておりまして、ウェブデザインからからアセンブラまで趣味で色々やってきています。

 

なので、たまには、自分の好きな分野について、「ちょっとだけ」マニアックな文章を書いても許されるかなと思い、「訴訟で使えそうな、ソフトウェアソースコードによる簡易な立証方法」についての提案をしてみたいと思います。

 

例えば、ソフトウェアの特許を有するXさんが、この特許を侵害するソフトを開発販売しているYさんに、損害賠償請求することを考えてみましょう。このような場合、どのように特許侵害を立証すればよいでしょうか。

 

一つには、ソフトウェアの動作を見ることが考えられます。実際にソフトウェアを動作させ、その挙動(画面表示や、作成されるファイルなど。)を注意深く見て、特許侵害が分かればそれで決着がつくでしょう。また、そうでなくとも、ソフトウェアの内部を「解析」する方法があります。これは、リバースエンジニアリングなんて呼ばれたりもしますが、ソフトウェアのゼロイチ信号を読み解いたり、動作を分析したりする方法です。しかし、「解析」の手法を取るとしても、「解析」自体が困難な場合も多く、また、やり方によっては法律や契約に違反してしまうこともあります。

 

次に、少し技術的な所を離れて立証することも考えられます。例えば、先の例で言えば、Yの友人の証言で、「Yが、Xの特許を侵害することになるが、かまわずソフトを売ろう!、と言っていました。」なんていう証言が引き出せれば、侵害の立証に役立ちます。ただ、そこまであからさまなケースは実際には無いでしょうし、何より、現物の「ソフトウェア」を離れてソフトウェアの立証を考えることはできるだけ避けたほうが良いと思います。

 

そこで、3つめの方法として、ソースコードによる立証が考えられます。プログラムをやっている人間としては、やはり、ソースコードに基づく立証が一番確実かな、という感覚がします。ただ、「相手方のソフトウェアのソースコード自体、入手なんてできないよ!」という声が聞こえてきそうですが、今回は、交渉や裁判の過程で、相手方から開示されたと仮定しましょう。

ソースコードは、その全てが開示されている場合、内容を分析し、特許侵害の箇所を特定することは、物理的には可能です。ただ、製品として売られているソフトウェアのデータ量は、通常膨大で読解に時間がかかり、また、訳の分からないアルゴリズムが使われていて読んで理解できないと、という可能性もあります。また、専門家に助力を得る際に、専門家によっては費用がかさんでしまったり、ということも考えられます。さらに、ソースコードが開示されるにしても、全部が開示されるとは限らず、営業秘密である等の理由で一部のみしか開示されない場合もあります。その場合は、ちゃんとした分析が難しくなることも有ります。

 

では、そういったソースコード全部を読めないor読んでいられない場合は、特許侵害の立証はできないのでしょうか。私は、そういう場合でも立証は可能ではないかな、と思っています。民事裁判では、簡単に言えば、提出された証拠を見た裁判官が「ああ、これは確かだな」と思えば立証できたことになるので(自由心証主義)、特許侵害をどのように立証するかも、比較的ラフに考える事ができます。

 

そこで、今回、少ない資料で(ソースコードを全て見ずに)、簡易迅速な立証ができるように、以下のような立証方法を提案してみたいと思います(以下、例としてあげるコードはC++言語によるものとします。)。

 

 

1. コメントからの推認

 ソースコードの中の「コメント」は、必ずしもプログラムコードとリンクするわけではありませんが(一度コメントを記載して、コードを修正後、コメントの修正を忘れることはままあることなので。)、一応の参考として、ソースコードの意味を理解するのに役立ちます。逆に言えば、ソースコードだけでは何をやっているか分からなくとも、コメントを踏まえて、ソースコードの内容を推認することができるかと思います。ただし、あくまで、コメントは参考までに留めるほうがよいでしょう。

 以下の例では、abc(p1,p2);というコードだけでは、何をやっているか分かりませんが、コメントを見ることで、足し算のコードであることが推認できます。


例)

              //p1p2を足した結果を画面に表示する

              abc(p1,p2);

 

2. 変数の接頭語からの推認

 多くのプログラマーは、ソースコードの可読性を挙げるため、ハンガリアン記法という記法(ないしその亜種の記法)を用いています。これは、変数の型を変数名の接頭語として用いるものです。これによって、変数の型が推測でき、その内容も推測できます。

 

一部をあげますと、

 b:真か偽かの値を取る変数

 sz:文字列型の変数

 plp:ポインタ型の変数

 f:浮動小数点型の変数

 m__:クラスのメンバ変数

といった感じです。

 

例えば、「fWeight」という変数に出会ったら、

それは、

 f   → 小数点型

 Weight → 重さ

という意味ですから、おそらくこの変数は、何かの物体の重さを小数点レベルで保存する変数なんだな、と推認ができることになります。

 

3. 文脈と変数名・関数名からの推認

 たとえば、オレンジジュース、アップルジュース、バナナジュースを販売しているジュース屋さんで稼働するプログラムのソースコードだ、という前提がわかった上で、ソースコード中に、「priceOfOJpriceOfAJpriceOfBJ」という単語を発見した場合、それぞれが、ジュースの価格であるという推測ができます。

 このように、ソースコードの文脈と、変数の名称から、プログラムが何をやっているかの推認が可能かと思います。経験則上、変数の名前は、コメントよりは、コードの内容を的確に表している可能性が高いので、それなりに確かに推認が可能かと思います。

 

4. 関数、その他の命名慣習からの推認

 変数だけでなく、関数にも、名前の付け方があったりします(ただし、それほどよく使われていないかもしれません。)。例えば、値を設定する関数には「in」や「set」という名称を先頭につけたり、値を取得する関数には、「out」や「get」という名称を先頭につけたりすることが有ります。以下の例では、getIpAdress()関数は、IPアドレスを取得する関数であると推認ができます。


例) ipa = getIpAdress();

 

5. インクルードファイルからの推認

 インクルードされるファイルをみると、何をやろうとしているのか推測できる場合があります。例えば、「math」という名称を含むファイルをインクルードしている場合は、多少高度な計算をするのか?と推測できますし、「graphic」と名の付くファイルがインクルードされていた場合、描画処理をするのかな?と推測ができます。

 

6. 使われているAPIからの推認

 よく使われるAPIというのがあって、そこから、何をやっているのかを推測するできることがあります。たとえば、CD/DVDドライブ情報を読み出すAPIを呼び出しているソースコードの箇所は、ディスクプロテクトに関わるコードの可能性がある、と推測できます。

 

7. 計算式同士の関係

 最後に、上記を組み合わせた上で、計算式を追ってゆくことによって、コードの意味を推認することが考えられます。例えば、以下の例では、最初のコード(fA = f1 + f2;)だけでは、fAの中身に何が入っているのか不明ですが、のちのち追っていくと、fV = 4.0f/3.0f*PI*fA*fA*fA;の式で、どうも球体の体積を求めているようで、そうするとfAは球体の半径ではないか?と推測できます。そうすると、さかのぼってf1とf2は、球体の半径に関係ある数字なんじゃないのか、というように、推測してゆくことが可能です。


例)

fA = f1 + f2;

・・・・・

fV = 4.0f/3.0f*PI*fA*fA*fA;

 

 

以上、こういった、ソースコードから推認する手法が定着してゆけば、訴訟等々の迅速化につながるんじゃないかな、と思います。