プログラムの著作権侵害が争われた事案。東京地判平24.12.18（http://d.hatena.ne.jp/redips+law/20130320/1363766287）の控訴審。
事案の概要
事案の概要は上記リンクの原審と同様。プログラムの著作物に係る著作権侵害が争われ，Xから著作権侵害に基づく差止請求権の不存在確認を求めたものである。原審は，請求認容（非侵害）で，Yが控訴した。
ここで取り上げる争点
原審同様に，プログラムの著作権侵害について
裁判所の判断
原審の判断を維持し，Xの請求（不存在確認請求）を認容するとしたうえで，次のように述べた。
まずは，プログラムの著作物性の判断基準について，次のように述べた。
ある表現物が，著作権法の保護の対象となる著作物に当たるというためには，思想，感情を創作的に表現したものであることが必要であり，創作的に表現したものというためには，作成者の何らかの個性が発揮されたものであることが必要である。この点は，プログラムであっても異なるところはないが，プログラムは，「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」（著作権法２条１項１０号の２）であり，所定のプログラム言語，規約及び解法に制約されつつ，コンピュータに対する指令をどのように表現するか，その指令の表現をどのように組み合わせ，どのような表現順序とするかなどについて，著作権法により保護されるべき作成者の個性が表れることになる。
したがって，プログラムに著作物性があるというためには，指令の表現自体，その指令の表現の組合せ，その表現順序からなるプログラムの全体に選択の幅があり，かつ，それがありふれた表現ではなく，作成者の個性，すなわち，表現上の創作性が表れていることを要する。
また，複製，翻案の判断基準については，これまで何十回，何百回と引用されたワン・レイニー・ナイト・イン・トーキョー事件（最判昭53.9.7）と，江差追分事件（最判平13.6.28）を引いて基準を示した。
その上で，具体的にX，Yのプログラムそれぞれを対比して検討した。12か所に渡って比較しているので，その一部を紹介する。
例えば，別紙１，２について。
IMPLEMENT_DYNAMIC 命令について本件プログラムの記述は，「IMPLEMENT_DYNAMIC（CjobsListPanel，CPanel）」であり，Xプログラムの記述は，「IMPLEMENT_DYNAMIC（CProjectListBox，CBox）」である。
本件プログラムとXプログラムとの共通部分は，「IMPLEMENT_DYNAMIC 命令」を使用している部分であるが，証拠（甲２２）によれば，「IMPLEMENT_DYNAMIC命令」は，マイクロソフト社があらかじめ用意している関数であるから，当該関数を使用していることをもって，当該表現に創作性を認めることはできない。
Yは，“CJobListPanel や”CTaskListPanel”の各クラスの上位クラスとして“CPanel”クラスを用意し，共通機能を“CPanel”クラスにまとめ，“CJobListPanel や”CTaskListPanel”を派生クラスと定義することにより，同じ機能を実現するに当たり，記述の重複やコーディング量を減らす等の表現の工夫をしているなどと主張する。
しかしながら，Yの上記主張は，「IMPLEMENT_DYNAMIC 命令」の一般的な機能を用いたプログラム作成上の工夫（アイデア）を説明するものにすぎず，上記共通部分に係る創作性について具体的に主張するものではない。また，Yは，「IMPLEMENT_DYNAMIC」は，いわゆるオブジェクトクラスの承継命令であり，クラス毎にコーディングしていくＣ＋＋言語における構造部分にも当たる重要な箇所であるところ，Xプログラムと本件プログラムのソースコードが同じ場所で同じように承継命令を記載しているのは，クラス分けの仕方がほぼ同じであるからにほかならないなどと主張するが，クラス分け（分類と整理）の仕方は，プログラムのアイデア又は解法に当たるものであって，プログラムの表現上の創作性を認める根拠となるものではない。
このように，あらかじめ用意されたライブラリの同じ関数を使用しているというだけでは創作性を認められず，また，クラスの定義の仕方は，アイデアであって，表現上の創作性の根拠とはならないとした。
続いて，別紙４について。
本件プログラムの記述は，以下のとおりである。
m_cbLanguage.AddString（_T（”Automatically”））;
m_cbLanguage.AddString（_T（”English”））;
m_cbLanguage.AddString（_T（”日本語”））;
m_cbLanguage.AddString（_T（”筒体中文”））;
また，Xプログラムの記述は，以下のとおりである。
m_cbLanguage.AddString（GetString（IDS_AUTOMATICALLY））；
m_cbLanguage.AddString（GetString（IDS_ENGLISH））；
m_cbLanguage.AddString（GetString（IDS_JAPANESE））；
m_cbLanguage.AddString（GetString（IDS_CHINESE））；
そして，「cb」は，コンボボックス（combo box）の頭文字からなる文字列であり，コンボボックスを意味する表現として慣用されるものと認められるところ（甲１０），本件プログラムとXプログラムとの共通部分である「m_cbLanguage.AddString」のうち，「m_cbLanguage」は，コンボボックス（combobox）で「言語」（Language）を選択するための関数であるため，combo box の頭文字と Language とを結合した表現であることは明らかである。また，証拠（甲１０）によれば，AddString は，マイクロソフトがあらかじめ用意していた関数名であると認められるから，「m_cbLanguage.AddString」は，「m_cbLanguage」という文字列と AddString とを文法に従って結合させたものにすぎず，創作性を認めることはできない。
とした。関数名が同じだとしても，それは機能を実現するためにありふれた名称であるから，創作性は認められないとする。
続いて，別紙７について。
(ア) 本件プログラムの記述は，以下のとおりである。
AddPage（&m_normalPage）;
AddPage（&m_discFormatPage）;
AddPage（&m_capacityPage）;
AddPage（&m_primeraPage）;
また，Xプログラムの記述は，以下のとおりである。
AddPage（&m_normalPage）;
AddPage（&m_jobPage）;
AddPage（&m_discFormatPage）;
AddPage（&m_mailPage）;
AddPage（&m_encryptPage）;
AddPage（&m_supSavPage）;
AddPage（&m_multiConnectionPage）;
AddPage（&m_hfPage）;
AddPage（&m_rimagePage）;
(イ) 本件プログラムとXプログラムとの共通部分は，「AddPage（&m_normalPage）」，「AddPage（&m_discFormatPage）」の２行であるが，「AddPage」は，マイクロソフト社があらかじめ用意している命令である（甲１４）。また，引数の「&m_normalPage」，「&m_discFormatPage」は，「AddPage」の対象が「normalPage」及び「discFormatPage」であることを意味するものにすぎず，創作性を認めることはできない。
Yは，本件プログラムでは，“AddPage”命令を用いて機能ごとにグルーピングしてタブを設け，複数のタブを切り替え表示することにより，１画面に表示される情報量を少なくし，利用者の使い勝手をよくするよう工夫されているところ，Xプログラムは「AddPage」関数で追加されるタブ数が本件プログラムとは異なるが，これは，Xプログラムが本件プログラムを流用した上で機能を追加しているからにすぎず，Xプログラムに，Xが流用後に追加した機能やそれに対応するプログラムやソースコードが存在するからといって，本件プログラムの著作権侵害を否定する理由とはならないなどと主張するが，これはプログラムの機能（アイデア）に当たるものであって，プログラムの表現上の創作性を認める根拠となるものではない。
タブを追加して使い勝手を良くするというのは，まさにアイデアの範疇に入るものであって，創作性を認める根拠とはならないとした。
最後に，別紙１２について。
アプリケーションの終了処理について本件プログラムの記述は，以下のとおりである。
if (theApp.m_taskMonitor.IsExistUnFinishedTasks()
&& AfxMessageBox(_T("There are some unfinished task(s).")
_T("￥nThe exact status will lose if you close the application.￥nAre you sure to close it?"), MB_YESNO) != IDYES
)
{m_bCloseSelected = FALSE;
END_SIGN_LOCK(theApp.m_taskMonitor.m_bListCtrlAccessAble)
return;
}被控訴人プログラムの記述は，以下のとおりである。
CString message = _T(“Unfinished task(s) exist, \n”)
_T(“If you close the application you will lost the status.\n”)
_T(“Are you sure to exit application?”);
if (theApp.m_taskListener.IsExistUnFinishedTasks())
{
if (AfxMessageBox(message, MB_YESNO) != IDYES)
{
m_bClosing = FALSE;
SIGN_LOCK_END(theApp.m_taskListener.m_bListCtrlAccessAble)
return;
}
}双方の記述を対比すると，まず，本件プログラムとXプログラムとの共通部分である if 文において，具体的な判断条件である括弧内の表現が異なっている。また，Xプログラムにおいては，if 文の条件が成立した場合に実行される命令列中に，さらに if 文を使用して条件を判断しているのに対して，本件プログラムにはそのような記述はない。
しかも，前記のとおり，if 文は条件に応じた処理に一般的に用いられるものであるのみならず，「AfxMessageBox」関数は，あらかじめマイクロソフト社が用意している関数（甲１８）であるから，いずれもありふれた表現にすぎず，当該記述に創作性を認めることはできない。
Yは，アプリケーションの終了処理に際し，ディスクへの書き込み作業等が終了する前にアプリケーションが終了し，不具合が生じてしまうことを避けるため，一定間隔で作業の終了確認を行い，終了が確認できた場合に限り，アプリケーションが終了するように工夫しているなどと主張するが，これはプログラムの機能（アイデア）に当たるものであって，プログラムの表現上の創作性を認める根拠となるものではない。
この点についても，ソースコード上の表現の違いを示したうえで，共通する部分は創作性を有しない部分か，アイデアに過ぎないものだということを述べた。
結果として，Yが主張する箇所全てについて著作権侵害を否定し，控訴を棄却した。
なお，判決文の末尾には，
Yの平成２５年２月１４日付け文書提出命令の申立て（略）については，本訴におけるYの主張内容等に鑑みれば，既に書証として提出されているXプログラムのソースコード（甲７）のほかに，上記申立てに係るXプログラムのソースコードの証拠調べの必要性はないものと認められるから，上記申立てを却下する。
とし，文書提出命令の申立てを却下した。
若干のコメント
ソースコードを対比させたうえで，共通部分の創作性を判断するという，いわゆる「ろ過テスト」を用いながら，著作権侵害の判断を行った事案です。
第三者が用意したライブラリ中の関数は，汎用的なものであることから，それを使ったというだけでは著作権侵害にならないことは当然であり，その関数を使うことによって実現する機能の共通性を説いたとしても，それは著作権で保護されるべき話ではないから失当だということになります。
また，見やすいコードを書こうとするほど，命名ルール，記述ルールは画一化されていく傾向にあるため，むしろ創作性を発揮しづらいということも言えるかもしれません。
この種の事件では，双方当事者のソースコードを対比して検討することが必須であるものの，対比することができないまま著作権侵害が否定されている事例は少なくありません。本件は，多数の箇所について比較を行ったという珍しい事例であり，具体的にプログラムの著作権侵害の判断方法，枠組みを知る上で参考になるといえるでしょう。
なお，Yは，控訴審に入ったところで文書提出命令を申し立てて，Xのソースコードを提出するよう求めたようですが，すでに原審でもXのソースコードとの対比が行われていることから，裁判所は「必要性はない」として却下しました。もっとも，この種の事案では，訴え提起前であれば証拠保全，あるいは訴訟継続中であれば文書提出命令の申立てを行うことで，相手方のソースコードの入手を試みることもよくあります。
