++If your software project operates on multiple contributions, and a contributor +becomes uncontactable or passes away, this can become an issue in +certain situations. Here we’ll discuss when a missing or deceased +contributor affects your software project, and what options you +have. +
+ +
+Which contributions are copyrightable?
+Before anything, when is a contribution copyrightable in the first +place? Commonly, software projects that are hosted on popular hosting +websites, such as GitHub, GitLab, BitBucket etc, often encompass +contributions by multiple contributors. Nevertheless, as only “creative +works” can be copyrighted, the extent to which the contribution can be +regarded as a “creative work” can be a bit tricky to ascertain. The +length of the contribution does not matter because short contributions +can also be creative.
+Primarily, anything that is accepted as a change into the source +code, and modifies the source code can constitute a creative work that +is copyrightable. This is the case even if they are minor or small +changes; even single line bug fixes with a creative scope is a +contribution that falls into this category.
+On the other hand, non-source code contributions, such as +translations, documentation, or configuration files can be commonly made +available in the public domain, or even regarded as insignificant +changes outside of the scope of the applicable Free Software license. +Nevertheless, to err on the side of caution, the safest approach is to +assume whenever in doubt that a contribution is a copyrightable +contribution, and act accordingly.
+When do you need to get in contact with a contributor?
+Generally, you would need to get in touch with a contributor to your +project whenever you wish to enact some kind of major change to the +overall project. The most common situation for this would be where a +project runner intends to re-license the project.
+If you need to make such a change, your first step should be to +compile a list of all contributions that are copyrightable, as well as +their respective contributors. You should then obtain consent for all +copyrightable contributions, including those of deceased or otherwise +uncontactable contributors.
+The reason that you need to do this is that software enjoys copyright +protection from the instant that is created. This means that a +contributor by default has copyright over their contribution, and does +not need any additional steps to protect their work under copyright. +There are of course exceptions to this, most notably when the +contributor has effectively transferred their copyrights over the +contribution to you or your project, making you or your project the +copyright holder.
+What happens if the contributor has passed away?
+Generally, copyright law provides that ownership of the copyright +remains with the contributor even after death. In most EU jurisdictions, +this means that copyright lasts for 70 years after the death of the +author, or in the case of joint authorship, after the death of the the +last surviving author. Once this 70-year term expires, the work will +enter into the public domain, where others may use the work for +commercial purposes without requesting any authorization or license.
+Copyright is considered to be personal property, and therefore +copyright ownership can be included in a will, and passed on to another +person upon the copyright holder’s death. Accordingly, you should +inquire with the deceased contributor's estate to see who the copyright +has passed onto and seek their consent before making any changes to the +project that require the consent of all contributors. In the event that +there is no specific provision for who takes ownership of the copyright +of software contributions in the will, the rights will be passed along +in accordance with the national laws of intestacy where the contributor +was residing in.
+Regardless of whether or not the ownership of the deceased’s +copyright in the project was covered in a will, the new copyright +owner(s) would now be the people that you have to obtain your consent +from. Nevertheless, please remember when doing so to always be +respectful and sensitive in such communications. Losing a loved one is a +difficult enough thing to go through, and many relatives will not want +to be contacted too soon after the death of their loved one with +questions about contributions.
+Looking for help with established platforms or software +foundations
+If your project is hosted online on a popular code repository hosting
+platform, you should check to see if they have any policies for deceased
+or absentee contributors. As an example, GitHub has a Deceased User
+Policy.
+This policy is written primarily to allow GitHub to work with authorized
+persons in the deceased's estate to determine what to do with the
+deceased’s GitHub account. It is also useful for next of kin,
+pre-designated successors, or other authorized individuals (which could
+include a collaborator or business partner) of a deceased user, to be
+able to gain control over a deceased user’s account.
+
+It could also be useful to send a request to other popular foundations
+such as the Apache Software Foundation, the Mozilla Foundation, or the
+Linux Foundation inquiring about the status of the deceased developer's
+account, as some developers have adopted the practice of willing
+contributions to Free Software foundations.
What happens if you can’t contact a contributor or their heirs?
+If obtaining the consent of a contributor or their estate has turned +out to be impossible, one practical recourse would be to fork the +project repository, while moving the contribution(s) of the missing +contributor(s) to stay under the original. A good practice when taking +this course of action would be to credit previous contributors who have +created the original program from which the fork is carved out. +Therefore, if all efforts fail to trace and contact the missing +contributor(s), you can at least point to some form of attribution to +mitigate any potential complications down the line.
+Another practical option that many project runners frequently take +would be to ignore the deceased and/or missing contributor(s) and their +contributions altogether. While this is not strictly the correct legal +approach, it is nonetheless a practical one that allows projects to move +forward with their plans. Software project that go down this route do so +after a thorough risk assessment, more specifically, after analyzing (1) +the significance of the contribution in question; (2) the likelihood of +the contributor or their estate contesting the decisions of the project, +based on their ownership of the copyright over the contributions; and +(3) the likelihood of success of any such contestation.
+In many cases, project runners may come to the conclusion that the +risk of the missing/deceased contributor showing up to assert the rights +of their ownership of the contribution is small enough, such that moving +forward without the explicit consent of that particular contributor or +their estate is worth the risk.
+We hope that this has been useful for your understanding of managing +this particular legal issue within a software project.
+ + + +