Canada: An Open Source Eye-Opener: The Basics of Open Source

As open source software (OSS) continues to mature and move into the mainstream, businesses are under increasing pressure to understand what OSS is and how it is used and licensed. What makes OSS different from proprietary software is the unique structure under which it is developed, licensed and distributed. Source code for OSS must be made freely available for use or modification as users or other developers see fit; typically, with proprietary software, only the object code is made available and modifications thereto are prohibited. Open source proponents are quick to point to the potential rewards and benefits associated with OSS, including a reduced development cycle, lower development costs, improved product reliability and stability, lower costs, increased flexibility and decreased vendor "lock-in". However, the use of OSS presents a number of legal risks which a business needs to consider in order to ensure that these risks are appropriately managed within its enterprise.

OSS is characterized by being subject to a license agreement which requires upstream developers to make the source code for the OSS available to downstream licensees and to permit such downstream licensees to use, modify and redistribute that source code. Modifications made to that source code, if distributed, are to be licensed on the same basis. It is important to recognize that OSS is not "public domain" software, as OSS continues to be subject to copyright protection. Similarly, OSS is not "freeware", which is software that is offered at no cost, but which may be subject to license restrictions, including restrictions which may prohibit the modification or redistribution of the software in question.

One definition of "open source" is that of the Open Source Initiative (OSI), a non-profit corporation which manages and promotes its "Open Source Definition" through a certification program and certification mark. Developers of software that is intended to be freely shared and possibly modified and redistributed by others may use the OSI’s certification mark if the associated distribution terms comply with certain criteria established by the OSI. In summary, the OSI’s "Open Source Definition" model of distribution terms require that:

• the software be freely redistributable, whether it is sold or given away;

• the source code for the software be made available in the preferred form in which a programmer would modify the software;

• the software be freely modifiable, with any modifications being distributable under the same terms as the license of the software itself;

• the license may require modified versions of the software to carry a different name or version from the original software, so as to preserve the integrity of the author’s source code;

• the license not discriminate against any person or group of persons or restrict anyone from making use of the software in a specific field of endeavour;

• the rights associated with the software apply to all downstream distributees of the software, without the need for execution of an additional license by such distributees;

• the rights associated with the software not depend on the software being part of a particular software product distribution;

• the license not place restrictions on other software (including proprietary software) that is distributed along with the licensed software; and

• the license be technology-neutral in that it may not be predicated on any individual technology or style of interface.

There are currently over fifty different forms of open source licenses which have been certified by OSI. These include the earlier, well known and widely used GNU Public License (frequently referred to as, the "GPL"), the BSD License and the MIT License, and the more recent and widely used Mozilla Public License, under which Netscape made its browser source code freely available. As the provisions in these licenses vary considerably, prior to licensing software subject to the terms of any of these licenses, software developers and users alike should ensure that they understand the terms and conditions of the particular license in question to ensure that such terms and conditions accord with their respective business objectives and do not result in exposure to undue risk.

Any business considering the procurement of OSS must recognize that in addition to the diligence which is customarily used in a proprietary software acquisition, there are a number of special considerations which need to be addressed in an acquisition of OSS. The following are some of the legal risks and considerations which a business should contemplate before procuring OSS:

Review of License Terms. As a starting point, it is essential that all of the particular license terms for the OSS product be determined and then reviewed for acceptability. As previously stated, although most open source licenses share familiar traits, each license will have its own specific provisions. Further, it is possible that the OSS product may be distributed together with proprietary software components which would be subject to "proprietary" license terms or with other OSS components which are licensed subject to different open source license terms. Once the particular license terms for the OSS product have been determined, the procuring business should ensure that the manner in which the OSS product is intended to be used within its enterprise falls within the scope of such license terms.

Unintentional Licensing of Business’s Modifications to OSS. Under many open source licenses, including the GPL and the Mozilla Public License, if a business makes modifications to the OSS, it must license such modifications on the same terms as the license of the original OSS. Under almost all open source licenses, this means that the business must make the source code available for any modifications for which it distributes the object code. This "reciprocal licensing" obligation may curb a business’ enthusiasm for devoting substantial time and resources on developing modifications to the OSS, as the business will not be able to maintain the source code for such modifications as proprietary software.

