Why sysadmins should license their code for Open Source

One of the best ways I know to give back to the Open Source community that provides everyone with incredible programs is to make programs and scripts open source using an appropriate license.

Introduction

As a Linux system administrator, I write a fair amount of code.

Does that surprise you? Well, I strive to be the “lazy” sysadmin, and I do this, in part, by reducing the number of repetitive tasks by automating them. Most of my automation started as little command-line programs. I automate tasks using executable scripts stored centrally. This allows me to efficiently manage any Linux host under my purview by re-running the scripts as required.

The problem with sharing unlicensed code

I also like to share my code. Open Source is all about sharing code to help others. The code that solved a problem for you could be a lifesaver for fellow sysadmins facing similar issues. But legal hurdles exist and even well-written code might not be usable as intended due to legal issues.

While keeping copies of licenses helps companies understand their rights and obligations, it can create a challenge. Legal departments often require this practice, but it can hinder code sharing. Unlicensed software creates a legal gray area. Without a clear license outlining usage rights, companies and individuals hesitate to use the code, fearing potential legal issues. This can prevent valuable software from reaching its full potential.

Why I license my code

One of the best ways I know to give back to the Open Source community that provides everyone with incredible programs like the GNU Utilities, the Linux kernel, LibreOffice, WordPress and thousands more, is to make programs and scripts open source using an appropriate license.

Writing code you believe should be Open Source isn’t enough to make it so — that requires an explicit license. Many sysadmins, myself included, write tons of useful scripts. But how often do we consider formally licensing them for Open Source use?

Making your code Open Source isn’t automatic. You need to explicitly declare it Open Source and choose a license. This critical step removes any confusion and allows others to freely study, use, modify and share your work. Without a license, your code remains essentially proprietary, hindering the community from benefiting from your contributions.

You should include the GPLv2 (or your other preferred) license header statement as a command-line option that prints the license header to the terminal. When distributing code, I also recommend including a text copy of the entire license along with the code (it’s a requirement of some licenses.)

A few years ago, I read an interesting article, The source code is the license that helps to explain the reasoning behind this.

It’s surprising that despite all the books I’ve read and classes I’ve taken on system administration, none have mentioned the importance of licensing code written for internal tasks. This seems like a significant oversight, considering how often sysadmins write scripts and tools.

All these sources completely ignored the fact that sysadmins write code too. Even in the conference sessions on licensing I’ve attended, the focus was on application code, kernel code, and even GNU-type utilities. None of the presentations so much as hinted that you should consider licensing it in any way.

Perhaps you’ve had a different experience, but this has been mine. At the very least, this frustrates me — at the most it angers me. You devalue your code when you neglect to license it. Many sysadmins don’t even think about licensing, but it’s important if you want your code to be available to the entire community. This is about neither credit nor money. This is about ensuring that your code is, now and always, available to others in the best sense of “free and Open Source.”

Eric Raymond, author of “The Art of Unix Programming,” writes that in the early days of computer programming and especially in the early life of Unix, sharing code was a way of life. In the beginning, this was simply reusing existing code. With the advent of Linux and Open Source licensing, this became much easier. It meets the needs of system administrators to be able to legally share and reuse Open Source code.

Raymond states, “Software developers want their code to be transparent. Furthermore, they don’t want to lose their toolkits and their expertise when they change jobs. They get tired of being victims, fed up with being frustrated by blunt tools and intellectual-property fences and having to repeatedly reinvent the wheel.” This statement also applies to sysadmins — who are also, in fact, software developers.

How I license my code

I mentioned adding an option to print the GPL (or other) license header as a command line option.
Here’s how I do it:

#############################################
# Print the GPL license header              #
#############################################
gpl()
{
echo
echo "############################################################"
echo "# Copyright (C) 2023 David Both                            #"
echo "# http://www.both.org                                      #"
echo "#                                                          #"
echo "# This program is free software; you can redistribute it   #"
echo "# and/or modify it under the terms of the                  #"
echo "# GNU General Public License as published by the           #"
echo "# Free Software Foundation; either version 2 of the        #"
echo "# License, or (at your option) any later version.          #"
echo "#                                                          #"
echo "# This program is distributed in the hope that it will be  #"
echo "# useful, but WITHOUT ANY WARRANTY; without even the       #"
echo "# implied warranty of MERCHANTABILITY or FITNESS FOR A     #"
echo "# PARTICULAR PURPOSE. See the GNU General Public License   #"
echo "# for more details.                                        #"
echo "#                                                          #"
echo "# You should have received a copy of the GNU General       #"
echo "# Public License along with this program; if not, write    #"
echo "# to the Free Software Foundation, Inc., 59 Temple Place,  #"
echo "# Ste 330, Boston, MA 02111-1307 USA                       #"
echo "############################################################"
echo
} # End of gpl()
end

That’s the license, included as a function. You can add an option to the code. I like to place the new case sections in alphabetical order to make them a bit easier to find when performing maintenance. This is the GPL, so I chose g as the short option:

#########################################
# Process the input options             #
#########################################
# Get the options
while getopts ":gh" option; do
case $option in
   g) # display the GPL header
      gpl
      exit;;
   h) # Help function
      Help
      exit;;
   \?) # incorrect option
      echo "Error: Invalid option."
      exit;;
   esac
done
end

These two bits of code are all you need to add a legitimate and enforceable license to your program.

Final thoughts

I always license all my code. I once presented a session on Bash at OLF (Open Libre Free, which used to be known as Ohio Linux Fest). Instead of using LibreOffice Impress for my presentation, I used a Bash program for the entire thing. After all, it is a presentation about Bash so why not make it a Bash program?

I included my license code in that Bash program. That way everyone who comes across a copy of my program knows that it’s properly licensed under GPLv3, and that they can use and modify it under the terms of that license. My code is the license.

This is the last post in my series on Bash – if you learned something, consider giving back by making your code available to everyone.