|
|
|
|
|
by noirscape
594 days ago
|
|
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 |
|
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.