道総研様のＡＩ、ＩｏＴ知財セミナー講師を務めました

はじめに

　このたび、地方独立行政法人北海道立総合研究機構（略称 道総研）様からのご依頼で、「令和 ５年度 知的財産マネジメントスキルアップ研修」（２０２３年１２月１５日開催）の講師を務めさせていただきました。

　道総研様のご厚意により、ご了承をいただきましたので、セミナーの概要をご紹介いたします。

今回のセミナーは昨年度の「ＡＩ・ＩｏＴ等のソフトウェアやシステムに関連する研究成果の知財化の進め方」というセミナーの続編ということでご依頼を受けておりました。

　そこで、第１部で「研究成果の普及に向けたＯＳＳ利用の考え方と研究計画デザイン」として、昨年度の復習を中心に解説し、第２部で「ＯＳＳコンプライアンスを意識した、企業等へ技術移転する方法のアドバイス」を取り上げることとしました（図２～図３をご参照）。

第１部「研究成果の普及に向けたOSS 利用の考え方と研究計画デザイン」のセミナー概要

　第1部では、昨年度の復習として、ソフトウェアの「使用」と「利用」の概念について取り上げたうえで、市販ソフトなどの「使用許諾契約」と、オープンソースソフトウエア（以下「ＯＳＳ」と略します）の「利用許諾」の目的や内容が異なる理由について、解説しました。

　ソフトウェアの「使用」と「利用」の概念は、「使用」がプログラムを実行させること意味するのに対し、「利用」とはプログラムを複製したり、翻案（修正）したり、頒布（配布、リリース）したりすることを意味する、というように明確に区別されます。

　これは、著作権法が、複製権、翻案権、譲渡権、公衆送信権などを規定しており、複製行為、翻案（修正、改変）行為、譲渡ないし公衆送信（配布）行為などの「利用」行為を規制する一方で、著作物を「使用」する行為（例えば、本を読むこと）を規制対象とはしていないことに基づいています。
⇒図４の（１）をご参照

　このため、市販ソフトのプログラムの実行等の「使用」行為については、著作権法で直接的に規制することができず、シュリンクラップ又はクリックオンなど、契約の一種である「使用許諾契約」により、プログラムを「使用」する行為について、同時使用の本数、使用期間などを規制することとしています。
⇒図４の（２）をご参照

　他方、ＯＳＳの場合は、ソースコードの翻案（修正、改変）や譲渡ないし公衆送信（配布）などの「利用」行為を行うことが目的であり、これらの「利用」行為を規制するため、「利用許諾」というライセンス形式が採用されています。
⇒図４の（３）をご参照

　このような著作権法の仕組みを理解することで、市販ソフト等の「使用許諾契約」とＯＳＳの「利用許諾」の違いを正確に理解し、ひいてはライセンスを正しく運用することにつながってくると思います。

　このため、第１部では、ＯＳＳの利用許諾が著作権法を基礎とすることを踏まえて、著作権法について概観するとともに、ＯＳＳにおいてソースの改良や改変行為によって伝搬していく法的性質を理解するために、翻案権や二次的著作物に関する権利について理解を深めるように配慮しました。
⇒図５、図６参照

　そのうえで、市販ソフトで使用される使用許諾（契約）とも対比して理解することで、ＯＳＳへの理解を深めるように工夫してみました（図７参照）。

　ＯＳＳでは、著作権法を権原として、市販ソフトのような「使用行為のコントロール」ではなく、「利用行為（複製、翻案、再配布など）をコントロールする利用許諾」という枠組みが用いられていることになります。
　これを纏めたのが、図８になります。

　また、ＯＳＳを利用するに際しては、独自に開発したプログラムも含めて、ソースコードを開示する義務が発生する「ソースコードの提供義務ないし開示義務」のリスク、異なるライセンス条件のＯＳＳを組み合わせて使用することが禁止される「ライセンスの両立性」のリスク、特許権不行使の特約を含むＯＳＳを利用した結果、製品を開発・リリースした場合に「特許権を行使できなくなるリスク」、「コピーライト表示やライセンス文の掲載義務が発生するなどのリスク」などもあるので、これらを概観するとともに、いくつかのＯＳＳを取り上げて具体的に解説しました。
⇒図９参照

第２部「OSS コンプライアンスを意識した、企業等へ技術移転する方法のアドバイス」のセミナー概要

