プログラムのソースコードが著作権法上の保護対象に含まれる（著作権法第10条第1項第9号）ことはよく知られているが、ではこれをどこまで利用すると著作権侵害となり得るのか、実務的な面で整理したい。 プログラムの著作権が及ぶ範囲 プログラムの著作権は「表現」に及ぶ。 つまり、ソースコードの具体的な表現として、 指令の表現自体 指令の表現の組み合わせ 表現の順序 などが保護されることとなる。 一方、アイデアやアルゴリズム自体は保護されない（著作権法第10条第3項第3号）。 例えば、「Aを入力したらBを計算して出力する」といった処理の仕組みや数式は著作権ではなく、場合によっては特許の対象になるだけである。 また、過去の判例（平成２９年６月２９日判決（東京地裁 平成２８年（ワ）第３６９２４号））では、次のように判示されている。 プログラムに著作物性があるというためには，指令の表現自体，その指令の表現の組合せ，その表現順序からなるプログラムの全体に選択の幅があり，かつ，それがありふれた表現ではなく，作成者の個性，すなわち，表現上の創作性が表れていることが認められる必要がある。 つまり、プログラムの表現に選択の幅が無い場合や、ありふれた表現である場合は著作権の保護対象とはならない。 なお、システム設計書等は著作権法上のプログラムには該当しないものの、言語の著作物（著作権法第10条第1項第1号）や図形の著作物（同法第10条第1項第6号）として保護され得る。 著作権侵害の判断基準 プログラムの著作権侵害を判断する場合、以下２つの基準が重要となる。 ソースコードが一致（類似）する箇所の量 比較対象と一致するソースコードの文字数や行数などの客観的な数値的の指標が高いほど、類似性も高くなり、著作権侵害が認められやすくなる。 一致（類似）する箇所を別の表現に創作できるか ある機能を実装するのに色々な書き方ができるにも関わらず、他社のプログラムと一致・類似する記述であれば、著作権侵害の可能性が高くなる。 更に比較対象のプログラムと同じバグが生じる場合は、ソースコードをコピペしている可能性が高く、著作権侵害を裏付ける要因となり得る。 逆に、ある機能を実装しようとすると誰が作成してもほぼ同じような表現になる場合、そこに創作性は存在せず、著作権法上の保護対象から外れることとなるため、侵害可能性は下がる。 ただし、変数や定数、関数の名称等を変えただけでは、実質的にはプログラムの類似度を低減することにはならないと思われる。 プログラムの創作性は、単なる変数等の名前の付け方ではなく、ある機能を実現するための構成という観点が重要（著作権上の保護対象となる）だからである。 他社のソースコードを参考にしただけの場合は？ 他社のソースコードを全てコピペすれば著作権侵害となる、一部を書き換えたに過ぎなければ侵害可能性が生じる、のは良いとして、場合によってはソースコードのアイデアやアルゴリズムは参考にしつつも、実際は一から自分でコーディングするような場合もあるかもしれない。 この場合はどう判断すべきだろうか？ ケースにもよるが、著作権侵害リスクはかなり低くなると思われる。 上述の通り、アイデアやアルゴリズム自体は著作権法の保護対象ではないため、これらをゼロベースで実装することでソースコードの構成が異なっていれば、もはや他社の著作物と類似するとは言えなくなるためである。 もうひとつの著作権侵害要件である「依拠性」は充足するとしても、ソースコード類似しなければ問題はない。 また、仮に元のソースコードとは異なる言語で記述すると、更に類似度は低下するだろう。 ただし、決してリスクがゼロになる訳ではなく、言語を変えたとしてもソースコードの具体的な構成・記述を忠実に模倣した場合は「翻案」とみなされ、著作権侵害と判断される可能性がはあると考えられる。

