Free and open source software (OSS) continues to dominate the software development landscape, with an astounding 1.5 trillion component downloads in 2020.
With this growth, organizations are finding it more important than ever to make sure that they have documented policies in place to govern their use, distribution, and contribution of OSS.
This post offers an introduction to the topic and discusses some motivations for developing an OSS policy (open source policy) for your organization. It also describes best practices that companies should follow when implementing their own OSS policies.
What is an OSS policy and why should I have one?
An OSS policy is a document developed and maintained by a company to govern how and when employees should use or contribute open source components. It sets out requirements that must be followed when:
-
Incorporating OSS code into software developed by the organization
-
Distributing and otherwise making code available to third parties
-
Contributing code to OSS projects
Effective OSS policies are crafted collaboratively with all stakeholders, and will help ensure compliance with your software license obligations. Poor OSS hygiene can result, among other things, in the loss of proprietary rights.
What are my license obligations?
Despite being "free" and "open," OSS is subject to license terms with which your organization must comply. A single set of principles for internal developers helps ensure that your company does not inadvertently violate the terms of open licenses. These violations risk giving up exclusive rights to proprietary Intellectual Property (IP) and create exposure to infringement claims.
Your OSS policy can make sure that you are keeping track of your attributions and create a structured process to resolve issues.
Other business considerations
Beyond compliance with license terms, there are several reasons to implement an OSS policy:
-
IP risks: Haphazardly incorporating OSS into your company’s software could compromise the proprietary nature of your IP, risking entry into the public domain and creating competitive risks.
-
Acquisition or financing events: Investors and acquirers will often ask to review an organization’s OSS policy as part of the diligence process. Besides giving them insight into your development system, a comprehensive policy signals to the investors or acquirer that the organization takes its requirements seriously.
-
Information governance: A well-drafted OSS policy can help create alignment among stakeholders within the organization. It is important to give technical, legal, and business stakeholders within your company a clear understanding about OSS components. It should address those packages that are (and should be going forward) included in the organization codebase, and under what circumstances.
This alignment reduces confusion about your organization’s OSS goals and promotes compliance. A policy implementing an approval and documentation process that tracks usage from procurement to deprecation makes governing the whole system more efficient.
Best practices to include in your OSS policy
Matching your organization's needs and risk tolerances is key. For instance, software distributed to third parties will suffer substantially from a policy that only describes internal use. Some additional considerations for your OSS policy include:
-
Policy stakeholders: Make sure to gather input from key stakeholders within your organization. At minimum, this should include legal, operations, management, and IT.
-
Scope of policy: The decisions made should apply broadly, including any person who develops or procures code for your organization. This includes employees, contingent workers, or contractors. Of course, that means your company is responsible for making sure that all relevant persons have both reviewed and agreed to abide by the policy.
-
Pre-approved licenses: Identifying OSS that can be used without additional approval from your organization means developers know what licenses are safe to use without further analysis. Licenses outside of this group should require additional review from your company’s legal department. For example, the policy may state that only licenses approved by the Open Source Initiative (OSI) may be used. Or code licensed under a "copyleft" license (e.g., GPL-2.0, LGPL-2.1) may only be used in distributed binaries with legal approval.
You may even prohibit certain licenses altogether without an express, case-by-case approval from legal. Many organizations take this approach for code licensed under GNU Affero General Public License version 3 (AGPL-3.0).
- External project approval: As an organization, supporting OSS projects can help maintain the vitality of software you rely upon. They can also validate your organization's role as an active participant in the OSS community. Whether or not you have a deliberate plan or policy about contributions to third-party OSS projects, your personnel may nevertheless seek to contribute code.
However, it's important to make contributions in a structured manner and organization-wide. It should govern both code contributions to existing projects and the publication of company-owned code under OSS licenses.
-
Oversight and auditing: Establish a process for ensuring that promptly after the OSS policy is adopted, your pre-existing code is examined to determine compliance. Use automated scanning and similar tools to help you create an inventory, identify problematic code, and monitor the license status. Although infrequent, projects can change licenses without direct notification, which may add new requirements for continued use.
-
Attribution: A process for ensuring that attribution is properly made in your organization's software that incorporates OSS code. Automated tools can assist with these operations.
---
Drafting assistance from Shannon McNeal.
