Posts

2026年1月より、下請法（下請代金支払遅延等防止法）が取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律）という法律に変更される。 気になったので、改めてどんな内容の法律で、委託業務での注意点をメモにしてみた。 適用対象取引 対象となる取引は、取引の内容と、委託者/受託者の資本金基準および従業員基準によって決定される。 なお、取適法では新たに従業員基準が設けられるとともに、適用対象となる取引の内容に「特定運送委託（製造等の目的物の引渡しに必要な運送の委託）」が追加されたことで、規制及び保護の対象が拡充されている。 具体的には、以下の通りである。 「製造委託」「修理委託」「特定運送委託」「情報成果物作成委託」「役務提供委託（プログラム作成、運送、物品の倉庫における保管、情報処理に限る）」 委託事業者 中小受託事業者 資本金３億円超 資本金３億円以下 資本金１千万円～３億円 資本金１千万円以下 従業員300人超 従業員300人以下 「情報成果物作成委託」「役務提供委託」（プログラム作成、運送、物品の倉庫における保管、情報処理を除く） 委託事業者 中小受託事業者 資本金５千万円超 資本金５千万円以下 資本金１千万円～５千万円 資本金１千万円以下 従業員100人超 従業員100人以下 義務・禁止事項 委託事業者には、４つの義務と１１の順事項が課されている。 ４つの義務 発注書面の交付（発注内容を書面または電子メール等の電気的方法により明示） 書類の作成・保存義務（取引記録を電磁的記録等として２年間保存する） 支払期日を定める義務（成果物の受領日から60日以内に支払期日を定める） 遅延利息の支払義務（遅延日数に応じ、年率14.6%の利息を支払う） １１の禁止事項 受領拒否 支払遅延（手形等での支払い手段もNG） 減額 返品 買いたたき 購入・利用強制 報復措置 有償支給原材料等の対価の早期決済 不当な給付内容の変更、やり直し 協議に応じない一方的な代金決定（※） ※取適法で新たに追加 発注前の作業依頼は違法？ ところで、委託業務の内容に齟齬が生じないよう、委託予定の企業にサンプルケースを提示し、そのケースを処理してもらった上で生じたサンプル成果物を確認する、ということがあり得る。 また、その場合は具体的な作業内容を踏まえて委託予定の企業に見積書を作成してもらうこととなるであろう。 このような発注前の作業は、発注書面の交付義務に違反することとなるだろうか？ こちらについては、サンプルケースの処理が委託業務内容の把握や見積書の作成に必要な行為であれば、問題ない。 ただし、その内容が実質的に先行して委託業務を行なっているとみなされないように注意する必要がある。 特に、その作業から生じたサンプル成果物を、本当の成果物の一部として委託元が取り扱わないようにするよう気を付ける必要がある。 取引内容の見直しによる減額は違法？ 発注後、社内事情により急遽成果物が不要となったり、計画が大幅に変更となることで、委託していた業務を中止することがあるかと思う。 このとき、残りの業務を中止する代わりに、支払い費用を減額するのは取適法違反となるだろうか？ 結論から言うと、不当な減額とならないよう委託先と合意形成がなされていれば問題ない（メール等で合意形成した場合であっても、ちゃんと証拠資料として保存しておきたい）。 例えば、委託先が業務１→業務２という順番で遂行する予定だったとき、業務１まで完了した段階で委託元が中止を求めたとする。 その場合は、委託先が業務１に要した工数等を踏まえて算定した対価を支払えば良い。 見積書でそれぞれの内訳が記載されていれば、その金額を支払うことが考えられる。 もし、委託元が業務２まで遂行することを見込んで業務１の対価を相場より安く見積もっていた場合は、委託先側で業務２が中止となった事情を踏まえて、もう少し高い対価を請求してもらうことがベターかと思われる。

