Why We Insist on Official Source Code Licensing Instead of a SaaS Subscription Wall

In the software industry, subscription has become almost a default assumption of correctness. It offers predictable cash flow, lower delivery costs, faster iteration. For vendors, it is an efficiency choice; for users, it is often a convenience choice. But convenience and efficiency do not automatically mean fit.

We chose a different path: delivering our products through official source code licensing, so that customers can deploy on their own, can extend the code, with licensing boundaries written into the contract rather than buried in the changelog of terms of service.

This is not a moral stance about business models. It is an engineering and commercial decision based on a long-term judgment. Let us lay out what we have thought through.

Two kinds of relationships in software delivery

SaaS by subscription is essentially "renting capability." What the customer buys is access to a service for a period of time. The code runs on the vendor's servers; the customer receives an account and an interface.

Source code licensing plus self-hosted deployment is essentially "transferring capability." The customer gains the right to run the system in their own environment, and the right to modify it within licensed boundaries. The code runs on the customer's own infrastructure.

Neither relationship is inherently superior, but they shape very different dependency structures. In the first, the relationship between customer and vendor continues as long as the subscription renews. In the second, the customer's relationship with the system stands on its own after delivery is complete.

We prefer the second. The reason is simple: we want customers to choose us because the product remains useful, not because switching costs are high.

Deployable: the right to run should rest with the user

Deploying a system on a customer's own servers, private cloud, or compliant domestic environment means several concrete things:

• Data does not leave the boundary. Business data, customer records, and behavioral logs stay within the customer's control.
• Availability is in the customer's hands. Network policies, backup cadence, and disaster recovery can align with existing systems.
• Lifecycle is predictable. Even if a version stops receiving updates, the deployed system can continue to run.

These are not abstract benefits. They are questions many organizations must answer during procurement. Especially in contexts involving compliance, audit, or industry regulation, "can we control it ourselves" often ranks ahead of "how many features does it have."

We do not believe every scenario requires self-hosted deployment. But for those that do, "subscription only, no deployment" is itself a form of exclusion.

Extensible: letting capability grow through use

No general-purpose product can anticipate every business detail. Real-world requirements branch: the same workflow has different approval levels in different organizations; the same data has different definitions across business lines.

Secondary development is not a rejection of the product. It is the inevitable extension of a product into a real environment.

We allow and support secondary development within licensed boundaries: interface extensions, process customization, module additions or removals, integration with existing systems. We also state the boundaries openly: what can be changed, what is not advisable to change, and which changes will affect future upgrade support.

Frankly, open extensibility has costs for a vendor. It means more complex support scenarios, harder version management, more scattered feedback. We accept those costs, because the "uniformity" that closure provides is often the vendor's convenience, not the customer's gain.

Clear licensing boundaries matter more than "unlimited freedom"

We emphasize source code licensing, but we do not advocate "no boundaries." Software is an asset, and rules protect both sides' expectations.

A clear license usually answers:

• Scope of use: number of deployable instances, user scale served, business entities covered.
• Scope of modification: modules that may be modified, components that may be replaced, notices and copyright information that must be retained.
• Distribution limits: whether redistribution is permitted, whether it may be embedded in products sold to third parties.
• Upgrades and support: how versions are obtained, support duration, and the division of responsibility after secondary development.

Spelling these out is troublesome in the short term and reduces disputes in the long term. Many partnerships break not because terms were too strict, but because they were never made clear.

The logic of seat-based SaaS, and its costs

Seat-based SaaS pricing is intuitive: by account, by active user, by call volume. It ties software value to usage scale—friendly to vendors, and friendly to early-stage users, since costs are low at small scale and rise with expansion.

Its costs are equally clear:

• Cost grows linearly with organizational size. More people means a larger bill, not necessarily proportional to the value the system delivers.
• Stop paying, stop using. Once renewal ends, accounts close, and the availability of historical data and configuration depends on how much export capability the vendor provides.
• Limited room for customization. Most SaaS offers configuration options and open APIs, but not the right to modify the core.
• The roadmap belongs to the vendor. Customers can submit requests but cannot set priorities.

This is not an indictment of SaaS. For scenarios that are highly standardized, fast-changing, and where the customer does not want operational responsibility, SaaS is a reasonable choice. We simply believe it should not be the only choice.

Ownership of customer assets: data, code, and knowledge

"Customer assets" is an overused phrase. We break it into three parts:

Data — business data, customer data, logs. Ownership should clearly belong to the customer. Vendors should not use it for their own purposes, should not provide it to outside parties, and should not retain it after cooperation ends.

Code — within licensed boundaries, the customer holds the right to use and modify delivered code. Ownership and disposition of derivative code produced by secondary development should be written into the contract.

Knowledge — implementation methods, configuration experience, process design. These tend to settle in documents and in people. Delivery should fix them as much as possible into documentation, scripts, and explanations, reducing the hidden lock-in of "only the original vendor can do this."

Of the three, the third is most easily overlooked. The long-term usability of a system often depends not on the code itself, but on whether the user truly understands it.

We do not deny the value of subscriptions

To be clear: we do not think subscription is wrong. It solved real problems of traditional perpetual licensing—stale versions, expensive upgrades, weak vendor incentive to keep investing. Many excellent software products have sustained long-term iteration through subscriptions.

What we oppose is not subscription, but the "subscription wall"—artificially placing deployability, modifiability, and self-control behind a paywall, leaving customers to choose only between accepting and leaving.

These are different things. Subscription is a billing method; a subscription wall is a power structure.

This is a judgment

Back to the beginning. We chose source code licensing and deployable delivery not because it is commercially easier—it is actually harder: heavier delivery, more complex support, less smooth revenue.

We chose it because it better matches our understanding of long-term relationships: a product's value should show up in use, not in switching costs; customer trust should come from continued usefulness, not from being unable to leave.

Our judgment about AI capability follows the same line. AI is becoming a foundational capability of systems. The deeper it goes into business, the more important data boundaries, explainability, and controllability become. Locking such capability on someone else's servers is not a long-term acceptable arrangement for many organizations.

So we choose to give away part of the choice. That is not a concession. It is a judgment.

A good software relationship should let both sides continue with dignity, and end with dignity. Source code licensing and deployable delivery are our answer in that direction.