« Previous Page : Next Steps

Table of Contents

Annex A - Legal Issues

• Intellectual property
• Managing Licence Obligations
• Patent Management
• Legal Risk Management

Intellectual property

Licences

Disclaimers

Most Open Source Software (OSS) licences include a disclaimer of warranty that aims to be as exhaustive as possible in ensuring that no warranty applies. For example, the following clause in the Mozilla Public License Version 2 (MPLv2) demonstrates a typical incarnation of this licence term:

Covered Software is provided under this License on an “as is” basis, without warranty of any kind, either expressed, implied, or statutory, including, without limitation, warranties that the Covered Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Covered Software is with You. Should any Covered Software prove defective in any respect, You (not any Contributor) assume the cost of any necessary servicing, repair, or correction. This disclaimer of warranty constitutes an essential part of this License. No use of any Covered Software is authorized under this License except under this disclaimer.

As shown, in addition to setting out that the licence is “without warranty of any kind”, these clauses are most often careful to exclude any warranty of “merchantability” or “fitness for a particular purpose”. This serves to clarify and make certain that these two warranties do not apply, as some legislation might otherwise impose them as implicit terms of a contract or licence. For example, where software is sold in Ontario, the Sale of Goods Act imposes implied warranties relating to merchantability (Section 13) and, in some cases, warranties of fitness for a particular purpose (Section 15). However, with the explicit exclusions in typical OSS licences, these warranties do not apply.

Many licences also explicitly disclaim warranties of non-infringement (for example, the MPLv2, as set out above). This disclaimer aims to exclude the U.S. doctrine of an implied warranty of non infringement in the Uniform Commercial Code § 2-312, which otherwise warrants that the software does not infringe any third party’s copyright. For example, if a software developer uploaded a piece of code to an OSS project and it originally came from copyright-protected closed-source software, anyone downloading or using the OSS application would technically infringe the copyright. If sued for such an infringement, the warranty of non infringement would result in such a user having no recourse against the distributors or developers – it is “users beware”. In Canada, even though a specific doctrine of a warranty of non-infringement does not exist, this licence clause still likely disclaims similar warranties of title (especially when considered in conjunction with a broad disclaimer against warranties of “any kind” in the Sale of Goods Act, Section 13). As well as disclaiming warranties, nearly all OSS licences disclaim liability. For example, the MPLv2 states:

Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall any Contributor, or anyone who distributes Covered Software as permitted above, be liable to You for any direct, indirect, special, incidental, or consequential damages of any character including, without limitation, damages for lost profits, loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses, even if such party shall have been informed of the possibility of such damages. This limitation of liability shall not apply to liability for death or personal injury resulting from such party’s negligence to the extent applicable law prohibits such limitation. Some jurisdictions do not allow the exclusion or limitation of incidental or consequential damages, so this exclusion and limitation may not apply to You.

Again, this disclaimer broadly aims to cover all bases of liability and all types of damages that could occur. The result is that when you use OSS, you do so at your own risk.

Given that the contributor (in this case the Government of Canada) carries no liability and offers no form of warranty for any contributions made or products produced they must also forgo any form of meaningful or perceived ownership over the code or product generated.

Although these disclaimers are standard in nearly all OSS licences, licensors can modify them. In some cases, an OSS licence allows the licensor to set out additional disclaimers. For example, the MPLv2 allows a licensor to “include additional disclaimers of warranty and limitations of liability specific to any jurisdiction”. In other cases, a licensor may do the opposite and choose to offer a warranty or accept liability, removing the effect of the disclaimer of warranty. For instance, the MPLv2 provides that “You may choose to offer and to charge a fee for warranty, support, indemnity or liability obligations to one or more recipients of Covered Software”.

Notice Obligations

