apps/api/plane/utils/email.py is the only file in apps/api/plane/utils/ whose header does not say AGPL-3.0-only. It says:
# SPDX-FileCopyrightText: 2023-present Plane Software, Inc.
# SPDX-License-Identifier: LicenseRef-Plane-Commercial
#
# Licensed under the Plane Commercial License (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# https://plane.so/legals/eula
#
# DO NOT remove or modify this notice.
# NOTICE: Proprietary and confidential. Unauthorized use or distribution is prohibited.
This looks unintentional, and I think it is worth a quick check.
Why it looks like a template slip
The repository is AGPL. LICENSE.txt is the GNU AGPL v3, and COPYRIGHT.txt reads:
Copyright (c) 2023-present Plane Software, Inc. and contributors
SPDX-License-Identifier: AGPL-3.0-only
The file lives in core, not in an enterprise directory. apps/api/plane/utils/ is ordinary shared code, and the module itself is a helper that turns an HTML email template into plain text.
It is the only exception in its directory. Every other .py file under apps/api/plane/utils/ carries the AGPL header.
It arrived with the header already in place, in f0dcf66 ("[WEB-5917] fix: generate clean plain text from HTML email template", #8535). That same commit updated eight files under apps/api/plane/bgtasks/, and all of them carry the AGPL header.
addlicense would not correct this. COPYRIGHT_CHECK.md documents the check you run:
addlicense --check -f COPYRIGHT.txt -ignore "**/migrations/**" $(git ls-files '*.py')
addlicense adds a header where none exists, but it leaves an existing one alone. A file that arrives with a different header therefore passes unnoticed.
Why it matters to people outside the team
Self-hosters, packagers and anyone forking the repository read these headers to decide what they may redistribute. As it stands, one file in the default installation says redistribution is prohibited, while the repository it ships in is AGPL and requires the complete corresponding source to be available. Removing the file is not an option either, since the application does not run without it.
That leaves no clean reading, which is why I am asking rather than guessing.
Suggested fix
If the file is meant to be AGPL like the rest of core, replacing the header with the standard one would resolve it.
If it is genuinely meant to be under the commercial license, a short note in the docs would help, so that self-hosters know which parts of a default installation they may pass on.
Happy to open a PR for the header change if that is the direction you want.
apps/api/plane/utils/email.pyis the only file inapps/api/plane/utils/whose header does not sayAGPL-3.0-only. It says:This looks unintentional, and I think it is worth a quick check.
Why it looks like a template slip
The repository is AGPL.
LICENSE.txtis the GNU AGPL v3, andCOPYRIGHT.txtreads:The file lives in core, not in an enterprise directory.
apps/api/plane/utils/is ordinary shared code, and the module itself is a helper that turns an HTML email template into plain text.It is the only exception in its directory. Every other
.pyfile underapps/api/plane/utils/carries the AGPL header.It arrived with the header already in place, in f0dcf66 ("[WEB-5917] fix: generate clean plain text from HTML email template", #8535). That same commit updated eight files under
apps/api/plane/bgtasks/, and all of them carry the AGPL header.addlicensewould not correct this.COPYRIGHT_CHECK.mddocuments the check you run:addlicenseadds a header where none exists, but it leaves an existing one alone. A file that arrives with a different header therefore passes unnoticed.Why it matters to people outside the team
Self-hosters, packagers and anyone forking the repository read these headers to decide what they may redistribute. As it stands, one file in the default installation says redistribution is prohibited, while the repository it ships in is AGPL and requires the complete corresponding source to be available. Removing the file is not an option either, since the application does not run without it.
That leaves no clean reading, which is why I am asking rather than guessing.
Suggested fix
If the file is meant to be AGPL like the rest of core, replacing the header with the standard one would resolve it.
If it is genuinely meant to be under the commercial license, a short note in the docs would help, so that self-hosters know which parts of a default installation they may pass on.
Happy to open a PR for the header change if that is the direction you want.