自社の製品やサービスの知名度を上げる手段の１つとして、他社の著作物を利用することが考えられる。 例えば、自社製品などに有名漫画のキャラをデザインしたり、自社イベントの広告やノベルティに、有名なアニメに出てくるグッズを用いる機会があるかもしれない。 この場合は、当然著作権者からの許諾が必要になる著作権者に問い合わせをして各種条件を合意したうえで使用許諾を得ることとなるが、いくつか留意点を挙げておきたい。 ライセンス条件 ライセンス条件の骨格としては、「独占性」「期間」「地域」「用途」を押さえておく必要がある。 独占か、非独占か 「著作物を自分が使用可能か」という観点のほか、「第三者にも同じ著作物を使わせて問題ないか」という点は検討事項になろうかと思う。 唯一の使用者になりたいなら独占的なライセンス契約とすることが必要だが、ライセンサーも色々な企業に使ってもらいたい場合が多いため、通常は非独占となることが多いと思われる。 ライセンス期間 選択肢としては、以下のパターンに層別される。 永続 期間限定 期間限定（更新可能/自動更新の有無） 期間限定イベントに使うのなら期間限定の契約でも問題無いが、そうでない場合は固定費が嵩むこととなる。 使用する側からすれば期間を気にせず使える永続がベターだが、その場合はライセンサーは将来の利用料を受け取れなくなるため、実際は期間を設けて使用を許諾してもらうことが多い。 仮に永続とした場合であっても、対価は高額になるであろう。 ライセンス地域 著作物は国境を越えて利用されるため、世界各国は様々な国際条約を結んで、著作物や実演・レコード・放送などを相互に保護し合っている。 日本も各条約に加入しているため、世界の大半の国と相互の保護関係がある。 著作物が利用される際の法律の適用に関しては、例えば、日本の著作物がアメリカで利用される場合にはアメリカの著作権法が、逆にアメリカの著作物が日本で利用される場合には日本の著作権法が適用されるのが原則となる。 というわけで、ライセンスのテリトリーについては日本国内だけでなく外国についても指定することが考えられる。 具体的には、例えば以下のようなパターンとなる。 日本国内のみ 特定の国・地域 全世界 ライセンス用途 ライセンサーとしてはどんなものにも使われてしまうとガバナンスが効かなくなってしまうため、例えば、利用できる媒体や業界を限定（例：書籍出版のみ、ゲームのみ、Web広告のみ）したり、または用途を限定（○○商品への掲載のみ、△△イベントの販促品のみ）することが考えられる。 ライセンス費の支払い方法 両者間で合意が取れればライセンス料の価格や支払い方は特に限定は無いが、支払い方法で言うと主に以下のような選択肢が挙げられる。 一括支払い 定額支払い ランニングロイヤルティ これらの組み合わせ もし顧客に販売するような自社製品に用いる場合であれば、「ランニング・ロイヤリティ方式」を取ることが考えられる。 例えば、「製品１個あたりの販売価格 × ●% × 個数」というような算出方法である。 ここで、販売価格を実際の販売価格から消費税、輸送費等を控除した額を指すように定義することもあり得るが、その場合はライセンシーが各種諸費用をわざと高く計算することもあり、その計算根拠についてトラブルが生じる原因ともなる。 したがって、販売価格は諸経費や手数料、税金などを含めた「グロス価格」とするのが望ましい。 一方、ノベルティに用いる場合だと、実際に販売するものではないことから、販売価格という指標を使うことはできない。 この場合は、販売価格ではなく、製品の１個あたりの原価を使って算出することが考えられる。 またライセンサーとしては、ライセンス許諾はしたものの、ライセンシーの製造・販売数が少なすぎるとライセンス料が予想を大幅に下回ることもある。 そういったケースを回避するため、最低限のライセンス料はいくら、ランニングロイヤリティ方式で算定した料金が上回ったらその金額を支払う、といったスキームを組むことも可能である。 中には展示物として使用するケース等、販売価格・原価のいずれで算出する方法も適当でない場合もあるので、その際は一括支払いや、定額支払い方式を採用することとなる。 その他留意点 その他、著作権のライセンス時における主な留意点を挙げておきたい。 著作者人格権は譲渡できない 日本法では、著作者人格権（氏名表示権・同一性保持権など）は譲渡不可である。 したがって、実務上は「著作者人格権を行使しない」との条項を入れる。 二次利用の範囲を明記 もし著作物の改変や二次利用を予定しているのであれば、改変や翻案・二次的著作物の作成（翻訳、リメイクなど）が可能かどうかを契約で明確にしておく必要がある。 対価の妥当性 これは完全買い取りにする場合、権利者は将来の利用料を受け取れなくなるため、初期対価が高額になるのが通常。 第三者権利の有無 許諾を依頼する作品に第三者素材（写真、音源、製品など）が含まれていれば、第三者部分の利用制限は残る点は注意すべきである。 その他 これは著作権に限った話ではないが、サブライセンスの可否、契約解除条件等も考える要素となってくる。