Like disclaimers, a notice obligation clause comes standard in nearly every OSS licence. This is an obligation to reproduce the licence text (either directly or through a hyperlink) whenever you reproduce the licenced work. In addition, notice obligations usually require distributions of the work to retain other notices that come with it – for example, copyright assertions, additional disclaimers of warranty or liability, or patent notices. Notice obligations usually at least apply to distribution of the source code, but, depending on the licence, often apply to redistribution of the object code as well. As one example of a typical notice obligation, the MPLv2 licence provides:

You may not remove or alter the substance of any license notices (including copyright notices, patent notices, disclaimers of warranty, or limitations of liability) contained within the Source Code Form of the Covered Software, except that You may alter any license notices to the extent required to remedy known factual inaccuracies.

Source Code Obligations

Reciprocal licences usually include a “source code obligation” that requires anyone distributing the work to include, or at least link to, the source code. This ensures that the software remains in a format that downstream users can continue to modify. Without such a requirement, someone could make changes to software under a reciprocal licence, but only redistribute the object code. This would make it impossible for others to make further changes or re-integrate any of the changes back into the original project.

Although a source code obligation usually goes hand-in-hand with a reciprocal licence, it is worth noting that, in some cases, it may only attach to the originally-licensed code. This becomes particularly important when using software libraries. For example, closed-sourced software vendors can link-to and make use of OSS libraries that fall under a Lesser GNU Public License. As long as the closed-source software merely links to these libraries, the reciprocal obligation does not engage. The vendor has no obligation to release its own source code. However, the source code obligation still applies to the libraries themselves. The vendor has an obligation to redistribute or otherwise provide the original library source code along with the closed-source product.

In some cases, it is not feasible for a person to directly provide the source code along with the object code. If distributing software on a CD or DVD, space constraints may make it difficult to include both – especially considering the fact that source code can be much larger than object code. For this reason, licences are usually flexible about the manner in which you must provide the source code. For instance, the GPLv3 allows a person to provide, in lieu of the source code itself, a written offer to distribute the source code on a separate CD or through a network server. If distributing the object code over the internet, a person may also simply provide instructions on how to download the source code from another internet-connected server.

Reciprocal Licensing

There is one distinctive and commonly-encountered feature of OSS that tends to divide licences into two categories: those with a reciprocal obligation (also called “copyleft”, “share-alike”, or “hereditary”) and those without. Licences in the reciprocal category stipulate that modifications to the software must also come under the same licence. Therefore, if a person makes a change to reciprocal software or includes some reciprocal-licensed code in his or her own software, that person cannot distribute the new work as closed-source software: he or she must only redistribute the new code under the same OSS licence. The GPL, which is the most popular copyleft licence, sets out the rationale for this stipulation as follows:

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code.

Only some OSS licences contain this stipulation: other popular licences such as the MIT, BSD and Apache licences do not. Licences without this stipulation are generally referred to as permissive. In these cases, the author of any modifications is under no obligation to place his or her changes under the same licence, or even under a OSS licence at all. In general, the author of the modifications can even use and redistribute the modified software as a closed-source software application.

However, blurring the distinction between these types of licences, different reciprocal licences stipulate varying degrees of when this reciprocal obligation to distribute under the same licence engages. This is perhaps the most confusing aspect of OSS licences and deserves careful attention. To determine whether a certain activity implicates a reciprocal obligation, one must consider (1) the type of distribution and (2) the extent of integration with the original code.

With respect to the type of distribution, reciprocal obligations only arise upon certain “distribution”-like activities. Where there is no such distribution, the licences almost always allow a person to use and modify reciprocal-licensed software without ever releasing their code. For example, a company can change and customize software under a reciprocal licence for in-house use, and it does not need to share this software or the software source code. However, a “distribution” does trigger a reciprocal obligation to distribute under the original licence. There are two common types of triggers found in OSS licences:

• Distribution of Source or Object Code: Distribution of the software, either through the internet or on a physical medium such as a CD, whether as source code or object code, is the most common trigger for a reciprocal obligation. For example, this is the trigger set out in the popular GPL licence.
• Access over a computer network: Found in the GNU Affero General Public License (AGPL), access over a computer network is a much broader trigger that imposes a reciprocal obligation whenever others access the licensed software over a computer network. This trigger aims to capture web service businesses that run their platforms on OSS – these businesses must make their source code available to others.

Even if the software is distributed, the reciprocal obligations still only extend to certain modifications (depending on the licence):

• Derivative works: As set out in the GPL, this type of reciprocal clause stipulates that the obligation applies to all “derivative works” (the U.S. analog of an “adaptation” under Canadian copyright law, likely with similar scope). The exact boundary of what constitutes a “derivative work” is hotly debated; however, it is clear that a mere “collection” of works does not trigger reciprocal obligations.
• Collections is where multiple software programs are distributed together (such as on the same CD-ROM), but where the programs do not tightly interact.
• Derivative works w/a linking allowance: The most prominent example of this type of clause is that found in the GNU Lessor General Public License (LGPL). This licence is similar to the GPL, but it explicitly allows a person to statically or dynamically link their code to a LGPL software library, without triggering the reciprocal obligation (in software development, “linking” involves a loose coupling where one piece of the software communicates with other software and makes use of its functionality).
• Modified files only: Unique to the Mozilla Public License (MPL), this type of clause only imposes reciprocal obligations on modified files. If a derivative work contains files which are modified versions form the original work, as well as entirely new files, only the directly-modified original files implicate and fall under the reciprocal obligation.

The differences amongst the various licences in the popular GNU suite illustrate how the type of distribution and extent of integration interact to determine when a reciprocal obligation engages, as shown in the following table.

	Derivative work of the original	Derivative work, but only links to original	Collection, including the unchanged original
Distribution of source code or object code	GPLv3: Yes LGPLv3: Yes AGPLv3: Yes	GPLv3: Yes LGPLv3: No AGPLv3: Yes	GPLv3: No LGPLv3: No AGPLv3: No
Provision of access over a computer network	GPLv3: No LGPLv3: No AGPLv3: Yes	GPLv3: No LGPLv3: No AGPLv3: Yes	GPLv3: No LGPLv3: No AGPLv3: No

Managing Licence Obligations

Where reciprocal licensing obligations apply, you do not have the benefit of being able to choose a licence. Your code, to the extent specified in the reciprocal licence, must come under the exact same licence, or, if the licence permits, a later version of the same licence, when you distribute the software. In such a case where you encounter a reciprocal licensing obligation, there are three ways to comply:

1. Do not distribute your software;
2. License your software under the exact same licence (or, where the licence permits, a compatible licence); or
3. Re-implement parts of your software such that it does not include any code or libraries that come under a reciprocal licence (or, at least, ensure that your code does not integrate tightly with reciprocal code such that the obligation engages).

Closed-source software vendors typically opt for solution three when they notice inadvertent reciprocal code, given that they need to distribute their software to paying customers but do not usually want to open up the rest of their source code to others. It is therefore important for these vendors to conduct a “due diligence” audit on their software projects, checking that their software does not include any OSS code or libraries that engage a reciprocal licensing obligation.

Likewise, organizations and businesses releasing their code as OSS should also conduct due diligence audits. Although they are already applying an OSS licence, a reciprocal licensing obligation generally imposes a requirement to license the code under the exact same licence. Thus, releasing code under a different OSS licence may not always comply. It may be necessary to dual-license your own code under the other reciprocal licence, or, in a similar manner to the closed-source context, ensure that the software does not include any code or libraries that engage the reciprocal obligation. Although reciprocal obligations pose the strictest set of parameters, organizations and businesses must also ensure they comply with other licensing terms. For example, they must comply with notice requirements and obligations to distribute the original source code. A due diligence audit ensures that this compliance is in place.

There are two general methods to conduct a due diligence audit: provenance checking and code scanning.

Provenance Checking

