The Linux Philosophy for SysAdmins, Tenet 14 — Use Open Source software

Image by Opensource.com: CC-by-SA 4.0

Author’s note: This article is excerpted in part from chapter 16 of my book, The Linux Philosophy for SysAdmins, with some changes to update the information in it and to better fit this format.

This tenet may not mean exactly what you think it does. Most times we think of open source software as something like the Linux kernel, LibreOffice, or any of the thousands of open source software packages that make up our favorite distribution. In the context of system administration, open source means the scripts that we write to automate our work.

Open source software is software with source code that anyone can inspect, modify, and enhance.¹

— Opensource.com

The web page from which the quote above was taken contains a well-written discussion of open source software including some of the advantages of open source. I suggest you read that article and consider how it applies to the code we write – our scripts. The implications are there if we look for them. This chapter will hopefully help you to achieve some insight just as writing it enlightened me.

Definition of Open Source

The official definition of open source is quite terse. The annotated version of the open source definition² at opensource.org contains ten sections that explicitly and succinctly define the conditions that must be be met for software to be considered truly open source.

This definition is important to the Linux Philosophy for SysAdmins so I include the text of that annotated definition here. You do not have to read this definition but I suggest you do so in order to gain a more complete understanding of what the term open source really means.

Note: The Open Source Definition is not a license. It describes the conditions that any license must meet in order to be considered an open source license.

The Open Source Definition (Annotated)

Version 1.9

The italicized sections below appear as annotations to the Open Source Definition (OSD) and are not a part of the OSD. A plain version of the OSD without annotations can be found here.

Introduction

Open source doesn’t just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

Rationale: By constraining the license to require free redistribution, we eliminate the temptation for licensors to throw away many long-term gains to make short-term gains. If we didn’t do this, there would be lots of pressure for cooperators to defect.

2. Source Code

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

Rationale: We require access to un-obfuscated source code because you can’t evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.

3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

Rationale: The mere ability to read source isn’t enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

4. Integrity of The Author’s Source Code

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they’re being asked to support and protect their reputations.

Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, “unofficial” changes can be made available but readily distinguished from the base source.

5. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons.

Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process.

Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.

7. Distribution of License

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.

8. License Must Not Be Specific to a Product

The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

Rationale: This clause forecloses yet another class of license traps.

9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

Rationale: Distributors of open-source software have the right to make their own choices about their own software.

Yes, the GPL v2 and v3 are conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of interface.

Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called “click-wrap” may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.

---

The Open Source Definition was originally derived from the Debian Free Software Guidelines (DFSG). Opensource.org site content is licensed under a Creative Commons Attribution 4.0 International License

Why this is important

The definition of open source is important to us as SysAdmins for several reasons. First, this definition provides us with a framework for evaluating the many licenses that are out there. Some of them are truly open source licenses while others only feign being open source.

True open source licenses allow us to easily and legally find, download, and use code that is open sourced. Without the assurance that the code we use is open sourced, we would be unable to use huge amounts of existing code that already meets many of the needs we have. Code that is distributed under any of the licenses recognized to be open source is free of any encumbrances. Understanding the requirements for true open source licensing allows us to ensure that the code we are using is properly licensed.

Properly licensed open source code is freely available and we can use it on as many computers as we like and copy it to give to others. There are no restrictions on how we can use or share it. There are a number of good yet different open source licenses. The Open Source Initiative web site has a current list of approved open source licenses³.

Coining the term

I enjoy learning about the history of Unix, Linux, and open source and so I think it important to acknowledge that Christine Peterson⁴ coined the term “open source.” In February of 1998, Peterson was in a series of meetings with Eric S. Raymond, Jon “maddog” Hall, and many other leaders to discuss licensing Netscape as free software. A number of people, especially Peterson, did not think that “free software” properly defined what they were trying to accomplish.

She came up with the term “open source” and approached some of the other attendees with the idea. In a meeting on February 5, some of the attendees started using “open source” to describe software that was free of restrictions and for which the source code was readily available. This story is really hers to tell so please read her article⁵ at Opensource.com. In a comment at the end of the article on Opensource.com, Eric Raymond validates and supports Peterson’s account of the birth of this now ubiquitous term.

Licensing our own code

