オープンソース化・OSS利活用に関する有識者検討会（第2回）

概要

日時

令和7年（2025年）12月18日（金）10時00分から12時00分まで

場所

オンライン（Microsoft Teams）

議事次第

開会
座長の挨拶
議事
- 第1回有識者検討会サマリ
- オープンソース化に関する論点と仮説の共有及び議論
- OSS利活用に関する論点と仮説の共有及び議論
今後のスケジュール
閉会・諸連絡

資料

出席委員

庄司座長
今村委員
中村委員
岩原委員
関アドバイザー
外山アドバイザー
鈴木アドバイザー

議事要旨

事務局から前回の検討会の振り返り、今回の検討会での論点と仮説について説明があった後、討議が行われた。各委員からの主な意見は以下のとおり。
なお、オープンソース化・OSS 利活用それぞれの論点が関連した議論であるため、議事概要について各論点での整理は行わないものとする。

「オープンソース化対象資産」、「利用許諾パターンの整理」、「推奨すべきオープンソースライセンス」、「長期的な維持主体と責任分担」について

改変ソースコード公開義務について、修正ルールで、改変後のソースコード公開義務有とされているが、改変だけで公開義務が発生するとするのか。もし、改変＋頒布行為で改変後のソースコード公開義務が発生なら、GPLに類似するので、商用利用の促進の観点からはネックになりうるとも考えられる。もし、改変だけで公開義務が発生するとすれば、GPL以上に厳しく、第三者利用は更に進みにくくなると考えられる。また、この場合、公開義務が発生する段階（要件）を規定することは難しくはないのか。
再配布ルールについて、無償かつ再頒布後の責任を負わされることから、再頒布の利用が進みにくくなるとも考えられる。利用者は、自ら再頒布するのではなく、再頒布対象者に、オリジナルのリンクを伝えて、再頒布対象者が、自ら直接頒布を受けるように促すことになるとも考えられる。
GPLは、強いオープンソースライセンスである。Linuxが2000年代に流行したのは、GPLライセンスであることが1つの要因であると考える。しかし、現代においては、GPLはリスクが高い場合も存在すると考える。
民間企業にはGPLは厳しすぎると考える。広く使用してもらいたい場合はMITの方が適切であるが、フリーライダーが出やすいという側面もある。将来的に政府から民間へ自立させたいという政策の場合も多く、あえてGPLを選択することでコミュニティが育ちやすいこともある。
改変は非営利目的に限るというのはかなり厳しい条件だと感じる。民間では、GPLは過去によく使われていたが、最近はホビー目的や商用オープンソースの場合で使われている印象である。ApacheやMITを使って、広く使ってもらい、コミュニティを活性化させることを優先している。
ライセンス選定の基本的考え方について、利用許諾ルールの基本方針を決定後に、それに沿ったライセンスを選定または新たに作成する必要があると考えられる。利用促進の考え方によって、BSD等の緩いライセンスか、GPL系の厳しいライセンスかに基本的にわかれるのではないか。
資料2（P.12）の利用許諾ルールの前提によれば、改変物にもソースコード開示義務を課すことが求められているので、GPL系が適しているか。改変のみで公開義務を課すことを念頭においているのであれば、GPLをベースとした新ライセンスを作成する必要があると考えられる。
特許条項は規定しておくほうがよいと思うが、どのような規定にするかは、政府関係の特許権の権利行使の可能性、第三者特許の権利行使性の低下をどの程度図るかなどの多角的な見地から慎重に検討すべきと考えられる。
民間企業では、標準ライセンスを利用することによって守られてきた経験があるため、独自ライセンスはリスクが高いと考える。もし、新規にライセンスを作成するのであれば国際標準を取るくらいの覚悟が必要である。また、特許条項については、Apacheにて既にセクションが存在しているため、活用するのが望ましい。
オープンソースのパラメーターが多く、様々な観点が複雑に関係するため、オープンソース化の推進プロセスはとても良いと感じた。ライセンスやオープンソース化の最終的なオーナーの所在に関する問題は、オープンソース化に限らず存在している。日本版バイ・ドール制度の適用にも一貫性が見られず、他の規則が適用される場合もあると認識している。発注者側と受託者側の立場が存在する公共の情報システム調達自体に、様々な課題があると認識している。また、オープンソース化には責任範囲等多くのリスクを伴うが、これらも根本的にはソフトウェア開発そのものの問題に起因している。例えばテストの実施や、開発されたソフトウェアがどのような資産となるのかといった基本的な事項が解決されなければ、オープンソース化の実現は困難であると考える。
民間企業がオープンソース化する目的は、他社による共同メンテナンスを実施し、運用コストを分担することで、自社単独で所有・管理する場合よりも費用を抑えられる点にある。このような明確なインセンティブがある場合にオープンソース化している。国に置き替えて考えると、国とボランティアの民間企業や個人で共同メンテナンスすることにより、運用コストの削減になるのではないか。また、複数の省庁と共通のコストとすることで、費用を抑えられる設計が必要ではないか。
オープンソース化したもののメンテナンスを行政がしていく場合において、予算や責任の考え方は作成するソフトウェアによって様々であり、中にはメンテナンスが不要なソフトウェアもある。継続的且つ主体的に政府が使用するものであれば、予算は確保される。ここでの問題は、委託で作成されたものに今後予算を継続しない場合どうするかである。社会的に有益であれば他の受益者がメンテナンスを引き継ぐ可能性もあるが、使われなければ放置されるだけである。また、メンテナンスされないソフトウェアが社会にもたらす不利益についても重要な論点である。
オープンソース化したものの今後使用予定がないものについて、メンテナンスをしないものに関しては、GitHubで公開しないことや、Zipファイルでダウンロードできるようにしておく等、自己責任で使用するよう明確に注意喚起することも1つの案である。オープンデータにおける議論と同様に、誤りがある場合でも政府は責任を負わないとしているが、明らかな間違いは直すことが望ましい。
責任範囲について、オープンソース化されたソフトウェアは無保証であることは主張したい。再利用される可能性のあるものは、どこの誰に再利用してもらいたいかを戦略的に明確にしてオープンソース化していくべきである。事例として、インドの公共インフラをオープンソース化した「India Stack」があるが、政府としての覚悟を日本も同様に持つべきではないかと考える。
今後保守費用を払うつもりのないものをオープンソースにすることについて、自分たちでメンテナンスをしない想定でオープンソース化することは一般的にバッドプラクティスとされている。そういった場合でも、受け手がいる場合にのみオープンソース化するべきであり、オープンソース化するか否かを戦略的に考えるOSPOの役割は必須である。
例えば学術分野では、論文が正しいことを証明するためや、学術的な知見を提供するためにオープンソース化しているという説明やラベルを付けて公開をしており、公開開始時から別途説明を付けること（いくつかのラベルを付けること）により納税者の不満の軽減になるのではないか。
戦略があることと、無保証であることは別問題である。品質に対しては無保証であるが、運用であるメンテナンスやコミュニティの維持に対しては発注者が責任を持つべきである。戦略・目的を定めることが必要である。
全てに1つのルールを当てはめることは難しく、パターン化するべきである。例えば、日本版バイ・ドール制度は受託契約には採用されず、研究開発の際に採用されることが多い。また、既にOSSの活動をしている場合、政府がシステム開発を発注する際に権利が移転すると、事業者が追加したコンポーネント等が再利用できなくなる問題が生じる。そのため、オープンソースライセンスを選択する方が望ましい場合もある。パターンに分けて決めていくことが必要である。
民間では、CNCFがOSSのステージ毎にラベルを付けて、「Sandboxプロジェクト」「Toolboxプロジェクト」や「Incubating」「Graduated」等、オープンソースを目的別に分類している。国もポータルサイトのようなものに、目的別、成熟度別、用途別、ライセンス別等整理しラベリングすることが望ましい。
無保証の議論について、無保証の条項を入れることで法律上は守られるが、行政への信頼面で、ライセンスのリスク度合いを踏まえ、より踏み込んだクリアランスを取る必要がある。
論点④（P.14）の長期的な維持主体と責任分担について、非営利団体を活用することは海外で行われている。Catena-Xの事例や、アメリカやインドで、国が作成したソフトウェアを、非営利団体として参加する企業から協賛金をもらいながら、メンテナンスする役割ができている。恒久的に国の税金で賄うことは困難であり、非営利団体を中心に協調領域を生み出していくことも重要である。
日本の政策のものは国内に限定するのは問題ないが、広めたいものは日本に限定せず、グローバルを目指して、コミュニティを巻き込むことを想定していくべきである。民間でも、日本国内だけを対象にオープンソースを公開することはない。

