Expert Panel on Open Source and OSS Utilization (4th)

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:: Friday, January 9, 2026, from 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 Third Expert Panel
- 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.

Proposed Roadmap for Open Sourcing

There is a sense of incongruity in the description that it takes two years to prepare. There is a sense of incongruity in dividing the three phases of cultivating a mind, preparing for operation well, and actually starting, but it should be done step by step from what can be done rather than spending one year each. For software that has already been released as open source, it should start with the minimum necessary things. For OSPO, it may be possible to start with activities by volunteers in a cross-sectional organization instead of making a budget and preparing before proceeding. I would like to show how to create a culture from what can be done.
It is said that the most expensive part of open source release is the community part. The way to activate the community for the government is very different from the way to activate the community for the general public. In the case of pilot release, there will be two kinds of pilot, one for the government and the other for the general public and the public, and it is necessary to pay attention to the community part in particular because it is different depending on the purpose of each. Looking at the case of the Linux Foundation, it seems that there are many costs to the community. In addition, regarding human resources, it is said that "organization for work certification and evaluation reflection process design of open source activities", but job description and evaluation system should be prepared as a matter of course rather than certification.
The contents of the roadmap seem to be heavy overall, but as other committee members say, I think that the impression will change if we proceed from what we can do. In addition, I wonder whether it is appropriate to use the expression of a matrix of materials. Isn't it necessary to reconsider the understanding of the axes such as rules and community?
As for the rules, first of all, a team like OSPO will be formed by volunteers, and at the preparation stage, the current situation will be clarified, and how to write the license, rights, operation, etc. in the repository will be discussed with those who have actually published it, and rules will be established. I have an image that good things will spread through trial and error, not that it will become 100% when this phase is completed.
How about incorporating the concept of "inner source" in the roadmap? Looking at the best practices in other countries, there is a trend to start with the inner source and open it if it seems good, and there are many cases where it is limited to the inner source only within the government and public institutions. Such a step-by-step approach may be considered as an option.
Certainly, as other members commented, it is common in other countries to start from within. If it is assumed that the phases described in the roadmap are also described with such an intention, it is more appropriate that there is a phase to start with the inner source first, and then a phase to expand the inner source. The current roadmap phase seems to take a long time to prepare. Since it is an operational phase within the agency, I felt that it would be good to make it a strategic phase.
If I were to say one thing, it would be that the rules of the government and the private sector differ greatly, so even if we were to open them up only within the government, we would need to consider how to apply them to the private sector.

OSPO function, Roles and Phases in Open Sourcing in Digital Agency

Although the difficulty is high, the OSPO design must be based on the utilization of open source. In general, there is no objection to the function described in the document, but the function that Digital Agency should have will differ greatly depending on the relationship between Digital Agency and vendors and how much in-house production is done. There are also some function that are not described in the document and are felt to be important. The first is "Window function". It is necessary to set up a consultation service for one-stop in Digital Agency and each ministry and agency. The second is "Antenna function". Antenna function that collects trends is very important as a premise for strategy and governance. It should be specified because it is necessary to have a function that collects information through exchanges with the open source community and OSPOs in foreign countries. function
As other members commented, it is important to make a function at the window. It should not be the case that "the OSPO is in charge of all OSSs". The OSPO is responsible for consultation when in trouble and for accompanying and supporting as a guide. They are concerned that everything will be left to the OSPO.
The role of OSPOs should not be overemphasized, especially in the early stages, and should focus on developing guidelines, etc., and should be limited to supporting roles such as monitoring, community liaison and information exchange.
The OSPO is developing a set of templates for the creation of internal portals within their organization. Such educational material would be a role for the OSPO.
Awareness-raising activities and the development of portals are very important roles of OSPOs in private companies. In addition, sharing within the company and mechanisms to absorb issues from within the organization are also important, and issues should also be shared. For example, there are cases in which departments using each OSS gather to hold regular meetings to collect issues and share issues using tools such as Teams.
In the case of legal and compliance, it is assumed that there are few staff familiar with the field, so it is necessary to decide whether the OSPO should make it in-house or seek external support. In the case of OSS, the issue is how much to cover infringement of rights, mainly copyright and patent rights. Actual software disputes and patent disputes are highly specialized, and it is difficult for companies to deal with them in the middle. As long as the government promotes OSS, it cannot avoid this. In particular, in the case of patent rights, there is a possibility that new patent infringements will occur in the process of modifying and using open OSS. In the private sector, it is common to get away with "non-assurance", but it is necessary to carefully consider whether it is appropriate for the government.
Because of the unit-based system in Digital Agency, I felt that there was a way to assign a legal representative to each unit or to cooperate with legal representatives of other units. The level of expertise is very high, and it is difficult to secure suitable human resources and time.

