生成AIでソースコードを作成した場合、意図せずOSSが混入してしまう場合がある。
OSSライセンスの再配布・表記義務・改変条件に沿う必要性から、これらOSSおよびOSSライセンスは検知しておくことが求められる。
実務上はツールでコードスニペットをスキャンするのが有用であるが、「どれくらい一致していたら、そのOSSを使っていると判断できるか?」は、慎重に扱うべきポイントとなる。
法的・実務的な判断ポイント
ソースコードの著作権侵害に関しては下記の通りまとめているものの、今のところ、具体的な法律上の行数基準はない。
プログラムのソースコードが著作権法上の保護対象に含まれる(著作権法第10条第1項第9号)ことはよく知られている。 しかし、アルゴリズムは流...
そこで、実務上は主に以下の観点で判断することなろうかと思う。
「創作的表現」の有無が重要
著作権上の保護対象は「創作的表現」であり、単に短い定型コード(例:forループ、import文など)は保護されない。
しかし、短いならOSSを使っていないと判断するのは早計である。
たとえ5~10行程度でも特定OSSの独自ロジックや特徴的な関数構造に一致していれば、利用している疑いは残る。
逆に、仮に多くの行が一致していても、定型コードの実装に過ぎないのなら著作物性は低く、OSS利用とは断定できない。
コードの著作権に関する判例
下記判例は著作権侵害に関するものである上、日本と米国の判例が入り交じっており、あくまで参考という位置づけだが、コードの一致する行数は客観的な事実として重要なポイントとして参酌されていることが伺える。
ただし、それのみをもってOSSライセンスの適用可否が決まるものではないことは付け加えておく。
判例1:測量業務用ソフトウェア事件(一審)東地 H19(ワ)24698
ここでは、ソースコードの同一/実質同一の割合が全体の90%を下ることはないことを理由に、被告プログラムと原告プログラムは、原告プログラムの作成者の個性が表現された部分について、実質的同一性ないし類似性が認められる、と判断している。
さすがに全体の9割以上が実質同一であれば、妥当な判決だと思う。
- ソースコードの記載が全く同一であるもの
- ソースコードの記載が実質的に同一であるもの(会社名の置換え、変数名、フォーム名等、プログラムとして機能する上で、その名称の違いに意味のない違いであり、これらの違いがプログラムの表現として実質的な意味を持たないもの。)
判例2:Oracle v. Google (2010-2021)
GoogleのAndroidで、OracleのJava APIを利用する際に11000行ものコードをコピーしていたと訴えられていたが、このAPIはプログラマーが広く利用しているものとして、最高裁は米国著作権法上の「フェアユース」に該当すると判断した。
ある判事は、「ここでOracleの著作権の権利行使を認めることは、公衆に損害を与えるリスクがある」と述べている点が興味深い。
もはや、実務上はJava APIが一般的な構文であると認定されたということだろうか。
スニペットスキャンの実務ガイド
判例からも分かる通り「何行」一致は大事な目安の1つであるが、ポイントは「一致部分が特定OSSの創作的ロジックかどうか」となる。
行数に囚われず、疑わしい一致が出た段階で、ライセンスを確認するのが最も安全である。
実際は手作業で各コードとOSSとの一致度を確認するのは無理ゲーだと思うので、現実的にはBlack DuckなどのOSS管理ツールを使って一致度を確認し、どこかで閾値を定めることになるかと思う。
| リスク | 特徴 | 対応 |
|---|---|---|
| 低 | 一般的な構文・短い定型コード | 対応不要(著作物性なし) |
| 中 | 特定OSSの関数名・処理が部分一致 | 出典確認・必要に応じライセンス確認 |
| 高 | 例えば30行以上一致、特徴的構造・コメント一致 | OSS利用の可能性大・要ライセンス確認 |