Google Fired an Engineer for Improving Its Own Tools. Who Owns Your Side Project?

You find a company tool annoying, so you build a better version on your own time. Then you open-source it. Sounds like the kind of thing that earns a slap on the back. Instead, it got someone fired. A story circulating in developer circles this week isn’t just gossip — it pokes directly at a question every working engineer eventually faces: who owns the code you write after you clock out?

Up front, a caveat. This one hasn’t been heavily vetted across the big communities yet, and discussion over the past month has been thin. So this isn’t a piece about putting one company on trial. It’s about the underlying fight, which is older than the headline — a live wire that’s been running through the tech industry for decades.

What Actually Happened

The shape of it is simple. An engineer built a CLI tool for Google Workspace — the bundle of Gmail, Drive, Calendar and friends most knowledge workers live in.

Quick refresher on what a CLI is: a Command Line Interface. Instead of clicking around with a mouse, you type commands. Developers reach for it whenever they want to automate repetitive work — clearing out an inbox, moving files, that kind of thing — collapsing dozens of clicks into a single line.

The problem was proximity. This tool sat right on top of the company’s own product, and the engineer pushed it out into the world as open source. To Google, that crossed the line between internal asset and public release. To the person who built it, it was just a side project that scratched an itch. Same action, two readings that point in opposite directions.

So Whose Side Project Is It, Really?

Here’s where the real argument starts. A lot of people don’t realize this, but most tech employment contracts contain an IP assignment clause.

In plain terms: any invention or code you create while employed — if it relates to the company’s business or was built using company resources — belongs to the company. Some places, like California, give employees real statutory protection. But that protection hinges on one phrase: the work must be unrelated to the employer’s business.

That’s exactly why this case is sticky. A Google Workspace tool sits squarely inside Google’s business. A hobby game, or an app in some unrelated domain, would likely have been safe. A tool that wraps the company’s own product? The boundary blurs. “I built it on my own time” turns out to be a weaker legal shield than most engineers assume.

Why Companies Get So Twitchy About This

From the employee’s chair, the reaction looks wildly disproportionate. From the company’s chair, there’s a logic to it.

First, security and exposure. A tool that touches internal APIs or auth flows can, unintentionally, reveal how the company’s systems work. That’s a free hint to anyone looking for a way in.

Second, support and liability. Once outsiders start using an unofficial tool, the “built by a Googler” halo kicks in. When something breaks, the company gets dragged into a responsibility fight over software it never shipped.

Third, precedent. Look the other way once, and you’ve lost the standing to stop tens of thousands of engineers from walking out the door with their own internal tools. A hardline response is often less about punishing one person and more about sending a signal to everyone else.

It’s understandable. Though understanding why something happens and agreeing it was handled right are two different things.

What Actually Sets Developers Off

Every time a story like this breaks, the developer community lights up — and not purely out of sympathy for a fired peer. Underneath is something heavier: broken trust.

Plenty of companies recruit with lines like “we encourage open-source contributions” and “we love side projects.” Engineers believe it and sign on. Then they actually build something, and the fine print in the contract trips them. The gap between what they said and what the contract says — that betrayal is the real fuel.

There’s also a colder, more personal question lurking underneath: “Wait, is that thing I built last weekend a liability too?” A case like this turns every salaried developer into a potential defendant. The fear that it could be your problem next, not just someone else’s, is what turns sympathy into anger.

The Practical Takeaways

Forget who wins in court. If you build things while holding a day job, a few rules are worth internalizing.

The big one is distance from your employer’s business. The closer your side project sits to your company’s product, the riskier it is. The further away, the safer. And if you used the company laptop, the company account, or company hours — even once — assume you’ve stepped into the gray zone.

Next: ask first. When it’s ambiguous, get written sign-off before you publish. It’s a hassle, but telling them after you’ve built it and asking before you build it lead to completely different outcomes.

Finally, when you start a job, actually read the IP clause in your contract. Almost everyone just signs. But that single page is what decides the fate of your side project years down the line.

Whether improving a company tool is a firing offense or a company legitimately defending its assets depends entirely on the angle you view it from. What’s not in dispute: countless developers stand on this blurry line every day, building something. That project you shipped last weekend — are you sure it’s entirely yours?