As the main developer of OpenQBMM, an add-on for OpenFOAM which implements quadrature-based moment methods for the solution of generalized population balance equations, I have been recently involved in the transfer of the copyright on the OpenQBMM code base to the OpenFOAM Foundation, to be able to contribute the corresponding source code to them. I summarize here some motivations, lessons learned and some advice that may be useful to others who want to follow the same path.
Why contribute?
This is a question several have asked. Why contribute a code base that took four years of work to be build (and quite some nights, holiday, weekends too), including research, overcoming unexpected difficulties, verifying, validating, changing plans to make things progress and disseminating results? Why not keep developing it on your own and eventually monetize?
In my view, for a project like OpenQBMM, the answer to these questions is quite simple: OpenQBMM does not work without OpenFOAM, so contributing is a question of efficiency. It makes more sense to keep the code aligned with OpenFOAM, so that it does not quickly become obsolete. It also makes sense to evaluate the possibility of integrating parts of the code of general interest with OpenFOAM, so that a broader community can benefit from them. This maximizes the likelihood of public impact of our research and development work and, in the end, is the goal of the project which led to the development of OpenQBMM, which was funded by public money.
The monetization aspect is not in contradiction with the contribution to an upstream project. Anybody with some experience of how the open-source business model has realized this aspect, so I do not think it is worth discussing it extensively.
A (very) frequently asked question: “Does this mean the project is concluded and you are done developing it?”
No. In the case of OpenQBMM it certainly does not. The OpenQBMM project is the core of my research work. The majority of the time I spend doing research goes into this project if I account for time invested in developing algorithms, writing code, maintaining it, training students working on the project. Contributing OpenQBMM to the OpenFOAM Foundation is a way to give better chances to the project to be more successful due to the improved exposure. It also means it will be maintained in alignment with OpenFOAM thanks to the interaction with its developers, but it certainly does not mean the project ends, and it does not mean our involvement is stopping. Quite the contrary. I am going to maintain the code also in the repository at the OpenFOAM Foundation. In some sense, contributing upstream means joining forces, and certainly does not mean dumping a piece of software in the hope someone else will keep it functional.
Lessons learned
It takes time to sign a contributor agreement
Transferring code to upstream projects may require the signature of a copyright transfer agreement or contributor agreement. This is the case for code contributions to the OpenFOAM Foundation. My first attempt to have the contributor agreement signed by my university was not successful. The OpenQBMM project was funded by a government agency, and there was some confusion on who had the rights on the intellectual property. People familiar with the GPL license know how using the GPL does not mean waving intellectual property rights, but, for many, the misunderstanding still exists. Here are some key points I believe were key to our success. These points are quite specific to the US academic system, but they are probably useful suggestions also in different systems.
- If the plan is to contribute software developed during a research project, prepare for this at the time you write your proposal in which you request the project to be funded. Clearly write about the intentions to contribute the software to an upstream project in the grant proposal. Specify the license you will use and justify it very explicitly. This will prevent confusion when the time to contribute your work to the upstream project will come. A good place where to do this is the data management plan, if the funder requires it. Specifying what are the plans to maintain the software after the end of the grant is a requirement of several solicitations. If a data management plan is not required, spend a paragraph of your proposal to clearly state your plans and your intention to contribute, when, under what license, to whom. It would be beneficial to agree to contribute with the upstream project. However, this is not always possible. It is difficult to evaluate the suitability of a contribution a priori, and it is understandable that an upstream project may have limited resources to participate in a request for funding.
- Discuss the contribution with the office of intellectual property of your university. Learn what are the expectations in terms of ownership of intellectual property. In the US, the intellectual property is typically transferred from the principal investigator to the university, with some exceptions. I would suggest to have this conversation before submitting the proposal, have it again once the proposal if funded, and when the contributor agreement needs to be signed.
- Make sure you own the intellectual property of everything you contribute. Before transferring the copyright and intellectual property of the project, this property needs to be owned by whoever signs the contributor agreement. It would seem obvious, but it is not so simple when working in an open environment. Contributing code is easy on platforms like GitHub, but the simple act of contributing does not imply an intellectual property transfer. When we decided to contribute OpenQBMM to the OpenFOAM Foundation, it was necessary to first have our external contributors sign a transfer agreement to my university, and only then proceed with the signature of the contributor agreement. If someone refuses to sign the transfer, his/her contribution will need to be removed in order to be able to sign the contributor agreement. This step takes time: start working on this since the beginning of the project, and make your intentions clear to your contributors.
- Be prepared to explain (and, sometime, insist). Let’s face it: the open-source work is not something legal offices in universities are particularly familiar with. The role of these offices is to protect the intellectual property of the investigators, typically with the perspective of having some form of return either through increased visibility or through financial returns due to commercialization. It may not be simple to discuss the transfer, at no cost, of a piece of software which was developed as part of a research project, particularly if the intellectual property was transferred to the university. Things become even more challenging if public money funded the research project, and the government agency which sponsored the research retains certain rights (i.e. the US government retains “unlimited rights” on software funded by its agencies). Finding an agreement requires time, work and openness to explain and listen, from all the involved parts. Often it is a question of being well informed and provide the right information to the right person. Finding both takes time, so be patient and do not give up at the first obstacle or the first no: inform yourself, make your point very clear, and, if needed, insist. Having the intention of contributing your work to an open-source project clearly specified in your proposal may be key to have leverage. Working with the office of intellectual property and the legal office at your employer is essential: they are there to help, but be prepared to explain: you may be asking something outside of their area of expertise. Try to find similar cases at other institutions of the same type of yours. Ask for help to your funding agency and, eventually, contact one of the organizations who support free and open-source software, which may offer advice.
Someone will tell you it is impossible or unnecessary to sign an agreement
Several seem to think it is impossible, not appropriate or even unfair to request transfer of intellectual property when contributing to an open-source project. There are legal systems, as the German one, where this is the case, but alternative solutions can be found. The OpenFOAM Foundation has a very flexible contributor agreement which covers these cases. It is also a fair agreement because the majority of the rights transferred are returned through a license back to the contributor. If someone says contributing is not possible, it is probably worth trying to gather more information on your specific case.
On this aspects, it is worth spending a few more words concerning recognition in academia. Many academics worry that contributing their work to an upstream project and transferring the copyright to another entity reduces their visibility and the potential for receiving credits for the work done. I think reality is different from this. First of all, most of the recognition for research work in academia comes from publications and their citations. One could argue that is not fair, but it is how the system currently works. Putting code in a GitHub repository, disseminating it and hoping to have the code cited may work for large projects, but it is quite uncommon for software, despite all the efforts to change this. Learning a lesson myself, I would say the effort should go into producing actual publications on relevant journals using the software, rather than hoping the software will be cited through a DOI associated to the software repository. This aspect may change over time, when researchers will become more educated to consider software in the same way as an actual publication, and will formally refer to it. In the meantime, I would suggest to disseminate the software as much as possible, as openly as possible (which is different from “under the most permissive license possible”. See here for more comments on license choice), and target interested communities with publications, if the focus is being cited.
Some think transferring copyright is unnecessary
This is probably the most controversial point. Some argue that in open-source projects a request to transfer the intellectual property is unnecessary. Some even see it as an unacceptable request. However, it is common practice also for very popular and undeniably open-source projects such as GNU Emacs. The Free Software Foundation provides several points to support copyright assignment. I believe the key aspects a contributor agreement needs to have to be convincing and in good faith are:
- The guarantee that the original contributor receives back a license that allows further use and development as fit.
- The limitation to the receiver of the contribution that the license under which the contribution happens won’t be changed.
If these conditions are satisfied, as they are by the OpenFOAM contributor agreement, I believe the risk for the contributor is minimal and no concerns on the possibility of continuing to access the contributed work is present.
Conclusions
There are several aspects to consider when making the decision to contribute the software produced in a research project. If the decision is positive, key aspects are to clearly specify it since the beginning and act consequently from the start. Involve the interested parties as early as possible, and make the case for the contribution, without giving up at the first obstacle. It may take some time and certainly quite some work, but it is also an interesting learning experience.