5

Open Source and Free Software

David J. Whitten

INTRODUCTION

It is estimated that, worldwide, over 78% of companies use open source software (OSS). In 2010, this number was only 42% (Vaughn-Nichols, 2015). More than 350 million people are estimated to regularly use these products and thousands of enterprises and organizations use open source code (Anderson & Dare, 2009) ); free and open source software are increasingly recognized as a reliable alternative to proprietary products. Most nurses use open source and free software (OSS/FS) on a daily basis (Table 5.1), often without even realizing it. When searching the Web, the acronym FLOSS is used approximately 10 times as often as the term OSS/FS; FLOSS stands for free, libre, and open source software. Since dental floss is a common item on the Web, searches should include “open source software” as well as FLOSS. Everybody who sends an e-mail or uses the Web uses FLOSS most of the time, as the majority of the hardware and software that allows the Internet to function (Web servers, file transmission protocol [FTP] servers, and mail systems) are FLOSS. As Vint Cerf, Google’s “Chief Internet Evangelist” who is seen by many as the “father of the Internet,” has stated, the Internet “is fundamentally based on the existence of open, non-proprietary standards” (Openforum Europe, 2008). Many popular Web sites are hosted on Apache (FLOSS) servers, and increasingly people are using FLOSS Web browsers such as Chrome and Firefox. While in the early days of computing software was often free, free software (as defined by the Free Software Foundation [FSF]; Table 5.1) has existed since the mid-1980s, the ‘GNU is Not Unix’ Project (GNU)/Linux operating system (Table 5.1) has been developing since the early 1990s, and the open source initiative (OSI) (Table 5.2) definition of open source software has existed since the late 1990s. It is only more recently that widespread interest has begun to develop in the possibilities of FLOSS within health, healthcare, and nursing, and within nursing informatics (NI) and health informatics.

In healthcare facilities in many countries, in both hospital and community settings, healthcare information technology (IT) initially evolved as a set of facility-centric tools to manage patient data. This was often primarily for administrative purposes, such that there now exists, in many facilities, a multitude of different, often disconnected, systems, with modern hospitals often using more than 100 different software applications. One of the major problems that nurses and all other health professionals currently face is that many of these applications and systems do not interface well for data and information exchange to benefit patient care. A major challenge in all countries is to move to a more patient-centric system, integrating facilities such as hospitals, physicians’ offices, and community or home healthcare providers, so that they can easily share and exchange patient data and allow collaborative care around the patient. In 2010, 84% of hospitals were keeping paper records versus using software. The healthcare industry is the only industry that needs to be paid to get them to switch to using software to store information—$20 billion spent between 2010 and 2013 to get us to 60% of hospitals storing information electronically (Barrata, 2014). Supporters of FLOSS approaches believe that only through openness, in respect to open standards and access to applications’ source codes, the user is in control of the software and able to adapt the application to local needs, and prevent problems associated with vendor lock-in (Murray, Wright, Karopka, Betts, & Orel, 2009).

However, many nurses have only a vague understanding of what free and open software is and how these possible applications are relevant to nursing and nursing informatics. This chapter aims to provide a basic understanding of the issues, as it is only through being fully informed about the relative merits, and potential limitations, of the range of proprietary software and FLOSS, that nurses can make informed choices, whether they are selecting software for their own personal needs or involved in procurements for large healthcare organizations. This chapter will provide an overview of the background to FLOSS, explaining the differences and similarities between open source and free software, and introducing some particular applications such as the GNU/Linux operating system. Licensing issues will be addressed, as they are one of the major issues that exercise the minds of those with responsibility for decision-making, and issues such as the interface of FLOSS and proprietary software, or use of FLOSS components are not fully resolved. Some commonly available and healthcarespecific applications will be introduced, with a few examples being discussed. Some of the organizations working to explore the use of FLOSS within healthcare and nursing, and some additional resources, will be introduced.

The chapter will conclude with a case study of what many consider the potential “mother of FLOSS healthcare applications,” Veterans Health Information System and Technology Architecture (VistA) (Tiemann, 2004), and recent moves to develop fully FLOSS versions.

FLOSS—THE THEORY