自社のソフトウェアをユーザーに販売・ライセンスする上で利用規約を定める際、不正コピー、リバースエンジニアリング、等といった事項を禁止行為とすることが多いと思う。 ここで、提供するソフトウェアがAIモデルの場合は、更に考慮すべき事項として、欧州AI法（EU Artificial Intelligence Act）が挙げられる。 これは世界初となるAIの開発や運用を包括的に規制する法律（2024年5月21日に成立し、8月1日に発効）であり、AIをリスクの程度で分類し、その程度に応じた規制を適用するものとなる。 具体的には、AIシステムは次の4段階に分類され、最上位の「容認できないリスク」に該当するAIシステムは禁止される。 分類 詳細 規制内容 容認できないリスク（Unacceptable risk） 人々の安全、生活、基本的人権に対する明白な脅威となるもの 禁止 高リスク（High risk） 人々の健康、安全、基本的人権に重大なリスクをもたらす可能性のあるもの 厳しい手続きの義務付け 限定的リスク（Limited risk） AI利用における透明性が欠如するもの 生成AIによるコンテンツであることを明示 最小のリスク（Minimal risk） リスクが最小限またはリスクなしとみなされる 自由に利用可能 特に「容認できないリスク」には倫理的なものが多分に含まれるため、欧州では勿論のこと、欧州以外の国に販売する場合であっても、欧州AI法で定める容認できないリスクとなる使い方を禁止するよう利用規約に定めておくことがポイントとなる。 欧州AI法における「容認できないリスク」は原則禁止 上述の通り、欧州では「容認できないリスク」に該当するAIシステムは禁止されている。 具体的な禁止行為は以下の通りとなるが、以降で各項目の詳細に言及していきたい。 禁止行為 内容 有害な操作と欺瞞 視覚・聴覚・その他の刺激を利用して、本人が気づかないうちに判断を歪め、重大な不利益を与える使い方 脆弱層への悪用 子供、高齢者、障害のある人、経済的弱者などの脆弱性につけ込み、行動や判断を誘導して害を与える使い方 社会的信用スコアリング 個人の行動や推測された性格などから「スコア」を作り、公共サービス・待遇・権利に不利益を与えるような運用 犯罪予測のためのリスク評価 住所、年齢、国籍、婚姻状況などの属性情報だけから「犯罪を起こしそう」と判断すること 顔認識データベースの無差別収集 インターネットや監視映像から、本人の同意なく人の顔を収集・学習・照合する行為 職場・教育現場での感情推定 従業員や学生の「感情」を読み取り、監視・評価・選抜に利用すること 生体情報によるセンシティブ属性の推定 顔・声・歩き方などから、人種、宗教、政治的意見、性的指向などを推測・分類すること 公共空間での「リアルタイム」遠隔生体認証 公共の場で、リアルタイムに個人を特定する 有害な操作と欺瞞（Article5(1)(a)） サブリミナル操作や、意図的に人を欺く・操作するAIを使って、人の判断力を損なわせ、本人が本来取らなかったであろう行動を取らせて重大な害を与える使い方は禁止される。 サブリミナル操作の具体的 視覚的サブリミナル：意識的には認識できないほど短時間に画像や文字を表示 聴覚的サブリミナル：他の音に紛れる、または非常に小さい音量でメッセージを流す 触覚的サブリミナル：人が気づかない程度の刺激で感情や行動を左右する 不可知刺激（視覚・聴覚）：人間の感覚では全く検知できないレベルの刺激（極めて速い点滅や可聴範囲外の音）を用いる 例えば、広告で潜在的に購買行動を誘導し、経済的損失を与えるようなものは良くない、ということである。 禁止されない具体例 サブリミナル操作であっても、それがユーザーの利益に繋がる以下のような場合は例外的に認められる。 サブリミナル療法を使って、ユーザーをより健康的な生活様式へと導き、喫煙などの悪習慣を断つよう促す治療用チャットボット ユーザーの感情を推測し、気分に合わせた楽曲を自動推薦する一方、抑うつ的な楽曲への過度な接触を回避する音楽プラットフォーム サイバーセキュリティ脅威に関する教育を目的としてフィッシング攻撃を模倣するために用いられる、AIを活用した操作的・欺瞞的手法 脆弱層への悪用（Article5(1)(b)） 年齢、障害、社会的・経済的弱者などの脆弱性を利用して、その人や集団の行動を歪め、重大な害を及ぼす使い方は禁止される。 禁止される具体例 子供に対し、家具への登り、高い棚の探索、鋭利な物体の取り扱いなど、次第に危険度を増す課題を達成するよう促す対話型AI搭載玩具 高齢者の認知能力の低下を悪用し、欺瞞的な個別対応型オファーや詐欺を仕掛けるAI 精神障害を持つ人々に対し、高額な医療製品の購入を促したり、本人や他者に有害な行動を取るよう誘導する治療用チャットボット AI予測アルゴリズムを用いて、低所得地域に住み深刻な財政状況にある人々を標的にし、搾取的な金融商品の広告を配信する 社会的信用スコアリング（Article5(1)(c)） 個人の行動や推定された人格特性に基づいてスコア化し、そのスコアをもとに不当・不均衡な扱いをすることは禁止される。 ...

