“Free to Use is Reassuring” — That Premise is Starting to Crumble

Many small and medium-sized enterprises (SMEs) have incorporated open-source tools into their operations, such as scheduling management, customer support, and internal chat. Tools chosen for their “free” or “freely usable” nature can suddenly become paid services. Licenses may change. They may become unusable altogether.

This is not a hypothetical scenario. It is happening right now.

In 2025, a series of emblematic events unfolded in the open-source world: the transition of scheduling tool Cal.com to closed-source, the complete ban on AI-generated code by game engine SDL, and Mozilla’s announcement of the enterprise-focused open AI “Thunderbolt.”

At first glance, these movements may seem unrelated. However, when we analyze the structure, one crucial message emerges that SMEs must not overlook.

The risk of relying on “free-to-use” tools is higher than ever.

—

The Real Reason Behind Cal.com’s Closure — The Fear of Being “Copied by AI”

Cal.com, an open-source scheduling management tool that gained popularity as an alternative to Calendly, has around 38,000 stars on GitHub. Companies worldwide have been self-hosting it on their own servers.

Now, Cal.com has decided to close off its core components.

The reason is simple. With the evolution of AI, the risk that open-source code could be used as “training material” and instantly copied into competing products has become a reality. Code developed over years can be mimicked by AI in just a few hours. Keeping it open has become synonymous with relinquishing one’s competitive edge.

What does this mean for SMEs?

Companies that have been using Cal.com for free via self-hosting may no longer receive updates in the future. If security patches cease, continuing to use it could become a risk. The migration costs of a tool that was adopted because it was “free” are often not calculated at the time of implementation.

For instance, if it takes an in-house engineer 40 hours to transition to an alternative tool, that amounts to 120,000 yen at an hourly rate of 3,000 yen. Outsourcing could cost between 300,000 to 500,000 yen. The bill for a “free tool” can arrive unexpectedly.

—

SDL’s Ban on AI Code — Quality or Efficiency?

Another shocking development is the decision by the game engine’s foundational library, SDL (Simple DirectMedia Layer), to completely ban AI-generated code.

The reasoning behind SDL’s decision stems from concerns over the quality of AI-generated code and legal risks. While AI-generated code may seem functional, it can behave unpredictably in edge cases. Moreover, there is a risk of license contamination from the source code used for training. If GPL contamination occurs, it could change the license of the entire project.

This decision has created a deep rift within the open-source community, pitting the “pro-AI for development speed” faction against the “AI code is unreliable” faction.

For SMEs, this is not just someone else’s issue.

The number of companies allowing AI to write code for their business systems is increasing. Over 1.8 million developers worldwide are using GitHub Copilot. But what if there is unknowingly license-violating code mixed in with that code? SDL’s decision may seem extreme, but the question of “who is responsible for AI-written code” looms over all companies.

—

Mozilla’s Contrarian Move — Winning Through Openness

While some players are closing down, others are moving in the opposite direction.

Mozilla’s announcement of the enterprise-focused open AI “Thunderbolt” emphasizes that companies can have complete control over AI models in their own environments. They can train with their own data without exposing it externally and build proprietary AI.

What makes this interesting for SMEs is the potential for “AI designed for large enterprises” to be offered in a way that is accessible to smaller businesses.

Using OpenAI’s API could incur monthly running costs in the tens of thousands to hundreds of thousands of yen. However, running an open-source model on a company server could mean that, aside from initial setup costs, the ongoing costs could be just electricity and server fees, amounting to as little as 5,000 to 20,000 yen per month.

Thunderbolt aims to structure this model for businesses. It responds to the needs of companies that want to use AI but do not want to expose their data or risk vendor lock-in, all through open-source solutions.

However, there is a caveat. Mozilla is also a for-profit entity. Just because it is open now does not guarantee it won’t follow the same path as Cal.com.

—

Observing the Structure — “Opening” and “Closing” are Happening Simultaneously

Let’s take a step back and organize the structure.

What is happening now is not a one-sided closure of open-source. “Closing” and “opening” are occurring simultaneously and accelerating.

The logic behind closing is this: AI has made the cost of copying code nearly zero. If it remains open, competitors can instantly imitate it. Hence, they close it off.

The logic behind opening is this: the risk of dependency on closed AI vendors (like OpenAI and Google) is increasing. To counter this, open options are necessary. Thus, they open up.

Both sides are correct. SMEs find themselves in a position to face both waves simultaneously.

The important thing is to stop the thought process of “open-source means safe” or “large services mean safe.”

—

Three Things SMEs Should Do Right Now

Let’s move beyond abstract discussions and focus on what to do concretely.

1. Take Inventory of Tools You Depend On

First, list the open-source tools used in your business operations: scheduling management, chat, CRM, project management, email. For each tool, ask, “If this tool became unusable tomorrow, would our operations stop?”

If the answer is yes, that indicates a dependency risk. Research alternative options now. Estimate the labor and costs involved in transitioning. Just doing this will significantly speed up decision-making when the time comes.

2. Check if You Can “Export Your Data”

Even if tools change, having your data on hand allows for migration. Conversely, tools that do not allow data export, no matter how convenient, are dangerous.

What you need to check is whether you can export all data via CSV or API. Dependency on tools that cannot do this should be reassessed immediately.

3. Estimate the “Migration Costs” in Advance

In the case of Cal.com, the migration costs to alternative tools (like Calendly, Doodle, or in-house development) can range from 100,000 to 1,000,000 yen, depending on the size of the company. Whether this is seen as an “unexpected expense” or a “planned investment” can drastically impact management.

Once a year, spend 30 minutes simulating “What if this tool becomes unusable?” This alone will significantly strengthen the IT infrastructure of SMEs.

—

Conclusion — Develop the Ability to See the Costs Behind “Free”

Open source is not dead. However, the era of “open source = free and safe” is undoubtedly coming to an end.

Cal.com has closed. SDL has rejected AI code. Mozilla has opened anew. These three movements indicate that the “opening and closing” of software has become a survival strategy for companies.

For SMEs, what matters is not which tools to use, but rather to create a system that can operate regardless of which tools become unusable.

Understand your dependencies. Keep your data on hand. Estimate migration costs in advance.

This may not sound flashy. However, the difference between SMEs that do this and those that do not will become decisive the moment the next “license change” occurs.

That day could be tomorrow.