What is open source software?

Open source software (OSS) is software for which the original authors have granted express copyright and usage permissions to allow all users to access, view, and modify the source code of these programs however they see fit and without the need to pay royalties.

This is in contrast to proprietary, closed source software, which typically requires a paid license and cannot be added to, modified, or distributed by anyone except the owner of the rights to the software.

The cost efficiency of using open source software has proven to be irresistible. Today, open source components often account for 80% or more of the code base of new applications. Virtually zero products are free from OSS somewhere along the supply chain.

OSS has a rich history and a colorful community who dedicate their time—often unpaid—to provide millions of useful libraries and programs to all for free.

The history and philosophy of open source software

Before “open source software” was a thing, there was just “free software”, and you can’t talk about the history of free software without talking about the daddy of free software himself, Richard Stallman. Eccentric founder of the Free Software Foundation (FSF) and author of the GNU Public License, known for its use of copyright law to enforce freedoms in a “viral” fashion, Stallman has been a strong advocate for free software since the 1980s. He still heads the FSF and writes on the topic of free software to this day.

Most of us think of free software as software that doesn’t necessitate an exchange of money to obtain, but “think free as in free speech, not free beer” is the mantra of free software advocates. Stallman sees a distinction between “open source” and “free” software. Though the Venn diagram of free and open source applications is basically a circle, he believes the two terms emphasize different philosophies. The FSF’s four essential freedoms are the pillars of the free software movement—and they’re not particularly interested in how much freedom free software gives businesses.

Enter the Open Source Initiative (OSI). Founded in 1998 by Bruce Perens and Eric Raymond, OSI took a more practical view of free software. For Perens and Raymond, using the term “open source” took away the political baggage clinging to “free software” and invited businesses to use and contribute to the growing number of libraries and applications that were freely available to all.  OSI may be friendlier to corporate participation in OSS, but it is still undergirded by a libertarian philosophy. Many of Stallman’s four freedoms are reflected in their 10-point definition of OSS. As things usually go with politics, most developers don’t have strong feelings one way or another about “free” versus “open source” software. You might see the more neutral acronym “FOSS” which stands for “Free and Open Source Software”, or even “FLOSS”, which stands for “Free Libre and Open Source Software”, where the “free” is back to the common meaning of “costing zero dollars”.

Prior to the early 2000s, many companies were skeptical or even downright hostile towards their developers using OSS, but the cost savings of using readily available open source components instead of using developer time to reinvent the wheel became too high to ignore. 

What is an open source license?

An open source license details the terms and conditions for using or modifying a software component. The text of the license will be included in an open source project’s distribution, either in the comments of a source code file or in a separate README file.

There are over 200 open source licenses out there in the world, but many are redundant. The OSI only recognizes about 80 unique and truly open source licenses. The vast majority of open source projects fall under just eight licenses. Not too bad. 

Learn more about those top open source licenses.

Types of open source licenses

All open source licenses fall into three broad categories:

• Strong copyleft. These licenses require that any code derived from an open source project, even if the original code is used unmodified, inherit its licensing terms. Popular copyleft licenses include the GNU and Affero GNU Public Licenses (GPL and AGPL).
• Weak copyleft. These licenses typically allow for use of an unmodified open source component without the requirement that the new project inherit its license. However, any modification to the open source component must be licensed with the original license. Popular weak copyleft licenses include the Lesser GNU Public License (LGPL), the Microsoft Public License (MsPL), and the Eclipse Public License (EPL).
• Permissive. These licenses allow developers to  use or even modify an open source component without requiring that the final application be under any particular license. Popular permissive licenses include the MIT License, The Berkeley Software Distribution licenses (BSD), and the Apache 2.0 license.

Open source compliance

Organizations that use open source code must take care to stay compliant with intellectual property (IP) law and to reduce their risk of breaches and attacks from malicious actors taking advantage of vulnerabilities in OSS.

Copyright and IP compliance

IP compliance and policy comes down largely to compatibility: whether or not the licenses of open source components are compatible with each other, and whether or not the licenses are compatible with the overall business goals of the project.

• Compatibility between licenses. Permissive open source licenses play nicely with everyone, but strong and weak copyleft licenses are usually incompatible with each other. Even if the intention is to release the final project under an open source license, components under the GPL cannot be used with components under the MsPL, for example, because both licenses require the source code of the derivative work to be licensed under that same license, with no room for dual licensing.
• Compatibility with business goals. Organizations frequently use open source components in projects that will not themselves be open source. Permissive licenses allow for this while strong copyleft licenses do not. Components with weak copyleft licenses can usually be used in closed source projects, but they must be used or linked to in particular ways laid out in the license.

Security compliance

Not all OSS projects are equal in terms of quality and security. Luckily, with the use of automated tools, developers can usually get a picture of how many serious vulnerabilities are present in a particular open source package before adding it to their projects. Many organizations put rules into place to stop developers from using components that have too many issues. We’ll go deeper into open source security in a later section.

What is an open source software policy?

OSS policies provide a team or entire organization with standards for the proper use of open source components. The goal is to maximize the benefits and impact of using these components while also addressing technical, business, and legal risks that might arise.