例えば業務として社内資料や外部向け資料を作るときに、他社がWeb上で公開している製品取扱説明書や動画を紹介したくなることがある。 ところが、ここには意外と著作権の落とし穴がある。 説明書等をダウンロードして載せるのは危険 企業が作成した取扱説明書やマニュアルには、文字の表現や図、レイアウトなどに著作権がある。 そのため、ダウンロードした説明書をそのまま添付したり、全文を転載するのは著作権侵害になる可能性が高い。 具体的には、主に「複製権」（著作権法第21条）または「翻案権」（同法第27条）の侵害が問題になり得る。 仮にその一部を引用する場合でも、「引用部分が従、記事本文が主」であることや「出典を明記すること」など、法律上の引用要件を満たす必要がある。 引用の要件に関する詳細は以下の記事で触れているが、結構判断が難しいので、安易に「これは引用だからOK」とするのは避けた方が良い。 著作物の「引用」について考えてみる 著作権法上、他人の著作物をそのまま使うと原則として著作権侵害になるが、「引用」としての使用であれば、著作権者の侵害とはならない。 引用と認... なお著作権に関しては、たとえ社内に留まる資料であっても、私的利用には該当しない。 このため、社内資料であっても、著作権侵害とならないようようケアしておく必要がある。 公式ページへのリンクなら安全 説明書を載せたいときは、公式サイトにあるページへのリンクを貼るのが一番安全である。 リンクそのものは著作権侵害にはならないためである。 ただし注意点として、非公式な違法アップロード先（海賊版サイトなど）のリンクを貼るのはNGである。 著作権侵害の手助けをしたと見なされる可能性がある。 YouTube動画のリンクや埋め込み YouTubeの公式チャンネルが出している動画をブログに埋め込む行為は、基本的に問題ない。 YouTube自体が「埋め込み機能」を提供しており、正規の利用方法だからである。 一方、誰かが無断でアップロードした動画と知りながら紹介した場合は、やはりリスクがある。 なので、公式チャンネルの動画を選ぶのが鉄則となる。 それでもダウンロードしたものを掲載したい 何かの事情でダウンロードした資料を使いたいのであれば、まずはダウンロード可能な公式サイトから利用規約を確認することをお勧めする。 場合によっては、掲載を可とするケースもあり得るからである。 ただし、利用規約で定められた条件（クレジット表記、利用目的、改変の可否など）を違反すると、著作権侵害になるため、規約を必ず熟読し、その範囲内で利用する必要がある。 また製作者には著作者人格権も存在するため、無用な改変は避けるべきかと思う。 「利用規約でも使用はダメと書いてあるけれども、どうしても使いたい」ということであれば、著作物を持っている他社に問い合わせ、許諾を得るしかない。 この場合は、もちろんライセンス料の支払いをはじめとする各種義務を要求される可能性が生じる。 まとめ 説明書をDLして載せるのはNG 公式サイトへのリンクなら安心 YouTube公式動画のリンク・埋め込みも安心 非公式や違法アップロード先へのリンクは危険 記事や資料で紹介したいときは、公式サイト等から「リンクで誘導する」スタイルが著作権リスクを避ける最も安全な方法といえる。

