Introduction
On May 18, 2026, the Digital Agency updated information on its “Expert Panel on Open Sourcing and the Use of OSS” and published meeting materials and related documents from the second meeting, which was held on December 18, 2025. This panel is positioned as a forum for discussing concrete measures for open sourcing and the use of OSS in government information system procurement. At the second meeting, participants discussed a wide range of issues, including assets subject to open sourcing, licensing rules, recommended open-source licenses, long-term maintenance entities and allocation of responsibilities, and methods for creating a recommended list of OSS for use.
What deserves attention in this discussion is that public administration appears to be moving from the stage of merely “using” OSS to the stage of “designing, publishing, maintaining, and embedding” OSS in society. The meeting suggests that simply publishing source code does not automatically enhance public value. Rather, institutional design is necessary, including licensing, allocation of responsibilities, maintenance, and community management.
Open Sourcing Is Not a Cost-Cutting Measure, but Procurement Reform Itself
The use of OSS by public administration is often discussed in the context of “cost reduction.” However, the materials for this meeting also presented the view that, as benefits of OSS use, it may be more effective to emphasize shorter development lead times and improved technical capabilities rather than cost reduction. This suggests that OSS should not be regarded merely as free software, but as a mechanism for transforming procurement, development, maintenance, and human resource development.
Government information systems in particular have long been criticized for issues such as vendor lock-in, rigidity in procurement, and the continuous increase of maintenance costs. Open sourcing can be one answer to these issues. However, making software open source does not automatically increase competition or reduce costs. It presupposes that the ordering party understands software rights, licenses, and operational responsibilities, and has the ability to manage them independently.
License Selection Is Not a Technical Issue, but a Policy Decision
An important point in this discussion is that licenses such as GPL, MIT, and Apache are being treated not merely as legal options, but as design tools for achieving policy objectives. The meeting summary notes that strong licenses such as the GPL may become a bottleneck from the perspective of promoting commercial use, while permissive licenses such as MIT are easier to adopt widely but may make it easier for free riders to emerge.
The question here is not “which license is correct.” The desirable license will differ depending on whether the government wants the software it publishes to be widely used by private companies, whether it wants modified results to be returned to the public sphere, or whether it wants to foster a community in a specific field. In other words, license selection is not merely a matter for engineers or legal staff. It is itself a policy decision concerning what the government seeks to achieve through the software.
Care should also be taken when creating unique licenses. The meeting summary includes the opinion that private companies have protected themselves by using standard licenses, and that unique licenses carry high risks. Patent clauses were also treated as an issue requiring careful consideration, in light of government-related patent rights and the possibility of enforcement of third-party patents.
“Publishing and Leaving It There” Is the Most Dangerous Form of Open Sourcing
What should be avoided most in open sourcing is the idea that responsibility has been fulfilled simply by publishing the source code. The meeting summary includes the view that it is generally regarded as bad practice to open source something on the assumption that the publisher will not maintain it, especially when there is no intention to pay maintenance costs in the future. It also includes the view that, even if quality is provided without warranty, the ordering party should take responsibility for maintenance and sustaining the community.
This point lies at the core of whether administrative OSS will succeed or fail. OSS does not acquire value at the moment it is published. It gains value when it is used, improved, when vulnerabilities are fixed, and when documentation is updated. If the government promotes open sourcing, it needs an operational structure that covers post-publication inquiries, security updates, dialogue with user communities, and roadmap management.
In some cases, a disclaimer of warranty may limit legal liability. However, if software published by the government contains defects or risks of rights infringement, trust in public administration may be damaged beyond mere contractual liability. Therefore, administrative OSS requires not only the perspective of whether the government can be legally exempted from liability, but also whether it can withstand public trust as a public institution.
OSPOs Will Become a Core Function of Administrative OSS
In this discussion, the role of OSPOs, or Open Source Program Offices, also became an important theme. The meeting summary includes the view that the selection criteria and creation rules for a recommended OSS use list fall within the role of an OSPO, and that it is important to establish a structure that includes urgent vulnerability response, education, and human resource development.
An OSPO is not merely a department that recommends the use of OSS. It is an organization that works across license compliance, vulnerability response, community coordination, OSS selection criteria, confirmation of rights relationships, and staff education. If public administration is to use and publish OSS in earnest, it needs a mechanism for accumulating organizational knowledge rather than leaving decisions to individual system managers.
This is especially important in public administration, where staff transfers, single-year budgets, and procurement procedures impose particular constraints. Given these administrative characteristics, it is essential to consolidate OSS-related knowledge in an organization such as an OSPO rather than leaving it dependent on individual personnel.
A Recommended OSS List Could Become an “Officially Endorsed List”
The recommended OSS use list also requires careful design. The meeting summary includes the view that, if the Digital Agency issues such a list, there is a risk that it will be treated like an “officially endorsed list.” It also includes the view that it would be desirable to create the list after an OSPO has been established, based on clear criteria and an application and review process.
This is a highly realistic observation. If the government recommends specific OSS, procurement sites may treat that OSS as a de facto standard. As a result, flexibility in technology selection may be lost, and excellent OSS outside the list may become less likely to be used. In fields with rapid update cycles, such as AI-related OSS, a fixed list could even become a burden on the front line.
On the other hand, a recommended list also has advantages. If OSS that satisfies certain criteria is made visible, government officials and contractors can select it with greater confidence. It may also contribute to human resource development and procurement efficiency. What matters is to position the list not as an absolute designation, but as reference information for risk assessment and selection support.
Maintenance Through Public-Private Collaboration Will Be Key
To maintain administrative OSS over the long term, the government should not try to handle everything by itself. Collaboration with private companies, nonprofit organizations, and communities will be necessary. The meeting summary also mentions ideas such as joint maintenance using nonprofit organizations, and the creation of organizations that promote OSS in collaboration with the private sector, manage lists, and foster OSS communities.
This direction is important for making administrative OSS sustainable. If a cycle is created in which the government bears development costs and publishes software, private actors use and improve it, and communities accumulate knowledge, OSS can more easily function as a public good. Conversely, if software published by the government increases but is used by no one and maintained by no one, open sourcing will become a mere formality.
In that sense, the success indicator for administrative OSS is not “how much has been published.” What matters is how much it is used, how much it is improved, and how continuously it is maintained.
Legal Risk Management Cannot Be Avoided
The use of OSS involves risks such as license violations, infringement of third-party intellectual property rights, lack of transparency in modification histories, and vulnerability response. The meeting summary points out the possibility that the government may bear legal responsibility if a vendor of private-sector OSS commits a license violation. It also points out that, in the case of OSS not created by the original upstream rights holder, rights infringement risks may arise due to modifications made by intermediaries.
This point must be taken particularly seriously in public procurement. When the government uses OSS, modifies it, and then publishes it, if upstream rights relationships and license compliance remain unclear, risks may spread to downstream users as well. If users who believed the software was safe because it had been published by the government later become involved in rights infringement or license violation issues, trust in public administration will be significantly damaged.
Therefore, the use of OSS requires due diligence before adoption, vulnerability monitoring during use, license confirmation when modifications are made, and clarification of rights relationships at the time of publication. This is not the job of the legal department alone. It is an issue that procurement, development, security, intellectual property, and operations must address in an integrated manner.
Conclusion
The Digital Agency’s expert panel shows that the use of OSS in public administration has entered a new stage. Until now, discussions on OSS have mainly focused on how to use existing OSS and how to reduce procurement costs. Going forward, however, the question will be whether public administration itself can publish and maintain OSS, form communities around it, and cultivate it as a public good.
To achieve this, the use of standard licenses, clarification of rights relationships including patent clauses, establishment of OSPOs, careful operation of recommended lists, and maintenance structures based on public-private collaboration are indispensable. Open sourcing is not merely the publication of technology. It is a reform of public procurement and digital government governance.
The true value of administrative OSS lies not in the publication of source code itself, but in the continued use, improvement, and trust of that source code within society. The Digital Agency’s latest discussion can be regarded as an important step toward seriously beginning the institutional design necessary for that purpose.