Back in the 1990s, I was concerned that Japan was beginning to lag behind the United States in software technology. The primary reason for this delay was likely Japan’s heavy focus on hardware at the time, viewing software merely as an accessory to hardware. I believed that Open Source (then still called “free software”) would be an effective way for Japan to catch up, but bringing Open Source into the mainstream of the software industry proved quite difficult.

In 1998, the term “Open Source” was born. Centered around the Open Source Initiative (OSI), what came to be called the Open Source movement took off. In Japan, however, there was only a boom that focused specifically on “using Linux,” rather than on Open Source as a whole. Back then, I still felt this was a significant change, but a few years later, I realized it was not enough. The benefits of using Linux systems alone were emphasized, while the advantages of collaborative development under Open Source were not recognized in Japan. This is evident even now in Japan’s relatively low level of contribution to Open Source compared to its economic scale and population.

There are various reasons why Japanese companies tend to be cautious about contributing to Open Source, but fundamentally, it seems to stem from a strong desire to avoid accountability. They are overly fearful of being held responsible if a problem is discovered in the code they have written.

To address this mindset, I began to advocate that companies hire individuals who are familiar with and attuned to Open Source communities, entrust them with all open source–related matters (including compliance), and have these individuals and their teams be responsible for building relationships with the community. By that time, Google already had an organization called an OSPO, though I wasn’t yet referring to such roles as OSPOs myself, and the TODO (OSPO) Group did not exist yet.

Now, I believe that all large Japanese enterprises should establish an OSPO. At the same time, I’ve also concluded that merely setting up an OSPO is not enough to make contribution to and release/publish of Open Source a widely accepted practice in Japan. One issue is that there are virtually no Japanese professionals working at Japanese companies (although there may be some at foreign-owned enterprises) with the capability to lead an OSPO. And even if such a person is found, the biggest problem is that Japanese companies often do not delegate sufficient authority. Without real authority, an OSPO is essentially relegated to nothing more than a department for addressing license inquiries.

I am deeply concerned that OSPOs in Japan are being treated simply as compliance organizations. Are the executives of large companies installing OSPOs, setting up internal mechanisms that follow OpenChain, and mistakenly believing they are now on par with cutting-edge companies? Japanese companies need, in a more fundamental sense, to adopt a continuous cycle of using, contributing to, and releasing Open Source, and strong leadership is essential to drive this. It may well require changes at the industry or societal level, or perhaps even some form of political intervention.

It seems there is still plenty for me to do.

If anyone from The Linux Foundation, the TODO Group or others happens to read this, I hope they understand that this is the view of someone who has been involved with Open Source in Japan for a very long time, and keep in mind that there is still much more that can be done in Japan to advance Open Source. Also, if there are companies that need help, please help them.

(original story is here : https://www.linkedin.com/pulse/missing-piece-japans-open-source-journey-strong-visionary-shuji-sado-2jnvc/ )

The Current State of the Theory that GPL Propagates to AI Models Trained on GPL Code

When GitHub Copilot was launched in 2021, the fact that its training data included a vast amount of Open Source code publicly available on GitHub attracted significant attention, sparking lively debates regarding licensing. While there were issues concerning conditions such as attribution required by most licenses, there was a particularly high volume of discourse suggesting…

The Legal Hack: Why U.S. Law Sees Open Source as “Permission,” Not a Contract

In Japan, the common view is to treat an Open Source license as a license agreement, or a contract. This is also the case in the EU. However, in the United States—the origin point for almost every aspect of Open Source—an Open Source license has long been considered not a contract, but a “unilateral permission”…

Evaluating OpenMDW: A Revolution for Open AI, or a License to Openwash?

Although the number of AI models distributed under Open Source licenses is increasing, it can be said that AI systems in which all related components, including training data, are open are still in a developmental stage, even as a few promising systems have emerged. In this context, this past May, the Linux Foundation, in collaboration…

A Curious Phenomenon with Gemma Model Outputs and License Propagation

While examining the licensing details of Google’s Gemma model, I noticed a potentially puzzling phenomenon: you can freely assign a license to the model’s outputs, yet depending on how those outputs are used, the original Terms of Use might suddenly propagate to the resulting work. Outputs vs. Model Derivatives The Gemma Terms of Use distinguish…

Should ‘Open Source AI’ Mean Exposing All Training Data?

DeepSeek has had a major global impact. This appears to stem not only from the emergence of a new force in China that threatens the dominance of major U.S. AI vendors, but also from the fact that the AI model itself is being distributed under the MIT License, which is an Open Source license. Nevertheless,…

Significant Risks in Using AI Models Governed by the Llama License

Although it has already been explained that the Llama model and the Llama License (Llama Community License Agreement) do not, in any sense, qualify as Open Source, it bears noting that the Llama License contains several additional issues. While not directly relevant to whether it meets Open Source criteria, these provisions may nonetheless cause the…

The Hidden Traps in Meta’s Llama License

— An Explanation of Llama’s Supposed “Open Source” Status and the Serious Risks of Using Models under the Llama License — It is widely recognized—despite Meta’s CEO persistently promoting the notion that “Llama is Open Source”—that the Llama License is in fact not Open Source. Yet few individuals have clearly articulated the precise reasons why…