OSS policies begin with choosing which licenses will always be allowed, sometimes allowed (through an escalation process), or never allowed for a particular project or across all development teams.

An OSS policy will also need to contain rules for which components will be allowed or not allowed based on risk of exploitation. This is typically done by deciding the number of vulnerabilities an open source component brought onto the project can have, based on the severity of the vulnerabilities. The 100% vulnerability-free open source component is a rare bird indeed. OSS policies typically disallow any component with high or critical severity vulnerabilities, but allow for some medium and low severity vulnerabilities.

Read more about choosing a comprehensive open source compliance policy. 

Open source software security

Using OSS instead of writing code from scratch isn’t without its drawbacks. OSS quality varies widely, and many components are buggy, insecure, and inconsistently updated. Here are some important tools and considerations for addressing open source software security.

Inventories and Software bills of materials (SBOMs)

It’s impossible to watch out for vulnerabilities in products you don’t even know you have. Software inventories and SBOMs are both important for getting a big picture of your software dependencies and for compiling a list of things that need to be monitored and updated.

Learn more about the value of SBOMs.

Dependency updates

Proprietary software vendors usually push out updates, while open source projects do not necessarily do so. Support is limited in open source and will vary greatly depending on the size of a project’s community. As a result, organizations using open source components need to proactively monitor for vulnerabilities and updates to ensure that all components are promptly patched and remediated.

Automated dependency health tools like our open source tool, Mend Renovate, take a great deal of the stress of tracking and scheduling updates off of developers.

Open source vulnerability scanning

Software composition analysis (SCA) is an application security testing tool that helps manage open source components. SCA tools automatically scan your source code to identify open source components, licensing data, and known vulnerabilities.

SCA tools provide visibility into open source components and offer prioritization and automated remediation to help fix vulnerabilities. 

Here is how it works:

• Vulnerability prioritization is done automatically by weighing factors such as whether or not a vulnerability is already being exploited in the wild (KEV and public exploits), whether or not a vulnerability is likely to be exploited in the near future (EPSS), the severity of a vulnerability were it to be exploited (CVSS), and vendor-specific insights.
• Vulnerability remediation is typically done manually with tool-provided information such as the location of the vulnerability. Some tools may also offer suggestions on how the fix may impact your build. Advanced tools offer automated vulnerability remediation workflows initiated according to vulnerability policies. These policies are triggered according to vulnerability detection and severity, CVSS score, and new version releases. 

Ideally, you should look for SCA tools that seamlessly integrate into your software development life cycle. Doing so helps resolve vulnerabilities during early phases when issues are more easily and cheaply fixed.

SCA is typically used during the building process of the software development life cycle. After code is deployed, vulnerability scanners like DAST and IAST are helpful to test applications for common vulnerabilities.

Binary repository managers

Here are key benefits of using binary repositories:

• Cache local copies of open source code to ensure you use only clean and verified components
• Avoid getting affected by source code updates or changes in a different copy
• Effectively manage, approve, and track components

Current trends in open source software

While the licenses and philosophies underpinning OSS have largely stayed the same since the 1990s, the proliferation of OSS and technologies covered under open source licenses has changed greatly. Here are two trends that have popped up in recent years.

Open source for me and not for thee

To be considered true open source or free software licenses according to both OSI and Stallman, no particular use of the software or type of person using the software can be prohibited. However, that doesn’t stop developer activists from writing licenses that they call open source, but aren’t.

This is becoming especially common in licenses for AI models, where concerns about unethical use of powerful technology have moved some authors to create “responsible” licenses, but such restrictions are actually not that new. The JSON License was written in 2002 and is an MIT license with an added clause that “The Software shall be used for Good, not Evil.” This clause restricts endeavor, failing criterion 6 of the OSI OSS definition. Therefore, the JSON License is not an open source license, despite the fact that the software is available to all for free and the source code is openly available.

Government interest in open source software

Within the last few years, the US government has taken notice of the prevalence and importance of open source software. President Biden’s Cybersecurity Executive Order includes guidelines to improve the software supply chain, including the creation of SBOMs, and remediation of vulnerabilities found in OSS. The CISA Open Source Software Security Roadmap details the government organization’s plans to assist the open source community.

Conclusion

Open source software has evolved from a community-driven initiative into an industry-standard approach to software development. The open source ecosystem offers various benefits, including flexibility, cost savings, and collective intelligence in development.

Understanding and implementing an open source policy is essential for risk management, as it sets the groundwork for compliant and secure use of open source components. Open source vulnerability scanning and software composition analysis tools are critical in identifying and remedying security risks. These practices allow organizations to reap the benefits of open source software while managing potential drawbacks effectively.

Thus, the open source model is not just about freely accessible code; it’s also about setting up frameworks for responsible use and contribution to the community. By adhering to standardized procedures for license compliance, security, and code contribution, organizations can foster a robust open source environment that advances innovation and resolves software challenges efficiently.

*** This is a Security Bloggers Network syndicated blog from Mend authored by AJ Starita. Read the original post at: https://www.mend.io/blog/a-guide-to-open-source-software/