ソフトウェア開発の現場では、ゼロから全部のコードを書くことは殆ど無い。 多くの場合、世界中の開発者が公開しているオープンソースソフトウェア（OSS）や、既存のライブラリを組み合わせて作られている。 ただ、この“部品の寄せ集め”には落とし穴がある。 もし使っている部品のひとつにセキュリティの欠陥が見つかったら？ もしあるOSSのライセンス条件を満たしていなかったら？ そんな時に頼りになるのが、ソフトウェアの「部品表」、つまりSBOM（Software Bill of Materials）となる。 この記事では、このSBOMが何なのか、そしてOSSライセンスとどんな関係があるのかをまとめておきたい。 特に知財部員（法務部員）としては、OSSライセンス管理を行う場合もあるかと思うので、SBOMについて理解を深めておくに越したことは無いと思う。 そもそもSBOMとは？ SBOM（Software Bill of Materials）とは、製品に含むソフトウェアを構成するコンポーネントや互いの依存関係、ライセンスデータなどをリスト化した一覧表のことである。 ソフトウェアは、殆どが自分でゼロから全部作っているわけではなく、オープンソースソフトウェア（OSS）や既製のライブラリを組み合わせて作られている。 SBOMは、その「中に何が入っているか」を一覧にしたドキュメントとなる。 例えば、 このアプリは「ライブラリA（バージョン1.2.3）」を使っています さらに「OSSライブラリB（MITライセンス）」も含まれています といった情報がSBOMに含まれる。 なぜSBOMが必要なのか？ SBOMが注目される理由は、大きく３つある。 セキュリティ もし部品のひとつに脆弱性（セキュリティの穴）が見つかった場合、SBOMがあれば「どの製品にその部品が使われているか」がすぐ分かる。 法的リスクの回避 OSSにはさまざまなライセンス条件（MIT、Apache、GPLなど）があり、それぞれに遵守すべきルールがある。 SBOMがあれば、どのOSSを使っているかが明確になり、ライセンス違反のリスクを減らせる。 顧客や取引先への透明性 ソフトウェアの品質や安全性を証明する材料として、SBOMは信頼性を高める手段になり得る。 SBOMとOSSライセンスの関係 OSSライセンスは言うなれば「そのソフトウェアやコードをどう使っていいか・配布していいか」を決めたルールブックである。 例えば、以下のようなものである。 MITライセンス → ほぼ自由に使えるが著作権表示は必要 GPLライセンス → 改変・再配布時にソースコードの公開義務あり Apacheライセンス → 特許権の扱いも含む詳細な条件あり これらの情報を整理する上で、SBOMが役立つ。 SBOMにソフトウェア部品（パッケージやライブラリ）毎のOSSの名前とライセンス情報が載っていれば、開発チームや法務部門は「このOSSはGPLだから配布方法に注意しよう」などの判断がしやすくなる。 SBOMでリスト化される単位 リスト化される単位だが、基本的には「外部から取得したソフトウェア部品（パッケージやライブラリ）」単位となる。 ただし、用途や生成ツール、利用するSBOM標準によって粒度は変わってくる。 一般的な単位 SBOMでは、次のような単位が多い（下に行くほど小さい単位）。 パッケージ単位：依存関係管理ツールが管理する「1つの外部依存パッケージ」ごとに記載 ライブラリ単位：OSパッケージやシステムライブラリを含む「外部で提供されたライブラリ」ごとに記載 コンポーネント単位：ソフトウェア構成管理ツールが定義する論理的な部品ごとに記載 ファイル単位（詳細）：ソースコードやバイナリの特定ファイルごとに記載 標準仕様ごとの傾向 SBOMの主要な仕様には次のようなものがある。 SPDX（Software Package Data Exchange）→ パッケージ単位からファイル単位まで細かく書ける。ライセンス情報も詳細に記録可能。 CycloneDX → アプリの依存関係やサプライチェーン全体を表すのが得意。パッケージ単位が多い。 SWID（Software Identification Tags） → インストールされたソフトウェア単位（製品やパッケージ）を識別。 実務では、最小はファイル単位、最大は製品単位まで幅があるものの、現実的には「依存パッケージごと」の粒度が多い。 ...

