Open source legal risks and best practices

Open source has become an essential pillar of software development in business. JavaScript libraries, web frameworks, operating systems, databases...

Few IT projects integrate no open source component at all. Yet many companies are unaware of the legal risks associated with these "free" technologies: licence violations, viral contamination, intellectual property disputes. Discover how to legally secure your use of open source and avoid the pitfalls that could cost you dearly.

If you would like to engage an IP lawyer, contact me!

Open source in business: opportunities and legal issues

Open source refers to software whose source code is accessible, modifiable and redistributable under the terms of specific licences. This philosophy of collaborative development has revolutionised the software industry and has become established in almost all tech companies.

The omnipresence of open source in information systems

The statistics speak for themselves: according to recent studies, more than 90% of enterprise applications contain at least one open source component. Cloud infrastructures rely massively on free technologies (Linux, Kubernetes, Docker), the most popular development frameworks are open source (React, Angular, Vue.js, Django, Spring), and even artificial intelligence solutions rely on free libraries (TensorFlow, PyTorch).

This omnipresence is explained by considerable advantages: licence savings, accelerated development thanks to the reuse of proven code, flexibility and customisation, access to a support community, and avoidance of vendor lock-in. Open source allows companies to focus on their core business value rather than reinventing the wheel.

However, this massive adoption is often accompanied by a worrying legal ignorance. Many companies consider open source to be "free and without constraint", whereas licences impose strict obligations whose violation can have dramatic legal and financial consequences.

Misconceptions about open source

The first misconception is to believe that "open source" means "without copyright". In reality, open source software is protected by copyright like any other software. The difference lies in the licence conditions granted by the rights holders, who broadly authorise use, modification and redistribution.

Another common confusion is to think that any open source code can be used without restriction in any project. However, open source licences are numerous, with highly variable requirements ranging from simple attribution to the obligation to publish your entire code under the same licence (viral effect).

Finally, many companies are unaware that they must comply with the terms of the licences even if they do not commercialise the resulting software. Internal use, provision in SaaS mode, or even simple distribution to clients can trigger certain obligations depending on the licences used.

The strategic stakes for companies

Beyond purely legal aspects, the management of open source presents major strategic stakes. In the context of a fundraising or acquisition, investors and acquirers carefully examine open source licence compliance. A non-compliance discovered during a due diligence can derail the operation or lead to a significant discount.

The company's reputation can also be affected. Open source communities are vigilant about licence compliance, and violations can give rise to damaging public campaigns, particularly for tech companies seeking to attract developer talent sensitive to these issues.

Finally, poor management of open source can create problematic technical and legal dependencies, particularly when high-value proprietary code becomes "contaminated" by viral licences, forcing it to be published or entirely rewritten.

Understanding open source licences: typology and implications

Open source licences form a complex landscape with dozens of different licences. Understanding their characteristics and implications is essential to securing your use of open source.

Permissive licences

Permissive (or liberal) licences impose a minimum of constraints. They authorise the use, modification and redistribution of the code, including in closed proprietary projects, generally subject only to the retention of the copyright and licence notices.

The MIT licence is one of the most permissive and popular. It authorises practically any use, including commercial use, without any obligation to publish modifications. The only requirements: retaining the licence text and the original copyright in redistributed copies of the code.

The Apache 2.0 licence offers similar protection while adding specific clauses on patents. It expressly grants a licence on patents held by contributors, and protects against patent infringement lawsuits. This licence is particularly appreciated in enterprise contexts.

The BSD licence (Berkeley Software Distribution) exists in several variants (2-clause, 3-clause). It also imposes few constraints, essentially attribution and the retention of legal notices. The 3-clause version prohibits the use of the project name to promote derivative products without authorisation.

Weak copyleft licences

Weak copyleft licences create a balance between permissiveness and protection of open source. They authorise integration into proprietary projects but impose certain obligations to redistribute the modified code.

The LGPL licence (Lesser General Public License) is typically used for software libraries. It allows the library to be used in proprietary software without having to publish the entire code, but modifications made to the library itself must be redistributed under LGPL.

The Mozilla Public License (MPL) operates at the file level: files coming from the open source project must remain under MPL if they are modified, but can be combined with proprietary code in separate files. This granularity facilitates integration into mixed projects.

These licences therefore allow commercial and proprietary use while guaranteeing that improvements to the open source component benefit the community. They are particularly suited to libraries and reusable components.

Strong copyleft licences (viral licences)

Strong copyleft licences require that any code derived from or incorporating the open source code also be distributed under the same licence. It is the viral effect or "contaminating" effect that poses the greatest legal difficulties for companies.