Unintentional Licensing of Proprietary Software Distributed Together with OSS. A business which intends to distribute OSS in conjunction with a proprietary software product needs to be vigilant about the manner in which the OSS and the proprietary software are distributed, as there is a risk that the business will not only be required to distribute the source code for the OSS itself, but also for the proprietary software. Many open source licenses (including the GPL) are often described as "viral", which means that by introducing code which is subject to a viral license into a program, the program as a whole will then be subject to that viral license. This means that if a business distributes proprietary software "in combination" with OSS which is subject to a viral license, the business is obligated not only to distribute the source code for the OSS components therein, but also for the proprietary software components. Although the GPL is clear that "mere aggregation" of proprietary software not based on the OSS with the OSS (or a work based on the OSS) on a volume of a storage or distribution medium does not bring the proprietary software within the scope of the GPL, it is not clear under the GPL what constitutes "combining" proprietary software and OSS. Failure to distribute the source code for such proprietary software could result in the business being subject to an injunction prohibiting the business from continuing to distribute the "combined" software, a monetary damages award and possibly even an order requiring the business to disclose the source code for the proprietary software components included in the "combined" software. Accordingly, a business will want to carefully consider the ramifications of distributing OSS in conjunction with proprietary software. A key factor in any decision to "combine" OSS with proprietary software will be the license terms associated with the OSS. It is possible that the OSS may be subject to non-viral licenses, such as the BSD License, the MIT License or the Apache Software License.

Increased Risk of Intellectual Property Infringement. OSS results from the collaborative efforts of a number of software developers, many of whom may not appreciate the legal consequences of including third party software in their contributions to the OSS. For example, a software developer may include in his contribution to the OSS a program that he developed in the course of his employment. He may not realize that, although he may have authored the program, his employer is in fact the owner of the copyright in such program. Therefore, only the employer, as the copyright owner, would have the right to license the copyright in the program. Accordingly, by using the program without the authority of the copyright owner, a business would infringe the copyright in the program. It is interesting to note that the GPL only applies to "any program or other work which contains a notice placed by the copyright holder saying that it may be distributed under the terms of this General Public License". Thus, if the notice is placed by a person other than the copyright holder, the GPL, under its own contractual terms, would not apply. Although the risk of copyright infringement exists in the proprietary software realm, because the development process for proprietary software tends to be more tightly controlled by the vendor, and often involves processes to ensure that unauthorized third party software is not included, the risk of copyright infringement is decreased.

In addition to an increased risk of copyright infringement, the use of OSS may also present an increased risk of patent infringement. Proprietary software vendors are more likely to be aware of third party patents which might be infringed by the exploitation of their proprietary software and may therefore seek to avoid infringing such patents in the design process. The same patent due diligence is not likely to be undertaken by each upstream developer of OSS, which could increase the risk of patent infringement.

No Warranties. Proprietary software licenses often include limited warranties in favour of the licensee. Generally, the warranties are intellectual property related. For example, it is not uncommon in a proprietary software license for a licensor to warrant that the software is an original work of the licensor, that the licensor has the right to grant the license being granted and that the software is free from viruses. On the other hand, OSS is typically licensed on an "as is" basis, without warranty of any kind. In fact, the GPL requires the licensee to publish on each copy of the licensed source code a disclaimer of warranty, the BSD license template includes a disclaimer of warranty and the Mozilla Public License requires that a form of notice containing a disclaimer of warranty be duplicated in each source code file distributed.

To the extent that a business wishes to rely on a disclaimer of warranty included in an open source license, the business should recognize that the disclaimer may not in fact be enforceable in Canada, which may lead to unexpected liability for the business. While open source licenses typically disclaim implied warranties of merchantability and fitness for a particular purpose, they do not disclaim any implied conditions of fitness for purpose or of merchantability, which are implied into certain contracts of sale by various Canadian provincial sale of goods legislation.

No Indemnities; Broad Exclusion of Liability. A proprietary software licensor is often willing to indemnify the licensee against certain third party claims for intellectual property infringement and generally excludes liability for all types of damages, except direct damages. On the other hand, open source licenses do not typically provide intellectual property infringement indemnities.

Open source licenses frequently include exclusions of liability for all types of damages, including direct damages. The GPL attempts to exclude liability for all types of damages "arising out of the use or inability to use the program", but does not expressly exclude liability for all types of damages "howsoever caused". The BSD License attempts to exclude liability for all types of damages "however caused". The Mozilla Public License, in contrast, only attempts to exclude liability for "indirect, special, incidental or consequential damages", but does not attempt to exclude liability for direct damages.