Gopgleマップを社内資料に貼り付ける場合、基本的には帰属表示をすれば良いと紹介した。 社内の電子資料にGoogleマップを使うには 社内資料として、Googleマップの地図画像をPDF、PowerPointなどの電子資料に貼り付けたくなることがあるかもしれない。 しかし... しかし、商用利用の場合は、その利用形態によってはライセンス料を支払わなければならない。 気にせず無償で商用利用したいのであれば、より自由度の高い「OpenStreetMap」を利用することをお勧めする。 日本地図に限定しても問題なければ、「国土地理院」の地図画像を使うのも良い。 しかし、両方とも帰属表示が必要な点はGoogleマップと共通する。 OpenStreetMapの使い方 ボランティアが地図データを編集・更新する仕組みなので、地域によってデータの詳細度が異なる場合があるものの、商用利用可能な点はメリットである。 まずはOpenStreetMapの地図画像を商用利用するための方法を説明する。 帰属表示とリンク貼り付けすればOK 用いるデータや媒体や用途によって表示形態は異なるが、電子資料に地図画像を貼り付けるのであれば、以下２点を行えば商用利用も可能で、地図画像の複製、配布、送信、改変を自由に行うことができる（データを改変または利用する場合は、同じライセンス下でのみ配布可能）。 帰属表示 著作権とライセンスのページへのリンク貼り付け 詳細はLicence/Attribution Guidelinesに記載されているので、そちらを以下に要約する。 具体的な帰属表示/リンク貼り付けの方法 帰属表示は「OpenStreetMap」を入れる必要がある。 「© OpenStreetMap contributors」や 「© OpenStreetMap」という帰属表示でも問題ないが、読みやすい見た目（フォントサイズ、色など）にしておくことが求められる。 また、「OpenStreetMap」のテキストに「openstreetmap.org/copyright」へのリンクを設定する必要がある。 もし印刷物等のようにリンクを設定できない媒体であれば、URLを直接記述すれば良い。 OpenStreetMapに由来しない素材と区別するため、使用しているOpenStreetMapのコンテンツを説明するクレジット表記を自由に行うことができる。 例えば、OpenStreetMapデータを独自のデザインでレンダリングした場合は、「OpenStreetMapの地図データ」と表記することができる。 同じ文書に複数の静止画像が含まれている場合は、帰属表示は１つで足りる。 なお、以下の画像には帰属表示は不要である。 100個未満の地物を含む静止画像 10,000平方メートル未満の面積を含む静止画像 小さなサムネイル／アイコン データセット、AIモデルに関する規定も OpenStreetMapデータから大量に抽出された学習データセットは派生データベースとみなされ、公開する場合はODbLの条件に従って利用可能にする必要がある。 このような学習データセットを用いて学習されたモデルは、モデルを使用するユーザーが情報を期待できるドキュメント（モデルのコードベースのREADMEなど）や、モデルをダウンロードできるウェブページなど）に、その帰属を明記する必要がある。 このようなモデルを用いて行われた予測は、ODbLの対象外となる。 ただし、OpenStreetMapデータの大部分を抽出、複製、または再作成するために制作作品が使用される場合、それは派生データベースとみなされることには注意が必要である。 国土地理院のコンテンツの使い方 日本地図のみの利用で問題なければ、国土地理院のコンテンツを用いることが選択肢となる。 一般ユーザーには使いづらい部分があるかもしれないが、日本国内の詳細な地理情報が提供されている点がメリットである。 次に、国土地理院の地図画像を商用利用するための方法となる。 出典の記載をすればOK 出典を記載すれば利用可能であり、記載方法は「国土地理院コンテンツ利用規約」に以下の通り例示されている。 （出典記載例） 出典：国土地理院ウェブサイト　（当該ページのURL） ※学術論文や図書等に引用する際は、学会誌等が定めたルールに適した方法で引用すること （コンテンツを編集・加工等して利用する場合の記載例） 地理院タイル （標高タイル（基盤地図情報数値標高モデル））を加工して作成 「○○データ」（国土地理院） （当該ページの URL）をもとに○○株式会社作成 第三者のコンテンツを含む場合は注意 コンテンツのうち第三者が権利を有しているもの、例えば地理院地図（タイルデータ含む）のうち他機関の情報であることが示されているものについては、権利侵害とならないよう、別途それらのライセンス条件や利用規約を遵守する必要がある。 例えば、別途クレジット表記をする等の表記等を行うなどの対応が求められる。

