GPL vs Apache Licence: What You Owe When You Self Host

A developer on a QA team writes a small plugin for the test management tool the company self hosts. It works well enough that someone suggests folding it into a product the company sells. Someone in that meeting asks what the team is obliged to publish, given the tool's own licence. Nobody in the room actually knows, and the meeting moves on without a real answer. That happens most weeks somewhere in a self hosted QA stack, and it is a narrower question than the general GPL vs Apache licence debate that shows up in blog comments. This post answers the narrow question well rather than the general one badly, and it refuses to argue that either licence is morally better.

The core difference, in plain words

Copyleft licences, GPL among them, ask that if you distribute a derived work, that derived work carries the same licence. Permissive licences, Apache 2.0 and MIT among them, do not ask for that. You can take permissively licensed code, build something closed on top, and distribute it under whatever terms you want. Copyleft is a reciprocal bargain.

Permissive is closer to a one way gift. Neither is a trick, and neither is more open than the other in any way that matters to a reader running the software day to day. Both meet the common industry definition of open source. The difference is what happens later, at the moment you choose to hand a copy to someone outside your own company.

The word doing all the work is distribute

GPL's obligation only triggers on distribution. Running a modified build inside your own company is generally not distribution under any common reading of these licences. That single fact is why most internal forks never trigger the question at all.

A QA team that patches its self hosted test management tool, adds a custom field type, and runs that patched version for its own testers has not distributed anything. Nobody outside the company received a copy. The obligation simply never activates, no matter how extensively the internal fork diverges from the upstream project over a year or two of quiet patching.

The three situations where it becomes real

For a QA team, the GPL question stops being theoretical in a small number of specific cases.

• Shipping a plugin publicly, where other teams can download and run your code
• Embedding the tool, or a derivative of it, inside a product the company sells to customers
• Offering the tool as a hosted service to customers outside the company

Outside those three, an internal fork or a private plugin used only by your own testers stays well clear of the reciprocal obligation, because nothing has been distributed to anyone. A team that runs a heavily customised internal build for three years, with nobody outside the building ever seeing a line of it, has simply never crossed the line that GPL cares about.

The licences actually on the table in this category

A reader comparing self hosted test management tools will meet a small, consistent set of licences.

• TestLink is GPL-2.0, checked 25 August 2026
• Kiwi TCMS is GPL-2.0, also checked 25 August 2026
• Tesbo is Apache 2.0

All three are open source licences under the common industry definitions. The difference between them is the shape of the bargain, not how open one is compared to another. A team picking between them on licence grounds alone is usually asking the wrong question, since the practical answer depends almost entirely on whether anything gets distributed outside the company.

What Apache 2.0 adds that MIT does not

Apache 2.0 and MIT are both permissive, but they are not identical. Apache 2.0 includes an explicit patent grant. Contributors license any patents they hold that cover their contribution, and that grant is what a corporate reviewer specifically looks for during a legal review.

MIT is shorter and says nothing about patents at all. That silence leaves the question unresolved rather than answered. For a company embedding open source code into a commercial product, that missing clause in MIT is often the exact reason legal asks for a substitution or a signed waiver before approving the dependency. Apache 2.0 closes that gap up front, which is a small technical detail that turns out to matter a great deal in a procurement review.

A fair statement about GPL

GPL is not a disadvantage, and this post is not building toward a conclusion that it is. It is a different bargain. In exchange for using GPL code, you commit to sharing your own modifications if you distribute them, which is a reasonable trade many projects have thrived under for decades.

For a tool you only ever run internally, inside your own infrastructure, for your own testers, the practical difference between GPL and a permissive licence is close to indistinguishable. The distinction only earns its keep in the three situations listed above, and most QA teams never reach any of them across the tool's entire lifetime inside the company.

What to actually check before that meeting happens again

The next time someone in a planning meeting asks what a licence obliges the team to do, the answer usually comes down to one question: are we distributing anything outside the company. If the plugin, the fork, or the integration never leaves the building, the licence rarely matters day to day, regardless of which of the three licences above is in play.

If it does leave, in a public repo, inside a shipped product, or as a service sold to a customer, that is the moment to read the specific licence text rather than rely on a general sense of what GPL means. A five minute read of the actual clause at that point saves a much longer conversation with legal six months later.