This page has been translated using TexTra by NICT. Please note that the translation may not be completely accurate.If you find any mistranslations, we appreciate your feedback on the "Request form for improving the automatic translation ".

Expert Panel on Open Source and OSS Utilization (2nd)

Overview

Date and

Friday, December 18, 2025, from 10:00 a.m. to 12:00 p.m.

US>

Online (Microsoft Teams)

Agenda

  • Opening
  • Message from the Chairman
  • Agenda
    • Summary of the First 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

Committee Members Present

  • Leader of the Shoji Group
  • Mr. Imamura
  • Member Nakamura
  • Commissioner Iwahara
  • Advisor
  • Advisor Toyama
  • Mr. Suzuki, an

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.
Since the points of open source and OSS utilization are related to each other, the outline of the proceedings will not be organized according to each point.

"Assets subject to open sourcing," "Arrangement of licensing patterns," "Recommended open source licenses," and "Long-term maintainers and responsibility sharing"

  • Regarding the obligation to disclose the modified source code, the Amendment Rule states that the obligation to disclose the source code after modification is applicable. Does it mean that the obligation to disclose the source code only comes into effect after modification? If the obligation to disclose the source code only comes into effect after modification and distribution, it is similar to the GPL and could be a bottleneck from the viewpoint of promoting commercial use. If the obligation to disclose the source code only comes into effect after modification, it is stricter than the GPL and it will be more difficult to use it to third parties. In this case, isn't it difficult to specify the stage (requirements) at which the obligation to disclose the source code comes into effect?
  • The redistribution rules may make the use of redistribution more difficult because of the free and after-the-fact responsibility, and users may be encouraged to share the original link with their recipients rather than redistributing themselves.
  • The GPL is a strong open-source license, and I think it's one of the factors that made Linux popular in the 2000s, but in this day and age, I think the GPL can be risky.
  • I think that the GPL is too strict for private companies. If you want it to be widely used, MIT is more appropriate, but it is easy to get free riders. In many cases, the policy is to make the government independent of the private sector in the future, so it is easier to grow the community by choosing the GPL.
  • I feel that limiting the modification to non-commercial use is a pretty strict condition. In the private sector, the GPL has been used a lot in the past, but recently it seems to be used for hobby purposes and in the case of commercial open source. Using Apache and MIT, they prioritize widespread use and activation of the community.
  • With regard to the basic concept of license selection, it is necessary to select or create a new license in accordance with the basic policy of licensing rules after deciding on it. Depending on the concept of promotion of use, it may be basically divided into a loose license such as BSD or a strict license such as GPL.
  • According to the premise of the licensing rules in Document 2 (p. 12), it is required to impose the obligation to disclose the source code even for modified works. Is the GPL system appropriate? If it is intended to impose the obligation to disclose only for modified works, it is considered necessary to create a new license based on the GPL.
  • It would be better to provide for a patent clause, but what kind of provision should be made should be carefully examined from various viewpoints, such as the possibility of exercising the rights of government-related patent rights and the extent to which the enforceability of third party patents should be reduced.
  • Private companies have the experience of being protected by using standard licenses, so independent licenses are considered to be risky. If a new license is to be created, it is necessary to be prepared to obtain an international standard. It is also desirable to utilize the patent clause, which already has a section on Apache.
  • Since there are many parameters of open source and various viewpoints are intricately related, I felt that the promotion process of open source is very good. Issues related to licenses and the ultimate owner of open source exist not only in open source. We recognize that there is no consistency in the application of the Japanese version of the Bayh-Dole System and that other rules may be applied. We recognize that there are various issues in public information systems procurement itself, where there are positions of the ordering party and the trustee party. In addition, open source is accompanied by many risks such as the scope of responsibility, but these are also fundamentally caused by the problems of software development itself. For example, if basic matters such as the implementation of tests and what kind of assets the developed software will become are not resolved, it will be difficult to realize open source.
  • The purpose of open-sourcing by a private company is to reduce the cost compared to the case of owning and managing it alone by implementing joint maintenance by other companies and sharing the operation cost. It is open-sourcing when there is such a clear incentive. In terms of the government, it may be possible to reduce the operation cost by joint maintenance by the government and volunteer private companies or individuals. Also, it may be necessary to design to reduce the cost by sharing the cost with multiple ministries and agencies.
  • In the case of the maintenance of open source software by the government, the budget and responsibility vary depending on the software to be created, and some software do not require maintenance. If it is to be used continuously and voluntarily by the government, the budget will be secured. The problem here is what to do if the budget is not continued for commissioned software. If it is socially beneficial, other beneficiaries may take over the maintenance, but if it is not used, it will just be left. Also, the disadvantage of unmaintained software to society is an important issue.
  • One idea is to explicitly remind people not to maintain open source software that they do not plan to use in the future, such as by not publishing it on GitHub or making it available for download in a Zip file. As with the open data debate, the government is not responsible if there are mistakes, but obvious mistakes should be fixed.
  • Regarding the scope of responsibility, I would like to assert that there is no guarantee for software that has been open-sourced. If there is something that can be reused, it should be open-sourced with a strategic clarification of who and where you want it to be reused. As an example, there is the "India Stack," which open-sourced public infrastructure in India, and I think that Japan should have the same determination as the government.
  • It is generally considered bad practice to open source something that you are not going to pay to maintain in the future. Even in such a case, you should only open source it if there is an audience, and the role of the OSPO to think strategically about whether or not to open source it is essential.
  • For example, in the academic field, in order to prove that a paper is correct or to provide academic knowledge, it is released with an explanation or label that it has been open-sourced, and it may be possible to alleviate taxpayers' dissatisfaction by attaching a separate explanation (several labels) from the start of the release.
  • Having a strategy is one thing, but having no guarantee is another. There is no guarantee of quality, but the owner should be responsible for the maintenance of the operation and the maintenance of the community. It is necessary to establish a strategy and objectives.
  • It is difficult to apply one rule to all, and patterns should be established. For example, the Japanese version of the Bayh-Dole System is often adopted in R & D, not in consignment contracts. In addition, if the rights are transferred when the government places an order for system development in the case of existing OSS activities, there will be a problem that components added by the business operator cannot be reused. Therefore, it may be preferable to choose an open source license. It is necessary to decide by pattern.
  • In the private sector, the CNCF labels different stages of OSS and categorizes open source by purpose, such as "Sandbox projects," "Toolbox projects," "Incubating," "Graduated," etc. It is desirable for the national government to organize and label open source projects by purpose, maturity, use, license, etc., like a portal site.
  • Although it is legally possible to protect an argument without assurance by including an assurance clause, it is necessary to take a more in-depth clearance in consideration of the degree of risk of the license in terms of trust in the administration.
  • Regarding the long-term main maintainer and responsibility sharing of issue 4 (p. 14), non-profit organizations are used overseas. In the case of Catena-X and in the United States and India, they are able to play a role in maintaining software created by the government while receiving sponsorship money from companies participating as non-profit organizations. It is difficult to finance it permanently with national taxes, so it is also important to create a cooperative area centered on non-profit organizations.
  • Japanese policies can be limited to Japan, but what we want to spread should not be limited to Japan. We should aim to be global and expect to involve the community. The private sector will not release open source only for Japan.

