054.3 Lesson 1
Certificate: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Topic: |
054 Open Source Business Models |
Objective: |
054.3 Compliance and Risk Mitigation |
Lesson: |
1 of 1 |
Introduction
An old quip in open source says that “Free software doesn’t come for free.” While free and open source software permit great innovation and creativity, users and developers have to comply with a number of rules. This lesson covers compliance and risk in open source software.
The lesson lists basic steps that developers need to comply with licenses, the risks of using open source software, and ways of tracking and cataloguing the software the organization is using. We’ll look at how these tasks can be turned into policies and promoted by an Open Source Program Office (OSPO).
Requirements for Releasing Software Based on Open Source Components
If the organization uses software internally, free and open source software licenses impose no requirements. The organization might define its own rules to prevent vulnerabilities, make sure everyone is using the same components, or for other reasons. But that’s beyond the scope of this lesson. Any requirements that the open source licenses or the organization itself impose on the use of software should be documented, and the organization should provide training in its policies.
Even if the organization runs software on its web server and offers services with which people outside the organization interact, most free and open source software licenses impose no requirements. However, the GNU Affero Public License requires adherence to copyleft requirements for software running as a service too.
The legal requirements of each major free and open source software license have been fully explored in other lessons, so this section just offers a list of actions that developers and managers should take to comply:
- Vetting open source components
-
The organization needs clear policies and education around what open source software to use and where to include it in products. Such policies cover compliance, as well as other issues such as ensuring security and participating in the community that develops the software.
- Keep the original license in the code
-
Developers must not strip the license from the component they use. Including the license in the source code is usually a requirement in the license. In fact, removing the license could be considered plagiarism, because the developer makes it look as if they wrote the code. Removing the license could also lead to serious trouble later, because the organization could violate the license when the code is included in its products.
- Keep track of licenses
-
The organization must maintain a catalog showing the license of each file or package used by the organization, in order to make sure it is complying with the licenses.
- Acknowledge the author
-
Nearly all licenses require that credit be given to the copyright owner (often called the “author”) when discussing and promoting the software. Each license explains what to include in this notice: Typically, they require a standard copyright notice with the year and the name of the copyright owner. This notice should appear in any documentation related to the product using the component, including the advertising and web site for the device or program.
- Don’t imply endorsement
-
Some BSD licenses require the person distributing a product with the components to make sure not to imply that the copyright owner endorses the product. Even if the requirement is not stated, complying with it is the ethical thing to do.
- Offer the source code for copyleft licenses
-
If an organization distributes a binary file containing copylefted components, whether as a software distribution or on a device, the organization has to offer the public the source code to those components. If the organization changes the code and redistributes the derivative work in binary form, the source code for the changed (derived) version must be offered to the public as well. Distribution can be done through any means that make access convenient to the public, such as posting the code on a web site or offering it on a disk or USB stick.
- Don’t include copylefted components in proprietary products
-
If the organization incorporates copylefted components into a product, under some circumstances the organization has to release the whole product under the same copyleft license. The conditions that trigger this requirement vary from license to license. It’s sometimes unclear, though, what kind of use triggers the copyleft requirement. So, except for clear situations such as using an open source library (which should not trigger the copyleft’s reciprocal requirement), developers should be very careful about their use of copylefted components unless the organization is prepared to release its product under the same license.
- Document code changes
-
When distributing modified versions of code, clearly indicate the changes that the organization made.
- Grant patent rights
-
Some free or open source software licenses require a grant for patent use on the software. Thus, if an organization releases code under such a license, and holds a patent on some process in the code, the organization can’t charge a fee or exert other controls based on its patent to anyone using or adapting the code.
- Respect trademarks
-
Some open source software is covered by trademarks. Trademarks can cover words and phrases, logos and other images, and many other things. On the one hand, an organization must handle the trademark properly for any software it uses: A common violation is to parody, alter, or simply display a trademark without permission. On the other hand, if the organization wants to use the trademark, it must comply with the trademark owner’s requirements, which might rule out modifications to the software.
Risks of Open Source Software
This lesson is about compliance, so we’ll focus on risks in that area, but cover a few other topics too.
License Violation
Free and open source software licenses have to be treated as seriously as other licenses and contracts. Organizations do enforce them, such as the Software Freedom Conservancy, which acts on behalf of small copylefted projects that don’t have their own enforcement mechanisms.
These organizations usually approach lawsuits as a last resort. Most violations are unintended, and are easy to resolve with education. Still, it hurts an organization’s reputation to be seen as ignorant and insensitive toward the communities on whose software it depends.
And lawsuits have actually been launched when a software user is flagrantly refusing to cooperate, and when the software and the defendant are important enough.
Even if an organization is not punished with a lawsuit, the damage that a license violation does to its relationship with the community, as well as to its reputation, can be substantial. A project can be derailed by something as simple as having developers' questions go unanswered on the forums devoted to the software they’re trying to use.
It can be a disaster for someone to find copylefted software in a proprietary product. To comply with the license, the developers must either strip out all the copylefted code or free their product under the copyleft license. Making their software free, with source code available, could have dire effects on business models based on license fees or other ways of monopolizing the value of the product.
Trust and Reputation
We’ve seen that license violations can be very damaging. Other types of behavior that disrupt trust and reputation also introduce risks.
Some organizations release software under a free or open source software license, and then announce at some point that future versions will be under a proprietary license. This switch can be tempting, because many open source projects fail to receive financial support from enough clients.
But such license changes induce anger among both clients and the external developers contributing to the project. Sometimes, external developers take the free version and continue to develop it independently, a step known as forking the project. The free version might become competitive with the company’s proprietary version and draw customers away from the company.
There are also risks when participating in project forums. A company must learn how to be a good citizen. Common problems include:
-
Trying to use a company’s financial or code contributions as leverage to force the project in a direction that other developers don’t want
-
Making too many demands on the community, such as by pressuring it with a lot of feature requests or even too many questions
-
Being rude in other ways and violating the project’s code of conduct
-
Trying to dominate publicity or capitalize inappropriately in other ways on the project’s success
Unrewarded Investments
Business models are discussed in another lesson; this section just notes the financial risk of participating in open source projects.
Companies might start or join open source projects with the expectation of deriving revenue through some mechanism such as support contracts, SaaS contracts, data collection, or even donations and grants. Unfortunately, those who conduct open source projects often find them less lucrative than hoped for. Of course, any business takes a risk when starting a new project, but it’s particularly hard to find a reliable source of income for open source.
Open source seems most sustainable when it supports some other form of income, such as the sale of hardware devices, cars, printers, etc.
Forks
As we’ve seen, members of a project sometimes disagree on the project’s roadmap, leadership, or other aspects and create an alternative project on the same code base. Forking can also be done by an organization to create a specialized version of the software. For instance, Android uses a specialized version of Linux that Google maintains. (Google also makes a lot of contributions to the core version of Linux, and they are not always accepted.)
Organizations may create a fork for various reasons. They might submit their changes to the core project and have them rejected, because other developers don’t want them. In a project with a permissive license, or a project used only within the organization, it might want to keep its changes secret.
The risk of a fork is that the developers of the forked project are responsible for the maintenance of the entire product. If important bug fixes or new features are added to the core project, the developers of the forked project must duplicate the changes or forego their benefits. As time passes and the projects get further apart, keeping apace with changes in the core project becomes harder and harder.
Incompatible Licenses
As explained in other lessons, some free and open source software licenses have incompatible clauses. Such components can’t be used together in a product.
This problem is likely to arise during a merger or acquisition. Each company might have been using software with a particular license, and if they want to combine the code in their projects, they must make sure the licenses are compatible.
Product Liability
Many open source software licenses (and the terms of service for many proprietary software and services, for that matter) explicitly disavow any liability for the software’s use. Another way to say this is that the license or terms of service offer no warranty or guarantee.
Software vendors are rarely held responsible for problems with their software, but clients occasionally sue them or try other forms of punishment. Courts don’t have to recognize the “no warranty” clauses.
Increasingly, laws and regulations are imposing responsibilities on the creators of software. These legal restrictions — or at least, proposals for restrictions — are seen particularly now for artificial intelligence, but sometimes are broader.
Export Regulations
Many countries restrict the export of goods and software. In software, such regulations apply most often to security products, and specifically to the use of cryptography. The United States used to have strict controls on any software containing cryptography, but the controls have been relaxed on open source projects.
Companies should be aware of the export regulations where they are creating software, in case these regulations affect the sale and distribution of their products.
Software Bill of Materials: Know What You’re Using
Many products come with a bill of materials, which is just a list of all their components. For instance, when you buy a consumer product, it might include a sheet of paper listing all the parts, down to the nuts and bolts. The list might include useful information such as the dimensions of a part, and a part number so you can order a new part.
Open source projects are now including a Software Bill of Materials (SBOM, pronounced “S-bomb”). At the very least, an SBOM lists packages, filenames, licenses, authors or owners, and version numbers. Many SBOMs go further and include information about security vulnerabilities.
Projects generate an SBOM for each release using automated tools. Users can scan the SBOM to find information they need. For instance, extracting licenses helps the organization decide quickly whether the components are compatible with their own code and whether it’s legally permitted to use the components with their code.
Similarly, extracting version information on each package helps the organization discover whether different parts of its product depend on different versions of a particular library. Using two versions of the library causes bloat at the very least. It also could create confusion and errors, if a component is built with the wrong version.
Standards for SBOMs
Because computing environments use enormous quantities (sometimes tens of thousands) of components and make frequent changes, SBOMs must be highly structured so that information can be extracted automatically and quickly. This section describes two of the most popular formats in the open source world:
- Software Package Data Exchange (SPDX)
-
The format represents each package and all the contents of that package in a tree structure. The format documents dependencies between files, and other relationships. Pointers to information, known as “snippets,” can be created and then used throughout the document so that information needs to be defined in only one place. This format was developed by the Linux Foundation.
- CycloneDX
-
This is a larger format with more detailed fields, particularly for vulnerability information. The format was created by the Open Worldwide Application Security Project (OWASP) and is popular in the military and other organizations with a focus on security. For instance, an entry for a file could include a name for a security vulnerability, the source of information about the vulnerability, affected targets, and more. This format is also designed for cloud deployments that can include thousands of different systems.
Both SPDX and CycloneDX create hierarchical structures in various formats, including JSON and XML. Many tools exist for each standard, both to create the formats and to scan created files for information. Popular version control repository sites let developers create an SBOM in one of these formats with the click of a button.
Software Composition Analysis
Knowing what an organization is using requires an assessment of its software that includes an understanding of where it comes from, what vulnerabilities it contains, what licenses it uses, and other factors that help an individual or organization decide whether to use the software. This task is called Software Composition Analysis (SCA), and many tools exist to perform sophisticated scans of SBOMs and of software itself.
Some tools extract license information, which helps an organization decide whether the software is safe to include in a product and whether different components have compatible licenses. Some tools even compare code snippets to libraries of common open source projects to find out whether code was taken from the open source projects without proper attribution.
Running these tools is especially crucial during a merger or acquisition. The acquiring company might find that the software it wants to acquire is less valuable than they had expected, because it contains open source components that impose requirements interfering with its intended use in the new organization.
Formal Policies and Compliance
The processes and techniques described in this lesson should be fashioned by managers with input from developers, attorneys, and other knowledgeable people. This section describes some of the policy decisions that organizations need to make concerning open source software. We’ll end with a description of an Open Source Program Office (OSPO), which can be an advocate and information source for the policies.
Principles Governing the Use and Contribution of Open Source Software
Organizations can benefit greatly from using and contributing to open source software, but they need to do so in ways that protect their own interests as well as benefit the open source projects. Policies should be defined for:
-
Where to use open source software (operations, internal projects, client-facing products, etc.)
-
What makes an open source project appropriate for the organization: features, performance, security, roadmap for future extensions, and community viability
-
Scans for software composition analysis, and where resulting documentation should be stored
-
Rewards for developers contributing to open source software, including their participation in public forums
-
Guidelines for contributing to projects, including how to be a public representative of the company
-
Documentation requirements, so that developers outside the core team can understand how to contribute and interact
The OSPO can coordinate the creation of these policies and education to ensure compliance.
Contributor Agreements
Open source projects need to ensure that contributions are legitimate: for instance, that the code has not been taken from some proprietary product or an open source project with an incompatible license. Many open source projects require developers to provide a document called a Contributor License Agreement (CLA) to ensure the legitimacy of their contribution.
Developers at an organization who contribute to these projects might ask the organization’s lawyers to review and approve the CLA. Thus, the lawyers should understand the relevance of the clauses of CLAs and be prepared to vet them.
Numerous criticisms have been aired about CLAs, including their complexity and the loopholes they leave for projects to use contributed code in ways not desired by the contributors.
Many projects, instead of a CLA, ask a developer to sign a short document called a Developer Certificate of Origin (DCO), attesting that the developer has a right to contribute the code. The DCO, which is discussed in another lesson, generally is not submitted to a lawyer for review.
Some projects simply ask contributors to sign the copyright to their code over to the project in a Copyright Assignment Agreement (CAA). However, many contributors dislike this practice, because they can’t use the code in some proprietary project of their own and because it grants a lot of power to the project.
The Open Source Program Office (OSPO)
Open source projects combine unusual social, technical, legal, and organizational factors. At this time, knowledge of these factors has not swept through organizations to the point where all managers, developers, attorneys, and others understand them deeply. So organizations can benefit greatly from creating an Open Source Program Office (OSPO) as a central point for advocacy, policy-making, policy enforcement, and education.
As a kind of all-purpose department, OSPOs can perform many roles, such as:
- Promoting open source
-
OSPOs can disseminate both the concepts behind the open source movement and suggestions for using open source throughout their organization. They can remind developers to look for open source solutions to the problems they’re solving and encourage them to adopt appropriate software. They can urge managers to grant time to developers to participate in open source projects, and to recognize that participation when evaluating developers for salary raises and job promotions.
- Policy definition
-
OSPOs can mobilize managers to create policies and set up repositories for them.
- Policy enforcement
-
OSPOs can remind developers to scan software and SBOMs and to follow corporate rules about the use of open source. The OSPOs can preserve documentation about the software adopted, and other aspects of corporate use.
- Education
-
OSPOs can explain to developers how to evaluate and participate in open source projects, explain to lawyers the details of licenses and other legal considerations, and help the company understand the organizational and cultural changes that facilitate the use of open source software.
There are numerous documents and online resources for creating an OSPO. A small organization can farm out the task to a third party who is expert in that area.
Guided Exercises
-
Why shouldn’t a developer just take code they like from an open source project and put it into their own code without preserving the license?
-
What sorts of documents would a developer sign when making a contribution to an open source project?
-
You find some open source software that would make an excellent basis for your retail site. Can you overlay your logo over its popular logo to make an eye-catching image for your web site?
Explorational Exercises
-
What considerations might lead you to make a fork of an open source project for your own use, despite the drawbacks of forks?
-
When you find some open source software that meets your need, what are some reasons you might reject it?
-
You’d like to use a copylefted logging tool in your proprietary product. Is there a way to combine them that doesn’t require you to offer your product under the copyleft license?
Summary
This lesson has covered many considerations to take into account before using free and open source software. It explained how to adhere to licenses, various legal, reputational, and financial risks, and how to define important policies and enforce them within your organization.
Answers to Guided Exercises
-
Why shouldn’t a developer just take code they like from an open source project and put it into their own code without preserving the license?
This is usually a violation of the open source license, and also represents plagiarism and copyright infringement. Practically speaking, the organization can be forced to comply with the license, with consequences ranging from embarrassment and reputational damage to the destruction of their business model if copylefted code is mixed in with proprietary code.
-
What sorts of documents would a developer sign when making a contribution to an open source project?
A Contributor License Agreement is a legal document granting rights to the open source organization to use the code. A Developer Certificate of Origin is a shorter and simpler document promising that the developer has a right to contribute the code. A Copyright Assignment Agreement grants all rights to the receiving organization.
-
You find some software that would make an excellent basis for your retail site. Can you overlay your logo over its popular logo to make an eye-catching image for your web site?
If the project has trademarked its logo, your change would probably violate the trademark. Even if the logo is not trademarked, your change could be seen as disrespectful as well as confusing.
Answers to Explorational Exercises
-
What considerations might lead you to make a fork of an open source project for your own use, despite the drawbacks of forks?
If you are satisfied with the current state of the code, you might not need to keep up with changes to the core project. You might want to create a product substantially different from the uses to which the core project is put, and therefore be willing to part ways with the core project. The code might be valuable enough in your business plan that your team is willing to take on complete responsibility for its development and maintenance.
-
When you find some open source software that meets your need, what are some reasons you might reject it?
The code might contain too many bugs and security vulnerabilities, the project’s developer community might not function well, you might not like the direction in which the code is evolving, or the license might not be compatible with other code in your product.
-
You’d like to use a copylefted logging tool in your proprietary product. Is there a way to combine them that doesn’t require you to offer your product under the copyleft license?
Integrating the code for the tool into your code might trigger the copyleft’s reciprocal requirement, depending on which license is in effect. The logging tool must be separated from your product so that your product is not seen as derivative. For instance, it might be safe to run the copylefted tool as a separate process and communicate with it through message passing.