The GPL licence (General Public License), in its versions 2 and 3, is the best known in this category. It requires that any software incorporating GPL code be itself distributed under GPL, with the obligation to provide the complete source code. This obligation is triggered upon distribution of the software.

The GPLv3 adds important provisions on patents and tivoisation (a practice aimed at restricting the use of software on certain hardware). It also prohibits certain forms of DRM that would prevent the modification of the software.

The AGPL licence (Affero GPL) extends the publication obligation to the SaaS case: if you use AGPL software to provide an online service, you must make the source code available to the users of that service, even without distribution of the software itself. This licence is particularly feared by SaaS publishers.

Specific licences and special cases

Some projects use proprietary licences or hybrid models (dual licensing). For example, a project may be available under GPL for non-commercial use and under a paid commercial licence for companies that do not wish to publish their code.

Creative Commons licences, although mainly used for non-software content, can apply to technical documentation or graphic resources. Their use in a software context requires particular attention.

Finally, some components may be subject to several licences simultaneously, leaving the user to choose the licence under which they use the code. This flexibility facilitates integration but requires rigorous documentation of the choice made.

Need an audit of your open source licences? Contact me!

The major legal risks of open source

The uncontrolled use of open source components exposes companies to various legal risks whose consequences can be considerable.

Violation of licence terms

Non-compliance with the obligations imposed by licences constitutes a breach of the licence agreement, but also a copyright infringement. In the absence of a valid licence (because it has not been respected), the use of the code becomes an unauthorised exploitation of a protected work.

The most frequent violations concern: failure to retain copyright notices, non-redistribution of the source code for copyleft licences, the incorporation of GPL code into a closed proprietary product, or the modification of code without respecting redistribution obligations.

The sanctions can be severe: an injunction to cease the exploitation of the software, an obligation to publish the source code (for viral licences), damages for infringement, reputational damage in the event of publicity of the dispute. In certain extreme cases, the company may be forced to withdraw its product from the market.

Viral effect and contamination of proprietary code

The viral effect of copyleft licences represents the most feared risk. If a developer incorporates even a few lines of GPL code into strategic proprietary software, the entirety of that software could legally have to be published under GPL.

This contamination can occur insidiously: a developer copies code found on StackOverflow without checking its licence, a seemingly permissive library itself depends on a GPL library, a component changes licence between two versions. The propagation mechanisms are sometimes subtle.

The consequences of contamination discovered late are dramatic: the impossibility of commercialising the software without violating the licence, the obligation to entirely rewrite the contaminated parts (considerable cost and delay), the loss of competitive advantage if the code must be published, or the costly negotiation of a commercial licence with the rights holders.

Patent-related risks

Some open source licences include patent licence clauses (Apache 2.0, GPLv3). Conversely, the use of open source code does not immunise against the risks of infringement of patents held by third parties who are not contributors to the project (patent trolls).

The issue becomes more complicated when a company holds patents and contributes to open source projects. Depending on the licences, it may find itself obliged to grant a licence on its patents, or conversely, lose the benefit of the open source licence if it initiates patent infringement proceedings.

Patent disputes in the open source ecosystem, although less frequent than licence disputes, can be extremely costly and strategically destabilising, particularly in heavily patented technological fields such as video codecs or communication protocols.

Liability and warranties

Open source licences generally contain very broad warranty exclusion clauses. The software is provided "as is" without any warranty of operation, quality or fitness for a particular purpose. The liability of contributors is also limited or excluded.

For a company that integrates these components into its commercial products, this poses a problem of liability towards its own clients. In the event of a defect in the open source component causing damage, the company will generally not be able to take action against the authors of the component.

This reality requires companies to put in place rigorous qualification and testing processes for the open source components used, as well as to provide for appropriate liability limitations in their commercial contracts.

Security risks and vulnerabilities

The use of open source components exposes one to the security vulnerabilities that can affect these components. Critical flaws are regularly discovered in widely used libraries (Heartbleed in OpenSSL, Log4Shell in Log4j).

The responsibility to monitor these vulnerabilities and update the components falls on the using company. The failure to update a known vulnerability, leading to a data breach, can engage the company's liability, particularly with regard to the GDPR.

The management of open source dependencies must therefore be accompanied by active security monitoring and procedures for the rapid deployment of patches, which represents an operational and legal burden (obligation to notify the CNIL in the event of a data breach).

Let's discuss your needs for 15 minutes!

Compliance audit: identifying open source components

The first step in sound management of open source is to precisely map the components used in your projects. This seemingly simple task often proves complex.

Exhaustive inventory of dependencies