　第２部では、ＯＳＳの選択、ＳＢＯＭの選択と適用範囲に関するポリシーの策定、及びＳＢＯＭを利用した運用方法の実例について検討しました。
　
　ＳＢＯＭとは、「Software Bill of Materials」の略で、ソフトウェア部品表を意味します。ＳＢＯＭは、システムに用いられているソフトウェア（主にＯＳＳ）を部品表として取りまとめることで、そのシステムにどのようなリスクがあるのか、あるいはどのようなライセンス条件を遵守する必要があるのかを一目で把握することができるようにするというものです。
　
　かなり以前からソフトウェア部品表を利用した管理は行われていましたが、近年、一層注目されるようになっているのは、米国の大統領令でＳＢＯＭに関するガイドラインが定められたことが背景にあります。また、日本でも、経産省によって、ＳＢＯＭに関するガイドラインが整備され、今後、法整備（義務化）される可能性が出てきたことも背景にあります。
⇒図１０参照

　ＳＢＯＭの作成には、大きく分けて、手動で作成するパターンと、自動生成ツールで自動生成するパターンの２つが考えられます。ＳＢＯＭの自動生成ツールにおいても、実行環境や開発環境によって、部品を検出できないケースもあるなど、いくつかの弱点があり、手作業で作成するメリットもあります。また、手作業でＳＢＯＭを作成することで、ＳＢＯＭに対する理解も深まり、何かあったときの対処もスムーズに行えるというメリットも期待できます。
⇒図１１参照

　そこで、経産省の取り纏めたＳＢＯＭに関するガイドラインでは、ＳＢＯＭの自動生成による運用を前提としていますが、小規模な企業では、手作業でＳＢＯＭを作成することも想定されるので、本セミナーでは、手作業でＳＢＯＭを作成するケースを取り上げました。
　
　また、ソフト開発スケジュールに、ＯＳＳの管理を目的としてＳＢＯＭを適用するという目的から、ソフトウェア開発から共同開発企業への技術移転までのステージに即して、ＯＳＳ選定及びＳＢＯＭ選択の基本ポリシー策定（準備期）、ＯＳＳの調査と選択（開発前期）、ＳＢＯＭ作成（開発中期）、ＯＳＳクリアランス調査（開発後期）、著作権・ライセンス表記の準備（移転準備期）、ＯＳＳソースコードの提供規定の解釈と運用（移転期）、という６段階のステージに分けて、それぞれ対応策について検討しました

⇒図１２参照

　ＳＢＯＭの選択に際しては、ＳＰＤＸ、ＳＰＤＸ－Ｌｉｔｅ、Ｃｙｃｌｏｎｅ ＤＸ、ＳＷＩＤといった主要なＳＢＯＭ４つを取り上げて、それぞれに適した用途、及び相違点について説明しました。
　また、ＳＢＯＭを手作業で作成する場合は、ＳＰＤＸ－Ｌｉｔｅが適していますので、ＳＰＤＸ－Ｌｉｔｅを用いて手作業で作成することを想定して、ＳＰＤＸ－Ｌｉｔｅの各項目について具体的に検討しました。
　ただし、ＳＰＤＸ－Ｌｉｔｅでは、依存関係の項目が欠けているので、その点に対する注意と、これをカバーするために、脆弱性検出ツール、及び、ライセンスリスク検出ツールの併用といった改善策について解説しました。
⇒図１３参照

　また、開発後期のステップとして、ソースコードの開示義務が発生するかどうかの判断基準について再確認するとともに、著作権表記やライセンス文の掲載、ソースコードの提供方法についても検討しました。
⇒図１４～図１７参照

小括

　以上のように、ＯＳＳの利用に際しては、ソースコード開示義務の発生などのリスクを考慮したＯＳＳの選択から、ＳＢＯＭを利用した管理に至るまで、いくつかの留意点があり、基本的な部分を押さえることで、一定程度のリスクヘッジができることがわかります。

　ＯＳＳに関する取り組みは、大手企業でもかなり苦労しているので簡単ではないと思いますが、今回のセミナーで解説した基礎知識をもとに、道総研様及び道内企業の方々によるＡＩ・ＩｏＴ関連の研究開発において、少しでもリスクを軽減した取り組みが進んでいくことを期待しています。

セミナーの様子について

　セミナーは、道総研様の本部のセミナー室での現地開催と、ウェブ開催（の併用で開催され、計７１名の方にご参加いただきました。