Background

While we use the term open source (and the acronym FLOSS) in this chapter, we do so loosely (and, some would argue, incorrectly) to cover several concepts, including OSS, FS, and GNU/Linux. Each of these concepts and applications has its own definition and attributes (Table 5.2). While the two major philosophies in the FLOSS world, i.e., the free software foundation (FSF) philosophy and the open source initiative (OSI) philosophy, are today often seen as separate movements with different views and goals, their adherents frequently work together on specific practical projects (FSF, 2010a).

The key commonality between FSF and OSI philosophies is that the source code is made available to the users by the programmer. FSF and OSI differ in the restrictions placed on redistributed source code. FSF is committed to no restrictions, so that if you modify and redistribute free software, as a part or as a whole of aggregated software, you are not allowed to place any restrictions on the openness of the resultant source code (Wong & Sayo, 2004). The difference between the two movements is said to be that the free software movement’s fundamental issues are ethical and philosophical, while for the open source movement, the issues are more practical than ethical ones; thus, the FSF asserts that open source is a development methodology, while free software is a social movement (FSF, 2010a).

FLOSS is contrasted with proprietary software. FLOSS software can be available for commercial use, commercial development, and commercial distribution. The two terms commercial and proprietary are often conflated but strictly need to be separated. Proprietary software is that on which an individual or company holds the exclusive copyright, at the same time restricting other people’s access to the software’s source code and/or the right to copy, modify, and study the software (Sfakianakis, Chronaki, Chiarugi, Conforti, & Katehakis, 2007). Commercial software is developed by businesses or individuals with the aim of making money from its licensing and use. Most commercial software is proprietary, but there is commercial free software, and there is noncommercial nonfree software.

FLOSS should also not be confused with freeware or shareware. Freeware is software offered free of charge, but without the freedom to modify the source code and redistribute the changes, so it is not free software (as defined by the FSF). Shareware is another form of proprietary software, which is offered on a “try before you buy” basis. If the customer continues to use the product after a short trial period, or wishes to use additional features, he or she is required to pay a specified, usually nominal, license fee. Shareware authors make a separate decision whether they want to release their source code.

Free Software Definition

Free software is defined by the FSF in terms of four freedoms for software users: to have the freedom to use, study, redistribute, and improve the software in any way they wish. A program is only free software, in terms of the FSF definition, if users have all of these freedoms (see Table 5.2). The FSF believes that users should be free to redistribute copies, either with or without modifications, either gratis or through charging a fee for distribution, to anyone, anywhere without a need to ask or pay for permission to do so (FSF, 2010a).

Confusion around the use and meaning of the term free software arises from the multiple meanings of the word free in the English language. In other languages, there is less of a problem, with different words being used for the “freedom” versus “no cost” meanings of free, for example the French terms libre (freedom) software versus gratis (zero price) software. The “free” of free software is defined in terms of liberty, not price, thus to understand the concept, the common distinction is in thinking of free as in free speech, not as in free beer (FSF, 2010b). Acronyms such as FLOSS (free/libre/OSS—a combination of the above two terms emphasizing the “libre” meaning of the word free) or FLOSS are increasingly used, particularly in Europe, to overcome this issue (International Institute of Infonomics, 2005).

Open Source Software Definition

Open source software is any software satisfying the open software initiative’s definition (OSI, n.d.). The open source concept is said to promote software reliability and quality by supporting independent peer review and rapid evolution of source code as well as making the source code of software freely available. In addition to providing free access to the programmer’s instructions to the computer in the programming language in which they were written, many versions of open source licenses allow anyone to modify and redistribute the software.

The open source initiative (OSI) has created a certification mark, “OSI certified.” In order to be OSI certified, the software must be distributed under a license that guarantees the right to read, redistribute, modify, and use the software freely (OSI, n.d.). Not only must the source code be accessible to all, but also the distribution terms must comply with 10 criteria defined by the OSI (see Table 5.2 for full text and rationale).

FLOSS Development Models and Systems