As with any exclusion of liability, particularly any exclusion of liability which seeks to exclude liability for all types of damages (including for death or personal injury), it is possible that exclusion of liability provisions contained in open source licenses are not enforceable. Exclusion or exemption provisions, particularly those found in contracts of adhesion such as open source license agreements, will be strictly construed against the party benefiting from the provision.

No Moral Rights Waiver. In Canada, the "moral rights" of an author in a copyright work are protected under the Copyright Act. Specifically, the Copyright Act grants authors the right to the "integrity of the work". Such right to integrity is infringed if the work is, to the prejudice of the honour or reputation of the author, distorted, mutilated or otherwise modified; or is used in association with a product, service, cause or institution. In addition, the Copyright Act provides authors the right, where reasonable in the circumstances, to be associated with the work as its author by name or under a pseudonym and the right to remain anonymous. Under Canadian copyright law, moral rights may not be assigned, but may be waived; an assignment of copyright in a work does not by that act alone constitute a waiver of any moral rights in the work.

Open source licenses generally force authors to implicitly waive their moral rights in and to software they develop. First, authors are forced to implicitly waive their right to the integrity of the work because most open source licences (i) require the author to permit modifications to be made to his or her software (even if such modifications are made to the prejudice of the honour and reputation of the author); and (ii) are predicated on the OSI’s Open Source Definition model. That model requires that (a) the license not discriminate against any person or group of persons or restrict anyone from making use of the software in a specific field of endeavour; (b) the rights associated with the software not depend on the software’s being part of a particular software product distribution; and (c) the license not place restrictions on other software, including proprietary software, distributed along with the licensed software.

Second, authors are forced to waive their right "to be associated with the work as its author by name or under a pseudonym and the right to remain anonymous" because most open source licences are predicated on the belief that users have a right to know who is responsible for the software they are using. The GPL expressly requires that any modified files carrying prominent notices which identify the name of the person who made the modifications. Identifying oneself as a contributor is optional under the Mozilla Public License. Thus, open source licensing models may in fact lead to the infringement of the moral rights of the author.

Uncertainty About Governing Law. Many open source licenses do not include any governing law provision. For example, none of the GPL, BSD License, MIT License or Apache License 2.0 include any governing law provision, although the Mozilla Public License specifically states that it shall be governed by California law. Absent any governing law provision, given that an OSS product may include numerous contributions made by different authors from around the world, it is unclear as to what law will govern the construction of the terms and conditions in the license. Further, in light of the potential chain of upstream developers and downstream licensees in the open source context, a host of interesting procedural and jurisdictional issues arise in connection with the enforcement of claims under open source license agreements, such as who has standing to sue, who must be made party to the proceedings and whether a court will assume jurisdiction over a defendant.

Uncertainty About Enforceability of OSS Licences. Open source licenses tend to be in the form of "shrink-wrap" or "Web-wrap" licenses. Accordingly, open source licenses are subject to the same uncertainty regarding enforceability as "shrink-wrap" or " Web-wrap" licenses. The question at the heart of the issue is whether the parties to the license have assented to the formation of a contract, so as to create a binding contract. In determining whether an open source license is enforceable, courts may typically look to whether the user’s acceptance of the license terms has been demonstrated in some manner, particularly by his or her conduct (such as clicking on an "I agree" icon) or whether a reasonable attempt has been made to make the license terms known to the user and whether such user has had a reasonable opportunity to read such terms.

Although OSS presents a number of risks, most of these risks, if appreciated and understood prior to the procurement of OSS, can usually be managed by establishing formal procedures and policies governing the licensing, procurement and use of OSS, and implementing appropriate systems for tracking how OSS is actually used within the business. Even if a business decides not to adopt OSS solutions, in contracts for the procurement or development of proprietary software, the business should at a minimum consider adding appropriate "open source" representations and warranties regarding the non-incorporation and non-combination of OSS into the software being provided and regarding the non-use of OSS in a manner that would subject such software to any open source license terms. Given the ever increasing pervasiveness of OSS in the commercial marketplace, businesses are well advised to understand open source risks and to determine a strategy for managing such risks sooner rather than later.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.