A Guide to Open-Source Software Licenses

From what began as a collegial protest against proprietary software among programmers in the 1990s, open-source software (“OSS”) has emerged as ubiquitous in the software engineering business.  According to one source, OSS is used in 99% of all commercial codebases across all major industries and makes up over 70% of all the code in these codebases.[i]  Although its principal uses are in operating systems, databases and development tools, OSS has also become an integral part of everyday technologies like web sites and apps, smart phones, cars, appliances and the internet of things.  OSS is a key asset of even companies whose business does not involve software development per se.

Consider Business Requirements and Benefits. Adopting OSS is an alternative to building or buying software. It should be considered after you have developed business requirements for the system you are designing, and it should be assessed for its suitability to these requirements.  Thereafter its benefits and detriments should be considered in the context of your business model.

• • BENEFITS.  OSS is easy and cheap (or free) to obtain, usually via the internet.  It is typically the product of hundreds or thousands of developers and millions of code hours – resources and creativity that would be difficult or impossible for the typical business to marshal.  Resources for bug-fixing and augmentation are plentiful and relatively inexpensive to acquire.  Because it is typically accompanied by source code, it is easier to maintain, extend and adapt than proprietary software, which is typically supplied as machine executable without source.  It is arguably more secure and reliable than proprietary systems, having been vetted and used by many people.
  • DETRIMENTS.  OSS may be vulnerable to malicious developer bugs and exploits.  It may also be obscure, have poor usability and require lots of configuration and supporting software libraries.  Support may be uncertain.

If the OSS fails to meet business requirements (even with anticipated modifications), or if it is of negligible business and technical value, you can exit the analysis now.  No matter how cheap or easy it may be to comply with OSS license conditions, there is little business value in adopting software that does not serve business objectives.

2. Distributed? OSS software license conditions are triggered by distribution.  If the OSS is not distributed, there is no requirement to adhere to the license conditions, and you can exit the analysis.  Although distribution is given different definitions by different OSS license variants, distribution is generally synonymous with publication, dissemination or propagation of copies of the code to third parties.  Conveyance of the code to limited groups for limited purposes and without rights to further use or distribute is not distribution.
   • SaaS Software. As so much of software migrates online to a SaaS model based on browser or app user interfaces to run applications that reside in the cloud, it is interesting to think that using OSS in support of a SaaS application probably does not constitute distribution since copies of the running code are (in most cases[ii]) not changing hands.
   • Employees. Copying code among a company’s employees is not distribution since the copies reside with the same licensee (the company for whom the employees work).  Intra-company use of OSS for backend and other internal systems is not distribution.
   • Contractors. For analogous reasons, conveyance to individual independent contractors is probably not distribution, so long as the code is treated as confidential, limited to company machines, and required to be returned or deleted at the end of the commercial arrangement.  However, conveyance of the code to consulting and outsourcing firms probably is distribution and therefore requires further analysis below.
   • Networks. Cloud storage of the code is probably not distribution, so long as the company maintains control over the account and the virtual space in which the code resides.
   • Subsidiaries. Conveyance to a wholly owned subsidiary is probably not distribution, whereas conveyance to minority owned subsidiaries or affiliates is more likely to constitute distribution.
   • Mergers & Acquisition. Although contracts (like an OSS license) may be assigned in the course of an acquisition, and therefore not distributed according the terms of the OSS license, non-exclusive intellectual property licenses are generally not assignable, raising the possibility that an acquisition or merger might constitute distribution and therefore trigger the OSS license terms with respect to the acquiring company.

If OSS is not distributed (and will not ever be distributed), the analysis can end there because the terms of the OSS license have not been triggered.