Provenance checking involves maintaining a careful audit trail: the developers maintain internal records of what code is in the project, how that code is used, and what licence applies to each element. Some build automation tools such as Maven (which developers use to automate code compilation and deployment) help with functionality to indicate, track, and report licences in a project, thereby assisting and standardizing the task of keeping records.

Looking at the internal audit records, a licensing expert can check a project for compliance either when a developer adds a new external element or upon release of the software (or both). A fresh legal analysis of the licence text is not required for each and every new library imported into a project. Once a licence manager approves use of a particular licence within a project, developers can generally safely use other libraries under the same licence, as long as they use them in a similar manner. For example, a business or organization might establish a policy for a project that: grants automatic approval for specific permissive licences including BSD, MIT and Apache; grants approval for weak reciprocal licences such as the LGPL on a case-by-case basis; and grants approval for strong reciprocal licences, such as the GPL, only after a careful and thorough legal analysis.

Automated Code Scanning

In many cases, provenance checking should prove sufficient for smaller projects. However, it may prove impractical for larger companies or larger projects. A large company often owns code purchased from other parties, or code received from acquisitions and mergers, that may have no accurate licence audit for the code. In this case, it is best to use automated code scanning tools that search through the entire code base to determine the licences that apply. Automated code scanning utilities search text files and embedded code comments that may indicate the licence applicable to a particular element of the software. Some tools even compare the code itself against known third-party OSS code.

Of course, while these tools can prove highly useful, it must be kept in mind that the results do not provide certainty that the source code is under only the reported licences, nor that it is free of copyright or patent infringements. An inherent limitation of the audit is that it can only compare the client’s source code to a wide, but not exhaustive, collection of other source code repositories. It may not detect copyrighted source code from closed-source vendors, or source code from smaller OSS projects. Where possible, businesses and organizations may also wish to reduce their risks and ease the auditing task by using software libraries from trustworthy organizations that have already audited the library code.

Patent Management

All of the OSS legal considerations which apply when using OSS equally apply when you distribute OSS. For code that you distribute, the lack of a disclaimer and warranty can work in your favour. The lack of a choice of forum or choice of law clause generates equal legal uncertainty for all parties. In addition to these legal issues, OSS distribution raises concerns related to patents. By licensing your code under a OSS licence, you may either implicitly or explicitly license the patents you own if any of the code implicates them. It is important to understand the nature and scope of the patent licences you grant.

Patent Licence Scope

The treatment of patents varies greatly throughout different OSS licences. The traditional approach – still seen in popular permissive licences such as BSD and MIT – is an implicit patent licence: the licence makes no specific mention of patents, but rather the stated right to use the software implicitly grants the licensee permission to “use” any relevant patents held by the licensor. An implicit patent licence almost certainly grants others the right to use the original code as distributed, including where such use implicates patent held by the licensor. However, the scope of an implicit patent licence becomes less clear when downstream parties modify the original code. If the modifications change the typical “use” of the software, does the original patent licence still cover a use that is different from what the licensor originally intended? If a new use infringes a different patent held by the original licensor, does the broad grant of rights to make modifications also end up licensing this other patent? Most likely, the answer to these two questions in “no”: the implicit patent grant often covers only uses implicated by the licensor’s original contributions, but not other uses that additional features and modifications might involve. Most modern OSS licences attempt to increase clarity and legal certainty by making this scope limitation explicit. For example, the Apache Version 2.0 licence provides:

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.

Under this clause, the patent licence only extends to uses of the software applicable to existing contributions. Where further downstream contributions alter the software’s use, the original patent licence may no longer apply.

Although a OSS licence could feasibly grant a broader patent licence that would cover downstream modifications, no popular licences presently take this approach. Not even the highly freedom-assertive GPLv3 licence makes such a grant. Given the nearly limitless number of ways that additional features could alter the typical use of a software application, such a broad patent licence is likely untenable for most businesses managing a patent portfolio.

