Open source software (OSS) has grown rapidly over the past decade. According to OpenLogic’s 2025 State of Open Source Report, over 58% of SMBs and enterprises reported higher use of OSS over the past year. Among larger enterprises, the figure jumps to 68%. That, in turn, has resulted in more contributions to OSS projects and more new OSS projects.
In-house legal counsels in organizations that use or create software need to understand open source. This article is a practical guide for in-house counsels on advising internal teams in three common OSS-related scenarios, which I call the “Open Source Trifecta”: (1) using OSS, (2) contributing to OSS projects, and (3) releasing software under an OSS license.
Understanding the Legal Risks in Open Source Software
Before diving into each scenario, let’s review the key OSS risks that companies face:
- License Compliance — OSS is governed by licenses that impose conditions upon the licensee. These may include requirements to provide license notices or to disclose the source code of modifications. Some OSS licenses are more flexible than others.
- Intellectual Property (IP) Risks — Like any kind of software, OSS embodies IP. Using OSS, contributing to OSS, and creating OSS all have IP implications. Doing so without understanding those implications can compromise a company’s IP position.
- Supply Chain Security — Hackers often try to breach organizations’ systems by exploiting vulnerabilities in common OSS tools. These kinds of cyberattacks are known as supply chain attacks. Such an attack could subject a company to liability if it compromises the safety or security of its products or systems.
Scenario 1: Using Open Source Software
This is the most common scenario. Most companies that employ software engineers use OSS in at least one of the following ways:
- They use OSS in their internal workflows.
- They include OSS in infrastructure systems.
- They incorporate OSS into commercial products.
In-house counsels should be familiar with the basic steps necessary for compliance in each of the above situations.
Steps to Ensure Compliance
- Identify the License Type — OSS licenses are of two types: copyleft and permissive. Copyleft licenses require licensees to disclose the source code of their modifications in certain situations. Permissive licenses only require licensees to provide notice that they’ve used the OSS and attribution to the copyright holder.
- Assess License Risks — Evaluate whether your company can comply with the conditions imposed by the OSS license without compromising your IP or taking on unacceptable risk.
- Review Dependencies — Many OSS projects include dependencies governed by different licenses, which may impose additional conditions. Be aware of these and understand how they affect your use case.
- Implement Tracking Mechanisms — Maintain an inventory of the OSS components that your company has incorporated in its products or customer-facing systems. Encourage your teams to use tools that track software bills of materials (SBOMs) or automated tools to monitor compliance.
- Provide License Notices Where Required — Make sure that any software applications or utilities your company makes available have a notices interface in which any notices required by OSS licenses are included.
- Implement Malware Scanning — To limit the likelihood of liability from software supply chain attacks, work with your InfoSec teams to ensure that adequate security solutions to protect the integrity of your software are in place.
To limit inefficiencies or obstacles to productivity that legal compliance mechanisms may introduce, consider implementing systems and standard operating procedures that teams can apply on their own. Effective compliance mechanisms should minimize escalations to legal and empower teams to make decisions while limiting risk.
Scenario 2: Contributing to Open Source Projects
Engineers often seek to contribute to OSS projects, whether on behalf of the company or as individuals on their own time. They might want to do this because::
- They want to grow the company’s profile and visibility within the OSS project’s community or in the sector at large.
- They want to influence the development of the OSS project in ways that benefit the company.
- They want to submit improvements or bug fixes for an OSS tool that the company uses.
- The engineers want to advance their own professional reputations.
- They are pursuing hobbies or entrepreneurial projects outside of work.
In any of these situations, legal teams must balance innovation with risk management.
Steps to Ensure Compliance
- Establish Contribution Guidelines — Define internal policies for OSS contributions made on the company’s behalf. Specify which types of projects are acceptable (e.g., projects that are governed by specific licenses) and any approval processes required. Be clear about who in your company has the authority to approve making contributions.
- Clarify Ownership and IP Rights — Some OSS projects require contributors to sign agreements (e.g., Contributor License Agreements or Developer Certificates of Origin) that assign rights or grant patent licenses to the project owners. Make sure teams know not to sign such agreements willy-nilly and to seek approval from legal first.
- Determine Disclosure Scope — Ensure that employees don’t inadvertently share proprietary code or confidential algorithms in open source contributions.
- Business and Commercial Considerations — Many OSS projects belong to commercial entities. The project your engineer wants to contribute to may belong to a competitor. Connect engineers with business and product teams to ensure that everyone is on the same page and that they aren’t unwittingly supporting a competing product.
- Define Permitted Outside Activities — If an engineer wants to contribute to an OSS project on their own time, make sure they are well-aware of their employment terms that govern outside activities and that your standard employment agreement adequately addresses such situations (be careful not to provide legal advice to employees in their individual capacities).
Scenario 3: Creating and Releasing Open Source Software
Engineers, product managers, and businesspeople sometimes want to create their own OSS projects to release software the company has developed internally. They might want to do so because:
- They want to grow the company’s visibility and enhance its reputation in certain sectors.
- They want to build a product around the open source project.
- The engineers want to advance their own professional reputations.
- They want to build goodwill within the open source movement at large.
Legal teams should understand proper licensing and governance strategies to avoid unintended legal exposure in each of these situations.
Steps to Ensure Compliance
- Choose an Appropriate License — The license determines what rights the company is granting licensees to use, modify, or distribute the code. It can be difficult to change the license of a project later on (especially if you want to change from a permissive license to a copyleft license), so the initial decision of which license to use is critically important. Companies should make sure that the terms of their preferred license align with the company’s business objectives (e.g., permissive licenses for encouraging adoption vs. copyleft licenses for maximizing control). If the OSS project incorporates third-party code, the chosen license must be compatible with existing dependencies.
- Define Contribution Policies — Establish governance mechanisms for external contributions and community management. Determine whether it makes sense to require that contributors sign a Contributor License Agreement (CLA). Create a code of conduct that governs communication within the community and communication between maintainers and community members. Make sure your engineers have established code review mechanisms.
- Create Succession and Continuity Procedures — Make sure that points of contact and responsible persons are designated to oversee the project and that there are handoff procedures in place in case a maintainer departs. Ensure that HR is aware of an employee’s role in the maintenance or governance of a project.
- Mitigate Trademark Risks — Companies should consider trademark registration and usage guidelines on the project name and branding to prevent misuse by third parties and to avoid reputational harm.
- Monitor Forking and Derivative Works — A “fork” of a project is an OSS project that is started by cloning the codebase of an existing project and developing it independently of the original project. Strong copyleft licenses often allow derivative works, which may impact commercialization strategies. Make sure your teams have considered the possibility that the project could be forked by a competitor and the business implications of that scenario.
Today, for companies using OSS, understanding its rules is a necessity, not an option. Most companies today have written policies for use of OSS written by others, and many also have policies for contributions and releases. Having the correct policies in place will help you manage risk, improve your products, and enhance your company’s reputation in the developer community.