最近、様々なユーザ向けの自社サービスを展開することとなり、そのサービスの利用規約を作成する機会があった。 法律上、サービス提供者に利用規約を作成する義務はないのだが、利用規約を作成しなければ、実務上色々と不便が生じる。 次回同様の対応があったときに備え、利用規約の位置づけや、個別契約との違いを整理しておきたい。 利用規約とは？ 利用規約とは、不特定多数の利用者に対して、あらかじめ一律に適用される契約条件をまとめたものである。 Webサービスやアプリなどでよく同意を求められる、あれのことである。 利用規約の特徴 １番の特徴は、契約内容が画一的（ユーザ毎のカスタマイズ不可）であってユーザ全員に同じ条件を適用できる点、そして所定条件を満たせばユーザがWeb上で「同意する」ボタンをクリックしたり、サービスの利用を開始することで契約が成立するところとなる。 また、運営側による一定の手続で変更も可能である。 仮に利用規約を設けていないと、サービス提供者は各ユーザに対して遵守してもらいたい事項等について、個別に説明・交渉しなければならない。 民法上は「定型約款」として扱われることが多いが、定型約款に該当するための条件などの詳細については別の記事を参考にしていただきたい。 利用規約に対するユーザ同意取得の運用 ソフトウェアやサービスを提供するにあたって、あらかじめユーザーに利用規約などのの同意取得を求めるケースについて考えてみる。 各ユーザーに紙... 主な記載事項の例 提供するサービスやアプリによって内容は異なるが、汎用的な内容としては以下のような項目が挙げられる。 サービスの利用方法・禁止行為 利用料金・支払方法 知的財産権の扱い 免責事項・責任制限 利用停止や契約解除の条件 規約変更の手続き 個人情報の取り扱い 準拠法・裁判管轄 利用規約と個別契約との違い 利用規約と個別契約は、どちらも取引やサービス提供の条件を定めるものだが、性質や役割がかなり異なる。 個別契約は、特定の相手と交わす、取引内容や条件を個別に定めた契約である。 ここでは、利用規約では決めきれない具体的条件を確定させることとなる。 そして当事者間で交渉し、内容を合意の上で確定させていく点が利用規約とは異なる。 交渉を要するのでコストがかかる反面、内容を柔軟に変更できるというメリットもある。 利用規約と個別契約の組み合わせ 一般的な構成だと、基本ルールは利用規約で定め、特定顧客・特定案件向けの条件は個別契約に定めていく形となる。 個別契約が利用規約と矛盾する場合も考慮し、個別契約側には「個別契約が優先」とする条項を置くことが多い。 実務例だと、SaaSの基本利用条件は利用規約に記載し、大口顧客には別途SLA（Service Level Agreement）や価格条件を個別契約で定めることが考えられる。 まとめ このように、利用規約は、極力契約締結の手間を省きつつトラブルを未然に防ぎ、サービスを円滑に運営するために重要な役割を果たす。 ただし、これだけで契約を完結させる必要は無く、適宜個別契約と組み合わせることでより柔軟な契約形態を構成することができる。

開発委託契約は請負型と準委任型に分類され、委託元に納めるべき成果物がある場合は請負契約とする、という点は以下の記事で紹介している。 請負と準委任との違い 基本的に、開発委託契約の契約形態は、「請負」と「準委任」とに分かれる。 いずれも業務を外部に依頼する契約形態だが、契約の目的・成果・責任範... しかし、もし開発してもらうソフトウェアがこちらに納品されるわけではなく、SaaSという形で提供される場合だと、契約はどのように考えたら良いだろうか？ SaaS提供とは？ SaaS（Software as a Service）とは、インターネット経由でソフトウェアをサービスとして利用する仕組みのことである。 通常、普通に納品してもらえば済むソフトウェアであれば、委託元としてはわざわざ継続して費用の発生するSaaS形式で提供してもらう必要性は低いかと思う。 このため、実際は相手方のSaaS提供ソフトウェアを自社向けにカスタマイズしてもらったり、自社サービスと相手方サービスとを連携させるための開発を行ってもらう際にこのような契約を締結することが想定される。 請負型、準委任型それぞれの課題 SaaSで提供してもらうソフトウェアを作ってもらう場合、厳密には委託先から完成したソフトウェアを自社に納品してもらう訳ではないので、素直に考えると請負契約とするのは少し違和感があるかと思う。 では準委任契約はどうかと言うと、こちらは「成果物の完成」ではなく「一定期間の業務を遂行すること」が契約目的となる。 このため、たとえソフトウェアが完成しなくても委託先が開発業務を遂行していれば対価の支払い義務が生じるが、委託元としてはちょっとリスクのある契約となってしまう。 準委任契約を成果完成型とすることで、未完成時の支払義務を回避することは可能である。 しかし、受注者が負う義務はあくまで善管注意義務に留まり、成果物の完成義務は無いし、契約不適合責任も発生しない。 開発してもらうソフトウェアの品質は担保してもらいたいところ、ちょっとこの建付けでは心許ない。 このような場合、契約書はどのようにドラフティングすべきだろうか？ 契約書の作成方針 結論としては、無理に請負・準委任という類型に当てはめることに固執せず、契約として必要な条項を設けておけば良い。 請負と準委任との間の相違は個別契約の中で修正できるし、請負、準委任と明記しない契約書とすることも実務上は珍しくない。 よって、例えば請負・準委任については明記しない代わりに、SaaSとしてケアすべき点として 委託先によるソフトウェアの完成義務 委託元によるSaaS形式での検収 契約不適合（仕様通りに動かない、バグがあったときの対応義務） SaaS提供の条件（ライセンス条件、保守サポート、アップデート提供など） 知財権の帰属（委託先に権利が帰属し、委託元には使用権のみの場合が多い） に関する条項を設けることが重要である。 注意点 SaaS提供となると、ソフトウェアを買い切る形ではなく、引き続き相手方からサービスを提供してもらうためにSaaS提供関連の条項を設ける必要が生じる点は気を付けたい。 あるいは、開発委託契約とは別にライセンス許諾をはじめとするSaaS利用契約を結ぶといった対応もありうる（個人的には、契約は別々にした方が良いと思う）。