"Selection criteria for private-sector OSS to be utilized by Digital Agency," "Inputs and methods for compiling a list of recommended OSS utilization," and "Matters to be considered after compiling a list of recommended OSS utilization"

  • Regarding the selection criteria, since the government requires fairness in procurement, it should be emphasized whether or not multiple companies can handle an OSS, not just one company, when selecting an OSS.
  • OSPO manages the selection criteria and selection rules in the organization to which it belongs. Risks are identified for each open source, and after that, it is selected by the person in charge of each project. For open sources with a large function, such as databases and certification infrastructure, OSPO lists them as proven open sources and posts them on the portal site. As selection criteria, it lists whether the license can be used commercially, the degree of community activity, and governance. Governance is especially important, and it is confirmed whether it is open with multiple maintainers and whether there is a system that can receive support from the company or other companies when the server goes down. The list is inventoried once a year and deleted. Additions to the list are made as needed by a knowledgeable person.
  • It is the responsibility of the OSPO to set the selection criteria and create the list. When a particularly urgent issue (for example, caused by a vulnerability) occurs, the system owner's ability to respond is often called into question. Vulnerability information is released by organizations such as IPA, but in the case of open source, once every six months or once a year, serious vulnerabilities may be discovered in widely used libraries. It is important to establish a system to respond to such situations, and education and human resource development are essential. As an example, when a CVE is issued, the person in charge of the system in the ministry or agency that manages the system tends to avoid updating the system due to concerns about the impact on the entire system.
  • The issue of who should create the "list of recommended OSS utilization" in the first edition is very important. However, simply referring to the bird' s-eye view or the CNCFLandscape is meaningless. For example, it is unfair to bring in a list from a specific information source. It should be created after the OSPO is established. It is one idea to collect information from multiple information sources in the form of information provision.
  • Users may want an endorsement, but if Digital Agency submits it, it will be treated like an endorsement list and the risk is high. I think it is appropriate for an OSPO to present a list to departments in need within the organization.
  • It is desirable to create the "List of Recommended Uses of Open Source Software" after an OSPO is created. In doing so, clear criteria should be established and the application and review process should be followed. In addition, there is a risk that it will become difficult for field workers to use open source software if the list is limited to OSSs related to AI, which are updated on a daily basis. There is no problem if the list is created only for reference.
  • Regarding the publication of the "List of Recommended Uses of OSS," although it is considered to be beneficial in that human resources for open source software in the list made public by the government will be intensively developed and the procurement side will be able to efficiently develop human resources, as pointed out by other members, it should be promoted carefully.
  • As an example, the Digital Public Goods Alliance started out by compiling a list of digital public goods that would be reviewed and updated on an annual basis. The EU Open Source Solutions Catalogue was also published by the European Commission. In the three years prior to its publication, the EU surveyed each country to identify what they were relying on. At present, the EU protects OSS by "investing" in the OSS on which it relies, and considers these activities to be worthwhile.
  • It is not realistic for the government to maintain the publicly available list even if an OSPO is set up. Therefore, as a solution, the government should establish an organization such as DPG Japan Alliance to promote OSS in cooperation with the private sector, and manage the list and foster the OSS community.
  • Regarding the description "legal (infringement of intellectual property rights, etc.) and operational risks are reduced" in Material 2 (p. 19), it is not considered that there are no risks because there have been no problems so far, but it is possible that there are problems but they have not surfaced. It should not be considered that risks have been reduced.
  • When selecting a private OSS vendor, the government will be legally responsible even if the vendor violates the license, so it is necessary to determine whether the vendor can be trusted and responsible enough.
  • If the private-sector OSS to be used is not created by the most upstream right holder, there is a possibility that modification by an intermediary may cause infringement of intellectual property rights of a third party. It is necessary to investigate the history of modification by the intermediary and its contents.
  • As OSS is usually provided without warranty, it is necessary for the government side to investigate not only technical defects but also the absence of infringement of third party rights.
  • When private OSS is used and modified and made into OSS, if the vendor violates the license, not only the government but also the downstream who received the distribution from the government may be held legally responsible. In this case, even if the legal responsibility of the government can be avoided by the non-warranty provision, if a third party is held legally responsible for using the software made into OSS by the government, it may significantly damage the credibility of the government. It is necessary to consider how to sort out this point.
  • It is important for the OSPO to select open source software that is less likely to incur the risk of infringement of rights. In the case of OSS donated to open source foundations, the risk of infringement of rights has been examined in due diligence checks, and it may be possible to reduce risks by selecting from them.
  • If you look at the policies of other countries, there are probably no cases where a country designates OSS, and there are provisions that give preference to open source.
  • It is almost impossible to completely eliminate the risk. Lawsuits concerning licenses occur frequently around the world. Lawsuits are not necessarily a bad thing, and there are good examples of OSPO spreading as a result of lawsuits demanding the establishment of OSPO in addition to compensation as a judgment.
  • As risks change on a daily basis, it is important for OSPOs to actively engage with various groups and keep them updated.

Greater than or