Posts

企業内でエンジニア相手にOSSライセンスの確認を行う際は、OSSの中にあるLICENSEファイルにアクセスすることが殆どかと思う。 そして、自社で開発したソフトウェアでもOSSライセンスの表示義務を果たすために、同じくLICENSEファイルの同梱をするよう促す。 しかし、最終的にはスマホアプリの形で配布する場合であったり、HW機器に組み込んだ形で提供することも念頭に置かないとならないところ、その場合は上記のような対応ではユーザーがOSSライセンスを確認できなくなってしまう。 したがって、OSSライセンスの表示方法は「どのようにOSSを配布するか」によって異なることとなる。 この点、意外と知財部員だと見逃してしまうポイントではないかと思われるので、一般的な整理を以下にまとめておきたい。 ソフトウェアのファイル自体を提供する場合 Zip配布する場合や、GitHub公開するケースが当てはまる。 この場合は、配布パッケージにLICENSEファイルやNOTICEファイルを同梱するのが通常である。 例えば、OSSごとに、ライセンス文をまとめたライセンスファイルを同梱することが考えられる。 ライセンスによって、どこまで同梱するか（全文なのか、著作権表示とライセンス条項なのか）の条件は異なる。 スマホアプリとして提供する場合 バイナリ形式で配布される場合は、「アプリ内での表示」が一般的である。 iOS/Androidのガイドラインでも「OSSライセンス表示」はアプリ内に設けることが推奨されている。 具体的には、アプリ内の「設定」「ヘルプ」「クレジット」等のメニューに「OSSライセンス情報」の項目を設けることとなる。 リスト化された各OSSをタップすると、OSS毎のライセンス文やが閲覧できる形である。 多数のライセンスを管理するのは大変なので、ライセンス表示のためのライブラリを用いることが多いかと思う。 なお、アプリ内にはプライバシーポリシー、利用規約といった表示を併記することが多い。 （Google Playの監査でプライバシーポリシーを指摘されることが多いらしい） ソフトウェアが組み込まれた機器として提供する場合 ルーター、家電、IoT機器等に組み込まれる場合も、表示は必要である。 付属CD/USBにライセンスファイルを格納したり、機器のUI（Web管理画面やディスプレイ）に「OSSライセンス情報」ページを設けて参照可能にすることが考えられるが、中にはそういった表示が難しい機器もある。 その場合は、機器に同梱するマニュアルもしくはユーザーガイド、または製品Webページにライセンス文を記載することで表示義務を果たすこととなる。 まとめ 表にまとめると、以下の通りである。 配布形式 OSSライセンス表示方法 ファイル配布 パッケージにライセンス文を同梱 アプリ配布 アプリ内に「OSSライセンス情報」メニューを設ける 機器配布 マニュアル、付属CD、Web UI、製品Webページ等で表示

企業同士で契約を取り扱う上ではあまり気にしなくても良いと思うが、未成年者と契約を締結したり、利用規約・プライバシーポリシーに同意してもらう際の留意点についてまとめておく。 「親の同意が必要では？」と思うかもしれないが、実際は同意を必要としないものもそれなりに存在する。 親の同意が必要・不要なケース 主親の同意に関係しそうな契約絡みのケースは、以下の通りである。 契約書の締結 以下の民法第5条にある通り、原則として、未成年者が締結する契約は、親権者など法定代理人の同意がなければ取り消し可能である。 （未成年者の法律行為） 第五条　未成年者が法律行為をするには、その法定代理人の同意を得なければならない。ただし、単に権利を得、又は義務を免れる法律行為については、この限りでない。 ２　前項の規定に反する法律行為は、取り消すことができる。 したがって、契約を締結する側としては、親の同意が必要となる。 例えば、以下のケースで必要となる。 携帯電話契約（端末購入・通信サービス契約） サブスクリプションサービスの有料契約（動画配信・音楽配信など） 習い事や塾の契約 クレジットカード・ローン等の金融契約 医療行為（手術や検査など、リスクを伴う場合） 一方、民法第5条3項では、以下のような例外が設けられている。 ３　第一項の規定にかかわらず、法定代理人が目的を定めて処分を許した財産は、その目的の範囲内において、未成年者が自由に処分することができる。目的を定めないで処分を許した財産を処分するときも、同様とする。 「法定代理人が目的を定めて処分を許した財産をその目的の範囲内で使う場合」とは、例えば参考書、定期券の購入のための代金のことである。 「目的を定めないで処分を許した財産で、支払いができる場合」は、いわゆる小遣いが該当する。 したがって、以下のケースであれば法定代理人の同意は不要である。 参考書や文房具の購入 小遣いからの飲食物の購入 定期券や切符の購入（通学・通勤に通常必要な場合） なお、民法第5条は強行規定なので、契約書で「法定代理人の同意は不要」と定めたとしても無効である。 この規定の適用を免れるとすると、未成年者保護の目的が果たせないためである。 利用規約への同意 利用規約は契約行為の一種に該当するため、未成年者は親の同意が必要となる。 ※利用規約の詳細に関しては、以下の記事を参照のこと。 利用規約の特徴と重要性 最近、様々なユーザ向けの自社サービスを展開することとなり、そのサービスの利用規約を作成する機会があった。 法律上、サービス提供者に利用規約... 利用規約では、未成年者の利用に関する条項を明確にし、親権者の責任についても適切に定めておくことが重要となる。 プライバシーポリシーへの同意 プライバシーポリシーは個人情報の取り扱いに関する説明であって、契約そのものではない。 それでは、原則親の同意は不要であるかというと、個人情報保護委員会のFAQには、次のように記載されている。 法定代理人等から同意を得る必要がある子どもの具体的な年齢は、対象となる個人情報の項目や事業の性質等によって、個別具体的に判断されるべきですが、一般的には12歳から15歳までの年齢以下の子どもについて、法定代理人等から同意を得る必要があると考えられます。 ということで、未成年という括りではなく対象年齢に幅があるのは気持ち悪いが、ある程度年齢が低い場合は親権者の同意が必要となる。 なお、利用規約の中にプライバシーポリシーの内容を含めることも可能ではあるが、個人情報の取り扱いを慎重に行うため、利用規約とは別にプライバシーポリシーを設けるのが通常となる。 その他年齢制限に関する規定 ただし、サービス事業者が独自に「◯歳未満は保護者の同意が必要」とポリシーに定めたり、規約で年齢制限をかけることはあり得る。 同意書の取得は必要？ 民法上は「未成年者が親権者の同意を得ている」ことが重要で、同意の形式（口頭・書面）は問われない。 つまり、親が口頭で「いいよ」と言っていても法的には有効である。 とはいえ、事業者側は、後で「同意がなかった」と言われるリスクを避けるため、同意書への署名を求めるといったエビデンスを残すことが多い。 一方、アプリ・ネットサービスの利用登録では、「保護者の同意を得ました」にチェックを入れる方式等で良しとしているケースの方が多い。 このあたりは、同意に関するリスクと、同意書取得のコストとのバランスで決めているのが現実ではないかと思う。 おまけ（未成年者の年齢引き下げ） ちなみに、2022年4月1日の民法改正により、成年年齢は20歳から18歳に引き下げられた。 このため、18歳未満は引き続き未成年者として扱われるが、18歳以上は親の同意なしに契約や進路決定が可能になっている。 一方、飲酒・喫煙・公営ギャンブルは、従来同様に20歳未満は禁止されている。 このため、関連する法律の名前も「二十歳未満ノ者ノ飲酒ノ禁止ニ関スル法律」等に変更されている。

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

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

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

