[thayne]

A DCO [1] would serve that purpose better. It's possible that the desire to have the flexibility to change the license at some point in the future is initially well-intentioned (for example you may start out as GPL, but want the option to change to Apache 2.0 later), so having a CLA doesn't necessarily imply they plan on doing a rug pull. And of course there is probably also some cargo cult of using a CLA because that is what other projects do, but there are other ways of insuring everything is open source that don't require the contributor to give you unlimited rights.

[1]: https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...

[noirscape]

Keep in mind that a DCO is not the same thing as a CLA; kemitchell has written about the subject[0]. In short - the DCO is specifically written to meet the needs of the Kernel and some of it's expectations assume the workflow of the LKML and the code style of the kernel. He lists 6 conditions that you'd need to meet before the DCO is useful for your project. The most notable ones are that or-later licenses aren't a good idea with a DCO, that you must put the license text in a file header and that there's a Signed-Off-By element in your commits.

The DCO is also very patch oriented, rather than contributor oriented, which only works if your workflow has more contributors than patches (which isn't how most FOSS projects are organized; you usually have only a few contributors, who submit patches.)

Finally, the DCO was put in place to resolve someone being annoying about the licenses rather than existing to unify the copyright of the Kernel behind one entity.

[0]: https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA

[thayne]

> rather than existing to unify the copyright of the Kernel behind one entity

Unifying the copyright behind one entity is the problem with a CLA. Especially if that entity is a company that might have pressures to change the license to a proprietary license.