Advisory Panel of Experts on Open Source and OSS Utilization (3rd)

Last Updated:: May 27, 2026

Overview

For an overview of this study group, please refer to Expert Panel on Open Source and Open Source Software Utilization .

Event Information

Date and Time:: December 23, 2025 (Tuesday) 11:00 a.m. to 1:00 p.m.
Location:: Online (Microsoft Teams)
Committee members present:: Chairperson SHOJI, IMAMURA, NAKAMURA, Iwahara, SEKI, TOYAMA and SUZUKI

Agenda

Opening
Message from the Chairman
Agenda
- Summary of the Second Expert Review Meeting
- Sharing and discussing open source issues and assumptions
- Sharing and discussing issues and hypotheses regarding OSS utilization
- Upcoming Schedule
Closing and Communication

Material

Summary of the proceedings

The Secretariat explained the review of the previous Study Group and the issues and hypotheses of the current Study Group, followed by discussion. The main opinions of the committee members were as follows.

<Managing open source software assets when Digital Agency open sources> Accept contributions

I think we're going to end up with a policy. Here's a helpful excerpt from Linux Foundation developer Linus' remarks:
- Use AI tools for maintenance (could AI be used for triage?)
- An operational rule to maintain backward compatibility without causing regression. (It should be solved by the interface. Therefore, it is important not to try easy refactoring even if it becomes a little complicated.)
- Do not respond to requests easily. (Lower your expectations beforehand.)
In general open source, contributions are basically accepted by anyone. However, since the acceptance policy is set by the community and reviewed by maintainers, it is important to have maintainers who can conduct reviews according to the policy. As in general software engineering, the policy should have a clear roadmap, such as the frequency of version upgrades and the timing of disruptive changes. In Digital Agency, it is necessary to hire people who understand these roles.
I think acceptance of contributions is a very difficult topic. It is possible to prepare a contribution markdown process and specify the cycle in which it will be reflected. However, when it comes to writing a policy, it is difficult to decide the level of rules because it depends on the nature of the development team and product. It has to be an overview with a high level of abstraction, such as specifying the reflection process and rules for contributions. It is assumed that the use of reviews and AI will become common in the future, so I think it is not necessary to write it as a policy. It is important to share practices rather than policies and create a culture.
One thing to consider is that in the case of open source, it is difficult to narrow down the scope of acceptance. It is possible in the case of inner source, but I think it is impossible to receive pull requests from a limited number of people due to the mechanism of GitHub. It is either open or pull requests are not accepted.
Creating a culture is important and Linus talked about creating one. For example, there is a culture where the LTS release date is not stated and the community can understand it. Also, I feel that it is effective to not touch the existing function.
When security holes occur, there is a possibility that the original software may be modified, even in good faith, to infringe the patent rights of a third party that did not infringe at first. It may be better to establish a system to check for patent infringement when making some modifications. It is not a problem that the government is not legally responsible without guarantee, but I think that it is necessary to go beyond the legal obligation from the viewpoint of ensuring the reliability of the government.
From a practical point of view, the question is whether it is possible to check for patent infringement.

<Digital Agency's Open Source Software Asset Management at the Time of Open Sourcing> Measures against vulnerabilities

There is an unspoken culture of maintainers in the general community. It is essential to have a team of maintainers who understand: large patches are NG, disruptive changes are only for major version upgrades (roadmap policies vary from community to community), and always include test code.
There are two patterns, one in which vulnerabilities are found in dependent libraries and the other in which vulnerabilities are reported in the open source (product) itself. If it is the former, experienced people can deal with it, but if the product itself has CVEs, it will be a serious problem.
If vulnerabilities are found in libraries, there should be a response process in the existing organization, not limited to open source. Therefore, even in the case of OSSs, follow that process. It is necessary to organize contact points where OSSs can contact the CSIRT, and it is ideal for the CSIRT to manage the SBOM. In addition, if vulnerabilities are found in the OSS itself, the vulnerability will be revealed if it is reported as an issue. Therefore, it is considered appropriate to have it reported to the contact point such as an e-mail address. Regarding vulnerabilities, it is desirable to prepare a security markdown at the time of publication and specify the contact point.
As for the vulnerability response, the community is basically free because there is no guarantee. However, it is necessary to refer to the best practices published by the Open SSF because it is necessary to define the response process for accepting and disclosing vulnerabilities in the case of open source that is used by many people and where moral responsibility is involved.
<https://www.bestpractices.dev/ja>
OSS can be freely added and modified by various people, and even if there are no problems at first, there are legal vulnerabilities that may satisfy the constituent elements of infringement of others' patent rights through continuous modification. It is desirable to prevent people who want to modify OSS from proceeding with development without understanding all patent risks and eventually getting involved in trouble, but this does not promote the use of OSS. For example, when the government adopts OSS or promotes its use, it may be effective to create a list of dangerous parts of related source code and the sufficiency rate of constituent elements and call attention to it.
There is a phenomenon in which suspected license violations become a topic on social media and spread first. A dedicated contact point for reporting is necessary, and it is considered that there is no problem with AI chat as a contact point.
It is not a bad thing to be reported, but it is not a good thing to increase the psychological burden of reporting. It is necessary to have a way to deal with the report well.
It is difficult to respond quickly, but there is a reputational risk if it is left unattended. The focus is on the system of response and the way of reaction.
Whether or not it is difficult to respond quickly depends on the project. If the project is currently being outsourced to a vendor, it is necessary to consider the case separately, such as raising the priority of the ticket and having it respond quickly.
It is necessary to consider this separately from cases such as R & D and academic research that are no longer used.
In addition, since it is impossible to respond to all cases due to human resources, AI chat, etc., can be used.
It is not a matter of whether corrections are made quickly, but it is important to visualize that the report itself has reached the organization.

