Open Source, Open Opportunities, Clear Obligations: Managing Open-Source Software Licences

🧭 Dojo Compass

Module: Finance, Risk Management and Long-Term Resilience

Focus Area: Technology, AI and Future Readiness

Learning Format: Article

Open-source technology offers SMEs significant opportunities to reduce technology costs, increase flexibility and develop internal technical capabilities. However, open-source software is not free of intellectual property rights or licensing obligations. Different open-source licences establish different conditions governing how software can be used, modified, integrated and distributed.

This article examines the principal types of open-source licences, the rights and obligations they create, and the practical steps SMEs should take to manage licence compliance. The objective is to ensure that businesses can benefit from open-source technology without inadvertently creating legal, operational or commercial risks.

🎯 Key Challenge

One of the attractions of open-source technology is that it can be accessed and used without the conventional licensing costs associated with proprietary software.

However, there is a potentially important misunderstanding: open source does not mean unrestricted use.

Open-source software remains protected by intellectual property rights, principally copyright. The licence attached to the software establishes the conditions under which others are permitted to use, modify and distribute it.

These conditions vary considerably.

Some licences allow businesses to incorporate open-source code into proprietary commercial products, subject to relatively straightforward attribution and notice requirements. Others impose reciprocal obligations that may require certain modified or derivative software to be distributed under the same licence, including making source code available.

For SMEs, the distinction can have significant commercial consequences.

Consider an SME developing a proprietary software application. Its developers identify an open-source component that provides useful functionality and incorporate it into the application. The business subsequently commercializes and distributes the application to customers.

If the component is governed by a permissive licence, the business may be able to retain its proprietary licensing model, provided it complies with the applicable conditions.

If the component is governed by a copyleft licence, however, the business may have additional obligations concerning the licensing and availability of the source code of the covered work. The precise obligations depend on the licence, the way the component has been incorporated and whether the software is distributed or otherwise made available in circumstances covered by the licence.

A failure to understand these obligations can create several problems:

• The business may inadvertently breach the licence conditions.
• Proprietary intellectual property may be subject to obligations the business did not anticipate.
• The business may need to restructure its software architecture or replace components.
• Commercialization and distribution arrangements may need to be revised.
• Potential investors or acquirers may identify open-source compliance deficiencies during due diligence.

There is also a less obvious problem. SMEs may assume that software available on a public repository or developer website is automatically available for unrestricted use. This is not necessarily the case. Software without an identifiable licence does not automatically become open source simply because its source code can be viewed or downloaded.

The challenge is therefore to understand the licensing framework before incorporating open-source technology into business operations or products.

🥋 Dojo Solution

The solution is to introduce a basic open-source licence management framework.

This does not require every SME to employ an intellectual property lawyer or establish a sophisticated software compliance department. It does require an understanding of the principal licence categories, an appreciation of their commercial implications and a process for identifying and managing the licences associated with adopted technologies.

1. Understand the principal categories of open-source licences

Although there are many individual open-source licences, they can broadly be understood through three categories.

A. Permissive licences

Permissive licences generally provide considerable freedom to use, modify and distribute software, including incorporating it into proprietary commercial products.

Common examples include:

• MIT Licence.
• Apache Licence 2.0.
• BSD 2-Clause and BSD 3-Clause licences.

These licences generally allow businesses to modify and redistribute the software without requiring their own proprietary modifications to be released under the same open-source licence.

However, permissive does not mean obligation-free.

For example, MIT generally requires preservation of copyright and licence notices. Apache 2.0 has additional requirements concerning notices, attribution of modifications in certain circumstances and patent provisions.

For SMEs developing proprietary software, permissive licences are often attractive because they generally allow greater flexibility in commercializing products while retaining proprietary rights in their own code.

B. Weak copyleft licences

Weak copyleft licences occupy an intermediate position.

They generally permit open-source components to be incorporated into larger software systems that may contain proprietary code, but impose reciprocal obligations on specified portions of the software.

Common examples include:

• GNU Lesser General Public Licence (LGPL).
• Mozilla Public Licence 2.0 (MPL).
• Eclipse Public Licence 2.0 (EPL).

The precise obligations differ between licences.

For example, the LGPL is designed to permit certain forms of linking between an LGPL-licensed library and proprietary applications, subject to conditions that preserve the ability to use, modify and, where applicable, replace the LGPL-covered library.

The MPL 2.0 generally applies its copyleft obligations at the file level. Modifications to MPL-covered files must remain available under the MPL when distributed, but separate files within a larger proprietary application can generally remain proprietary.

These licences can provide useful opportunities for SMEs, but developers need to understand how the particular licence treats modifications, linking, distribution and the combination of different software components.

C. Strong copyleft licences

Strong copyleft licences impose more extensive reciprocal obligations.

Common examples include:

• GNU General Public Licence version 2 (GPLv2).
• GNU General Public Licence version 3 (GPLv3).