Roadmap for promoting OSS use and application (draft)

In the private sector, a list of internally proven OSS and a list of supported OSS are available on the corporate portal website, and each department uses them for reference. If they are used internally, for example, for scoring, the criteria for selecting private OSS to be used should be clarified. However, if the purpose of the recommended list is not clear, it may be meaningless and management may be complicated.
For the purpose of eliminating vendor lock-in, various parameters to be considered may occur. Recently, there have been situations that are difficult to predict, such as the global situation, price hikes of cloud services, and sudden SaaS service outages.
It is important to understand before using OSS. Your organization is recommended to handle OSS correctly in order to respond quickly to unexpected situations caused by vendor lock-in.
Many parts of the OSS utilization roadmap overlap with those of existing OSS promotion roadmaps, and we felt it necessary to reconfirm the significance of creating separate roadmaps.
It is written that a reference Architecture should be prepared. If it is prepared, open source software may become a dead giveaway. If it is made OSS-independent, there is a concern that the reference Architecture will become too abstract. In the private sector, the ordering party selects an open source software and outsources the work, but the function should be different depending on the selection method of the side that selects the open source software.
Human resources who can handle the roadmap system, community activation, and human resources items internally are required.

"Operation of OSPOs by function, Roles, and Phase in OSS Utilization in Digital Agency"

This issue also needs to be considered based on procurement rules. How about strategically considering the matrix of the roadmap as a phase to consider how to advance procurement reform?
At present, it is organized from the perspective of how to expand OSS utilization and how to organize OSPOs, but I felt that it could be organized from the perspective of what to do as procurement reform.
It is necessary to consider the discussion separately, but it is not necessary to set many arrow feather (action points) as the final output. It may be easier to see if the phases are not separated.
It may not be necessary to make the assignment of full-time. In Digital Agency, there are many people who hold concurrent positions, so I think it is difficult. Even if full-time is assigned, it does not mean that the phase on the roadmap has progressed, so there is no need to emphasize full-time.
There is no need to be particular about the type of employment, but in some cases it is better to have many concurrent jobs. It may be helpful to show a sense of scale in light of the budget. Since many knowledgeable people are also enrolled in the Digital Agency, it may be an idea to hire people with extensive experience in open source software.
If it is only the phase of using open source safely, "Legal" and "Compliance" are sufficient as a function that OSPO should have. If it is for the purpose of eliminating vendor lock-in and reducing costs, I think it is an image that open source knowledge will be accumulated by hiring enthusiastic and considerable experts who will lead OSS utilization. In addition, attention must be paid at the time of procurement, and if it is made a rule to always procure supported products, there is a possibility of depending on a specific vendor, so it is essential to appoint knowledgeable human resources.
It is important to create and administer training curriculums on risk management (intellectual property, legal affairs, etc.), and it is necessary to improve the minimum level of knowledge in the original section by providing training on licensing and intellectual property, because it is assumed that there will be a shortage of resources due to the large number of consultations and questions received by legal personnel by establishing OSPOs.
The content of Document 2 (P. 31) on Legal and Compliance only mentions infringements of rights on the government side, but it should be noted that there is a possibility that the government may become virtually unable to exercise patent rights depending on the content of the patent provisions.

Greater than or