社内資料として、Googleマップの地図画像をPDF、PowerPointなどの電子資料に貼り付けたくなることがあるかもしれない。 しかし、地図画像もGoogleの立派な著作物である（著作権法第10条1項6号）。 こう思うと資料への貼付けが躊躇われるが、あくまで電子資料が社内使用に留まるものであり、商用の広告として用いたり、多くに配布するものでなければ、帰属表示をはじめとする利用規約を守っておけば貼り付けは可能である。 遵守すべき利用規約 遵守すべき利用規約として「Google 利用規約」と​「Googleマップ追加利用規約」の２つがある。 Google 利用規約には、Googleアカウント利用時の年齢要件、サービスの不正利用の禁止等が規定されているが、この中で「サービス固有の追加規約」の遵守を求めており、Googleマップの場合は​「Googleマップ追加利用規約」がそれに当たる。 Googleマップ追加利用規約の概要 Googleマップ追加利用規約では、「適切な権利帰属を伴うコンテンツを、オンライン、動画形式、印刷形式で公開表示する」ことを許可している。 言い換えると、適切な権利帰属のないコンテンツの使用は認められないということである。 「適切な権利帰属」とは、要するに「ちゃんと帰属表示をしてね」ということで、その具体的な内容は「Googleマップ、Google Earth、ストリートビューの使用にあたっての許可に関するページ」に記載されている。 その中身は、以下の通りである。 帰属表示の内容 Googleマップでは、コンテンツの下部に、例えば「Map data ©2019 Google」などの著作権表示とともに帰属表示が記載される（正確な帰属表示のテキストは、地域やコンテンツの種類によって異なる） この帰属表示は、web embeds,、API、Google Earth Pro、Earth StudioといったGoogleのツールで地図画像を出力すると自動で表示されるようになっている。 これを、以下のルールに従って表示することが求められる。 遵守事項 帰属表示は地図画像の近くに表示すること スクリーンショットを使用する場合は、画像中の標準的な帰属表示をそのまま記載すること データや画像の一部がGoogle以外のプロバイダから提供されていれば、帰属表示のテキストに「Google」＋「データプロバイダ（複数可）」を明記すること（例：「地図データ：Google、Maxar Technologies」） 禁止行為 帰属表示を地図画像から離れた場所（書籍の末尾、映画や番組のクレジット、ウェブサイトのフッターなど）に表示する行為 帰属表示を削除したり、隠したり、切り取る行為 Googleロゴをインラインで使用する行為（例: 「これらの地図は [Google ロゴ] から提供されています」という表示を入れる行為） Google以外のプロバイダのデータが含まれているのに、「Google」またはGoogleロゴのみを記載する行為 認められる行為 必要に応じて、帰属表示テキストのスタイルや配置をカスタマイズ可能（ただし、閲覧者が判読できるよう、テキストはコンテンツの近くに表示する必要あり） その他、禁止行為 帰属表示の他にも、Googleマップ追加利用規約では以下の行為を禁止している。 Googleマップを再配布・販売したり、そこから新しいサービスを作る行為 地図や画像などのコンテンツを勝手にコピーする行為（例外あり） 大量にダウンロードしたり、自動でデータを取る仕組みを作る行為 Googleマップの情報を使って、別の地図サービスやデータベースを作る行為 リアルタイムのナビや自動運転用に、他社のサービスと組み合わせて使う行為 用途によっては、更なる決まり事も 地図画像をどう使うか（印刷するのか、動画に使うのか、等）によって、次のように更なる遵守事項が課される。 地図画像を印刷する場合は、非営利目的または個人的な使用に限る 埋め込みコードでウェブサイトにGoogleマップを埋め込むだけならOK（Googleマップへのリンクを貼ることも可能） 映画やテレビ番組でGoogleマップを使用する場合（例：俳優がスマートフォンでGoogleマップを使用）は、事前承認が必要 オンライン動画広告やプロモーション目的（例：不動産会社が賃貸物件の空き状況を表示するなど）で使用する場合は、事前承認が必要 PDFやPowerPointといった電子資料に貼り付けるだけであれば、基本的には帰属表示を守っておけば良い。 まとめ 最もシンプルにGoogleマップの地図画像を社内の電子資料に使いたければ、Googleのツールで帰属表示付きの画像を出力し、何も加工せずに貼り付けるのが手っ取り早い。 しかし、商用利用含めてもっと制約なく使いたければ、OpenStreetMap（クレジット表記は必要）等の別のコンテンツを使うのが良い。 OpenStreetMapの詳細については、また別の記事で紹介したい。

