Open-source News

Why sysadmins should license their code for open source

opensource.com - Wed, 01/25/2023 - 16:00
Why sysadmins should license their code for open source dboth Wed, 01/25/2023 - 03:00

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 I need to do by automating them. Most of my automation started as little command-line programs. I store those in executable scripts for re-use at any time on any Linux host for which I have responsibility.

The problem with sharing unlicensed Code

I also like to share my code. I think that, if my code has helped me to resolve a problem, it can also help other sysadmins resolve the same or similar problems. This is, after all, the essence of open source — the sharing of code. While code sharing is a good thing, legal issues can prevent perfectly good code from being used as intended by the developer.

The primary problem is that many companies have legal departments that require them to keep copies of licenses. This makes it easy to understand their rights and obligations. Software without a license attached to it in any way becomes a legal liability. This is because there is no basis upon which to determine whether the code can be used legally or not. This can prevent perfectly good code from being used by many companies and individuals.

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.

Just because you write a program, believe in open source, and agree that programs should be open source code, does not make it open source. As a sysadmin, I do write a lot of code, but how many of you ever consider licensing your own code?

You have to make the choice to explicitly state that your code is open source, and decide which license you want it to be distributed under. Without this critical step, the code you create is functionally proprietary. This means the community cannot safely take advantage of your work.

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 that you include 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.

I find it very interesting that in all of the books I have read, and all of the classes I have attended, not once did any of them tell me to include a license for the code I wrote in my tasks as a sysadmin. All of 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 neither about credit or 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 2003 book, 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. The code below is a procedure that does so:

############################################# # 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 ":ghc" option; do case $option in c) # Check option Check=1;; g) # display the GPL header gpl exit;; h) # Help function Help exit;; \?) # incorrect option echo "Error: Invalid option." exit;; esac done end

More for sysadmins Enable Sysadmin blog The Automated Enterprise: A guide to managing IT with automation eBook: Ansible automation for Sysadmins Tales from the field: A system administrator's guide to IT automation eBook: A guide to Kubernetes for SREs and sysadmins Latest sysadmin articles

These two bits of code are all that's needed to add a legitimate and enforceable license to your program.

Final thoughts

I always license all of my code. I recently 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 did include my license code in that Bash program. That way everyone who encounters 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.

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.

Image by:

Opensource.com

Sysadmin Licensing What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Mesa 23.0 Graphics Drivers Aim For Release Next Week

Phoronix - Wed, 01/25/2023 - 13:00
Barring any release-blocking issues from coming up in the next week, Mesa 23.0 aims for its official release while 23.0-rc3 is now available for last minute testing...

systemd 253 RC1 Released With New "ukify" Tool

Phoronix - Wed, 01/25/2023 - 07:34
Systemd developers today released their first release candidate of the upcoming systemd 253 feature release, which introduces a new "ukify" tool and has many other changes for this dominant Linux init system...

FSF Updates By-Laws - Tighter Approval Process For New/Updated Licenses

Phoronix - Wed, 01/25/2023 - 05:50
The Free Software Foundation (FSF) Board of Directors has adopted updated by-laws that go into place next month with an aim of further protecting copyleft licensing...

AMD 4th Gen EPYC "Genoa" To Enjoy Slightly Better Performance With Linux 6.3

Phoronix - Wed, 01/25/2023 - 04:30
Expected to be squared away in time for the Linux 6.3 kernel cycle, which is kicking off in February, is Automatic IBRS as a new feature of Zen 4 processors. The patches already have been queued up into TIP's x86/cpu branch so barring any issues will be all wired up for this next kernel version. Automatic IBRS can provide better performance than the Retpolines implementation used currently on Zen 4 and prior CPUs as part of the Spectre V2 mitigations. With the switch over to Automatic IBRS for Zen 4, it means better performance in some areas as shown by these benchmarks today with AMD 4th Gen EPYC "Genoa" processors.

DXVK 2.1 Released With HDR Support, Many Game Improvements

Phoronix - Wed, 01/25/2023 - 04:14
DXVK 2.1 has just been released as this Direct3D 9/10/11 to Vulkan API translation layer that is most notably used by Valve's Steam Play (Proton) for helping to run Windows games with great speed on Linux...

openSUSE Making It Easier To Install H.264 Codec Support

Phoronix - Wed, 01/25/2023 - 02:36
The openSUSE project in collaboration with Cisco is making it easier to deploy H.264 codec support on openSUSE Leap and Tumbleweed...

Pages