Therefore, as a best practice, whenever you modify OSS you should consider whether the modifications change the use of the software in a way that might implicate other patent licences, or in such a way that existing patent licences may not cover the new use.

Patent Termination and Retaliation Clauses

Many OSS licences attempt to protect the software against patent infringement lawsuits by including automatic-termination clauses. These clauses trigger whenever a licensee alleges that any part of the software infringes his or her patent. For example, the Apache Version 2.0 Licence succinctly states:

If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

These triggers differ amongst licences. For example, unlike the Apache Version 2.0 licence, the Mozilla Public License Version 2 (MPLv2) explicitly allows parties to defend themselves with patent infringement counterclaims and cross-claims, all without triggering the termination clause.

Some licences also include broader retaliation clauses - that is, a broader termination of rights. The Apache Version 2.0 patent termination clause, set out above, only terminates patent licences. The MPLv2, on the other hand, terminates all rights under both copyright and patent law. When involved in patent infringement litigation, whether initiating an originating action or a counterclaim, it is important to carefully assess the impact this could have on any OSS that you use or towards which you contribute.

Legal Risk Management

Lack of a Warranty

A warranty is an assurance by a vendor that a product will operate as promised and without any defect. A warranty can also include assurances that a product is free of legal encumbrances, such as unlicensed intellectual property that may be owned by third parties (i.e., a warranty of non-infringement). Depending on the terms of the warranty, when a product does not fulfill the assurances, the customer can request that the vendor fix the product, refund the customer and/or provide monetary compensation.

Given the typical lack of a warranty in an OSS licence, it becomes more imperative for a business or government organization to secure external support contracts. An OSS support services business familiar with the software can help resolve any issues and, importantly, directly patch any bugs that crop up.

Some support services businesses also help mitigate the risks that can arise due to the lack of a warranty of non-infringement. For example, Red Hat offers customers the Red Hat Open Source Assurance Program and Canonical provides the Ubuntu Advantage Assurance. Both of these programs provide services to replace any portion of their respective Linux distributions (Red Hat and Ubuntu) that turn out to infringe intellectual property rights of other parties. Additionally, these programs also offer to indemnify customers against any lawsuits they face as a result of any such intellectual property infringements.

Disclaimer of Liability and Lack of Indemnification

Where a licence or contract contains no disclaimer, a licensee can ordinarily hold the licensor civilly liable for losses suffered due to any negligence in the software design, implementation or testing. Further, where a licensor agrees to indemnify the licensee, if another party (most often, a customer of the licensee) sues the licensee for damages and the cause of the damages can be traced back to the original licensor’s software, then it is the licensor who must ultimately pay a damage award.

However, given the disclaimer of liability and lack of indemnification clause in a OSS licence, organizations and businesses cannot shift or “flow through” their civil liability risks to the vendor. The disclaimer means that you cannot generally recover compensation from the vendor for damages that arise due to problems with the software. The lack of indemnification means that, if other parties suffer losses due to problems involving your use of the software, you risk liability and cannot shift this risk onto the original software vendor.

Overall, the indemnity clauses in closed-source software licences function similarly to insurance: they cover your losses when third parties sue you. Therefore, when it comes to OSS, companies and organizations may wish to consider insurance as a substitute for an indemnity clause. Instead of the software vendor insuring against legal liability, an insurance provider does the same.

No Choice of Law or Choice of Forum Clause

One other difference that OSS users should keep in mind is that OSS licences rarely include choice of law or choice of forum clauses. Closed-source licences may specify that courts shall interpret the licence and resolve disputes pursuant to the laws of a particular country or jurisdiction (choice of law) and that lawsuits shall be heard by courts in a particular jurisdiction (choice of forum). Where these remain unspecified in OSS licences, courts will apply standard conflict of law rules to determine the appropriate law and the appropriate forum in a particular context. This increases the uncertainty of whether you may have to litigate a lawsuit in a foreign jurisdiction, or under unfamiliar laws – which would involve higher litigation expenses.