In the meeting of 11-11-2024, the TCT decided not to allow differently-licensed code on TCT-supplied resources any more. This means that everyone committing to any of the https://core.tcl.lang/* repositories will have to make a choice: Either change (back) the licence to the Tcl licence, or move it to somewhere else.

History: Nov 1st, a message appeared in the Tcl Core group: https://sourceforge.net/p/tcl/mailman/message/58836410/ In this mail:

I would also love to have a general decision on copyright statements

Many responses were sent to the Tcl Core list (they can be found on sourceforge), and also received privately by TCT members. This resulted in the conclusion as stated above.

Assigning to Nathan, please make a choice. The same for "tcllib" as well.

Since TIP #705 is accepted, this ticket can be closed.

The "unchanged" branch is also closed now. It can be re-opened if the licence is changed to another license which is approved by the TCT. GPL is not!

The BSD/Tcl license and the GPL license are asymmetrical.

Someone working on a BSD project that intends to remain a BSD
project has to be on alert not to bring in GPL code, or fear
running afoul of license requirements.  There is an element
of protection for downstream user base as well, with their
expectations of continued clean BSD releases.

The barrier has to be somewhere.  It is far more practical to
keep GPL submissions out of the repository than it is to have
mindfulness and rigorous review attached to every branch merge
during development.

Someone working on a GPL project intending to remain GPL does
not have the same worries about bringing in BSD code.  I'm not
enough of a fossil expert to give detailed instructions, but it
seems to me another repository hosting a GPL-welcoming fork of
Tcl should be able to pull from the original server without
(too much) trouble, with protections against mistakenly flowing
patches the other direction.

This isn't a question of what license the Tcl core team chooses for the branches it develops, but of whether to allow a fork licensed under the GPL to coexist in the same repository. There are pros and cons to allowing a branch in the repository to be licensed under the GPL, and they should be openly discussed. Choosing to limit all branches to licenses that exclude the GPL is in my opinion a significant-enough administrative policy to warrant a vote. Also, if this is or becomes official policy, it should be officially documented somewhere.

I agree with Brian - a simple restatement of the Tcl/Tk license does not require a TIP because this in no way represents a change.

From "Tcl and the Tk Toolkit" written by John Ousterhout, it is written (Appendix A, page 433):

The source code and reference documentation for Tcl and Tk are freely available.
No license is required to use them and there are no restrictions on how you use them (for
example, you can redistribute part or all of Tcl or Tk in products). ...

From "Tcl and the Tk Toolkit Second Edition" (Appendix A, page 717):

The source code and reference documentation for Tcl and Tk are freely available.
Tcl and Tk are available under a BSD-style license, which provides great flexibility,
including the use of Tcl and Tk in commercial products without royalties or being 
required to open-source your own code. ...

GPL is not compatible with the BSD-style license. Commercial products containing proprietary or closed source software, must have the freedom to interface and morph the open source as necessary. That is the intent, IMO, of Ousterhout's original "no restrictions" statement.

I find that the statement presented by the representatives, at the TCT meeting, simply reiterates and confirms what has always been true of the Tcl and Tk code base.

The GPL is a free license, and choosing not to allow a branch in the repository to be licensed under the GPL is a weighty enough decision that it should not simply be decided at a meeting, but should pass a vote of the core team as described in TIP 0. The vote should be preceded by an open discussion, as is customary, about the proposal. Therefore, it is early still to require removal of a branch such as "unchained" from the repository.