Legal issues that companies should be aware of when using open source software (Taiwan)

Elva Chuang[1]

Open source software has become the norm for enterprise IT departments around the world

Open source software is by nature a type of computer program, which is still a type of work regulated and protected by the Copyright Law and whose distribution is also restricted by the terms of its license agreement.  Open source software is different from general commercial software primarily in the terms of its license agreement.  The terms of the license agreement for general commercial software are mainly based on the receipt of royalties, while the terms of the license agreement for open source software are mainly premised that the licensor shall maintain the freedom and openness of the open source software program.  An open source license agreement has the following main characteristics:  The software source code should be made public at the time of distribution, and open source code software should be made freely available for download, use, duplication and modification by other users, and may be freely distributed to third parties for any purpose.[2][3]

Due to the prosperous development and application of the Internet, more and more people can participate in the development and editing of open source software through online collaboration tools, and because the development of open source software is participated by a multitude of people, the speed of open source software optimization and innovation is sometimes even faster than that of commercial software developed by ordinary enterprises.  In recent years, more and more software companies, such as Apple and Microsoft, have opened up the source code of their underlying technologies in order to save their own development costs and widen the application of their products.  According to Sonatype’s Software Supply Chain Status Report 2020, over 1.5 trillion open source software components and software units have been requested for download by developers worldwide in 2020, demonstrating the current high usage of open source software.

Common types of open source software license agreements

There are many types of open source software licenses, and they are classified according to the “degree of freedom to modify and release the program” (also called the “copyleft” effect).  Currently, common open source software license agreements may be roughly categorized based on their copyleft effect as follows:

Copyleft
Effect
Strongest Compromise Weakest
Type/ characteristics of the Agreement A license agreement that guarantees the original source code and modified version as open source software. Compromise-type license agreement, seeking to balance the concerns of proprietary and open-source developers A license agreement that grants the licensee the right to freely use the software
Examples
  • GNU General Public License(GPL)
  • Mozilla Public License(MPL)
  • GNU Library or Lesser General Public License(LGPL)
  • APACHE
  • Berkeley Software Distribution License(BSD)
  • MIT License(MIT)

GPL type license agreement

In comparison with most open source license agreements, the GPL-type license agreement has the strongest copyleft effect.  The most important spirit of this type of license agreement is that “for the software to which the GPL license agreement applies, the revised version or derivative works of the software should also be distributed or licensed out by applying the same terms of the GPL license agreement.”  Take GPL v.2, which is one of the most popular types of GPL license agreement, for example. The GPL v. 2 license agreement has 12 articles, of which the more important ones are Article 0, which explicitly states that the objects protected under the GPL license agreement include any program or other work which contains a notice placed by the copyright holders saying it may be distributed under the terms of this GPL, and the “Program” under this agreement refers to any such program or work, and a “work based on the Program” means either the Program or any derivative work under copyright law.  Besides, according to article 2 of the GPL v.2 license agreement[4], if the Licensee wishes to modify the original program, it must meet three requirements: (1) the Licensee must cause the modified files to carry prominent notices stating that you changed the files and the date of any change; (2) the Licensee must cause any work that it distributes or publishes, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License; and (3) If the modified program normally reads commands interactively when run, the Licensee must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that the Licensee provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License.  (Exception: if the Program itself is interactive but does not normally print such an announcement, the Licenses’ work based on the Program is not required to print an announcement.)  However, the above restrictions on dissemination shall not apply to the act of mere aggregation dissemination.” Pursuant to the above terms, the GPL v.2 license agreement shall apply even if the future license is only for “works based on the original program,” and no fees may be charged for this license in accordance with Article 2 of the GPL v.2 license agreement.

Article 3 of GPL v.2 ensures the licensee the right to distribute its works in object code or executable form, provided that it must agree to provide unconditional public access to the source code.  Other terms and conditions include the requirement to indicate the original copyright holder and the indication that no warranty is provided.  If the licensee violates the terms of the GPL license, all rights under the license agreement will be terminated and the licensor may prohibit the licensee in violation from continued distribution and modification of the original program and its derivative works.

MPL license agreement

The MPL license is the license used by Netscape[5] in 1988 to make public the source code of its Netscape web browser.  Compared to the GPL type, its copyleft effect is slightly weaker.  The major difference between the MPL license and the GPL type is that “if the licensee has not made any changes to the software licensed under the MPL license, the licensee may distribute the software or the combined software under any license conditions.”  In other words, in case the licensee has not modified the original software and the original license agreement is used, the licensee has new copyrights to the software licensed by MPL, and the licensee may sublicense the software using another license agreement.[6]

BSD license Agreement

The BSD (Berkeley Software Distribution License) license agreement is practically the most widely used license agreement originated from the University of California at Berkeley.  The BSD license agreement only requires the licensee to identify the original copyright holder when distributing the software, indicate a disclaimer of warranty, and not to endorse or promote the modified derivative software in the name of the original licensor without any further obligation.  The BSD license agreement does not require that derivative works be distributed under the same license terms as a GPL-type license agreement, nor does it require that no fees be charged.

