While open source software is free and has several advantages, it does have compliance and licence requirements, as well as intellectual property rights. It is important that companies are aware of these.
Compliance of open source software is often overlooked by companies. They do not ensure compliance before shipping their products or services or releasing updates. Ignoring baseline compliance requirements and procedures can lead to serious consequences for companies, especially during future revisions of the product (or other products/services that use code from the initial baseline).
Non-compliance not only exposes companies to the risk of litigation, they also stand to lose hefty amounts as damages. Loss of reputation and rewriting of software are some of the other unavoidable repercussions. Further, companies may have to withhold the marketing, sale or distribution of products and services until the compliance requirements are met, the consequences of which can be more damaging than the monetary payouts.
Once the product or service is shipped, it becomes challenging to identify any non-compliance unless the company has a software bill of materials (SBOM). But even then, there is no denying that extensive time and cost will be incurred in becoming compliant. Therefore, every company should focus on putting in place a process to ensure compliance before its products and services are shipped to stakeholders (internal or external).
Non-compliance may prove costly
Non-compliance has led to several disputes in the past. Settlement terms have often included taking necessary steps to become compliant or taking corrective measures. These can be costly in terms of the engineering efforts and product launch timelines, ceasing binary distribution of the open source software in question, appointment of a compliance officer along with continued monitoring of the compliance process, notifying previous recipients of the non-compliant product, publishing licensing information, making source code and modifications available, and paying undisclosed amounts as damages to the claimant.
Also, defending the non-compliance in courts of law as well as paying the damages could affect company revenue. Open source non-compliance can also lead to loss of reputation and dent the brand name.
Though ensuring open source compliance is primarily the responsibility of the legal department, the obligation lies with every department of the company. Thus, open source compliance is a process-driven exercise where several departments have to be involved — for example, legal, intellectual property, sales, marketing, engineering, development and procurement.
Compliance process
Companies should implement an end-to-end process for ensuring open source compliance. And framing an open source policy is the first step in establishing the open source governance process. The policy should be internally communicated and should be flexible.
For this, companies should:
- Identify the source code, libraries, and snippets to be used.
- Audit the source code using tools for scanning dependencies, licences, etc, and resolve conflicts and issues. They must undertake code and licence reviews by using tools to understand the open source licence. Bona fide checks need to be undertaken at the developer level. A decentralised methodology of conducting reviews will help save considerable amount of time and potential headaches. FOSSology helps run licence, copyright and export control scans from the command line or Web user interface. In one click you can generate an SPDX file, or a ReadMe with the copyright notices from your software.
- Identify and map all the software used in products or services using the SBOM. SBOM assists in identifying, tracking, and managing the open source components used. A good SBOM will list not only the open source components but also the versions used, and download locations for each project and all dependencies. SPDX is an open standard for communicating SBOM information between organisations. The SPDX document provides machine-readable information such as version number, licence for data and authors; package information like product, container, component, and packaged upstream projects; file information containing name, licence and copyright information; snippet information; and licence information.
- Review the obligations under each licence, with the help of the legal department.
- Develop open source use and distribution policy, and procedures for use within the company. The policy should be made available to all internal stakeholders. The roles and responsibilities of the legal, intellectual property, engineering, technology, etc, teams should be clearly outlined.
- Mitigate risks through processes and best practices.
- Train employees from legal, intellectual property, engineering, as well as product, sales, marketing, procurements, and quality assurance teams on open source compliance. Even those responsible for bringing open source components into the company, using these components, developing new products or services, maintaining existing products and services, and interacting with external parties about existing and upcoming products and services, should be aware of their role in ensuring open source compliance.
Open source compliance in the software supply chain
The software supply chain includes various stakeholders, viz., open source software communities, software suppliers, original equipment manufacturers (OEMs), vendors providing an SDK, and the final product entity. If any member of the supply chain fails to comply with licence obligations or fails to provide appropriate licence information, it will significantly impact the vendor who is obligated to comply with the licence.
OpenChain Project
The OpenChain Project of Linux Foundation builds trust in open source by making open source licence compliance simpler and more consistent. The OpenChain Specification (1.0, 1.1, 1.2, 2.0 and 2.1) defines a set of requirements that every quality compliance programme must satisfy. In fact, OpenChain specifications 2.0 and 2.1 are functionally identical to ISO/IEC 5230:2020. The OpenChain Conformance allows organisations to demonstrate adherence to these requirements. The Open Chain Curriculum supports this process by providing extensive reference material for effective open source training and management. As a result, open source licence compliance becomes more predictable, understandable and efficient for all participants in the software supply chain.
Compliance failures
Some common open source compliance issues are:
- Failure to provide copyright notice. A copyright notice on copies of work indicates the copyright ownership. For instance, Monta Vista sued Lineo for distributing software written by the former without the copyright notice.
- Failure to provide licence notice. A licence notice contains the open source licence text included in the product or stack, and is usually provided with product documentation and/or within the product or application user interface. For example, the MIT licence notice reads: “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the software.”
- Failure to provide attribution notice. An attribution notice has to be provided as a text file together with the open source component that provides the acknowledgement as supplied by the contributors of open source components.
- Failure to provide modification notice. A modification notice calls out modifications to the source code in a change log file. For instance, GPLv2 states: “You must cause the modified files to carry prominent notices stating that you changed the files and the date of any changes.”
- Failure to provide the source code. Certain licences require the source code to be provided. In the Welte vs Fortinet UK Ltd. (2005) suit, a preliminary injunction was sought against Fortinet prohibiting distribution of its products in the absence of a GPL code. Fortinet eventually agreed to make the source code in its products available under GPL.
- Failure to provide a written offer to end users with open source code in case of GPL/LGPL.
- Failure to provide scripts needed to compile the source code in case of GPL/LGPL.
Code scan
The code should be scanned and approved each time a developer modifies a previously approved component in a different context. Licences can change between different versions of the same inherited software component.
For example, React was initially licensed under Apache 2.0. In October 2014, React 0.12.0 replaced this with the 3-clause BSD licence and added a separate patent text file. Finally, on September 26, 2017, React 16.0.0 was released under the MIT licence.
Global trends in open source compliance enforcement
Community enforcement: The first set of open source enforcement cases were filed by community enforcers. From 2007 to 2009, the Software Freedom Law Center filed suits on behalf of Busy Box Principal Developers against various entities including Samsung, Verizon, BestBuy and Westinghouse for violations of the GNU GPLv2. The sole objective of these litigations was to ensure compliance.
Similar instances of community enforcement were also seen in Europe. Notable amongst the cases is the gpl-violations.org suit against D-Link in the District Court of Frankfurt in 2006.
Company/competitor enforcement: CoKinetic Systems Corporation sued its competitor Panasonic Avionics Corporation claiming US$ 100 million for violation of GPLv2. GPLv2 requires reciprocal disclosure of the source code. Panasonic had allegedly refused to distribute the source code, and in turn, was accused of blocking its competitors (CoKinetic and others) from developing software for in-flight entertainment, along with other malpractices to monopolise the business. CoKinetic alleged that Pansonic’s refusal to distribute the source code was a blatant violation of the rights of numerous developers who have contributed to Linux. The case was eventually settled out of court.
Copyright troll enforcement: Patrick McHardy, an erstwhile contributor to a Linux project, has had the reputation of profiting from copyright claims. Copyright trolls are on the lookout for companies which, often unknowingly, violate the terms of GPL. Such violations are bound to happen when companies embed third-party software into their own services and products without realising that they need to buy licences before using the software.
Dual-licence product enforcement: Businesses often use dual-licence software. Such licensing structures allow them to use/modify/distribute the software with some restrictions such as the requirement to comply with an open source licence, or without those restrictions upon payment of a fee to obtain a commercial licence. Sometimes, the open source licence for dual-licence software prohibits its commercial use and distribution without a commercial licence. Businesses may mistakenly believe that since the software is available under the open source licence for personal use or hobbyists, it can also be used under the open source licence for commercial purposes. This leads to numerous lawsuits, most of which never end well for the infringer. Artifex, the developer of Ghostscript, an open source PDF interpreter, filed a suit against Hancom, a Korean developer of office apps. Hancom had used Ghostscript for developing and distributing an application without purchasing a commercial licence. No surprises here – Hancom lost the lawsuit.
User enforcement: End users of a product, which has an underlying open source code protected under GPL, may be able to seek open source compliance enforcement. For instance, AFPA sued Edu4 with the help of an open source advocacy group, FSF France, to enforce GPL after Edu4 refused to make its software source code available. Generally, only copyright owners have the right to sue. However, GPL recognises the right of end users too.
Customs enforcement: Enforcement through customs may also be initiated. Various countries have empowered customs authorities to issue directions to seize goods at the border, which infringe intellectual property rights.
Section 337 of the US Tariff Act, 1930, empowers the US International Trade Commission to issue orders directing infringing goods to be excluded from import into the US. The Indian Customs Act, 1962, prohibits import of goods that infringe intellectual property rights. Section 11 of the Act empowers the Central government, for the purposes specified in subsection 11(2), to prohibit import or export of goods of any description by issuing a notification.
Software distributors beware
Many open source licence obligations like providing copyright notice and source code are triggered by distribution. The term distribution has special importance in software as a service (SAAS), but has different interpretations in different jurisdictions. Most licences were written before the emergence of the SAAS model. However, Section 13 of AGPL closed the GPL SAAS loophole by obligating companies to make their source code open and available to the public when using AGPL components on a server connected to the network. AGPL states: “Notwithstanding any other provision of this license, if you modify the program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the corresponding source of your version by providing access to the corresponding source from a network server at no charge, through some standard or customary means of facilitating copying of software.”
The difference between the GPL and the AGPL in relation to SAAS is that the triggering factor for licence enforcement in the AGPL is modification, while that in the GPL is distribution.
Therefore, if the open source compliance process is followed diligently and no code, library or snippet with AGPL is used, SAAS companies do not have to provide the corresponding source code.
The UK High Court in the Football Dataco Limited vs Sportradar GmbH lawsuit in the context of GPLv2, held that the act of making material available to the public by online transmission occurs when the transmission takes place, and not where it is received, for the purpose of copyright.
Distributors also responsible for ensuring open source compliance
In several instances, distributors/vendors of products have attempted to absolve open source compliance responsibility by relying on the representation of the OEM or the contract manufacturer. In the case between Harald Welte and FANTEC GmbH, the Regional Court of Hamburg found the latter guilty of violating GNU GPLv2 in its media player. The court decided that FANTEC must pay a penalty fee plus costs for the lawyers. Additionally, FANTEC was ordered to provide information about its chain of distribution of the media player. In this case, FANTEC had attempted to rely on the representations of its Chinese contract manufacturer, who had provided the firmware to FANTEC.
Thus, open source distributors should not entirely rely on the assurance given by the suppliers. They should conduct assessments independently or with the help of a qualified third party, to determine whether the software infringes any third-party rights.
Best practices for distributors of software or hardware incorporating software, should start from undertaking detailed assurances and corresponding documentation from the OEMs/contract manufacturers, and then conducting independent or third-party checks.
Patent grant
Certain open source licences contain provisions about patents, such as a patent grant clause and defensive termination clause. In certain licences, such as GPL v3.0, Apache 2.0, Eclipse and MPL, a patent licence is automatically granted to those who receive a copyright licence. Contributors with a patent on the code can grant a patent licence to all recipients of the code to enable them to exercise their rights under the open source licence.
Open source licences that contain express patent licences generally include a defensive termination clause as well. If users benefitting from an open source licence assert a patent against other recipients of that software or its derivatives, they can lose their own rights under the open source licence.
Companies should be aware of legal issues when using open source software. The cost of open source non-compliance can be exorbitant. Ensuring compliance may initially seem expensive. But, in the long run, compliance, being process driven, is a cost and reputation saver.