3. Permissive or Copyleft?  Although there are literally hundreds of different and often idiosyncratic OSS licenses, they bifurcate into Permissive licenses (notice only) and the so-called Copyleft license (source + notice).
   • Permissive.[iii] If OSS is acquired under a permissive license, license conditions are straightforward and easy to accommodate: include a notice with the downstream binary or source code you distribute.  For the contemporary software development and publishing world, to “distribute” often means to put on GitHub or a similar versioning system.  The license will typically reside in source comments or in a “LICENSE” or “COPYING” file in the root of the repository and should exist for every version and every publicly available build.  The notice is short and includes the OSS author name, copyright notice, and disclaimer on liabilities and warranties.[iv]  Having included notice with the distribution, you’ve complied with your obligation and can exit this Lawgorithm.
   • Copyleft.[v] Copyleft licenses are more complex.  Notice is required, as with Permissive licenses, but Copyleft adds conditions: 1) the program and any derivative works must be made available free of charge under the same license under which the program was originally acquired; 2) if a binary is distributed, source of the program and any derivative works must also be made available; and 3) the distributor of the program (you) can impose no restrictions on the exercise of the license conveyed with the OSS program.

3. Distribute Derivative Code. In cases where you make modifications to the Copyleft open-source program, your modifications are “derivative works”[vi] which are subject to the Copyleft notice and source distribution requirements (in 3 (b) above).
4. Distribute Aggregated Code. Aggregated code is separate and distinct programs that remain separate and distinct in distribution and use.  They are, for purposes of distribution, merely packaged together in the same container.  For example, suppose your proprietary interface Program X opens a connection to an unmodified open-source database program and fetches the results of queries made by the user of the interface.  Program X then renders the results.  Under these circumstances, each program will be distributed subject to its own license terms and Program X users may have a proprietary license from you and a separate Copyleft license from the Copyleft author with respect to the database program.
5. Distribute Integrated Code. However, many Copyleft licenses will view the integration of OSS programs with proprietary programs as conferring derivative work status on both the original OSS code and on any proprietary code that integrates with the OSS code, and can therefore cause the integrated code to be subject to the Copyleft license terms.  Whether integrated code constitutes a single derivative work program depends on some controversial distinctions among the way integration might happen.  On the one hand, it is fairly clear that a plug-in is not a derivative work of the OSS code but that the wholesale incorporation of OSS modules into another program is.

It is in the “boundary” cases that there is considerable uncertainty whether the relationship between two programs is such that a derivative work has been created and that, therefore, a requirement to publish as the resultant source code, for free and subject to the same non-proprietary license.  For example, it is unknown whether there is a distinction between static linking (the import of libraries into memory at program load) is distinguishable from dynamic linking (loading libraries at runtime) for purposes of discerning whether a derivative work has been created.

Perhaps it is useful to think of these different kinds of integrations as being on a continuum, as pictured above, from a Composition (a mixture in which members have a part-of kind of association to one another, as a hand or foot is a part-of a person) to Aggregation (a collection without an association among the members).  Thus, the closer the two codebases get to being a Composition, the more likely they are to be regarded as a derivative work and the entirety of the now singular program subject to Copyleft.  The Free Software Foundation, the source of the GNU operating system and the original open-source software consortium, draws the line at linking – integration occurring through communications protocols, remote procedure calls and the like are not considered derivative works.

Compliance with OSS licenses can be of extreme importance to your business.  If a licensor believes that you have breached the conditions of their license, they can bring a copyright action for damages (for unlicensed use) or to enjoin you from distributing or using their (and potentially your) software.

[i] Synopsys 2020 OPEN SOURCE SECURITY AND RISK ANALYSIS REPORT, https://www.synopsys.com/software-integrity/resources/analyst-reports/2020-open-source-security-risk-analysis.html?cmp=pr-sig.  According to this study, 67% of all codebases have licensing conflicts, which is an interesting finding in light of the topic of this article.

[ii] Even the SaaS line is blurring.  Angular, Node and other JavaScript based constructs run in and are distributed to the user’s browser in response to server messages.

[iii] The principal examples of permissive licenses include the MIT and BSD licenses.  The Blue Oak Council (blueoakcouncil.org) counts over 150 permissive licenses currently in use.

[iv] Here is a copy of the MIT license (permissive): MIT License

Copyright (c) 2021

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[v] Copyleft licenses include the AGPL (Affero General Public License), the GPL (General Public License), the LGPL (Lesser General Public License), and the Eclipse, Mozilla and Common Development and Distribution licenses.  See: https://blueoakcouncil.org/copyleft.

[vi] Copyleft licenses generally adopt the Copyright Law’s definition of “derivative work”: “a work based on one or more pre-existing works … in which a work may be recast, transformed or adapted.”  17 USC §101.