One of the best ways I know to give back to the open source community that provides us with all of these incredible programs like the GNU Utilities, the Linux kernel, LibreOffice, WordPress, and thousands more, is to open source our own programs and scripts with an appropriate license.

Just because we write a program and we believe in open source and agree that our programs should be open source code, does not make it so. As SysAdmins we do write a lot of code but how many of us ever consider the issue of licensing our own code. We must make the choice and explicitly state that the code is open source and under which license it is being distributed. Without this critical step the code we create is subject to becoming fettered with proprietary licenses so that the community can not take advantage of our work.

Remember the bash shell template we created back in Tenet 08 — Always use shell scripts? We included the GPL V3 license header statement as comments in the code and we even provided a command line option that would print the license header on the terminal. When distributing code I also recommend that we make it practice to include a text copy of the entire license with the code.

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 be sure to license any 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 that I have attended, the focus was on application code, kernel code, or even GNU-type utilities. None of the presentations even so much as hinted at the fact that we SysAdmins write huge amounts of code to automate our work or that we should even consider licensing it in any way. Perhaps you have had a different experience, but this has been mine. At the very least, this frustrates me; at the most it angers me.

We devalue our code when we neglect to license it. Most of us SysAdmins don’t even think about licensing but it is important if we want our code to be available to the entire community. This is neither about credit nor is it about money. This is about ensuring that our code is now and always will be available to others in the best sense of free and open source.

Eric Raymond 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 the open source licensing, this became much easier. It feeds 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.

This leads us to the problems associated with organizational code sharing and open source.

Organizational code sharing

As SysAdmins our natural inclination is to share code. We like to help people which is why we are SysAdmins in the first place. Yes, some of us just prefer computers to people but we all like to share our code.

Many organizations have no idea how to share code or the advantages of doing so. Others have figured this out and some even pay employees to write open source code.

Silos suck

Having worked at a good number of different organizations as a SysAdmin I have found that many suck at sharing code both externally and internally. Most of the places I have worked at have never even thought about sharing code internally let alone externally. Every development project was isolated from every other one. Departments were like silos, tall and narrow with lots of silage inside, self enclosed fiefdoms eschewing contact with the outside world. In many ways they acted like rivals instead of teams working for the same organization.

I always found it difficult to obtain code from other departments in these organizations. The PHBs of other internal organizations always seemed to think that we were in some sort of competition with them and that sharing code was a zero sum game in which the one sharing the code was the loser. At the very least it took weeks of discussion and sometimes some sort of written legal forms that included a non-disclosure agreement. I am not talking about two departments writing commercial code that might overlap or compete in some way in the external marketplace; I am talking about two internal lab organizations, for example, that perform essentially the same tasks every day. Sharing code would have made so much sense, saved so much work, and been so easy to do.

In some cases it was just easier to write our own code than it was to struggle through the bureaucratic nonsense to obtain code we already knew would solve a problem for us. What a waste of time!

Open Organizations and code sharing

That type of internal organization that results in uncommunicative silos needs to be replaced by an open organization⁸ which will encourage code sharing at least internally. Jim Whitehurst, CEO of Red Hat, has written a book, The Open Organization⁹, which discusses the advantages and qualities of the open organization and how to make the transition. Whitehurst has also written a very interesting article, Appreciating the full power of open¹⁰, for Opensource.com in which he discusses the concept of sharing, “Sharing something often increases its value, because sharing allows more and more smart, creative people to get their hands on it. The value actually increases as you remove restrictions to sharing—if you share as much as you can with as many people as you can. That means sharing your instructions, your recipe, your source code, and opening it up to everyone, not limiting access to certain persons, groups, or ‘fields of endeavor,’ as the Open Source Initiative¹¹ puts it.”

In 2005, Karl Fogel wrote an interesting book, Producing Open Source Software – How to Run a Successful Free Software Project¹², and followed up with a second edition in 2017. Fogel covers in detail the techniques, technology, legal issues, and the social an political infrastructure of creating open source software. This is an interesting book that details many practical aspects of creating software that is truly open source. It discusses the advantages of sharing code internally as well as externally using open source licensing.

Some organizations pay their employees to write open source code. For example many companies pay some of their employees to write code for the kernel which ultimately, if approved by Linus Torvalds, will be shared with programmers throughout the world. This is not always purely altruistic because many companies that do this wish to make the kernel work better for their own software. In many cases this new or revised code will make Linux work better for everyone and Torvalds may accept it into the kernel source code tree.