「デジタル庁が利活用すべき民間OSSの選定基準」、「『OSS利活用推奨リスト』を作成する際のインプットと作成方法」、「『OSS利活用推奨リスト』を作成後に考慮すべき事項」について

OSS利活用推奨リストはメンテナンスの方法や縛ってしまうと厳しくならないか。選定基準について、政府は調達の公平性が求められるため、OSSを選択した際、一社随契だけでなく複数の会社が取り扱うことができるかどうかは重視するべきである。
所属組織では、選定基準や選定ルールなどをOSPOにて管理している。オープンソース毎にリスクを洗い出し、それを示したうえでそれぞれの事業担当者が選定している。データベースや認証基盤等の機能が大きいオープンソースについては、実績のあるオープンソースとしてOSPOがリスト化しポータルサイトへ掲載している。選定基準としては、ライセンスが商用で利用可能か、コミュニティ活性度、ガバナンスを挙げている。特にガバナンスは重要であり、メンテナーが複数者おりオープン化されているか、サーバダウン時に自社や他社からサポートを受けることが可能な体制があるのかを確認している。リストは1年に一度棚卸を実施し削除対応を行う。リストへの追加は随時目利き人材が行う。
選定基準の設定やリスト作成は完全にOSPOの役割である。特に緊急度の高い案件（例えば脆弱性に起因するもの）が発生した場合、システムのオーナーがその対応力を問われる場面が多い。IPAなどの組織から脆弱性情報を発信されているが、オープンソースの事例においては半年に一度、あるいは1年に一度の頻度で広く利用されているライブラリに重大な脆弱性が発見されることがある。こうした事態に対応するための体制整備が重要であり、教育や人材育成が不可欠である。事例として、CVEが発行された際にシステムを管理する省庁の担当者がシステム全体への影響を懸念し、アップデートを避ける傾向が見受けられる。
第1版の「OSS利活用推奨リスト」を誰が作成するかが非常に問題である。ただ単に鳥瞰図やCNCFLandscapeを参考にしても意味のないものになってしまう。例えば特定の情報源からリストを持ってくるのは公平性に欠けるという問題もある。OSPOができてから作成するべきである。情報提供という形で複数の情報源から収集するのは一つの案である。
利用者はお墨付きが欲しいのかもしれないが、デジタル庁が出すとお墨付きリストのような扱いになりリスクが高い。OSPOが組織内の困っている部署に対してリストを提示するのは適切な形だと考える。
OSPOができてから「OSS利活用推奨リスト」を作成するのが望ましいと考える。その際は明確な基準を作って、申請・審査するプロセスを経るべきである。また、AI関連OSSは日々更新されるため、リスト内と限ることで現場がOSSを使用しづらくなるリスクもある。参考程度に作成するのであれば問題ない。
「OSS利活用推奨リスト」の公開について、国が公開したリストの中にあるオープンソースの人材が重点的に育成されて、調達される側も効率が良く人材育成が可能になるなど有益な点も考えられるが、他委員の意見の通り、慎重に進めるべき。
事例として、「Digital Public Goods Alliance」が出すデジタル公共財リストは年次で審査・更新するということで始まった。また、「EU Open Source Solutions Catalogue」が欧州委員会から公開されているが、公開する前の3年間で、各国に対し「何に依存しているか」を調査して洗い出した上でリストアップしている。現在EUはその依存しているOSSに対して「投資」することによりOSSを守り、これら活動には意義があると考える。
一般に公開するリストのメンテナンスはOSPOを設置したとしても政府が行うことは現実的ではない。そのため、一案として政府が声を掛ける形で、民間と協働しOSS推進を行うDPG Japan Alliance のような団体を作り、リストの管理やOSSコミュニティの育成を行う等によって解決できるのではないか。
資料2（P.19）の「法的（知的財産権侵害等）・運用リスクが軽減される」という記載について、今まで問題になってなかったからリスクがない、と捉えるのではなく、問題があるが表面化していないことも考えられる。決してリスクが軽減されたとは考えるべきではない。
民間OSSのベンダーの選定について、民間OSSのベンダーがライセンス違反を犯した場合も国が法的責任を負うので、この点について十分な信頼と責任を負えるベンダーかどうかを判断する必要がある。
利活用する民間OSSが、最上流の権利者が作成したものでない場合、中間の者の改変により、第三者の知的財産権侵害を引き起こす恐れが出てくる。中間の者の改変履歴とその内容を調査する必要がある。
OSSは無保証で提供されることが通常であるため、技術的な欠陥はもちろん、第三者の権利侵害がないことについても、国側で調査する必要がある。
民間OSSを利活用し、改変等をしたものを更にOSS化した場合、ベンダーがライセンス違反をしていると、国だけではなく、国から頒布を受けた下流者が法的責任を負いかねない。この場合、無保証規定により、国の法的責任は回避できたとしても、国がOSS化したソフトウェアを利用したことで第三者が法的責任を問われるのは国の信頼性を著しく損ないかねない。この点をどう整理するかを検討する必要がある。
OSPOが権利侵害のようなリスクが起きにくいオープンソースを選定しておくことが重要である。オープンソース関連の財団に寄贈されているOSSの場合、デューデリジェンスチェックにて権利侵害のリスクを審査されており、それらから選定することによりリスク軽減が可能になるのではないか
諸外国の政策を参考にしても、国がOSSの指定をするという事例はおそらくなく、オープンソースを優先的に使用する条項はある。
完全にリスクを無くすことは不可能に近い。世界的に見てもライセンスに関する訴訟は頻繁に起こっている。訴訟は必ずしも悪いことではなく、判決として賠償金に加えてOSPO設置を求め、訴訟をきっかけとしてOSPOが広まった好事例もある。
リスクは日々変化するため、OSPOが様々な団体に積極的に関わって、常に情報をアップデートしていくことが重要である。

以上