Introduce component-based licensing: Serena GPL-3.0-or-later, SolidLSP MIT

The repository is licensed per component. SolidLSP (src/solidlsp,
test/solidlsp, test/resources) remains MIT-licensed and independently
reusable; the Serena application (src/serena, src/interprompt, scripts,
test/serena, docs) is licensed under GPL-3.0-or-later starting with the v2
licensing transition. The change is not retroactive: all releases and
commits up to v1.7.0 / 74c38a65 (tag mit-final) remain available under MIT.

Since MIT is GPL-compatible, a distribution combining both (such as the
serena-agent package) is as a whole subject to GPL-3.0-or-later, while the
SolidLSP files themselves stay MIT and can be extracted and used separately
under MIT terms. The distribution metadata therefore declares
GPL-3.0-or-later, with both license texts shipped alongside it.

Serena originally began under the GPL (v2) and was switched to MIT in
May 2025 following community requests. We consider that change a mistake;
the substantial changes in v2 make this the appropriate time to revert it.
We want the best version of Serena to remain free.

Changes:
* LICENSE is now the licensing overview; canonical license texts live in
  LICENSES/ (MIT.txt is the previous LICENSE verbatim, GPL-3.0-or-later.txt
  is the unmodified FSF text)
* pyproject.toml declares the PEP 639 license expression
  "GPL-3.0-or-later" and bundles LICENSE and LICENSES/* as license files;
  the deprecated MIT classifier is dropped and flake.nix declares gpl3Plus;
  README has per-component license badges and a License section
* SPDX-License-Identifier headers in all Python sources under src/ and
  scripts/, added by the new idempotent scripts/add_spdx_headers.py, which
  gen_prompt_factory.py also uses to keep the header on the generated
  module; existing third-party notices are preserved
* CLA.md: Contributor License Agreement (contributor retains copyright;
  grants a perpetual, irrevocable license including relicensing under any
  terms, incl. proprietary/commercial; patent grant; authority
  representations), to be enforced repository-wide via cla-assistant.io
* CONTRIBUTING.md, PR template and a new docs page explain the licensing
  boundary and the CLA workflow
This commit is contained in:
Dominik Jain authored and Dominik Jain committed 2026-09-14 21:33:18 +02:00
1 parent 9f9db76622
commit 6707cd9b7e
186 files changed
+1331 -24

No files matched your search

+24
View File
@@ -11,6 +11,30 @@ The following types of contributions can be submitted directly via pull requests
For other changes, please open an issue first to discuss your ideas with the maintainers.
## Licensing and Contributor License Agreement (CLA)
Serena is multi-licensed by component (see [LICENSE](LICENSE)):
the Serena application is licensed under GPL-3.0-or-later, while SolidLSP (`src/solidlsp`) is licensed under MIT.
All contributions to this repository require acceptance of our [Contributor License Agreement](CLA.md).
The CLA lets you keep the copyright to your work while granting Jain & Panchenko IT-Berater Partnerschaft (Oraios AI) the rights needed to maintain and
distribute Serena under different terms in the future (including the free community edition and possible
commercial editions).
Acceptance is handled automatically by [CLA assistant](https://cla-assistant.io/):
* When you open your first pull request, the CLA assistant bot comments on it with a link to accept the CLA.
* You accept it once, authenticated with your GitHub account; the acceptance is remembered for all future PRs
(you will only be asked again if the CLA text changes).
* PRs cannot be merged until the `license/cla` status check passes.
The CLA is required repository-wide for operational simplicity, i.e. also for SolidLSP-only changes.
This does not change SolidLSP's MIT license.
When adding new source files, include the SPDX identifier that matches the component:
`# SPDX-License-Identifier: GPL-3.0-or-later` for Serena application code and
`# SPDX-License-Identifier: MIT` for SolidLSP.
When submitting a PR, ensure a well-defined scope.
Every PR should cover a single logical change or a set of closely related changes.