Managing software copyright may be a difficult exercise, especially when it is produced from multiple sources and authors as it is frequent in Open Source projects. More generally, when a project is initiated, authors try to implement some project governance and to determine who the project leader and copyright owner is. This may be done through a CAA (Copyright Assignment Agreement) or by a CLA (Copyright Licensing Agreement) or be ruled by the outbound licence itself. Other stakeholders propose a simpler DCO (Developer Certificate of Origin).

A CAA is a legal document (a contract on paper or electronically signed) transferring the ownership and rights of a specific creative work or works. The CAA protects the rights of parties involved by clarifying and providing a record of ownership of a work, especially in the event of a later transfer. It is a typical contractual clause that must be included when a contracting authority awards a development to a third party software developer: exclusive (or in some case shared) copyright will belong to the contracting authority. Depending on the CAA, this authority could decide everything in relation to the use, further development or distribution of the work (under any licensing conditions, for free or for a fee).

Signing a formal CAA will not look very popular for an open source software developer, especially when providing voluntary work. Why would a voluntary developer provide, without any control, all copyright to a project owner? A solution may be to sign a CLA. The Copyright Licensing Agreement is especially useful in the open source ecosystem for conditioning the copyright transfer to the redistribution of the global resulting work under one or more specific open source licences. So the volunteer contributor giving worktime to develop a part of the work will be granted back to receive open source permissions on the whole work once finished, including contributions from all other contributors. The CLA may provide some flexibility to the project owner by specifying licensing under later versions of a licence (i.e. “under the EUPL v1.2 or later”) or specifying that the project will always be licensed “under an OSI approved licence selected by the project owner”, for example.

Many projects, even with a great number of contributors, were initiated without CLA. Such projects are exclusively or mainly ruled by the outbound licence. In case this licence is copyleft (the GPL, typically) it grants a perennial character to the open source or free software availability and distribution of the code. However, any modification of this outbound licence (even from the GPL V2 to the GPL V3, for example) must receive the formal agreement of all authors and contributors, which could not always be possible

A simpler solution is to request from contributors a Developer Certificate of Origin (DCO), which is an affirmation that the source code being submitted is originated from the developer, or that the developer has permission to submit the code. As it is a “light weight” simple declaration, the DCO is known to be a well-accepted way for contributors to certify that they wrote or otherwise have the right to submit source code as their contribution to a project, while at the contrary a Copyright Licensing Agreement (CLA) – or Assignment (CAA) – which is a formal signed contract assigning exclusive rights to one of the stakeholders – may constitute a dissuasive barrier.

The European Union Public Licence (EUPL) is one of the very rare open source licence that includes a DCO for both the original licensor and for all subsequent contributors. None of the permissive licences (BSD and MIT) and none of the more elaborated popular licences (GPL, LGPL, Apache, CPL, MPL) presents a similar provision. The EUPL states (article 6):

• The original Licensor warrants that the copyright in the Original Work granted hereunder is owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence.
• Each Contributor warrants that the copyright in the modifications he/she brings to the Work are owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence.

Therefore the fact a contributor agrees to provide source code into a project covered i.e. by “the EUPL v1.2 or later” includes the subscription of a DCO. The documentation of this DCO is facilitated by other obligations present in the EUPL “attribution clause”:

• The Licensee (= any contributor after the source code is received from the original licensor) must cause any Derivative Work to carry prominent notices stating that the Work has been modified and the date of modification.

However, regarding this copyright guarantee, a simple DCO will provide less security than a formal CLA in the specific case where a volunteer contribution is provided by a third party employee. The 2009/24/EC Directive on the protection of computer programs assumes that – by default – copyright on employees’ work belongs to the employer. When the employer is not a contractor (case normally covered by some CAA clause), it is wise to request the agreement of the employer, even knowing this could be a heavy process. At the contrary, a DCO is a unilateral declaration by the contributor that he/she is entitled to submit the code. Like a project owner states: “It treats you like an adult and relies on your accurate statement about your rights to submit a contribution.”

It may be that in a near future, AI will make things even more complex: it is already possible to obtain some novel original works from AI: a painting in the style of Rembrandt or a concerto in the style of Vivaldi. In the field of software, it could soon be possible (or it may already be possible) to ask your favourite AI "Write me an exam results management program for my school", and the AI may then question you about specific parameters or requirements and integrate appropriate elements from various sources, while leaving the copyright to whoever initiated the idea, formulated the question and the needs. But knowing that the same AI could provide the same source code to a third party formulating the same question, and that copyright protects the form and not the ideas or requirements, it could be necessary to stamp AI generated content with a specific “AI generated, public domain” stamp of origin.

 

The above question was debated in May 2023 at the JRC (EC Joint Research Centre) between Jean-Paul Triaille (JRC), Adeline Toader (JRC) and Patrice-Emmanuel Schmitz (Joinup).