This post is a personal response to the Kathmandu Post article, “Source code theft emerges as a growing threat to Nepal’s software industry.” My thanks to the writer, Sajana Baral and the Kathmandu Post team for bringing attention to an important issue.
After reading the article, I started thinking about source code theft not just as an isolated act of wrongdoing, but as a deeper system problem involving incentives, company structure, internal security, legal enforcement, and industry culture. In this post, I share my own perspective on why this happens and what the broader lessons might be for software companies.
What struck me first was how ordinary the problem sounds once you strip away the drama. The article notes that Nepal’s Cyber Bureau received 10 complaints involving source code theft in fiscal year 2025–26, and that similar cases have already reached the courts. It also shows that these are often not external hacks in the cinematic sense, but insider cases: former employees, collaborators, or people with legitimate access walking away with code and repackaging it elsewhere. That detail matters. It shifts the question from “How did someone break in?” to “Why was the system so easy to walk out of?”
First thought: this is probably about dissatisfaction
My first reaction to the headline was simple.
Underpaid employee. Frustration. Disappointment. A person feeling that they are contributing more value than what they are receiving back. In that state, the idea of taking the code they helped build can start to look less like theft and more like repayment in their own head.
That does not make it right. It just makes it understandable.
And once something becomes understandable, it stops being a random act and starts looking like a pattern.
The deeper layer: this is not happening in a vacuum
The article says Nepal’s Cyber Bureau received 10 complaints related to source code theft in fiscal year 2025–26, and that some of these disputes have already reached the courts. It also describes insider-style cases, where people with legitimate access allegedly walked away with code and reused it elsewhere.
That detail matters.
It means the question is not only, “How did someone get in?” It becomes, “Why was the system so easy to walk out of?”
That is a different problem entirely.
Why the problem grows
Employee dissatisfaction is one reason. But it is not the whole reason.
A weak or slow legal system changes the calculation. If a case takes too long, costs too much, or gets delayed until the stolen product has already generated returns, then the punishment no longer feels immediate or serious. Corruption, slow courts, and weak enforcement do not just fail to stop theft — they quietly make theft more attractive.
That is where the system starts leaking.
Not in one dramatic moment. In small, repeated failures.
The legal system is not just weak — it is structurally misaligned
This is the part that often gets reduced to a single sentence like “laws are weak,” but the reality is more layered.
First, software theft cases are inherently slow to adjudicate. Courts are designed for physical evidence, contracts, and clearly traceable harm. But source code disputes involve version histories, commit logs, access permissions, forks, partial rewrites, and sometimes even AI-assisted generation. That means the court is not just deciding guilt — it is first forced to understand the technical system itself.
Second, there is a technical literacy gap inside legal institutions. Judges and lawyers are trained in law, not in software engineering. But modern IP disputes require understanding things like:
Git history and commit attribution
Repository access control systems
Clean-room implementation vs derivative work
Open-source license boundaries
Code similarity vs functional similarity
Trade secret definitions in digital systems
AI-generated or AI-assisted code ownership
Without this understanding, legal interpretation becomes fragile. The system risks judging surface-level similarity instead of structural or procedural theft.
Third, enforcement delay changes everything. In software, time is not neutral. A stolen product can be monetized quickly, iterated on, and even rebranded before a case is resolved. So even if the law eventually rules correctly, the economic damage has already been absorbed into the market.
Fourth, settlement culture weakens precedent. Many cases never reach public judgment. They are quietly resolved to avoid reputational damage. But this creates a hidden cost: the industry never builds shared legal memory. There is no public learning, no deterrent signal, and no evolving case law that clarifies boundaries.
So the legal system is not just “slow.” It is structurally outpaced by the speed of software.
And that mismatch is exactly what makes insider theft economically rational in some cases.
The company itself may already be fragile
Another thought that kept coming back to me was this:
If a company survives mainly because of its source code, then it may already be too fragile.
A serious software company should not depend on one repository, one person, or one internal access path as its only real moat. It should have layers — architecture, process, customer trust, support systems, documentation, technical discipline, and a structure strong enough that copying the code is not the same thing as copying the company.
If the code is the whole business, then the business has already been reduced too far.
That is not just a security issue. That is a business-design issue.
AI changes the equation, but not in the way people think
This is where the modern layer matters.
AI has made code generation easier. Natural language now turns into working software faster than before. That does not mean source code stopped mattering. It means copying, rewriting, and commercializing code became easier.
So the real question is not whether code still has value. It does.
The real question is whether code is still a durable moat by itself.
In 2026, the answer is increasingly no.
What matters now is not only syntax or output. It is execution, reliability, iteration speed, trust, product depth, and the ability to maintain something after the first version exists. AI lowers the barrier to building software. It also lowers the barrier to imitation. That makes structural weakness even more dangerous.
Internal security is where the wall often breaks
One of the strongest questions here is also one of the simplest:
Why did anyone have full access in the first place?
If employees are meant to work on specific parts, then access should be isolated, segmented, and limited. Internal security should not be weaker than external security. In fact, modern security thinking says the opposite: internal access should be treated carefully because the insider already has context, permissions, and knowledge of how the system works.
If one person can walk away with everything, then the system was never tightly built.
That is not the thief’s failure alone. That is also the company’s failure.
Quiet settlements create public ignorance
There is another problem here that people often miss.
When cases are settled outside court and stay hidden from public view, the industry loses memory.
Other companies do not learn what happened. Other employees do not learn what the consequences were. Other founders do not learn what kind of risk they are really sitting on.
Public visibility matters because it creates deterrence. It also creates education. If everything disappears into private settlement, then the same pattern will repeat with the next company that thinks it is special enough to be immune.
That is how weak systems survive. They do not learn loudly enough.
The open-source contradiction
There is also a deeper contradiction in the software world.
Many companies build on open-source foundations. They reuse libraries, frameworks, APIs, models, and shared standards. That is normal. That is how software is built now.
So when a company says, “This code is ours,” while also building on shared and borrowed code, some people start asking a morally messy question:
If companies can build on public code and commercialize the result, why can’t employees do the same with what they touched?
That question does not justify theft. But it does reveal that ownership in software is never as clean as companies want it to sound.
The industry loves reuse when it speeds production. It hates reuse when it weakens control.
That tension is real.
The Claude Code leak shows how fast source spreads
The broader 2026 context makes this discussion sharper.
Anthropic’s Claude Code source was accidentally exposed through a packaging/source-map mistake, and reporting described a very large code leak that spread quickly once it became public. Even if no customer credentials were involved, the lesson was obvious: once source code is out, it moves fast.
That is the core danger.
Source code is portable. Copying is cheap. Redistribution is brutal.
So if a company’s only serious advantage is “we have the code,” that advantage is thinner than it looks.
So what is the actual answer?
Not one thing.
Not just better salaries. Not just harsher law. Not just better contracts. Not just stricter code access.
It has to be all of them together.
Companies should treat employees fairly enough that resentment does not become a business case. They should isolate sensitive source code instead of making the whole system too easy to walk away with. They should use tighter permissions, better logging, and stronger internal controls. The legal system should move faster and treat source theft as a serious matter. And the industry should stop pretending that quiet settlements are harmless. They are not. They erase lessons.
At the deepest level, this is not only a theft problem.
It is a system problem — one shaped by incentives, access, delay, trust, ownership, and the changing economics of software itself.
And that is why the real question is not simply who stole what.
It is what kind of system made the theft thinkable, profitable, and survivable in the first place.