These licences generally require covered derivative or combined works to be distributed under the applicable GPL terms when they are distributed or conveyed in circumstances covered by the licence.

This can include making the corresponding source code available and preserving the rights granted under the GPL.

The GNU Affero General Public Licence (AGPL) introduces an additional consideration. It addresses circumstances in which modified software is made available for interaction over a network, potentially triggering source-code obligations even when conventional distribution of copies does not occur.

For an SME developing proprietary software products or commercial online services, these distinctions can be particularly important.

Strong copyleft licences are not inherently problematic. They can be perfectly appropriate for businesses that are comfortable with their reciprocal requirements. The important consideration is whether the licence is compatible with the intended business model.

2. Understand the difference between using, modifying and distributing software

One of the most important considerations in open-source licence management is that different activities can trigger different obligations.

Using open-source software internally is not necessarily equivalent to distributing it to customers.

For example:

• Installing an open-source application for internal accounting purposes may involve relatively limited compliance obligations.
• Modifying an open-source component and distributing the modified software may trigger additional obligations.
• Incorporating open-source libraries into a proprietary application and distributing that application requires careful examination of the applicable licence.
• Making software available as an online service may have different implications depending on whether the licence contains network-use provisions, as with the AGPL.

The distinction between internal use, modification, integration, distribution and network deployment should therefore be part of the SME’s evaluation process.

It is particularly important not to assume that combining two software components automatically makes them a single derivative work. The legal treatment depends on the nature of the integration, the applicable licence and other relevant circumstances.

3. Understand licence compatibility

An additional consideration arises when combining multiple open-source technologies.

An SME might adopt several components, each governed by a different licence. Although each component may be individually suitable, the licences may impose conditions that are difficult or impossible to satisfy simultaneously when the components are combined and distributed.

For example, Apache 2.0 and GPLv3 are generally compatible for certain forms of combination and distribution, whereas Apache 2.0 and GPLv2-only present a compatibility problem.

Licence compatibility is therefore not simply a question of whether individual components can be used. It is also a question of whether their respective licensing conditions can be satisfied together in the intended software architecture.

This becomes increasingly important as SMEs develop more sophisticated applications incorporating numerous third-party libraries and dependencies.

4. Recognize the commercial and intellectual property implications

Open-source licence management should form part of the organization’s broader intellectual property strategy.

Before incorporating a component into a proprietary product, the business should consider:

• Whether the licence permits the intended commercial use.
• Whether the business can retain proprietary rights in its own code.
• Whether modifications must be made available under an open-source licence.
• Whether source code must be provided to customers or other recipients.
• Whether particular notices, acknowledgements or licence texts must accompany distribution.
• Whether patent-related provisions are relevant.
• Whether the licence is compatible with the other components in the application.

These questions are especially important where the SME intends to commercialize software, develop proprietary technology or build intellectual property that may eventually attract investment or acquisition interest.

The objective is not to avoid open-source technology. It is to ensure that the business understands the conditions under which it can build commercial value around it.

🏗️ Putting It into Practice

SMEs can introduce a straightforward process for managing open-source licences without creating excessive administrative overhead.

Step 1: Establish an open-source software inventory

Identify the open-source technologies currently used by the business.

This should include not only major applications and platforms but also the libraries, frameworks and other dependencies incorporated into internally developed software.

For each component, record:

• Name and version.
• Source or repository.
• Applicable licence.
• Purpose and business function.
• Whether it has been modified.
• Whether it has been incorporated into another product.
• Whether it is distributed to customers or used internally.

Do not limit the exercise to software deliberately selected by management. Developers may have introduced open-source components as dependencies without senior management being aware of them.

Step 2: Verify the applicable licence

For each component, locate and review the actual licence.

Do not rely exclusively on a website description, a developer’s informal statement or the fact that the software is publicly accessible.

Check:

• The licence file in the relevant repository.
• The precise licence version.
• Any additional exceptions or licensing conditions.
• Whether the component includes third-party dependencies with separate licences.
• Whether the software is dual-licensed, and which licensing option applies.

Where no licence can be identified, do not assume that the software is available for unrestricted commercial use.

Step 3: Establish an acceptable licence policy

Develop a simple internal policy identifying which licences can be adopted without additional approval and which require further examination.

For example:

• Permissive licences such as MIT, BSD and Apache 2.0 may be approved through an ordinary technical review, subject to compliance with their conditions.
• Weak copyleft licences such as LGPL and MPL may require a review of how the component will be integrated and distributed.
• Strong copyleft licences such as GPL and AGPL may require legal and technical approval before adoption into proprietary products or commercial services.

These are suggested internal risk categories, not a substitute for examining the actual licence. A permissive licence can still create compliance obligations, while a copyleft licence may be entirely appropriate for a particular business model.

