At first, it may have been a natural approach, as projects managed by the Apache Software Foundation use individual and corporate CLAs on which OpenStack CLAs are based verbatim. More recently, we have seen that the CTC regime is causing friction to some contributors, while we are also seeing some distance from the use of CLAs in open source projects. It is time for OpenStack to step back and consider whether our CTC plan would benefit from a change. Opinions differ as to how an open source project should manage ownership and copyright licensing for individual software contributions to the project. One possibility is that an author (copyright owner) of such software retains ownership of the copyright of the software, but can bring it under an open source license defined by the project. If the open source project is managed by a single entity (“responsible”), the author may instead grant the software copyright license to the project manager who, in turn, releases the software under the project`s open source license. In another option, the author of the software contribution may delegate to the person responsible the ownership of the copyright of the software that publishes the software under the open source license of the project. Another possibility is obviously not to define a specific directive for licensing or ownership of software contributions for the project. All projects should have some kind of contribution agreement. Foreigners who look at the world of free software often see something that looks like a “free-for-all” with code that flies in all directions and makes little noise. But the potential for trouble is still there, and projects need to protect themselves.

Every project, he says, should be able to prove that every line of code it distributes has been voluntarily contributed. A project can`t just pick up stains on the street and hope everything will be fine; If the code was not used in a non-disinterested manner, the author was always able to try to revoke the project`s right to code, which created problems. The underlying reality here is that a CCLA cannot protect GoodProject from The resignations of EvilCorp, because nothing can protect against The resignations of EvilCorp. It`s just like that, and ritual gestures like the requirement that contributors come under a CCLA is about as useful as displaying a hexagonal sign on your home to prevent fires and floods. Traditionally, the project manager had to impose whether a contributor had the right to transfer code for his or her project. This would become particularly complicated if you got signatures for corporate CLAs of companies and updated the white list of authorized developers for each company. OpenStack attaches great importance to its ability to attract new contributors and has been a great success. However, we are increasingly concerned about the ability of OpenStack operators to give feedback on the project and influence its direction. A form that can accept this feedback is a fix for the code, documents or tool to make available.

Any barriers or frictions that we insert into our contribution process necessarily interfere with our objective of increasing the feedback of operators. It is easy to forget that we require contributors to our documentation to also sign the CTC, including its patent provisions, which are clearly irrelevant in this case. Section 7.2 of the Statutes recognizes that documentation can and should be treated differently and it may be easy to argue that the Board of Directors should quickly adopt a smooth contribution agreement, such as the DCO for documentation.