米国の審査に影響する話となる。 2026年度のUSPTOによる審査官業務評価計画で、新たな変更が導入されるとのこと。 １案件につき、審査官インタビューが合計１時間までに限定されることとなる。 以下に、その詳細を記載する。 審査官へのクレジット これまでは、審査官インタビュー１回につき１時間分のクレジットぎ付与されていた。 今回の変更により、１審査ラウンド（新規出願か、RCE毎）あたり合計１時間分のクレジットが付与されるだけとなる。 つまり、実質的に２回目以降の審査官インタビューにはクレジットが付与されない。 ２回目以降の審査官インタビューは可能か 結論、理論上可能ではある。 しかし、審査官自身で審査促進に繋がることを示す必要がある上、スーパーバイザー審査官による正式承認を要する。 果たして、クレジットも付与されないのに審査官がそこまで審査官インタビューを実施してくれるものだろうか？ また、仮に応じてくれたとしても、クレジットが得られないことから審査官による準備が充分に行われず、審査官インタビューの質が低下する可能性も否めない。 この方針は、審査促進のための対話を奨励するMPEP §713の精神と整合性が取れないものだが、それだけ審査官の工数不足を補う必要があるという表れなのかもしれない。 対話を繰り返す方法はお勧めできない これまでは、OA時に限定的な補正を行った上で相手方の反応を確認し、その後に複数の審査官インタビューを通じた対話を繰り返して論点を絞っていく方法もあったかと思う。 しかし、今後はそのような方法だとRCEを繰り返すこととなり、コスト面からも望ましいアプローチとはいえなくなる。 最初のOA後の審査官インタビューが重要 審査ラウンド毎の審査官インタビューが原則１回に限定されたことで、最初の拒絶理由通知後に行う審査官インタビューの価値が高まったといえる。 今後は、最初の拒絶理由通知後（最後の拒絶理由通知後よりも補正の自由度が高いタイミング）に審査官インタビューを行うことが有効と思われる。 ここでは、あらかじめ論点を整理しつつ、いくつか補正案を作成した上で、インタビューでは審査官と効率的に議論を行うことが求められる。

製品や技術をを外国企業に輸出する際には、輸出規制・倫理的制約・リスク管理などの観点から、販売国・地域、使用者（企業・組織）を限定・禁止することが一般的である。 特に、ソフトウェアはクラウドを介して世界に販売・ライセンスすることが比較的容易なので、あらかじめ販売先の限定を検討しておくことが重要である。 知財業務の観点からは離れるかもしれないが、ソフトウェア販売において頭の片隅に入れておいたほうが良いと思うので、販売国・地域、使用者の観点で整理してみたい。 国（使用地域）の限定 日本の輸出規制は、大きく２つの規制「リスト規制」「キャッチオール規制」がある。 規制 概要 リスト規制 輸出される技術の機能・性能が武器や軍事転用が可能かどうかに着目 キャッチオール規制 輸出される技術の使用者や使用目的が軍事転用などの懸念があるかどうかに着目した規制 確認フロー 技術を輸出する場合、まずその技術がリスト規制に該当するかどうかを確認し、該当する場合は、例外規定を除き経済産業省の輸出許可が必要となる。 リスト規制に該当しなかった場合は、次にキャッチオール規制の確認を行い、キャッチオール規制に該当すれば、やはり経済産業省の輸出許可が必要となる。 リスト規制 輸出される技術が「輸出貿易管理令」の別表第一または「外国為替及び外国貿易法」の別表の1～15の項に該当する場合であってⅠ物等省令で定める仕様に該当するものは、事前に経済産業大臣の許可が必要となる。 対象品目または役務（技術）の内容は、以下の通り。 武器関連（輸出貿易管理令 別表第一1の項） 核兵器、化学・生物兵器およびミサイル（輸出貿易管理令 別表第一2～4の項） 通常兵器関連汎用品（輸出貿易令別表 第一5～15の項） ただし、貿易外省令第9条において、許可を必要としない技術提供が規定されている。 例外規定に当たる場合は、提供する技術がたとえリスト規制技術であっても、許可を取得する必要はない。 例えば、以下のようなものは許可を取得しなくても良い。 公知の技術を提供する取引又は技術を公知とするために当該技術を提供する取引（第9条第2項第1号） 工業所有権の出願・登録を行うために必要な最小限の技術を提供する取引（同項第11号） ソフトウェアの場合、OSSであれば問題ないが、OSSの一部を改変しかつ改変後のソースコードを公開せずに、改変後OSSを組み込んで提供する場合は、例外規定には当たらない。 キャッチオール規制 輸出される技術が、大量破壊兵器等の開発、製造、使用または貯蔵、もしくは通常兵器の開発、製造または使用に用いられるおそれがあることを輸出者が知った場合、または経済産業大臣から許可申請をすべき旨の通知を受けた場合には、輸出または提供にあたって経済産業大臣の許可が必要となる。 このキャッチオール規制では、木材・食料品を除くほぼすべての品目が規制の対象となっており、以下に細分化される。 この「キャッチオール規制」に該当するか否かの判定要件は、経済産業省から許可を受けるべき旨の通知を受けた場合に許可を要する「インフォーム要件」と、輸出者自身で技術の用途や需要者の確認を要するかを確認する「客観要件」との2要件から構成されている。 客観要件は、次の2つの要件に分かれている。 用途要件：輸入者等において、大量破壊兵器等の開発等に用いられるかどうか。 需要者要件：輸入者等が、大量破壊兵器等の開発等を行っているかどうか。または、特定の（外国ユーザー）として指定されているか否か等。 また、キャッチオール規制は更に以下の小項目に分かれている。 大量破壊兵器キャッチオール規制 用途要件または需要者要件のいずれかに該当し、大量破壊兵器等の開発等に用いられる恐れがある場合には、経済産業大臣の輸出許可が必要となる。 対象は、後述のグループA以外の国・地域となる。 通常兵器キャッチオール規制 用途要件に該当し、通常兵器の開発等に用いられる恐れがある場合には、経済産業大臣の輸出許可が必要となる。 対象は、国連武器禁輸国・地域となる。 優遇を受けられる国（グループA） リスト規制の対象ではあるが、キャッチオール規制は対象外という優遇を受けられる国々があり、これらはグループA（旧ホワイト国）と呼ばれる。 グループAは大量破壊兵器などの拡散を防ぐための輸出管理が厳格に行われている国々とされているため、キャッチオール規制の確認は不要となる。 グループAの具体的な国々は「輸出貿易管理令」の別表第三で定められており、2025年時点では以下の国々となる。 アルゼンチン、オーストラリア、オーストリア、ベルギー、ブルガリア、カナダ、チェコ、デンマーク、フィンランド、フランス、ドイツ、ギリシャ、ハンガリー、アイルランド、イタリア、大韓民国、ルクセンブルク、オランダ、ニュージーランド、ノルウェー、ポーランド、ポルトガル、スペイン、スウェーデン、スイス、英国、アメリカ合衆国 企業・組織（使用者）の限定・禁止例 その他、以下のような特定企業等には輸出しないという社内ルールを設けることも考えられる。 制裁リスト掲載企業 米国OFACリスト（SDNリスト） EU制裁リスト 経産省の外国ユーザーリスト 競合他社 その他、社内事情で指定する企業等 輸出国・企業の限定条件の一例 例えば、リスト規制の対象とはならない通常のソフトウェアであれば、以下の取り決めとすることが考えられる。 グループA：特定企業でなければOK 国連武器禁輸国：NG 上記以外の国：個別判断