FLOSS has existed as a model for developing computer applications and software since the 1950s (Waring & Maddocks, 2005); at that time, software was often provided free (gratis), and freely, when buying hardware (Murray et al., 2009). The freedoms embodied within FLOSS were understood as routine until the early 1980s with the rise of proprietary software. However, it was only in the 1980s that the term free software (Stallman, 2002) and in the 1990s that the term open source software, as we recognize them today, came into existence to distinguish them from the proprietary models.

Richard Stallman advocates free software as an ethical imperative. He believes the software needed to make a program that is used by someone should always be available. “Free software” adheres to the four software freedoms. These are numbered starting with zero as computers internally do. Freedom 0 ensures that users were free to use software in any way as they saw fit. Freedom 1 users are free to study its source code, and they are free to modify software for their own purposes. Freedom 2 means that a user can redistribute copies to help others. Finally, Freedom 3 means a user is free to share his or her modified program with others (Finley, 2019) (GNU Operating System, 2019).

The way that software is developed using models of FLOSS contributes to their distinctions from proprietary software. Shaw et al. (2002) state that as FLOSS is “developed and disseminated in an open forum,” it “revolutionizes the way in which software has historically been developed and distributed.” A similar description, in a UK government report, emphasizes the open publishing of source code and that development is often largely through voluntary efforts (Peeling & Satchell, 2001).

While FLOSS is often described as being developed by voluntary efforts, this description may belie the professional skills and expertise of many of the developers. Many of those providing voluntary efforts are highly skilled programmers who contribute time and efforts freely to the development of FLOSS. In addition, many FLOSS applications are coordinated through formal groups. For example, the Apache Software Foundation (www.apache.org) coordinates development of the Apache hypertext transfer protocol (HTTP) server and many other products.

FLOSS draws much of its strength from the collaborative efforts of people who work to improve, modify, or customize programs, believing they must give back to the FLOSS community so others can benefit from their work. The FLOSS development model is unique, although it bears strong similarities to the openness of the scientific method, and is facilitated by the communication capabilities of the Internet that allow collaboration and rapid sharing of developments, such that new versions of software can often be made available on a daily basis.

The most well-known description of the distinction between FLOSS and proprietary models of software development lies in Eric Raymond’s famous essay, “The Cathedral and the Bazaar” (Raymond, 2001). Cathedrals, Raymond says, were built by small groups of skilled workers and craftsmen to carefully worked out designs. The work was often done in isolation, and with everything built in a single effort with little subsequent modification. Much software, in particular proprietary software, has traditionally been built in a similar fashion, with groups of programmers working to strictly controlled planning and management, until their work was completed and the program released to the world. In contrast, FLOSS development is likened to a bazaar, growing organically from an initial small group of traders or enthusiasts establishing their structures and beginning businesses. The bazaar grows in a seemingly chaotic fashion, from a minimally functional structure, with later additions or modifications as circumstances dictate. Likewise, most FLOSS development starts off highly unstructured, with developers releasing early, minimally functional code and then modifying their programs based on feedback. Other developers may then join, and modify or build on the existing code; over time, an entire operating system and suite of applications develops, evolves, and improves continuously.

The bazaar method of development is said to have been proven over time to have several advantages, including the following:

•   Reduced duplication of efforts through being able to examine the work of others and through the potential for large numbers of contributors to use their skills. As Moody (2001) describes it, there is no need to reinvent the wheel every time as there would be with proprietary products whose source code cannot be used in these ways

•   Building on the work of others, often by the use of open standards or components from other applications

•   Better quality control; with many developers working on a project, code errors (bugs) are uncovered quickly and may be fixed even more rapidly (often termed Linus’ Law, “given enough eyeballs, all bugs are shallow” [Raymond, 2001])

•   Reduction in maintenance costs; costs, as well as effort, can be shared among potentially thousands of developers (Wong & Sayo, 2004).

CHOOSING FLOSS OR NOT

Proposed Benefits of FLOSS