The policy should also identify who has authority to approve exceptions.

Step 4: Introduce an open-source approval process

Before developers introduce a new open-source component into a commercial product or an important business system, require them to identify its licence.

The approval process should consider:

• The functionality provided.
• The business justification for adopting the component.
• The licence and its obligations.
• The integration method.
• Whether the component will be modified.
• Whether the resulting software will be distributed or made available as a service.
• Any compatibility issues with existing components.

This need not be a lengthy approval procedure. The objective is to identify potential problems before they become embedded in the technology architecture.

Step 5: Maintain licence notices and comply with distribution obligations

Establish a process for retaining and providing the notices and other materials required by applicable licences.

Depending on the licence and the manner of distribution, this may include:

• Copyright notices.
• Copies of applicable licence texts.
• Attribution statements.
• Notices identifying modifications.
• Corresponding source code or instructions for obtaining it.
• Installation information in certain GPLv3 distribution circumstances.

These requirements should be incorporated into the software release and distribution process rather than being treated as an afterthought.

Step 6: Use automated tools to monitor dependencies

As the technology portfolio becomes more sophisticated, manual tracking can become difficult.

Fortunately, a number of tools can help identify open-source dependencies and their associated licences.

Examples include:

• Software composition analysis (SCA) tools.
• Dependency scanners.
• Software Bill of Materials (SBOM) generators.
• Repository-based dependency and licence monitoring tools.

A Software Bill of Materials is particularly useful. It provides an inventory of the software components incorporated into an application, helping the business understand its software supply chain.

Some tools can identify known licences, flag potential compatibility issues and detect changes in dependencies.

However, automated tools are not a substitute for legal and technical review. They can misidentify licences, overlook exceptions or fail to determine whether a particular integration triggers an obligation.

Step 7: Include open-source compliance in commercial and investment due diligence

Finally, ensure that open-source licence management is incorporated into the organization’s broader intellectual property governance.

When developing proprietary software, entering commercial partnerships, raising investment or considering an acquisition, the business should be able to demonstrate that it understands the open-source components incorporated into its products and has procedures for complying with their licences.

This is particularly important where proprietary intellectual property represents a significant part of the organization’s enterprise value.

A properly maintained open-source inventory, documented approval process and evidence of compliance can help reduce uncertainty during due diligence.

📌 Key Takeaways

• Open-source software is not free of intellectual property rights or licensing obligations. Its use is governed by the conditions of the applicable licence.
• Permissive licences generally provide greater flexibility to incorporate software into proprietary commercial products, while copyleft licences impose varying reciprocal obligations.
• The distinction between permissive, weak copyleft and strong copyleft licences is important when developing proprietary applications.
• Using software internally, modifying it, distributing it and making it available as a network service can have different licensing implications.
• Combining software components with different licences can create compatibility issues that should be assessed before integration.
• Open-source licence management is part of intellectual property and commercial risk management, not simply a technical issue.
• SMEs should maintain an inventory of open-source components, verify licences, establish approval procedures and retain required notices and documentation.
• Automated tools can help monitor dependencies and licences, but do not replace appropriate technical and legal review.
• Good licence governance protects the commercial value of proprietary intellectual property while allowing SMEs to benefit confidently from open-source technology.

🌿 Reflection

Open-source technology creates an opportunity to participate in a broader ecosystem of innovation and technological development.

However, participation comes with responsibilities.

The ability to access, modify and distribute technology is established through legal frameworks that balance the rights of original developers with the freedoms granted to subsequent users.

For SMEs, understanding these frameworks is part of becoming a more sophisticated technology participant.

There is also a broader lesson about business management. Opportunities and risks frequently arise from the same decision. Open source can reduce costs, increase flexibility and accelerate innovation, but poorly managed adoption can create unexpected legal and commercial consequences.

The objective should not be to avoid technologies because their licensing arrangements appear complicated. Nor should businesses assume that freely available technology can be used without restrictions.

Instead, they should develop the knowledge and processes necessary to manage these arrangements intelligently.

Are you treating open-source software as a collection of free resources, or as a portfolio of intellectual property assets and obligations that needs to be understood and managed?

⚔️ Dojo Mission

Conduct a basic open-source licence audit.

Select five open-source technologies currently used by your business or incorporated into its software products.

For each one:

1. Identify its exact licence and version.
2. Determine whether it is permissive, weak copyleft or strong copyleft.
3. Identify the principal obligations associated with its use.
4. Establish whether it is modified, integrated into other software, distributed to customers or used to provide an online service.
5. Determine whether the business has complied with the applicable licence requirements.

Identify any components for which the licence is unclear or the obligations have not been assessed.

Then introduce one simple internal rule: no new open-source component should be incorporated into a commercial product without its licence first being identified and reviewed.

The objective is to establish a foundation for responsible open-source adoption that protects the business while preserving the strategic opportunities that open source offers.