ライセンス契約における保証条項では、次のような事項をライセンサー（権利者）が保証することがよくある。 有効性保証：特許等が有効に存在することを保証 非侵害保証：ライセンシーの利用が第三者の権利を侵害しない さらっと書かれているのだが、ライセンサーから見れば、これらを100％保証するのは事実上不可能といっても過言ではない。 ライセンシーの立場であれば「しめしめ」で済む話かもしれないが、ライセンサーとしては、ある程度遵守できる範囲の内容にするための交渉が求められる。 保証する側（ライセンサー）の主なリスク 各保証の項目について、もう少し詳しく述べておきたい。 無効・取消しのリスク 特許権等に無効理由があることが確定すると、特許権等ははじめから無かったものとみなされる（特許法第125条、商標法第46条の２）。 無効理由の有無はライセンサーではなく特許庁や裁判所が判断する上、権利化後に新たに見つかった資料によって無効となる可能性もあるため、権利の有効性はライセンサーにも完全にはコントロールできない。 仮にライセンサーが「有効であることを保証」してしまうと、特許や商標が後に無効審判で無効となった場合、契約違反・債務不履行を問われる可能性がある。 このため、ライセンサーとしては「保証しない」と規定したいところである。 とはいえ、ある程度の譲歩が求められることもあると思うが、その際は、例えば「ライセンサーの知る限り、契約締結日において、無効審判の請求、その他特許の有効性を争う法的手続がなされたことがないことを保証する」といった条件を設けることが考えられる。 このような規定であれば、ライセンサーもより確信を持って保証することができる。 その他、「契約締結時においてライセンサーの知る限り無効理由はないことを保証する」という書き方もあるが、個人的には上述のように「法的手続きがなされたことがない」という書きっぷりにした方が、より疑義のない内容になると思う。 とはいえ、実務上インパクトのある差ではないと思う。 第三者権利侵害のリスク たとえ特許権が登録となっていても、ライセンシーの実施行為が第三者の特許権等を侵害する場合がある。 例えば、特許が第三者の特許権に対して下位概念や利用関係にあって、当該特許の実施が当該第三者の特許権を侵害する場合が挙げられる。 この場合、ライセンサーが非侵害を保証したにもかかわらず、実際には第三者の特許・著作権・商標を侵害していたということであれば、損害賠償責任を負う可能性がある。 特にソフトウェアや複合技術の場合、全ての構成要素について侵害の有無を完全に確認することは困難である。 また、パテントトロールからの攻撃を受けるというリスクも存在する。 もちろん、特許権の実施行為以外の部分が原因で訴えられることもあるが、ライセンサーとしては無用なリスクは回避したいところである。 そもそもライセンサーの立場としては、ライセンス行為はあくまで「おたくに権利行使しませんよ」という地位を与えているに過ぎず、第三者の権利の非侵害を保証するのは過度な負担であると考えられるので、ライセンサーとしては「保証しない」と規定したくなる。 それでも交渉により何らかの保証をせざるを得ない場合には、「契約締結時に知り得る限り第三者の権利を侵害していないことを保証する」と規定することが考えられる。 または、「これまで権利侵害の通知を受けたことがないことを保証する」という記載もあり得るが、必ずしもライセンサー自身が特許権等を実施しているとは限らないため、ライセンシーからはもっと確実な保証を要求される可能性はある。 より相手方に歩み寄る案としては、「第三者からの請求があった場合に、協議の上、合理的な範囲で協力する」ことを義務付けることが考えられるが、この辺りになると現実的に何らかの対応を迫られることも視野に入れておくべきかと思う。 ライセンサー視点の実務対応 以下に保証の条項案のまとめておく。 このほか、損害賠償義務が発生することが想定される場合は、上限額を設けたり、免責条項で「間接損害・逸失利益については賠償しない」等と規定することが考えられる。 保証内容 最善策 譲歩案 有効性保証 保証しない ・契約締結時において無効審判の請求等がないことを保証する ・契約締結時において知る限り無効理由はないことを保証する 非侵害保証 保証しない ・契約締結時において知る限り非侵害を保証する ・これまで権利侵害の通知を受けたことがないことを保証する ・第三者から請求があった場合、協議の上合理的な範囲で協力する

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