FLOSS has been described as the electronic equivalent of generic drugs (Bruggink, 2003; Goetz, 2003; Surnam & Diceman, 2004). In the same way as the formulas for generic drugs are made public, so FLOSS source code is accessible to the user. Any person can see how the software works and can make changes to the functionality. It is also suggested by many that there are significant similarities between the open source ethos and the traditional scientific method approach (supported by most scientists and philosophers of science), as this latter method is based on openness, free sharing of information, and improvement of the end result. As FLOSS can be obtained royalty free, it is less expensive to acquire than proprietary alternatives. This means that FLOSS can transform healthcare in developing countries just as the availability of generic drugs have.

This is only one of several benefits proposed for FLOSS, with further benefits including lack of the proprietary lock-in that can often freeze out innovation, and with FLOSS projects supporting open standards and providing a level playing field, expanding the market by giving software consumers greater choice (Dravis, 2003).

Besides the low cost of FLOSS, there are many other reasons why public and private organizations are adopting FLOSS, including security, reliability, and stability, and developing local software capacity. Many of these proposed benefits have yet to be demonstrated or tested extensively, but there is growing evidence for many of them, and we will address some of them in the next section.

Issues in FLOSS

There are many issues in the use of FLOSS that we cannot address here in detail. It is important that nurses who are exploring, using, or intending to use FLOSS receive a basic introduction with pointers to additional resources. Generally, decision-making is facilitated through an active awareness of the issues. This section is intended to support interested nurses in their decision-making. The issues that we introduce include, not necessarily in any order of importance:

•   Licensing

•   Copyright and intellectual property

•   Total cost of ownership (TCO)

•   Support and migration

•   Business models

•   Security and stability

Licensing and copyright will be addressed in the next section, but the other issues will be covered briefly here, before concluding the section with a short description of one possible strategy for choosing FLOSS (or other software, as the issues are pertinent to any properly considered purchase and implementation strategy).

Total Cost of Ownership. Total cost of ownership (TCO) is the sum of all the expenses directly related to the ownership and use of a product over a given period of time. The popular myth surrounding FLOSS is that it is always free as in free of charge. This is true to an extent, as most FLOSS distributions (e.g., Ubuntu [www.ubuntu.com], Red Hat [www.redhat.com], SuSE [www.opensuse.org], Debian [www.debian.org]) can be obtained at no charge from the Internet; however, copies can also be sold.

It is part of the definition of open source/free software that an application can’t charge a licensing fee for usage. This means that on a licensing cost basis FLOSS applications are almost always cheaper than proprietary software. However, licensing costs are not the only costs of a software package or infrastructure. Personnel costs, hardware requirements, migration time, changes in staff efficiency, and training costs are among other costs that should be considered as well. Without careful consideration of all of this information, it is impossible to really know which software solutions are the most cost effective. The real costs with FLOSS center around the configuration of the software and support for the software as well as training people to use the software (examples are provided in Wheeler, 2007 and Wong & Sayo, 2004). These costs are also included by proprietary software vendors, but not necessarily detailed as such.

Wheeler (2007) lists the main reasons why FLOSS comes out cheaper, including the following:

•   FLOSS costs less to initially acquire, because there are no license fees.

•   Upgrade and maintenance costs are typically far less due to improved stability and security.

•   FLOSS can often use older hardware more efficiently than proprietary systems, yielding

•   smaller hardware costs and sometimes eliminating the need for new hardware.

•   Increasing numbers of case studies using FLOSS show it to be especially cheaper in server environments.

Support and Migration. It can be costly to make an organization-wide change from proprietary software to open source software. Prudently, there are times the costs will outweigh the benefits. When many FLOSS packages were first created, they do not have the same level of documentation, training, and support resources as their common proprietary equivalents. Depending on the extent of adoption, some FLOSS packages did not fully interface with other proprietary software. This is important as an organization may need to share information with other organizations that depend on proprietary software (e.g., patient data exchange between different healthcare provider systems). In recent years, this situation has changed. Proprietary vendors may not provide backward compatibility with previous versions of their own systems to force consumers to upgrade to the newest version. Once a FLOSS package incorporates methods to access older versions, there is little reason to remove them, so they are more compatible than the original system (Apache Open Office Migration Guide, 2018).