特許明細書を作成する際、発明の説明する上でどうしても登録商標を使用せざるを得ない場合があるかと思う。 この場合、商標権者の許可を取ることなく登録商標を使用することは可能だが、いくつか留意点がある。 その留意点について、概要をまとめておきたい。 商標表示義務の発生 登録商標を明細書等に使用する場合について、「特許法施行規則第24条　様式29［備考9］」には以下の通り記載されている。 登録商標は、当該登録商標を使用しなければ当該物を表示することができない場合に限り使用し、この場合は、登録商標である旨を記載する。 つまり、やむを得ず登録商標を明細書等に使用する場合、最初の登録商標「○○○」の後に「（登録商標）」といった表示をする（未登録商標であれば、商標名の次に「(商標)」と表示する）ことが求められる。 仮に商標名をそのまま明細書に記載すると、以下のような不都合や商標権者等への不利益が生じるためである。 物品や物質の普通名称と商標名とが混同をきたすようになる その商標名を商品の普通名称であるかのように誤認させ、商標が本来有している商品の出所表示の機能を弱める結果を生じる なお、商標名である旨の付記は、職権訂正により行ってもよいとされており、表示がないことのみをもって拒絶されることは無いかと思う。 場合によっては拒絶理由となることも また留意すべきは、特許請求の範囲、又は明細書若しくは図面のうち、請求項に係る発明について商標名を記載することで、拒絶理由通知の可能性がある点である。 商標は一定の限られた商品にだけ使用されるとは限らないし、一定の商品について使用される場合であっても、同一の商標でありながら、製造の時期などによって商品の品質、組成、構成などが一定でないことが多い。 このことから、請求項に係る発明について記載された部分に商標名の記載がある場合、 発明の詳細な説明の記載が明確かつ十分に記載されていない（特許法第36条第4項第1号） 特許を受けようとする発明が不明確（特許法第36条第6項第2号） と認定されることがある。 ただし、商標名が以下の要件を満たせば問題ない。 その商標名が物質又は物品の普通名称となっていると認められるとき（登録商標名は本件に該当しない） 物質又は物品の普通名称となっていなくても、次の三つの条件を同時に満たしていると認定できるとき 類似品のうちから特にその商標名のものを選定したことに、発明としての充分な意義が認められること 商標名が記載されていても、その発明が不明確とならないこと（例えば、その商標は、少なくともその発明の特許出願以前から出願当時にかけて、常に一定の品質、組成、構成などのもののみに付されていたことが明瞭であること) 商標名で記載されていても、その発明の技術が充分に公開されていると認めることができること(例えば、その商標名の商品の市販が、何らかの理由で停止されても、その発明と実質上同一の発明を、その発明の属する技術の分野における通常の知識を有する者が容易に実施することができること) まとめ 以上のように、使用の際は明細書中で登録商標等である旨の表示をする必要があり、また商標使用により発明が不明確とならないよう留意することが求められる。 より詳細な情報が知りたければ、特許・実用新案審査ハンドブック「2003 明細書、特許請求の範囲又は図面に商標名が記載されている場合の取扱い」を確認いただきたい。 （参考）使用頻度の高い登録商標のリスト 参考として、特許庁HP「明細書への登録商標の記載について」に掲載されている、明細書等で登録商標である旨の表示がなく使用されている登録商標のうち、使用頻度の高いもののリストを転記しておく。 五十音順 アルファベット順 ウィンドウズ ANDROID ウォークマン BLACKBERRY ウォシュレット Blu-ray カラーコーン BLUETOOTH ガルバリウム鋼板 COMPACTFLASH ケーブルベア DLNA ケーブルベヤ FeliCa 碁石茶 FIREWIRE コンパクトフラッシュ FRAM サーボパック HDMI サイダック HIT サランラップ iPad セルフォック iPhone セロテープ iPod 宅急便 JAVA テトラパック JAVASCRIPT テフロン Linux テレスコ PENTIUM トルクス PHOTOSHOP ハーモニックドライブ PYREX パイレックス QRコード パトライト SmartMedia パワーゲート TEFLON フォトショップ TETRAPAK ブルートゥース UNIX ベルクロ VELCRO ペンティアム VICS ポラロイド WALKMAN マジックテープ WINDOWS 万歩計 YouTube リナックス ZIGBEE レイデント レバーブロック