Many open source projects besides the kernel are supported by organizations that understand the value proposition of supporting open source software both monetarily and with code.

Things to avoid

This article is about using open source software but that means that we also need to distinguish true open source software from that which has hidden restrictions or simply does not comply with the licensing under which they claim their software is distributed. It is a sad thing that we need to discuss companies that falsely claim their software to be open source.

This is one of the reasons I have included the Open Source Definition in this chapter. Understanding the objectives of open source can help you to understand when a license does not meet the requirements. But there are other things to beware of also.

If a software vendor states that their software is open source, then the source code should be easily available for download from the Internet. In some cases I have been interested in software and in viewing the web site found no indication that the source code was available. In those cases no one responded to my queries about that issue.

If in order to download some software, you are required to provide your name, email address, and other identifying information, the software is definitely not from a reputable company even if they claim to use an open source license. I have seen many alleged “free white paper” downloads that would actually interest me if they did not require “registration” of some sort. I recommend giving these companies a wide berth. They are probably using the false or misleading promise of open source software to build a spammer’s list of email addresses.

Share your code

Writing this article has caused me to contemplate my own role in the open source ecosystem. I have written a number of shell scripts over the years that were intended to automate some of the tasks I perform as a SysAdmin. About 10 years ago I began adding the GPL V2 license to my code. I added the license statement in the comments, and later as an option that it could be printed by the user.

The last 15 years or so of my career was spent, at least in part, as an independent consultant for organizations and individuals wanting to try Linux. I used my programs in the systems I set up for them and I would send the occasional script to remote customers or other consultants. But I never really made my programs available in a public forum like GitHub or even a directory on my own web site.

In order to make these scripts more widely available, I have posted them on my web site. You can download them and use them as you see fit within the terms of the licenses. The code is all distributed under the GPL V2 and the PDF documents are published under a Creative Commons Attribution-ShareAlike license.

If you make changes to improve any of the code or documents you download, please send me a diff file along with a short description of the changes.

Parting thoughts

Using the open source software created by others is important but I am not suggesting that we completely forgo the use of proprietary software when it meets a need that cannot otherwise be met. By this I mean that we consider proprietary software after extensive searches have failed to locate appropriate open source software, and then exploring the possibility of writing a script to perform the task in question.

If you choose to write a script to solve the problem, open source your own code. Make it available for others because if you need to perform this task others also need to do so. You will be saving others the work you invested in creating it.

Stay away from the trap of always writing your own code when something is already available. We could write our own web based content management or blogging software but there is already plenty of software that does that. WordPress, Drupal, Joomla, Plone, OpenCms, Mambo, and many more are already available and it will take far less work that writing your own. Write a plug-in for whichever one you choose if some bit you need is not already available.

Use open source software written by others when you can; the rest of the time write open source software that others can use.

---

1. Both.org, What is open source?, https://www.both.org/?page_id=3085 ↩︎
2. opensource.org, The Open Source Definition (Annotated), https://opensource.org/osd-annotated ↩︎
3. Open Source Initiative, Licenses, https://opensource.org/licenses ↩︎
4. Wikipedia, Christine Peterson, https://en.wikipedia.org/wiki/Christine_Peterson ↩︎
5. Peterson, Christine, Opensource.com, How I coined the term ‘open source, https://opensource.com/article/18/2/coining-term-open-source-software ↩︎
6. Raymond, Eric S., The Art of Unix Programming, Addison-Wesley (2004), 380, ISBN 0-13-13-142901-9 ↩︎
7. Ibid. ↩︎
8. Opensource.com, What is The Open Organization, https://opensource.com/open-organization/resources/what-open-organization ↩︎
9. Whitehurst, Jim, The Open Organization, Harvard Business Review Press (June 2, 2015), ISBN 978-1625275271 ↩︎
10. Opensource.com, Appreciating the full power of open, https://opensource.com/open-organization/16/5/appreciating-full-power-open ↩︎
11. See the Annotated Open Source Definition in this article. ↩︎
12. Fogel, Kark, Producing Open Source Software, https://producingoss.com/en/index.html ↩︎