Migrating from one platform to another should be handled using a careful and phased approach. The European Commission has published a document entitled the “IDA Open Source Migration Guidelines” (European Communities, 2003) that provides detailed suggestions on how to approach migration. These include the need for a clear understanding of the reasons to migrate, ensuring that there is active support for the change from IT staff and users, building up expertise and relationships with the open source movement, starting with noncritical systems, and ensuring that each step in the migration is manageable.

Security and Stability. While there is no perfectly secure operating system or platform, factors such as development method, program architecture, and target market can greatly affect the security of a system and consequently make it easier or more difficult to breach. There are some indications that FLOSS systems are superior to proprietary systems in this respect, and the security aspect has already encouraged many public organizations to switch or to consider switching to FLOSS solutions. The French Customs and Indirect Taxation authority, for example, migrated to Red Hat Linux largely because of security concerns with proprietary software (International Institute of Infonomics, 2005).

Among reasons often cited for the better security record in FLOSS is the availability of the source code (making it easier for vulnerabilities to be discovered and fixed). Many FLOSS have a proactive security focus, so that before features are added, the security considerations are accounted for and a feature is added only if it is determined not to compromise system security. In addition, the strong security and permission structure inherent in FLOSS applications that are based on the Unix model are designed to minimize the possibility of users being able to compromise systems (Wong & Sayo, 2004). FLOSS systems are well known for their stability and reliability, and many anecdotal stories exist of FLOSS servers functioning for years without requiring maintenance. However, quantitative studies are more difficult to come by (Wong & Sayo, 2004).

Security of information is vitally important within the healthcare domain, particularly in relation to any process that might access a patient record, maintain and store the record, and transmit a patient records between two organizations. The advocates of FLOSS suggest that it can provide increased security over proprietary software, and a report to the UK government saw no security disadvantage in the use of FLOSS products (Peeling & Satchell, 2001). According to the same report, even the US government’s National Security Agency (NSA) supports a number of FLOSS security-related projects. The NSA actually maintains a Web site at https://code.nsa.gov to make its code available. Ghidra, a software reverse engineering (SRE) suite of tools developed by NSA’s Research Directorate in support of the Cybersecurity mission, has also been released (Ghidra, 2019). Stanco (2001) considers that the reason the NSA thinks that free software can be more secure is that when anyone and everyone can inspect source code, hiding backdoors into the code can be very difficult.

In considering a migration to FLOSS, whether it is for everyday office and productivity uses or for health-specific applications, there are some commonly encountered challenges that one may face. These challenges have traditionally been seen as including the following:

•   There is a relative lack of mature FLOSS desktop applications.

•   Many FLOSS tools are not user-friendly and have a steep learning curve.

•   File sharing between FLOSS and proprietary applications can be difficult.

As FLOSS applications have matured in recent years, and the user community grown, many of these challenges have been largely overcome, such that today, many OSS/FA applications are indistinguishable from proprietary equivalents for many users in terms of functionality, ease of use, and general user-friendliness.

Choosing the Right Software: The Three-Step Method for FLOSS Decision-Making. Whether one is working with FLOSS or proprietary tools, choosing the right software can be a difficult process, and a thorough review process is needed before making a choice. A simple three-step method for FLOSS decision-making can guide organizations through the process and works well for all kinds of software, including server, desktop, and Web applications (Surman & Diceman, 2004).

Step 1. Define the needs and constraints. Needs must be clearly defined, including those of the organization and of individual users. Other specific issues to consider include range of features, languages, budget (e.g., for training or integration with other systems), the implementation time frame, compatibility with existing systems, and the skills existing within the organization.

Step 2. Identify the options. A short list of three to five software packages that are likely to meet the needs can be developed from comparing software packages with the needs and constraints listed in the previous phase. There are numerous sources of information on FLOSS packages, including recommendations of existing users, reviews, and directories (e.g., OSDir.com and OpenSourceCMS.com.) and software package sites that contain promotional information, documentation, and often demonstration versions that will help with the review process.

Step 3. Undertake a detailed review. Once the options have been identified, the final step is to review and choose a software package from the short list. The aim here is to assess which of the possible options will be best for the organization. This assessment can be done by rating each package against a list of criteria, including quality, ease of use, ease of migration, software stability, compatibility with other systems being used, flexibility and customizability, user response, organizational buy-in, evidence of widespread use of the software, and the existence of support mechanisms for the software’s use. Hands-on testing is key and each piece of software should be installed and tested for quality, stability, and compatibility, including by a group of key users so as to assess factors such as ease of use, ease of migration, and user response.

