Every decade or so the technology world gets punched in the face by a problem requiring poring through massive amounts of code written well before many of us were born.
In the late 1990s it was the Y2K problem when two digit years were no longer sufficient.
In the 2008 financial crisis COBOL based systems required hand editing in order to change state employee salaries en mass.
In 2020 we had the Pandemic related economic impact requiring Bank and Employment system’s code to be modified, many of which again were written in COBOL!
In 2032 we’ll have the Y2k38 problem when the Unix time will overflow causing software issues akin to Y2K.
While many of these systems were closed source and proprietary, open source systems are starting to dominate the software landscape. Much like your grandparents’ hammer, these examples show us that useful tools will almost always outlive the person who first selected or created them.
Besides the question of maintainability and programmer experience with very old languages like COBOL, questions of intellectual property and software licensing will complicate the usability of open source software over the next 50 years and beyond.
Think about Licensing!
As part of software due diligence (when a company purchases another company and confirms that the source code they are buying is correctly owned, licensed and documented) I have had the experience of trying to track down the ownership and licensing of code decades old. This type of software archeology requires access to archives of source code, books, magazines, blogs and other places that programmers have published software over the last 60 years! In many cases the true origin of some source code is lost to time, or can be only partially known.
Questions such as “Who wrote this?”, “Did they expect others to freely use this source?”, or “Does a commercial company own this?” are common.
It is important to make these types of answers clear for those who come after us.
The most important of these is to specify an open source license for the code you are publishing, even if it’s just a “single page” or block of code. If it’s worth putting on the Internet, it’s worth telling people what its license is. There are many suggestions on how to label code to make the copyright and license clear, but I strongly suggest that each file contains a copyright statement and at least a SPDX license identifier (See https://spdx.org/licenses/)
This allows someone in the distant future to know who wrote the source code and what the obligations are even if only a single file remains.
Who do you depend on?
Document all your third party dependencies, including dependencies of dependences. There is no guarantee that any of our current repository managers will still be working decades in the future, but your code may be. By listing these dependencies, you help the Future build and run your code.
In a similar vein, your build system and running environment should be documented as well. For example, if you depend on a certain make system or database to be installed, call these out in separate build and running environment documentation.
Till Death Do Us Part
In the short term, understand that source code is considered property. What happens after you die should be clearly specified. In most places the ownership of your code will pass on to your heirs, but possibly with complicated and divided ownership. Do you want anyone in particular to be the new code owner (or someone outside of your family)? In this case your will (or related documents) should make this clear.
While everyone should have the permissions available under your open source license for the duration of your copyright, you may wish your heir to have the ability to “own” the code just like you do.
By making the ownership clear, they will then have the ability to change the license for your code, just like you likely do now. This means they may have the permission to also sell commercial licenses to this code, or change the open source license of the project. An open source project with multiple contributors has additional concerns about ownership. You may need to make clear dividing lines between projects you own outright as opposed to projects you contribute to, or have others contribute to.
Do you want to change the license after your death, or after a certain amount of time? Make these changes clear as well. Some may want to open previously closed source, or change to a Creative Commons Zero (CC0) license or Public domain declaration.
Similar questions may come up in the case of divorce. While it’s often clear who owns code you write when “on the clock at work”, the code you write at home may have complex ownership issues.
Go beyond the code!
An additional thing to consider is account access, logins, domain names and payments.
Typically we tell everyone to keep their account information private and secure. This may be at odds with your desire to keep your project going even after your death.
Keeping a list of domain names, third party services and other account information related to your project can help the heirs to your code keep the project going.
Bear in mind that, after your death, certain accounts may be locked, go away or may be controlled by people other than the code owner.
As with most things involving intellectual property and life events, it is best to consult a lawyer to understand your best options.
Rest in Peace!
A little care and effort in the present can save the community a significant amount of time in the future. By specifying a license, documenting project dependencies, and clearly transferring ownership you can make sure your code stands the test of time.