Open source licenses, as a practical matter, are treated as fire-and-forget by most developers. But what happens when the contributor dies?

As a contributor, you usually have a copyright in the code that you created. That copyright came into existence automatically, and if you don’t do anything with it legally then the copyright will pass to your heirs when you die. Failing to register the copyright promptly has legal consequences this article will not discuss, but the copyright exists whether you register it or not.

If you have a will that is properly executed and presented to the court, then the copyright ownership will pass to your heirs under the will—although they may not even know it exists, because nobody told them about your open source contribution. If you don’t have a will, then the copyright will pass to your “heirs at law” under the laws of your state. These are your default heirs, the people your legislators in the state capitol have decided should get your stuff if anything happens to you.

But this is all a bunch of legal mumbo-jumbo. If you have the intention of putting your project out in the community for all to use freely, why does it matter who owns the copyright?

Why it Matters

There are many reasons that it matters who owns the copyright, even in open source software released under an MIT license or the GPL.

The license that should be used for the software may change over time. Maybe a law changes, or there is an updated and better version of the GPL. Maybe someone actually wants to use your project to help educate thousands or even millions of people but their boss won’t let them use GPL software—so your project is wasted unless someone has the legal authority to re-issue it under the MIT license.

Maybe you feel very strongly about only allowing your project to be used in open source projects, and want your license terms enforced. Only the legal or beneficial owner of a copyright can bring a suit in federal court for infringement. See 17 U.S.C. § 501(b). If the legal owner is a grandson who knows nothing about software, doesn’t know the open source community, and doesn’t even know they own the copyright, then nobody will enforce your license.

These examples and others are not the most important things in ensuring the success of open source projects. They only matter if certain sets of events occur. But then, that’s also true of assertions, unit tests, race conditions, and even plumbing. Being prepared for edge cases is part of engineering.

How to Leave Copyrights to Another

There are a variety of ways to transfer your copyrights in a work. Most obviously, it can be done via a will when you die or via a transfer or assignment during your lifetime. A will is in some respects the most reliable method of transferring ownership in works you did not create for hire, because of copyright termination rights (discussed below). Still, there are other options, including transfers via trust, via another entity like an LLC, nonprofit, or C Corporation, or via the marital or community property laws of your state.

A trust is a legal entity that holds property and manages it under terms specified on a paper called the “trust instrument.” While a trust can be set up in a will, it does not need to be. The trust instrument names a trustee to manage the property in the trust. When the person who started serving as trustee dies or resigns as trustee, someone named in the trust instrument (or selected according to a procedure it describes) takes over management of the trust property. It would be easy, for example, to transfer your copyright to a trust, to allow other contributors to the open source project to contribute to it, and to name successor trustees to manage it when you die or resign as trustee.

Other entity types have a wide variety of advantages and disadvantages, and discussing the benefits and drawbacks of each is beyond the scope of this article. However, they can certainly own intellectual property and be used to protect copyrights in the open source community. Most obviously, the Free Software Foundation collects copyrights from the contributors to many GNU packages such as GCC and EMACS, and works to get better compliance with open source licenses.

Another Problem: Copyright Termination

As part of the song-and-dance that industry used to extend copyright terms out to 95 years, Congress compromised by giving authors (or, if they are deceased, their families) the ability to terminate an early copyright license and to re-sell or renegotiate the rights to their authored work. For authors who once gave away rights to their works for a pittance, this termination right allows them or their families to shed old agreements that no longer reflect the economic demand for their work.

In the open source community, renewal rights present a legal minefield. 17 U.S.C. § 203 allows a deceased developer’s spouse or grandchildren to terminate any copyright licenses granted by the author, including the GNU General Public License and the MIT License. These termination rights do not exist for works made for hire or for licenses and transfers of copyright accomplished by will, so companies obtaining works made for hire need to document that carefully, and open source contributors who intend copyright licenses or transfers to be truly irrevocable should incorporate the licenses and transfers into their will.

While this is a legal minefield, the damage is delayed: the termination right arises after 35 years. While this seems like a long time, successful open source projects can live for a long time. The copyright registration on EMACS dates to 1986, for example.

Where joint authors are involved, the termination right may be executed by a majority of authors who executed the transfer of ownership, with the termination interest of deceased authors being executed by the author’s widow or children who together control a majority of the author’s termination interest by statute. 17 U.S.C. §203(a). So for large works with many authors who intended to make a joint work, there is less risk of someone terminating the license down the road than there is with a solo developer project or a small team project.

There can also be more risk where one author contributes almost all of the changes to a given substantial update. This author could be the author of a “derivative work” of the prior version, rather than a joint author of the same work. (Sole authorship is not required for derivative works, but sole authorship makes it easier to invoke termination rights).

While forking a repository and starting your own somewhat different project with it is the most obvious signal you will be making a derivative work, adding a substantial feature and deploying it to the master branch of an existing project on Github could also be considered making a derivative work. As sole owner of the copyright in the derivative work, the author (or the author’s relatives) could one day terminate the package’s license with regard to their contributions.

Still, once the right to create derivative works of that derivative work is given, while it can be recalled, derivatives of the copyrighted derivative work may still be used under the license in force at the time the derivative work was made. Most obviously, music and movie producers use this Hollywood loophole to avoid having to renegotiate rights with authors or their families. See, e.g., Mills Music v. Snyder, 469 U.S. 153 (1985).

This would allow some use of subsequent versions of software, but courts do not appear to have weighed in on post-termination creation of derivative works of open source derivative works for which the author of yet another underlying derivative work has terminated the license.

And sentences like that are why you didn't go to law school.

Estate Planning Strategies for the Open Source Developer

Transferring your copyrights to an appropriately drafted open source trust, leaving them to a co-contributor, or otherwise providing for them may prevent someone from killing a project with legal drama. It may even allow the open source community to enforce the terms of your open source license after you are gone.

The bottom line is that there are a couple of ways to handle this from an estate planning perspective, and developers should ask about them. Selecting the right option is going to depend on your goals for your open source contributions. It may be as simple as adding a line to your will.

---

Tom White writes " A Little Deathy ." He is Attorney/Owner of King County Business Law in Seattle, Washington, is admitted to practice law in WA and NY, and is the pseudonymous author of UN-acclaimed anti-human-trafficking novel River of Innocents . He is an Eagle Scout and recipient of the Order of the Arrow's Vigil Honor, and he volunteers at the Housing Justice Project . A graduate of Williams College and Georgetown Law, Tom can occasionally be spotted in the wild at Seattle coffee shops.

Like This Article?

Like, Comment, or Share it with your network.