Making a Decision. Once the review has been completed, if two packages are close in score, intuition about the right package is probably more important than the actual numbers in reaching a final decision.

Examples of Adoption or Policy Regarding FLOSS

FLOSS has moved beyond the closed world of programmers and enthusiasts. Governments around the world have begun to take notice of FLOSS and have launched initiatives to explore the proposed benefits. There is a significant trend toward incorporating FLOSS into procurement and development policies, and there are increasing numbers of cases of FLOSS recognition, explicit policy statements, and procurement decisions. Many countries, regions, and authorities now have existing or proposed laws mandating or encouraging the use of FLOSS (Wong & Sayo, 2004).

A survey from the MITRE Corporation (2003) showed that the US Department of Defense (DoD) at that time used over 100 different FLOSS applications. The main conclusion of their study (The MITRE Corporation, 2003) was that FLOSS software was used in critical roles, including infrastructure support, software development, and research, and that the degree of dependence on FLOSS for security was unexpected. In 2000, the (US) President’s Information Technology Advisory Committee (PITAC, 2000) recommended that the US federal government should encourage FLOSS use for software development for high-end computing. In 2002, the UK government published a policy (Office of the e-Envoy, 2002), since updated, that it would “consider OSS solutions alongside proprietary ones in IT procurements” (p. 4), “only use products for interoperability that support open standards and specifications in all future IT developments” (p. 4), and explore the possibility of using FLOSS as the default exploitation route for government-funded research and development (R&D) software. Similar policies have been developed in Denmark, Sweden, and The Netherlands (Wong & Sayo, 2004).

European policy encouraging the exploration and use of FLOSS has been consequent on the European Commission’s eEurope2005—An Information Society for All initiative (European Communities, 2004) and its predecessors, such as the i2010 strategy (European Communities, 2005) with their associated action plans. These have encouraged the exchange of experiences and best practice examples so as to promote the use of FLOSS in the public sector and e-government across the European Commission and member states of the European Union (EU). In addition, the EU has funded R&D on health-related FLOSS applications as well as encouraged open standards and FLOSS where appropriate in wider policy initiatives.

In other parts of world, Brazil and Peru are among countries whose governments are actively moving toward FLOSS solutions, for a variety of reasons, including ensuring long-term access to data through the use of open standards (i.e., not being reliant on proprietary software that may not, in the future, be interoperable) and cost reduction. The South African government has a policy favoring FLOSS, Japan is considering moving e-government projects to FLOSS, and pro-FLOSS initiatives are in operation or being seriously considered in Taiwan, Malaysia, South Korea, and other Asia Pacific countries.

OPEN SOURCE LICENSING

While FLOSS is seen by many as a philosophy and a development model, it is also important to consider it as a licensing model (Leong, Kaiser, & Miksch, 2007; Sfakianakis et al., 2007). In this section, we can only briefly introduce some of the issues of software licensing as they apply to FLOSS, and will include definitions of licensing, some of the types of licenses that exist, and how licenses are different from copyright. While we will cover some of the legal concepts, this section cannot take the place of proper legal counsel, which should be sought when reviewing the impact of licenses or contracts. Licensing plays a crucial role in the FLOSS community, as it is “the operative tool to convey rights and redistribution conditions” (Anderson & Dare 2009, p. 101).

Licensing is defined by Merriam-Webster (2010) as giving the user of something permission to use it; in the case here, that something is software. Most software comes with some type of licensing, commonly known as the end-user licensing agreement (EULA). The license may have specific restrictions related to the use, modification, or duplication of the software. The Microsoft EULA, for example, specifically prohibits any kind of disassembly, inspection, or reverse engineering of software (Zymaris, 2003). There are some countries especially in Europe where this is unenforceable, as the laws specifically give this right to all. This law is intended to support interoperability (Directive 20009/24/EC of the European Parliament, 2009). Most licenses also have statements limiting the liability of the software manufacturer toward the user in case of possible problems arising in the use of the software.

