Open-Source JavaScript: Compliance Tips For Companies

This article originally was published by Law360 .

By Michael Sochor & Dan Ovanezian

Many companies are now aware that if they incorporate open-source software into their products, there are specific terms and conditions that go along with the grant of the use of the particular OSS that are spelled out in license(s) accompanying the OSS. Ramifications for failing to abide by such terms and conditions may not only subject companies to liability for copyright infringement and court order injunctions against continued use of the software but also may require exposing a company’s proprietary software source code, which incorporates the OSS, to open sourcing.

Therefore, it is very important that companies implement an open-source compliance program and understand not only the various different OSS licenses and obligations, but also understand the differences that exist between programs and programming languages that may seem to be the same.

One such situation is with the use of JavaScript programming language. While JavaScript includes the name Java, the JavaScript programming language and the Java programming language are two separate and different programming languages that differ in many respects. One of the most significant differences between the two languages, and relevant to the discussion of open-source compliance, is that JavaScript is an interpreted programming language whereas Java is complied (e.g., into a nonhuman readable computer executable form). Or as the name implies, JavaScript is a scripting language. This means that JavaScript is human readable code that is processed with an interpreter instead of compiled in advance and executed. JavaScript code is often part of an HTML webpage file. In some cases, the JavaScript code file is referenced with a link in the HTML file which points to the .js JavaScript file.

While JavaScript first appeared around 1995, where it executed in web browsers or on client machines, the functionality was added more recently so that JavaScript could be executed on the server side. Nevertheless, there has been a proliferation of JavaScript on the client side, e.g., the use of JavaScript which commonly executes in web browsers on our smartphones, tablets, laptops and desktop computers.

Many open-source licenses, including GNU Public License, GNU Lesser General Public License, etc., require that a copy of the source code be distributed with the program that incorporates the open-source code (or make the source code available). With JavaScript being an interpreted language and interpreted on the client side by a web browser, the JavaScript code is downloaded to the client device. This download may trigger the distribution clauses of many open-source licenses.

JavaScript is very difficult to conceal when it is downloaded on the client side. Simply right-clicking in a web browser and selecting “View page source” (or something similar) will present a user with JavaScript code that is usually located or referenced at the top of an HTML file. Where a JavaScript file is referenced as a link to a .js file, the user just needs to click the link to the .js file to be presented with the JavaScript source code. There are many posts on the internet asking how to securely hide JavaScript source code with the closest available solution being obfuscation which only makes it somewhat harder to access. This thus makes JavaScript relatively unique as compared to most programming languages including Java and C++, which are compiled into an executable that may be distributed and the source code thereof kept private.

Turning to the open-source implications, because JavaScript code is accessible (or viewable) by a user thus satisfies the requirement of distributing a copy of the code because the JavaScript source code is downloaded as part of the webpage downloaded by a web browser. Once downloaded by the web browser, it can be viewed by the user. This makes JavaScript code one of the most easily accessible pieces of source code that can satisfy such a requirement of an open-source code license.

Turning next to program structure, how open-source code is linked to other code can have significant implications to open-source license compliance. One of the most common licenses where linking structure is implicated is the GNU Lesser General Public License. With this license, the requirement to disclose your own code is not implicated if you dynamically link the LGPL code to your code or program. In the JavaScript context, as long as you have any LGPL code in a separate JavaScript file or in an HTML file (both of which make the LGPL code visible), the LGPL code can be considered to be dynamically linked. This is because the JavaScript code is dynamically executed upon webpage rendering.

Regarding attribution, open-source licenses often require a copyright notice regarding the author or owner of the code. The ease of access to JavaScript source code makes satisfying the attribution requirement simple because the copyright notice can be put in the JavaScript source code itself in order to satisfy the copyright notice requirement. Requirements to provide a copy of the open-source code license may similarly be satisfied by including the license in comments of the JavaScript code. Of course, if a centralized part of a program or product is used where all open-source code attributions and license are accessible, the attributions for JavaScript code may be similarly located there.

As illustrated by the above discussion, a company incorporating open-source software into its products needs to understand not only the various different OSS licenses and obligations, but also understand the differences that exist between programs and programming languages. In particular, when implementing JavaScript, a company should consider the best fit of how to satisfy the various license requirements in light of its open-source compliance program or policy given the various ways that JavaScript differs from more traditional complied languages.

(Note that variations in situations or licenses may require different approaches to be taken in order to comply with open-source licenses.)

Michael Sochor is director of intellectual property at ForeScout Technologies Inc.

Dan Ovanezian is a partner at Womble Bond Dickinson (US) LLP and an adjunct professor at Santa Clara University School of Law.