<Open Source Software Asset Management at the Time of Digital Agency's Open Source>

As a general rule in open source, the management and reporting of defects are often handled by GitHub issues. There are also rules when reporting issues, and in the case of bugs, it is required to describe how to reproduce them. It is necessary to consider governance in advance, such as whether the severity of the defect will be determined by the hired maintainer, who will approve it, and whether it will be divided between the vendor maintainer and the OSPO maintainer. In doing so, it is a prerequisite that the OSPO side also hires people who are knowledgeable about technology.
If it is a minor problem, the user may fix it, or a bug report and a patch may arrive together. In a normal community, there are some criteria for priority, but it is only a collection of volunteers, so maintainers often respond in the order they feel like.
In order for OSPOs to undertake all the matters described in the document, it is difficult for the administration to allocate a large amount of resources to OSPOs. It is assumed that human resources will be gathered little by little and promoted concurrently as a horizontal cross-sectional team. In reality, it is difficult to make decisions on order issues, etc. for all open OSS. It may not be possible to respond unless OSPOs check whether what was dealt with on the site is being done well.
AI could be used to determine the severity of the decision to amend, and AI could be addressed to a certain extent by formatting the report and describing the method of reproduction.
For OSPOs, it is safe to decide which level is critical.
In general, OSPOs are not involved in the development and only give policies. The actual community management should be carried out by the management team. When the management of the community is entrusted to a vendor, it is difficult to predict the amount of development, so how to order is also an issue.
We share a website link because there is a paper on the difficulty of delegating communities.
<https://www.jstage.jst.go.jp/article/aaostrans/12/2/12_2023-005/_pdf/-char/ja>
An example of an order is a Linux Foundation project that collects money from its members to hire maintainers. The hiring of maintainers is done by various organizations, and the contract type is a quasi-mandate contract.
I think there are several patterns. By being able to make agile contracts, it is possible to respond flexibly. The important thing is to have experts who can make decisions within the organization and establish a system that can give appropriate instructions to vendors. It is necessary to flexibly change the way of proceeding depending on the maturity of the project, but the expected value control should be done well.
As unclear priorities and criteria are likely to lead to omissions and increased risks, it is recommended to clarify who will respond, but in practice this may need to be considered on a case-by-case basis.
I would like to deepen the discussion on the need to manage patches. I would like to avoid the burden of developing an incident management system for that purpose. I think it is meaningful to share critical ones with other teams.
Depending on how GitHub is used, I don't think it is necessary to develop a new system. If you fix a critical one, you should release it quickly, but if you fix a small bug, you should decide on a policy such as releasing it in a lump.
I think it's better not to write too much "How". It's important to clearly state why you are doing this, so why don't you post best practices on GitHub such as that the OSPO decides the labeling requirements and each team complies with them?
There should be no problem as long as the corrected ones can be traced back to the past.

<Procurement requirements when Digital Agency uses OSS> Guidelines for OSS licensing at the time of procurement