ソフトウェア開発において、もはやOSS（オープンソースソフトウェア）の利用はほぼ必須と呼べると思われるが、OSSライセンスについて問題ないかを確認する作業は開発者にとってかなりの負担になっているかと思う。 世の中にはOSSの管理を支援するツールも普及しているものの、一部の言語には対応していなかったり、完全に人のチェックを手離れさせるのはまだ難しいという印象である。 知財部の立場から言えば、自社のプロプライエタリなコードの開示義務が生じたり特許権の許諾義務が生じる可能性もあるので、口酸っぱく注意喚起するしかないのが辛いところである。 ところで、パッケージにちょいちょいOSSのデュアルライセンスが含まれるケースを見かけるのだが、自分の勉強も兼ねてデュアルライセンスについてこの記事で整理しておきたい。 デュアルライセンスの概要 OSSのデュアルライセンスとは、同じソフトウェアに２つのライセンスを重ねて適用するものではなく、２つの異なるライセンス形態で選択的に提供される仕組みである。 ユーザーは、その中からいずれかのライセンス条件を選んで配布することができる。 デュアルライセンスは、いずれもOSSライセンスの場合と、商用ライセンスとOSSライセンス（コピーレフト条項が付いていることが多い）を選択可能なデュアルライセンスの場合とがある。 ちなみに、３つになればトリプルライセンスと呼び、こういった複数ライセンスのうちいずれか１つを選択可能な場合をマルチライセンスと呼ぶらしい。 いずれもOSSライセンスの場合 この場合であれば、企業としてはより条件の緩いライセンスを選択することが普通であろう。 ソースコード開示義務や、特許権の許諾義務を極力回避したいからである。 例えば、GPLとMITのデュアルライセンスの場合は、通常はMIT Licenseを選択する。 商用ライセンスとOSSライセンスとを選択させる場合 例えば、GPLと商用ライセンスとGPLのデュアルライセンスの場合について考えてみる。 商用ライセンスの実務上の位置づけとしては、OSSライセンスの制限を避けたい企業向けの「ライセンス回避の選択肢」として設計されている。 この場合、商用ライセンスでは、OSS版で義務付けられているソース開示や特許ライセンスを免除する旨を明記していることが多い。 したがって、企業が独自の製品に組み込んで販売するなら、対価を支払うことで商用ライセンスを選択し、クローズドな利用とすることが可能である。 一方、対価を払わない場合はGPL条件を遵守する必要があるが、オープンソースプロジェクトならGPLを選択するということもできる。 デュアルライセンスにおける誤解 OSSのソースコードのパッケージには幾つかのコンポーネントが含まれており、それぞれのコンポーネントのライセンスが異なる場合もある。 OSSの勉強をし始めたときはこれがデュアルライセンスかと思っていたが、これはデュアルライセンスではない。 パッケージとして見ると、一部のコンポーネントはその他のコンポーネントとは異なるOSSライセンスが適用されているだけであって、別なライセンスが選択可能というわけではないからである。 開発から「このパッケージのOSSライセンスはこれです」と出された後、開示されているURL先を見に行ったときにOSSライセンスが聞いていたのと違う場合、このパターンであることが多い。 この場合、パッケージから手作業でライセンスの明記されているテキストを漁ったりする必要があり、かなり面倒である。 OSS検知ツールである程度は把握できるとはいえ、たまにこういう事例があるので、なかなか人の目を完全に無くすのは難しいという印象である。 まとめ デュアルライセンスは便利な柔軟性を持つ一方で、「同じコードに複数のライセンスが重なっている」と誤解されやすい。 実務では、著作権者、ライセンス内容、選択の影響を整理した上で運用することが重要である。

