Using Open Source Software

Introduction

What is Open Source Software (OSS)?

Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.
The Open Source Initiative (OSI) is a non-profit corporation formed to educate about and advocate for the benefits of open source and to build bridges among different constituencies in the open-source community.

According to OSI, open source software (OSS) is defined as follows:

OSI Logo

Free redistribution of code
Source code availability
Allows derived works
Allows integrity of the author’s source code
No discrimination against persons or groups
No discrimination against fields of endeavor
Distribution of license with code
License must not be specific to a product
License must not restrict other software
License must be technology-neutral

In order to differentiate from other concepts, some related terms are explained here to separate them from OSS:

Term	Description
Proprietary	Proprietary software, also known as non-free software or closed-source software, is computer software for which the software author reserves some licensing rights to use, modify, share modifications, or share the software. It is the opposite of open-source software.
Freeware	Freeware just means software that is free, ie. does not cost anything. Most of the Freeware is proprietary and there is no common copyright definition.
Public Domain	This is every work to which no exclusive intellectual property rights apply. Those rights may have expired, been forfeited, expressly waived, or may be inapplicable.
COTS	Commercial off-the-shelf (COTS) software and services are built and delivered usually from a third party vendor. COTS can be purchased, leased or licensed.

Importance of OSS

Today, the advantages of using OSS in business applications are not disputed anymore. Several studies by the EU (last 12.10.2021) lists many important economic impacts of OSS such as:

OSS applications are first to third rung products in terms of market share in several markets, including web servers, server operating systems, desktop operating systems, web browsers, databases, e-mail and other ICT infrastructure systems.
OSS market penetration is also high. In the public sector, Europe has particularly high penetration. In the private sector, OSS adoption is driven by medium- and large-sized firms.
The existing base of quality OSS applications would cost firms almost Euro 12 billion to reproduce internally. This code base has been doubling every 18-24 months over the past eight years, and this growth is projected to continue for several more years.
This existing base of OSS software represents a lower bound of about 131’000 real person-years of effort that has been devoted exclusively by programmers. Annualized and adjusted for growth this represents at least Euro 800 million in voluntary contribution from programmers alone each year.
Firms have invested an estimated Euro 1.2 billion in developing OSS software that is made freely available. Such firms represent in total at least 565’000 jobs and Euro 263 billion in annual revenue.

A huge number of Open Source projects exist and this number is growing rapidly. SourceForge, a product of VA Software, alone hosts over 170’000 open-source projects with over one million registered users. It is also where multitudes of open-source developers and users go to find software.
However, in the commercial world, two main obstacles to an even broader usage of OSS seem to exist:

Support
Typically, an OSS license excludes any warranties and liabilities for defects in the source code. This is compensated by broader usage rights as well as full transparency through the availability of the source code. However, this situation requires more technical knowledge on the user’s side.
Legal Risks
A multitude of different OSS licenses, rare case law and some few prominent legal cases such as SCO vs. IBM resulted in uncertainties whether the usage of OSS contains legal risks that outweigh its economic benefits.

This guideline defines the strategies applied by PAR Ordering to mitigate the legal risks when using open source software.

Classification of OSS Licenses

Open source software is fundamentally based on copyright law. As with the holder of any copyright, the copyright holder for a piece of open source software gets to elect which rights he/she will grant to others. Open source authors simply choose to grant more rights than proprietary vendors and the set of granted rights makes the difference between different OSS licenses.

OSI maintains the definition of open-source software and certifies licenses that adhere to it. However, it alone lists more than 70 different licenses. There are initiatives in order to consolidate the amount of licenses. But in practice, each developer is free to invent his own license.
Fortunately, only about half a dozen of licenses are in wide use.

Major categories of OSS Licenses

Downloading and using open source software alone is no threat. However, copyright and license considerations become critical if source code is being modified, packaged in another solution and distributed.

Based on this distinction, open source licenses can be divided into three major categories:

Category	Description	Example Licenses
permissive	Permissive licenses allow developers basically to do anything they want with the source code. Even modifying the code and distributing it within a package is allowed. The license does not demand to be shipped with the package.	BSD, MIT, Apache, OpenSSL
weak copyleft	Weak copyleft licenses enable the coexistence of open and proprietary software in a package. Modifications in the OSS source files fall under the the same OSS license (viral effect), whereas additional files added to the OSS projects do not need to be published under the same OSS license and can even be proprietary or commercial. Consequently, they weaken they restrict the viral feature to changes on the source code of the OSS library.	MPL (Mozilla) EPL (Eclipse) LGPL v3.0 CPL (Common Public)
strong copyleft	All modifications to OSS source code fall under the same OSS license (viral effect). Also all derived work (e.g. static linking against a GPL licensed library) fall under the GPL. There seems to be some dispute whether dynamic linking also results in 'derived work'. Users who use only GPL binaries are not affected at all by the viral property of the license, e.g. Linux, Emacs text editor, GNU C compiler etc.	GPL v3.0, LGPL <= 2.1

Recommendations for using OSS licenses

Do not permit the uncontrolled importation of software onto company computers

Do not permit employees to download freeware, shareware, or open source software onto company computers without first clearing the license terms with the legal department. At the same time, bar the use of proprietary software except to the extent that the company can account for the permitted licenses. In other words, know what you are putting on your machines, otherwise you expose your company to risk.

PAR Ordering's development guidelines stipulate a lifecycle process of a software component, be it a customer project or an OSS component to be embedded into a project. In order to use a new OSS component, the developer and his code must go through a defined review process. The analysis of the OSS license is part of this review process. This is to ensure that a new OSS product adheres to company policies as well as to stop the proliferation of a multitude of products covering the same requirements.

Any approved 3rd party software component (be it OSS or closed software) is installed in a specified file system zone (similar to a download cache) adhering to certain naming conventions. Thus we enable versioning and unique identification of all 3rd party components. PAR Ordering uses library managers such as npm (JavaScript), Maven (Java), Composer (PHP) for this purpose.

Never copy 3rd party source code directly into you project. Always use a dependency manager.

Deal with reputable software vendors with financial staying power

One of the biggest risks a company takes is adopting software that has no future. Equally true is licensing software from a company without the financial power to maintain and protect that software. Know your vendors. Know their financial strength, know their policies on licensing, know their responsiveness, and know that their software is reliable.

This recommendation equally serves in order to solve the support issue. At the same time, this is one of the biggest added values, a company like PAR Ordering can provide to its customers.

Know how the software will be used

It's one thing if Open Source is to be used as an operating system on a back office server, it is something altogether different if that same open source software is to be modified and embedded in a product. The former is not problematic; the latter may be. At the same time, make sure your IT folks are well aware of the typical proprietary restrictions which prohibit reverse engineering or modification. While some proprietary vendors may permit such activities under a special development license or a community source code license, they do not generally permit the activities under their general commercial licenses. It may be worthwhile to categorize each item of software and its permitted uses, e.g., approved for general use in executable form only, approved for use at the source code level in specialized applications or modified applications, and not approved for any use. Finally, nature of use is important in knowing whether the software will be distributed outside the company, potentially triggering open source licensing restrictions.

The following table defines the guidelines for using OSS projects under the different licenses in PAR Ordering projects and packages:

OSS Category	Usage at PAR Ordering	Explanation
permissive	ALLOWED	our favorite
weak copyleft	CONDITIONAL	avoid, because usage could lead to trouble when not properly used according to license terms
strong copyleft	FORBIDDEN	don’t use because of viral effect (would force us to open source the PAR Ordering software)

Have a means for documenting what software, and what version of that software, is in use

Knowing this information and having ready access to it will help assure licensing compliance and at the same time permit IT managers the ability to manage the IT architecture and its advancement.

Such information is used, e.g. in order to provide the same transparency in maintenance or software development contracts. The idea is that all used 3rd party components are listed within the contract. Therefore, the customer knows which OSS components are part of a delivery and he is able to match the used OSS components according to his own OSS policies.

For this purpose, PAR Ordering maintains a list of all used 3rd party components. If a developer wants to use a software component that uses a new OSS license, she needs to request this usage at the architecture guild.

Require documentation of all internal software development projects

This includes modification of open source software. Such documentation should indicate the source of any base software that is modified, all of the authors of the developed software, prior projects (both internal and with prior employers) on which such developers worked, and the identification of any known related intellectual property, particularly patents.

License Extraction

The following tools easily extract the licensing information from within the project directory.

Frontend

npm i -g license-checker
license-checker --summary

Todos

Discuss in Architecture Guild (decide/optimize process)

Add guidelines for Acknowledgment handling

formulate a KB article from this