MIT Licenses Code, Not the Whole Product

The recent Mole / Burrow incident involving @HiTw93 on X has sparked discussion about open source, derivative work, product boundaries, and “free alternatives.”

An open-source CLI project called Mole was taken by another developer to build a GUI project, whose README included phrases like “free, open-source mole.fit,” and whose UI and interactions the original author felt closely resembled his commercial product.

Mole’s author tw93 raised two core points in the issue: first, Burrow should not position itself as a free alternative to mole.fit; second, the MIT license covers the Mole CLI code, not mole.fit’s GUI design, branding, or trade dress. He made clear that building your own GUI on top of the MIT-licensed CLI is fine, but asked Burrow to remove descriptions like “free mole.fit,” redesign its own UI, and make the comparison table less adversarial.

Burrow’s author later responded positively (see image below), made targeted changes to the README, and said the UI would be updated in a future release.

Based on what’s available so far, the response is constructive. It no longer uses “free mole.fit” as the main narrative, instead reframing the relationship as “an independent project built on the same CLI engine.” It also does not dismiss the original author’s concerns about UI and product expression, and has begun making adjustments along the lines suggested in the issue.

Although the two developers have reached a tentative resolution, the surrounding discussion exposed some side effects AI has brought to open source. In particular, as the barrier to development drops, many people who are not open-source enthusiasts have flooded into the community, turning gray areas that previously didn’t need much thought into issues that now have to be considered and addressed, such as:

Where exactly is the boundary when open-source code is taken and reskinned as derivative work? For a long time, beyond basic open-source license constraints, the community relied on the values and ethics of open-source enthusiasts. Now more proactive defensive measures may be needed.

When a commercial product is built on an open-source core, what can and cannot be reused?

When AI lowers the cost of reskinning, how do open-source authors protect their products?

How do you balance the hidden communication costs? The Mole issue was resolved largely because tw93 has a large following. For many unknown open-source enthusiasts and indie developers, getting that kind of exposure and attention is clearly difficult, and they would most likely have to swallow the loss quietly.

The dispute is not about “using MIT-licensed code”

When tracing the timeline and issue list, I noticed that many people discussing similar incidents tend to reduce the issue to a single sentence:

Since it’s MIT-licensed, isn’t it normal for others to take it and use it?

That statement is not wrong on its own, but in this specific case it only captures half the story.

The MIT license does allow others to use, copy, modify, distribute, and even build commercial products on the code. If Mole CLI is MIT-licensed, then someone building a GUI on top of the CLI is not itself a problem. Mole’s author explicitly acknowledged this in the issue: building a product on the MIT-licensed CLI is fine.

The real issue is this: MIT licenses the code, not the whole product.

A complete product is more than code.

It also has UI, interactions, branding, copy, narrative, commercial positioning, and user perception.

None of these automatically become public material that can be freely copied just because the underlying CLI code is MIT-licensed.

So the most easily misunderstood part of this kind of incident is here:

Some people interpret “open-source code” as “the entire product can be taken”;

Some people interpret “you can build a product on open-source code” as “you can replicate the original author’s commercial product UI and expression”;

Some people interpret “open-source freedom” as “you can use the original author’s commercial product to market yourself as a free alternative.”

This is not a problem with the open-source license itself, but with a crude understanding of where the license boundary lies.

Many people are used to viewing projects from the repo perspective: the code is on GitHub, the license is MIT, so forking, modifying, and publishing all seem fine.

But users don’t perceive a product through code alone.

If a project is closely tracking the original author’s commercial product across these dimensions, it is no longer simply using open-source code; it is replicating the product itself.

(Writing this reminds me of another incident I followed recently: the CEO of the “Lazy Cat” product line tweeted accusing a developer of copying Lazy Cat’s products without attribution, only for the story to flip when netizens discovered that many of his own products were copies that also failed to credit the originals. A boomerang moment… Similar things have happened from time to time over the past couple of years, but I won’t go into detail here.)

On caezium’s response

What I find good so far is that neither side pushed things toward escalation, and tw93 did not close-source Mole.

Mole’s author did not reject the MIT license itself, nor did he demand that the other party stop using the CLI. Instead, he drew the boundary very clearly.

Burrow’s author also responded actively and shared his perspective and original intent. Judging from the README changes, caezium has clearly suggested that users who want to support mo development can purchase mole.fit.

This is actually a good example of how to handle an open-source dispute.

Not every controversy has to end with mutual accusations, and not every boundary conflict has to turn into total hostility.

A public issue, clearly stated requests, acknowledging what is reasonable, revising the README, adjusting product positioning; these are all more valuable than a war of words.

@Xuanwo also expressed approval of caezium’s response: the project author explained the situation, addressed the requests, and offered his own perspective; an approach worth learning from. Open source ultimately returns to open source, with mutual benefit under the framework of open-source licenses.

AI makes boundary issues more serious

In the past, replicating a project was not that easy.

You had to read the code, understand the architecture, study the product logic, redo the UI, fill in the documentation, build a website, write the introduction, and handle all kinds of details.

Now it’s different.

You can feed the repo, README, screenshots, website, issues, and discussions to AI, and it will hand you a competitor at 80% completion.

This means the original creator bears the cost of exploration, while latecomers harvest the visible results.

Many open-source projects are not part of a big company’s strategic layout; they are built bit by bit by individual developers, small teams, and indie developers.

Many projects follow a common model: open-source the core capabilities for community use and contribution; charge for the commercial product to sustain long-term maintenance; the free part serves developers, while the paid part covers time costs and ongoing investment.

That is actually healthy. But if the model becomes: I open-source the free version, and someone else takes it to replicate my commercial version; I rely on the commercial product to fund the project, and someone else markets themselves as my free alternative; I spend time polishing UI, interactions, copy, and product positioning, and someone else uses AI to quickly reproduce them; and in the end I still have to explain why MIT does not mean the product is licensed.

Then open-source authors will naturally start to reconsider the ROI, and ask themselves one more time: Should I still open-source this?

That is the most serious consequence. What gets damaged in the end is not just one project, but the entire open-source ecosystem.

Because what is truly scarce in the ecosystem is not people who can fork, but people willing to explore from 0 to 1, to maintain, and to invest for the long term.

Open-source authors need to write boundaries more explicitly

This kind of incident also reminds all open-source authors that a license alone may no longer be enough.

Especially when your project has an “open-source core + commercial product” structure, you need to spell out the boundaries clearly.

These things may not have needed to be written in such detail before, because there was a default assumption that people still had some sense of boundaries.

The Mole / Burrow incident did expose a very typical problem: MIT licenses the code, not the whole product.

The follow-up response, in turn, offers a relatively positive example: the original author publicly and with restraint articulated the boundaries; the derivative author responded to the requests, revised the README, and tried to reposition the project; onlookers also actively participated (though there was plenty of meaningless noise, which is best ignored), discussing open-source licenses, brand boundaries, commercialization, and the ethics of derivative work.

It provides a useful reference for those who come after, and that is what makes this incident valuable.