From this working definition of licensing, and some examples of what can be found in a EULA, we can examine copyright. While licensing gives a person the right to use software, with restrictions in some cases, copyright is described as the exclusively granted or owned legal right to publish, reproduce, and/or sell a work (Merriam-Webster, 2010). The distinctions between ownership of the original work and rights to use it are important, and there are differences in the way these issues are approached for proprietary software and FLOSS. For software, the work means the source code or statements made in a programming language. In general, the person who creates a work owns the copyright to it and has the right to allow others to copy it or deny that right. In some cases the copyright is owned by a company with software developers working for that company, usually having statements in their employment contracts that assign copyright of their works to the company. In the case of FLOSS, contributors to a project will often assign copyright to the managers of the project.

While in the case of proprietary software, licensing is generally dealt with in terms of restrictions (i.e., what the user is not allowed to do; for FLOSS, licensing is seen in terms of permissions, rights, and encouraging users to do things). Most software manufacturing companies hold the copyright for software created by their employees. In financial terms, these works are considered intellectual property, meaning that they have some value. For large software companies, such as Oracle or Microsoft, intellectual property may be a large part of their capital assets. The open source community values software differently, and FLOSS licenses are designed to facilitate the sharing of software and to prevent an individual or organization from controlling ownership of the software. The individuals who participate in FLOSS projects generally do realize the monetary value of what they create; however, they feel it is more valuable if the community at large has open access to it and is able to contribute back to the project.

A common misconception is that if a piece of software, or any other product, is made freely available and open to inspection and modification, then the intellectual property rights of the originators cannot be protected, and the material cannot be subject to copyright. The open source community, and in particular the FSF, has adopted a number of conventions, some built into the licenses, to protect the intellectual property rights of authors and developers. One form of copyright, termed copyleft to distinguish it from commercial copyright terms, works by stating that the software is copyrighted and then adding distribution terms. These are a legal instrument giving everyone the rights to use, modify, and redistribute the program’s code or any program derived from it but only if the distribution terms are unchanged. The code and the freedoms become legally inseparable, and strengthen the rights of the originators and contributors (Cox, 1999; FSF, 2010c).

Types of FLOSS Licenses

A large and growing number of FLOSS licenses exists. Table 5.3 lists some of the more common ones, while fuller lists of various licenses and terms can be found in Wong and Sayo (2004). The OSI Web site currently lists over 60 (www.opensource.org/licenses), while the FSF Web site lists over 40 general public license (GPL)-compatible free software licenses (www.gnu.org/licenses/licenselist.html). The two main licenses are the GNU GPL and the Berkeley system distribution (BSD)-style licenses. It is estimated that about 75% of FLOSS products use the GNU GPL (Wheeler, 2010), and this license is designed to ensure that user freedoms under the license are protected in perpetuity, with users being allowed to do almost anything they want to a GPL program. The conditions of the license primarily affect the user when it is distributed to another user (Wong & Sayo, 2004). BSD-style licenses are so named because they are identical in spirit to the original license issued by the University of California, Berkeley. These are among the most permissive licenses possible, and essentially permit users to do anything they wish with the software, provided the original licensor is acknowledged by including the original copyright notice in source code files and no attempt is made to sue or hold the original licensor liable for damages (Wong & Sayo, 2004).

Here is an example from the GNU GPL that talks about limitations:

16. Limitation of Liability. In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or redistribute the program as permitted above, be liable to you for damages, including any general, special, incidental, or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages. (FSF, 2007, para. 16)

Like the Microsoft EULA, there are limitations relating to liability in the use of the software and damage that may be caused, but unlike the Microsoft EULA, the GPL makes it clear what you can do with the software. In general, you can copy and redistribute it, sell or modify it. The restriction is that you must comply with the parts of the license requiring the source code to be distributed as well. One of the primary motivations behind usage of the GPL in FLOSS is to ensure that once a program is released as FLOSS, it will remain so permanently. A commercial software company cannot legally modify a GPL program and then sell it under a different proprietary license (Wong & Sayo, 2004).