近年は生成AIの発達が凄まじく、こちら側のプロンプトに応じてソースコードや画像を作成してくれる。 このとき、作成したものについて特許権や商標権を取得することができるか、現状を整理しておきたい。 特許権について AIが作成した発明であっても、権利取得は可能である。 特許要件（産業上利用可能性、新規性、進歩性など）についても、従来と特段の違いは無い。 ただし、出願書面の発明者の氏名には、AIの名前ではなく、自然人の氏名を記載する必要がある。 日本では、AI自身を発明者と認めていないためである。 また外国の多くの法域でも同様に、AI自身を発明者と認めていない。 AIを発明者とは認定せず AIを発明者と認定せずとの判決を下した「ダバス事件（東京地判令和6年5月16日（令和5年（行ウ）第5001号））」を紹介する。 原告は、発明者の氏名の欄に「ダバス、本発明を自律的に発明した人工知能」と記載した国内書面を提出したが、特許庁は自然人の氏名を記載するよう補正を命じ、最終的には補正しなかった原告の出願を却下した。 ここで、特許法に規定する「発明者」は自然人に限られるか（＝AIは「発明者」に該当し得るか）問題となったのだが、結論としては、自然人に限られるものと解するのが相当であると東京地裁は判決を出している。 判決文から、筆者が抜粋・編集した理由は、以下の通り。 知的財産基本法は、特許その他の知的財産の創造等に関する基本となる事項として、発明とは、自然人により生み出されるものと規定していると解するのが相当 特許法では、発明をした者は、その発明について特許を受けることができる旨規定している。AIは法人格を有するものではないから、「発明をした者」は、特許を受ける権利の帰属主体にはなり得ないAIではなく、自然人をいうものと解するのが相当 では発明者は誰か 発明の過程にAIが利用される場合でも、現状はプロンプトの入力など、人間の関与が一定 程度必要である。 このことから、現状は発明の技術的特徴部分の具体化に創作的に関与した人間を発明者とするという考え方が通常である。 つまり、AIを発明者から除く点以外は、現行の発明者要件の考え方が踏襲される。 2024年に特許庁が行った「AIを利活用した創作の特許法上の保護の在り方に関する調査研究」でも、同様の意見が寄せられているところである。 一方、学説によれば、発明者とは、当該発明の創作行為に現実に加担した者だけを指し、単なる補助者、助言者、資金の提供者あるいは単に命令を下した者は、発明者とはならないとされている。 したがって、人間が抽象的なアイデアを出す助言者という位置づけの場合、現行の考え方ではその人間を発明者として認定できないこととなる。 すると、発明が生まれたにも関わらず発明者が存在しないという、よく分からない状況が生じてしまう。 そこで特許庁は、法解釈の変更を含めた対応を検討しており、2026年にも特許法の改正を目指している状況である。 商標権について AIが作成した商標であっても、基本的には権利化可能である。 商標法は、商品やサービスを他と識別するための「標識」（ネーミング、ロゴ、図形など）を保護する。 生成AIが出力したロゴやブランド名であっても、商標の要件（識別力など）を満たせば登録可能である。 ただし、商標登録出願は使用主体（人または法人）によって行われる必要があるため、こちらも特許権と同様にAI自身を出願人とすることはできないと解する。 一方、商標の場合、創作者という概念が法律に規定されていない。 従って、創作の貢献の有無によらず誰でも出願することができ、権利者（商標権者）になることができる点は特許と事情が異なる。 著作物性について ちなみに、AIが作成したものにも、一定条件が備わっていれば著作権としての保護対象となり得るとされている。 その場合、著作権者はAI自身とはなり得ず、プロンプロト入力した自然人等が著作権者となる。 この際、AIに作らせるという行為には製作者のコントロールが及ばないところはあるのが実情だが、それだけを理由に著作物たり得ないと判断されることは無いようである。 中国の話にはなるが、生成AI（Stable Diffusion）による生成画像の著作物性を認めた北京インターネット裁判所判決（春风送来了温柔事件判決）も存在する。 その他留意点 AI発明を権利化する際は、AIの利用規約に、生成物の知財権の取り扱いについて記載が無いかは確認した方が良い。 多くはAIを使用した時点で利用規約に同意したことになるだろうが、「生成物の権利取得は禁止する」「AI作成者に帰属する」といった規定がされている可能性も考えられるからである。 ただそういった縛りをかけると利用者から敬遠されるのか、近年は生成物のや権利は利用者とする規約も増えている気がする。

In U.S. patent applications, many people struggle with § 101 rejection. Of course I’m one of them. As a personal memorandum, I’d like to leave some countermeasures to avoid § 101 rejection. This is merely my personal opinion and should be taken as such. Decision Flow First, the following is the basic flow for determining patent eligibility. MPEP §2106 Step 1 If the claim falls within one of the statutory categories (process, machine, manufacture, or composition of matter), then it clears the first hurdle and proceeds to Step 2A. ...