ソフトウェア開発の現場では、ゼロから全部のコードを書くことは殆ど無い。 多くの場合、世界中の開発者が公開しているオープンソースソフトウェア（OSS）や、既存のライブラリを組み合わせて作られている。 OSSを使う際は、そのライセンス条件をきちんと遵守できているかを確認する必要があるところ、OSSの数が多くなるとそれらを全て把握するのは至難の業である。 そんな時に頼りになるのが、ソフトウェアの「部品表」、つまりSBOM（Software Bill of Materials）となる。 この記事では、このSBOMが何なのか、そしてOSSライセンスとどんな関係があるのかをまとめておきたい。 特に知財部員（企業によっては、法務部員）としては、開発側がちゃんとOSSライセンス管理を行っているのかチェックする立場になるかと思うので、SBOMについて理解を深めておくに越したことは無いと思う。 そもそもSBOMとは？ SBOMとは、製品に含むソフトウェアを構成するコンポーネントや互いの依存関係、ライセンスデータなどをリスト化した一覧表のことである。 ソフトウェアは、その殆どが自分でゼロから全部作っているわけではなく、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 パッケージ単位からファイル単位まで細かく書ける。ライセンス情報も詳細に記録可能。 CycloneDX アプリの依存関係やサプライチェーン全体を表すのが得意。パッケージ単位が多い。 SWID インストールされたソフトウェア単位（製品やパッケージ）を識別。 実務では、最小はファイル単位、最大は製品単位まで幅があるものの、現実的には依存パッケージごとの粒度が多い。 目的による単位の違い 目的がセキュリティ管理なら、パッケージ単位で十分なことが多い。 一方、目的がライセンス管理なら、１つのパッケージ内で複数ライセンスが混在する場合もあるので、場合によってはファイル単位まで必要となる。 まとめ SBOMがあればOSSライセンスを極力見落としなくDBとして管理できるので、実務上はSBOM管理ツールを導入し、SBOMをうまく活用することが重要である。 ソフトウェアが社内利用に留まるものであればいざ知らず、外にリリースするものであればライセンス遵守については事前確認するのが当たり前なのだが、これがSBOM管理されていないと、開発部・知財部ともにOSSの洗い出しやライセンスチェックで地獄を見るのではないかと思う。

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

開発委託契約は請負型と準委任型に分類され、委託元に納めるべき成果物がある場合は請負契約とする、という点は以下の記事で紹介している。 ページが見つかりません: post/2025/05/24/202346/index.md しかし、もし開発してもらうソフトウェアがこちらに納品されるわけではなく、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検知ツールである程度は把握できるとはいえ、たまにこういう事例があるので、なかなか人の目を完全に無くすのは難しいという印象である。 まとめ デュアルライセンスは便利な柔軟性を持つ一方で、「同じコードに複数のライセンスが重なっている」と誤解されやすい。 実務では、著作権者、ライセンス内容、選択の影響を整理した上で運用することが重要である。