Regarding transparency, in the case of a system for verifying something, if there is no verifiability, there is a problem that it is not known if the verification is really complete. For example, recently, problems of false information and misinformation are prominent. Transparency is required for whether the algorithm that determines false information can really determine it. It is desirable to make the algorithm itself verifiable.
The components of the system itself should be made public.
Systems that are open and transparent should be based on Digital Agency OSS from the beginning before using open source. For systems that handle personal data, it is necessary to check the design and consider a convenient open source function and license. Even if it is a GPL license, it is important to respond flexibly if it is convenient and the range of propagation is limited.
"In a system that handles personal information, there is a possibility that the risk will increase in the case of a copyleft type" is not considered necessary because it is unlikely that the source code will be modified in a way that includes personal information while the original system is open to the public.
If a system is not complete, but a patchwork of systems, there is a concern that if a system developed and released by Digital Agency contains technology developed by an outside developer that infringes on the rights of another party, the technology developed by Digital Agency will continue to infringe on the rights of another party.
There are no special risks associated with being an OSS, as license violations must not occur even in normal procurement, regardless of whether it is an OSS or not.
As far as the infringement of other companies' rights is concerned, it has been stipulated in the contracts for the procurement of systems in the past. As for the type of license to choose, there is nothing that should be avoided other than not using the GPL for software that is not going to be released, whether it is OSS or not.
What do you think about the category or responsibility of software development, which should not be discussed in this study group? There are so many different perspectives on open source that the discussion diverges.
If we focus only on usage, not on re-distribution, there is a mixture of MIT and Apache in the permissive type in the document. It seems that the rights of others = patent rights, but even among OSSs, some have provisions on patent rights and others do not, and the way they are prescribed varies and is ambiguous. It is necessary to consider whether to adopt those that do not restrict the exercise of patent rights, etc., based on the extent to which the government may exercise patent rights against companies in other countries.
There are concerns about how to check in-house development using open source software in Digital Agency.
OSPO's role will be to provide education to raise awareness of licensing.
If Digital Agency uses open source software for in-house development, it must be kept in mind that it may infringe on other parties' patent rights when modifications are made.

<Procurement requirements when Digital Agency uses open source software> Requirements to be evaluated in procurement specifications

When procuring using OSS, it is not desirable to specify a specific OSS in the specifications from the viewpoint of fairness. Therefore, it is difficult to decide the OSS in advance. Therefore, there is a problem that it is difficult to specifically write the results of contributions to the community, etc. It is possible to make the submission of OSS-related certifications, etc. a requirement. In practice, there are cases where vendors who respond to pull requests are excluded from the defect warranty requirements. This is relevant not only to procurement but also to discussions related to contracts.
Since it is difficult to decide on open source, if it is possible to evaluate additional points, it is assumed that it will be an appeal point when the use of open source is included in the bidding requirements or when a bidder proposes the use of open source, but whether to evaluate additional points or not will depend on the knowledge of the evaluator. Regarding the management system, the minimum system can be secured by using the ISO standard Openchain, etc. and acquiring self-certification based on the checklist. Furthermore, regarding maintenance and operation capabilities, there is a possibility that there will be a large gap between actual technical capabilities and budget constraints, and it may be possible to respond if an adequate budget is secured. Depending on the budget, it may be difficult for open source maintainers to respond immediately and it will affect the priority of each project. Therefore, attention should be paid to the description method and evaluation method.
<https://openchainproject.org/checklist-iso-5230-2020>
It may be necessary to make the presence or absence and the degree of ability to check legal risks a requirement. Even if the warranty liability is stipulated in the contract, it is meaningless if the vendor does not actually have that ability. There are few vendors who have a legal check system. It is necessary to confirm and evaluate the past performance and the legal check system or to reflect it in the price. If they do not have that ability, the government will need to establish a legal check system. However, it can be an indication that the burden on the government can be reduced if it is strong.
The current state of the administration is that many legal checks are entrusted to business operators, and there is a lack of knowledge to confirm whether they are actually being checked. I think it is necessary to create standards related to the legal check system when launching a product as a country.
It is important to secure human resources who can make legal decisions, but few lawyers understand the scope of patent rights, and if we rely on orders, the cost will increase. Therefore, it may be an idea to transfer people with knowledge from Japan Patent Office, for example. In addition, we consider that it is also necessary to create a system in which we can share the awareness of problems by implementing training, etc., for the purpose of improving knowledge in the field.

<Procurement requirements when Digital Agency uses open source software> Organization of SBOM

Since a system is required to manage downloaded open source, it should be assumed that one exists. Since CVE information can grow over time, such changing information should preferably not be included in the SBOM. The approach is to include the package URL in the SBOM and have Digital Agency pull up the CVE.
In practice, it is meaningless to submit SBOM on DVDs unless reasonable requirements are set based on the operation. Therefore, it is ideal to have a repository on GitHub with a mechanism to update the SBOM so that vulnerabilities can be investigated immediately if they are found. The direction of the hypothesis is correct, but the requirements should be examined after the operation of the OSPO and CSIRT is clarified.
It is essential that the file format is machine-readable, and it is important that it can accommodate automatic updates.
In terms of the roadmap, how the SBOM will operate will be important.

Greater than or