A code audit must identify all the open source components used, including transitive dependencies (the libraries used by your libraries). In modern projects, the number of dependencies can reach several hundred, or even thousands.

Automated analysis tools are essential: dependency managers (npm, Maven, pip) that generate dependency lists, software composition scanners (SCA - Software Composition Analysis) such as Black Duck, WhiteSource, FOSSA, or Snyk that analyse the source code and identify the components.

The audit must also cover copy-pasted code from external sources (forums, StackOverflow, GitHub) without the formal use of a library. These pieces of code often constitute dangerous blind spots because they are not tracked by standard tools.

Identification of licences and compatibility analysis

For each identified component, its precise licence and version must be determined. This information is not always clearly documented, and some components may have changed licence between versions or combine several licences.

The compatibility analysis of the licences is then necessary. Some licences are incompatible with each other: for example, combining GPL code with code under a licence incompatible with the GPL is legally problematic. Tools such as License Finder or FOSSA offer compatibility matrices.

This analysis must also take into account your distribution model: an internal project, commercialised software, a SaaS service, or an embedded product do not have the same implications depending on the licences. The AGPL, for example, poses no problem for internal use but becomes constraining in SaaS.

Documentation and traceability

All the components, licences and analyses must be documented in a database or a dedicated management tool. This documentation constitutes an essential element of your compliance program and will be scrutinised during due diligences.

Traceability must make it possible to quickly answer critical questions: does this component use a viral licence? What are our publication obligations? Have we respected the terms of the licence? In the event of an update, has the licence changed?

This documentation also serves as proof of good faith in the event of a dispute. Demonstrating that a rigorous process was in place and that an error was occasional rather than systemic can considerably mitigate the legal consequences.

Detection of violations and remediation

The audit frequently reveals non-compliances that must be addressed urgently. The remediation options include: replacing the problematic component with an alternative under a compatible licence, negotiating a commercial licence with the rights holders, refactoring the code to remove the dependency, or publishing the code if that is acceptable.

A prioritised remediation plan must be established according to the criticality of the violations (legal exposure, technical impact of the replacement, cost). Violations of viral licences in strategic code generally constitute the absolute priority.

The remediation must be documented to demonstrate your responsiveness and your commitment to compliance. This documentation can be decisive in the event of a dispute to obtain a favourable outcome or limit damages.

Putting in place an open source usage policy

Beyond the one-off audit, a formalised open source usage policy is essential to prevent risks in a sustainable manner.

Defining acceptable licences

The policy must establish a list of approved licences for different uses. For example: permissive licences (MIT, Apache, BSD) authorised without restriction, weak copyleft licences (LGPL, MPL) authorised for libraries under conditions, viral licences (GPL, AGPL) prohibited except with specific authorisation.

This classification must take into account your business model: a publisher of commercial software will have a more restrictive policy than a using company without redistribution. SaaS companies must be particularly vigilant with the AGPL.

The policy must also provide for an exception process for cases where the use of a component under a normally unaccepted licence is justified by technical or strategic reasons. These exceptions must be validated by the legal and technical teams and documented.

Approval and validation process

Before integrating a new open source component, developers must follow a validation process: checking the licence, assessing compatibility with existing licences, risk analysis, validation by a designated manager (architect, DPO, legal counsel depending on the organisation).

This process can be tooled to minimise friction: integration into dependency management tools, automatic blocking of prohibited licences, validation workflows in CI/CD systems. The objective is to secure without excessively slowing down development.

The validation criteria must be clear and documented: code quality, active maintenance of the project, support community, security history, technical compatibility, and of course licence compliance.

Training and awareness of developers

Technical teams must be trained in the legal issues of open source. Many developers are unaware of the implications of licences and consider that any code available on GitHub is freely usable.

The training must cover: the different types of licences and their implications, the legal risks for the company, best practices for use, the internal validation process, and the people to contact in the event of doubt.

Regular awareness-raising is necessary because teams evolve and practices must be maintained over time. Reminders during onboardings, communications when the policy evolves, or question-and-answer sessions help maintain the level of vigilance.

Contractual clauses with service providers

When you have code developed by external service providers (freelancers, agencies, IT services companies, ESN), your contracts must strictly regulate the use of open source. The clauses must provide for: the obligation to declare any open source component used, compliance with your acceptable licences policy, the warranty of compliance with the licences.

The contracts must also provide for the consequences of a violation: an obligation to remedy at the service provider's expense, a warranty against eviction in the event of litigation, liability for the damages caused. These clauses protect the company in the event of non-compliance discovered after delivery.

I want reliable legal documents!