ソフトウェア企業の中には、自社技術のアピール、利用者のコミュニティ形成のため、自社プロダクトをOSS化するところもある。 こういった企業が収益を確保するには、例えば、プロダクトは無償で提供しつつも、導入サポートやプロダクトを利用するプラットフォームを有償とすることで儲けるという方法が考えられる。 OSSによる収益化の課題と脱OSS しかし、近年は競合参入（大きなクラウドベンダーなど）によって上記のビジネスモデルが脅かされるリスクが大きくなっている。 OSSコミュニティによって得られる恩恵は大きいものの、「純粋にOSSを使って商用展開する事業者（クラウドベンダー）」が恩恵を受ける一方で、開発元への還元が少ないというわけである。 その結果、これまでは自由な再配布を認めていたライセンスの再策定が進んでおり、いくつかの製品では、非OSSのソース公開型ライセンス（Source-available License, SAL）に移行してきている。 具体的には、ビジネスモデルを保護できるよう「競合他社を排除する」という観点が取り入れられたSALへ変更する動きである。 OSSの定義 ここで、OSSの定義について振り返っておきたい。 OSS（オープンソースソフトウェア）とは、Open Source Initiativeによって以下のように定義されている。 自由に再頒布ができること（無償か有償かは利用者の自由） ソースコードが入手可能であること 派生ソフトウェアの作成・派生ソフトウェアを元と同じライセンスで配布することを許可すること 作者のソースコードの完全性（integrity） 「ソースコード+パッチファイル」の形式で再頒布を認める場合、元のOSSを変更して再頒布することを禁止しても良い 変更されたソースコードから構築されたソフトウェアの頒布を明確に許可していなければならない 派生ソフトウェアに元のソフトウェアとは異なる名前やバージョン番号をつけるよう義務付けるのはOK 個人やグループに対する差別の禁止 利用する分野に対する差別の禁止 再配布において追加ライセンスを必要としないこと 元のOSSを改変せずそのまま再頒布する場合の追加ライセンスの禁止 特定製品でのみ有効なライセンスの禁止 他のソフトウェアを制限するライセンスの禁止 ライセンスは技術中立的でなければならない このように、OSSでは「個人やグループに対する差別の禁止」「利用する分野に対する差別の禁止」という項目があるため、競合他社の参入を防ぐことはできない。 Source-available License (SAL) これに対し、各企業が移行を進めているのが、非OSSのSALである。 SALは「ソースコードが利用可能なライセンス」を意味し、OSSも含んだ概念であるので、ここでは非OSSのSALという少しまどろっこしい表現となっている。 非OSSのSALとして、例えば以下のようなものが挙げられる。 ライセンス名 特徴 Business Source License (BSL) ・一定期間は商用利用、競合製品開発など特定の用途に制限が課される ・商用利用の際、商用ライセンス契約が必要な場合がある ・一定期間経過後、通常のOSS（Apache 2.0など）に変わる ・多くの場合、非商用目的では無償で自由に利用可能 Server Side Public License (SSPL) ・SaaS提供の場合、SaaS運用に必要な管理ツールや関連ソースコードも公開しなければならない ・非公開でSaaS提供する場合、商用ライセンス契約が必要 Elastic License 2.0 (ELv2) ・製品をマネージドサービスとして提供する行為の禁止 ・ライセンスキーによる保護機構を回避する行為およびライセンスキーで保護される機能を削除または隠蔽する行為の禁止 ・使用許諾、著作権、その他の通知を削除、またはわかりにくくする行為の禁止 SAL移行のメリットとデメリット 非OSSのSALへのメリットは、競合他社による商用利用を規制し、自社製品の収益化を強化できる点である。 一方、OSSの精神（自由な利用）からの逸脱によりコミュニティからの信頼が低下し、その利用リスクから利用者や貢献者が逃げる可能性がある。 例えばBSLの場合、提供元から突然「おたく、競合他社ですわ」だと言われると使えなくなる状況が生じることもあり得るわけである。 また制約に関係する用語の定義が曖昧なライセンスもあり（例：競合製品とはどこまでを指すのか？）、企業法務としては利用は避けてもらいたいと思うのではないだろうか。 まとめ 以上のように、OSSは成長段階で収益化とのバランスを取るために、非OSSのSALへの移行が増加している。 こういった取り組みは、“OSSとしての自由”と“持続可能な商用ビジネス”のせめぎ合いを象徴している。 今後のライセンス戦略は、単なる技術選定ではなく、法的・経済的・コミュニティ的視点を含む企業全体のリスク・リターン戦略として捉える必要があるだろう。