Legal issues and coping strategies for the use of open source software by enterprises  

With the increase of the utilization rate of open source software, relevant legal risks also come along.

In recent years, there has been a trend for engineers to use open source software, and for companies to use both open source software and self-developed software to provide products and services.  With the increase of the utilization rate of open source software, relevant legal risks also come along.  Due to the free-distributing nature of open source software, anyone should be able to obtain open source software very easily (and mostly without compensation) and modify the source code of the software so obtained, but open source software is not in public domain and its copyright holders still own the copyright to the open source software and are protected by copyright-related laws and regulations.  Therefore, users have the right to modify and distribute open source software only in accordance with the terms of the license agreement.

Currently there are several relevant court cases in foreign countries where the validity of open source license agreements were recognized.  For example, in 2006, the German subsidiary of D-Link sold NAS products whose driver used software licensed under the GPL license.  Since D-Link did not include a disclaimer of warranties as required by the terms of the GPL license and did not provide the source code of the driver and the full text of the terms of the GPL license, Welte, the copyright holder, filed a complaint.  Ultimately, D-Link lost the lawsuit and was required to recall the products it had sold.

It is recommended that an enterprise conduct certain due diligence before using open source software, formulate an internal policy on the use of open source software as early as possible, and conduct regular training and education of internal employees.

Since the development of open source software may incorporate contributions from many people, if any of the contributors improperly uses another person’s software patents or other proprietary software in the open source software, the entire open source software may be involved in an IP right infringement lawsuit.[7] In addition to the aforementioned risks of IP right infringement, an enterprise’s use of open source software developed by others may involve risks such as virus infection or the forced disclosure of an internal confidential program since it may require specific license terms.

In view of the above-mentioned case, an enterprise should first review the license agreement adopted for the individual open source software, including the assessment of whether the derivative work the enterprise intends to create may potentially include confidential code and of whether it is necessary to adopt a strategy to separate the distribution of the source code licensed under GPL from that of the source code not licensed by GPL to ensure that the enterprise does not infringe when distributing open source software in compliance with relevant terms of the license agreement.  If it knows in advance that the open source software involves the intellectual property rights of others, it should obtain the permission of the rights holder or find an alternative solution.  But if the enterprise has difficulty knowing whether the open source software to be used may involve the rights of others and use of the open source software is inevitable, it may consider proper diversification of risks through an insurance mechanism.

In practice, there are companies that adopt prior self-verification before using open source software and require their downstream vendors to provide “open source code included in the product” when purchasing software to verify that each element in the supply chain has fulfilled its open source obligations.  However, the enterprise self-verification may incur certain time and monetary costs.  In addition, there are also enterprises that acquire open source code from enterprises that meet a specific third party standard (such as OpenChain[8]) to ensure that the code as used has followed strict legal compliance procedures.

Finally, it is recommended that relevant operators should formulate an internal policy on the use of open source software as early as possible, and conduct regular training and education of internal employees so that they are familiar with the company’s policies and procedures for using open source software and the consequences of violating open source licenses.  Only through assessment and control of risks associated with the use of open source software in advance can the enterprise truly avoid irreparable harm to the company as a result of any improper use of open source software by internal engineers and truly enjoy the value brought by open source software.

 

[1] The author is a lawyer at Lee, Tsai & Partners.  However, the contents of this article merely reflect personal opinions and do not represent the position of the law firm.

[2] St. Laurent, Andrew M. (2008). Understanding Open Source and Free Software Licensing. O’Reilly Media. p. 4. ISBN 9780596553951., cited from Wikipedia at https://en.wikipedia.org/wiki/Open-source_software, last browse date: November 16, 2020

[3] The Open Source Initiative, a California-based non-profit organization founded by programmer Bruce Perens in 1998, focuses on protecting and promoting open source software, development and communities, and has defined open source software.  According to the introduction on the official website of the Open Source Initiative, the following ten criteria must be met for the distribution of open source software: (1) free distribution; (2) open source code; (3) derived works; (4) integrity of the author’s source code; (5) no discrimination against persons or groups; (6) no discrimination against fields of endeavor; (7)distribution of license; (8) license must not be specific to a product; (9) license must not restrict other software; and (10) license must be technology-neutral.

[4] Open Source Initiative, GNU General Public License version 2, Source:  https://opensource.org/licenses/GPL-2.0, last browse date: November 16, 2020

[5] Announcements – Updating the MPL. Mozilla Foundation. Source: https://web.archive.org/web/20120313153018/https://mpl.mozilla.org/announcements/, last browse date: November 16, 2020

[6] See Chih-chieh Yang and Hsien-lung Li, Legal and Strategic Analysis on Open Source Code License Agreements, Intellectual Property Rights Journal, Issue 58, October 2003

[7] Yi-chan Chang, Exploration into the Business Model for Open Source Code Software and Relevant Legal Issues, June 6, 2006, Page 156

[8] OpenChain, URL of its official website: https://www.openchainproject.org/, last browse date: November 7, 2020