In relation to using FLOSS within a healthcare environment, as with use of any software, legal counsel should be consulted to review any license agreement made; however, in general terms, when using FLOSS there are no obligations that would not apply to using any copyrighted work. Someone cannot legally take a body of work, the source code, and claim it as their own. The licensing terms must be followed as with any other software.

Perhaps the most difficult issue comes when integrating FLOSS components into a larger infrastructure, especially where it may have to interface with proprietary software. Much has been said about the “viral” nature of the open source license, which comes from the requirement of making source code available if the software is redistributed. Care must be taken that components utilized in creating proprietary software either utilize FLOSS components in such a way as to facilitate distribution of the code or avoid their use. If the component cannot be made available without all of the source code being made available, then the developer has the choice of not using the component or making the entire application open source. Some projects have created separate licensing schemes to maintain the FLOSS license and provide those vendors that wish to integrate components without making their product open source. MySQL, a popular open source database server, offers such an option (Table 5.3).

Licensing is a complex issue; we have only touched on some of the points, but in conclusion, the best advice is always to read the license agreement and understand it. In the case of a business decision on software purchase or use, one should always consult legal counsel; however, one should remember that FLOSS licenses are more about providing freedom than about restricting use.

FLOSS APPLICATIONS

Many FLOSS alternatives exist to more commonly known applications. Not all can be covered here, but if one thinks of the common applications that most nurses use on a daily basis, these are likely to include the following:

•   Operating system

•   Web browser

•   E-mail client

•   Word processing or integrated office suite

•   Presentation tools

For each of these, FLOSS applications exist. Using FLOSS does not require an all or nothing approach (Dravis, 2003) and much FLOSS can be mixed with proprietary software and a gradual migration to FLOSS is an option for many organizations or individuals. However, when using a mixture of FLOSS and proprietary or commercial software, incompatibilities can be uncovered and cause problems whose severity must be assessed. Many FLOSS applications have versions that will run on non-FLOSS operating systems, so that a change of operating system, for example, to one of the many distributions of Linux, is not necessarily needed. Most FLOSS operating systems now have graphical interfaces that look very similar to Windows or Apple interfaces.

Operating Systems: GNU/Linux

A GNU/Linux distribution (named in recognition of the GNU Project’s significant contribution, but often just called Linux) contains the Linux kernel at its heart and all the FLOSS components required to produce full operating system functionality. GNU/Linux is a term that is increasingly used by many people to cover a distribution of operating systems and other associated software components. However, Linux was originally the name of the kernel created by Linus Torvalds in 1991, which has grown from a one-man operation to now having over 200 maintainers representing over 300 organizations.

A kernel is the critical center program code for an operating system. The kernel controls central processing unit (CPU) usage, memory management, and hardware devices. The kernel also is necessary to allow communication between different programs which run on the operating system. Since the kernel influences performance and limits or includes the hardware platforms that the FLOSS system can run on, it is important that its source code is freely available. The Linux kernel has been ported to run on a vast variety of hardware, from huge computers that fill special air conditioned rooms such as mainframes and supercomputers, through more common consumer computers such as desktop, laptop, and tablet machines. The Linux kernel has even been converted to run on mobile phones and other mobile devices. The Linux kernel is FLOSS, licensed under the GNU GPL. An interesting development in recent years has been running the open source operating system on physical hardware that has been built using the hardware specification for an Open Processor Core as a form of open source (Katz, 2018)

Over time, individuals and companies began distributing Linux with their own choice of FLOSS packages bound around the Linux kernel; the concept of the distribution was born, which contains much more than the kernel (usually only about 0.25% in binary file size of the distribution). There is no single Linux distribution, and many commercial distributions and freely available variants exist, with numerous customized distributions that are targeted to the unique needs of different users (Table 5.4). While all distributions contain the Linux kernel, some contain only FLOSS materials, while others additionally contain non-FLOSS components, and the mix of FLOSS and other applications included and the configurations supported vary. The Debian GNU/Linux distribution is one of the few distributions that is committed to including only FLOSS components (as defined by the open source initiative) in its core distribution.

Stay updated, free articles. Join our Telegram channel

Join