GPL3 in sources

[mplatings]

Describe the bug
There is a file licensed under GPL3 in the Catch2 sources: tools/scripts/updateDocumentToC.py

The LICENSE.txt file in the project source states that the project is under the Boost license, but clearly it's not as simple as that.

Expected behavior
I suggest either removing non-boost-licensed files from the project or follow a system like https://reuse.software/ that allows for multiple licenses.

[teo-tsirpanis]

This file is a development-only script that does not seem to be used at all by end users. I don't think this brings Catch2's license into question.

[mplatings]

Imagine I distribute a program and bundle the complete Catch2 sources along with it - unwittingly I would be subject to GPL3.
(I guess you could debate the degree to which I'd be subject to the license, but that's a legal matter, not a technical one, so it's a debate best avoided).

In this case the easy solution is to remove updateDocumentToC.py from the sources, but you can only do that if you know that it's there.
So my suggestion is that either remove the file or make it easy for Catch2 users to know that it is there under a different license so that they can remove it themselves.

[neobrain]

Imagine I distribute a program and bundle the complete Catch2 sources along with it - unwittingly I would be subject to GPL3.

Does this present a tangible problem for you?

It sounds like you're misunderstanding the implications here. The script is no different than using a GPL-licensed compiler.

[mplatings]

I do understand that Catch2 as a whole is licensed under Boost, and that this script doesn’t change that. My concern is about the practical consequences for downstream redistributors. When bundling Catch2’s sources, they’d also be a file that carries a GPLv3 license. That raises two practical issues:

1. Compliance checks – I’m not a lawyer, but as I understand it, GPL-licensed files are normally expected to come with a copy of the GPL license text. Since the repo doesn’t include that, it could be seen as incomplete from a compliance perspective.
2. Adoption hurdles – Many organizations use automated license scanners. A GPL file inside a Boost-licensed project will get flagged, which triggers audits and slows down or blocks adoption.

From a redistributor’s point of view, this makes things harder than they need to be. The simplest fix would be either to remove the script (since it’s not needed by end users) or keep it but make its license completely clear by adding the GPL text and a note in the repo. I suggest providing the license at LICENSES/GPL-3.0.txt, as recommended by the REUSE specification.

That way Catch2 stays straightforward to adopt and doesn’t surprise people running compliance checks.

[teo-tsirpanis]

Any downstream redistributor that has a problem with the licensing of this file, can delete it and not redistribute it, or maybe even delete the whole tools/ directory.

[mplatings]

Sure, redistributors can delete the file or the whole tools/ directory, but that assumes they know the file is there and under a different license in the first place. Without digging, most people will just assume the whole repo is under Boost, because that’s what LICENSE.txt says. That’s where the risk of surprises comes in.

I think it’s worth flipping the perspective: which is easier overall?

• Every downstream redistributor having to notice the GPL file, understand the implications, and strip it out manually, or
• The Catch2 repo making that clear once and for all, either by removing the unused script or marking it properly and including the GPL license text?

The second option not only brings Catch2 into compliance with the GPL (I think) but also avoids repeated confusion for anyone adopting Catch2, and it’s a very low-effort change on your side. That’s why I’m suggesting it — not because I personally can’t work around it, but because it would save many downstream users from hitting the same concern.