開発委託契約においては、主に以下の2つの契約形態が用いられる。 請負契約（民法632条） 準委任契約（民法656条） 履行割合型 成果完成型 従来の準委任契約は業務そのものの遂行が目的であって、成果物の納品義務はないものとしているところ（履行割合型）、実務上は準委任契約の中でも「成果完成型」と呼ばれる慣行があり、これが請負契約との違いを分かりにくくしている。 以下に、準委任契約の「履行割合型」と「成果完成型」との違い、更に「成果完成型」と請負契約との主な違いを整理して示す。 準委任契約の「履行割合型」と「成果完成型」 準委任契約における「履行割合型」と「成果完成型」は、いずれも成果物の完成義務を負わないという点で共通するが、報酬の支払基準や業務の性質において実務的に大きな違いがある。 履行割合型では業務の遂行自体を目的とするため、業務自体が報酬の対象となり、「作業時間」「作業工数」「作業量」等に基づいて、業務遂行の割合に応じて対価の額が決定される。 対価の支払いタイミングは、例えば月毎に請求するといった対応が考えられる。 一方、成果完成型は、一定の成果に向けた作業（例：プロトタイプ作成、設計書の作成など）が求められることから、成果物の完成は義務ではないものの、成果物の納品が報酬対象とされる。 したがって、請負契約と同様に、納品をもって対価を支払うこととし、対価の額は納品物の性質によって決められる。 このように、履行割合型とは異なり成果物の受け取りをもって対価を支払うため、所望の成果物が得られないのに対価を支払わないといけないというリスクは小さくなる。 準委任契約（成果完成型）と請負契約との違い いずれの契約も、成果物の納品が対価の対象となっている点は共通する。 しかし、成果完成型の準委任契約は「成果物の納品をもって対価を支払う」約束をするだけであり、請負契約のような「仕事を完成させる義務」は無い点が異なる。 また、受託者が善管注意義務を払って仕事を履行した結果である限りは、成果物が求める水準に達していなくても問題ないとされる。 これだと、委託元としては所望の成果物を確実に受け取ることができる請負契約の方が望ましいようにも見える。 一方、成果完成型だと成果の完成義務はないものの、途中で成果物の仕様が変わるケースにも対応しやすい点がメリットとなる。 実務での使い分けの目安 委託業務内容や納品物の性質によって、どの契約類型が望ましいかを以下の表に整理する。 実務上は無理に請負・準委任という類型に当てはめず（請負、準委任とは明記せず）、納品物の有無、納品物に関する事項（納品物の内容、引き渡し方法、検収方法など）、対価の額、対価の支払い条件など、必要な条項を設けて対応することもあるが、一つの目安となれば幸いである。 契約類型 契約の特徴 適した業務内容 準委任契約（履行割合型） 成果物を前提とせず、作業プロセスや知見提供が価値の中心 ・運用/保守 ・プロジェクト管理 ・技術支援 ・コンサルティング 準委任契約（成果完成型） ・成果物の提出が期待されるが、完成責任は負わない 「何らかの成果」は出るが、求める水準である必要はない ・要件定義書、設計書、プロトタイプの作成 ・技術調査、評価レポート作成 ・ユーザーマニュアル草案作成 請負契約 ・成果物の完成義務あり ・瑕疵担保責任も原則発生 ・実装されたプログラムの作成 ・検収可能なアプリ、Webシステムの作成 ・ハードウェアの作成