MediaTech Law

By MIRSKY & COMPANY, PLLC

Open Source, Dynamic Linking and Licensing Consideration for Developers

Introduction:

There is often confusion among software developers regarding the licensing of open source code. Questions center on what can be done with open source code and what is considered a derivative work.  One particular area of confusion arises when the derivative work uses static or dynamic links when compiling the source code.  This distinction is critical and implicates different licensing requirements dependent upon this decision.  It is important for developers to have an understanding of the basic principles of the most popular open source licenses and how static versus dynamic links can affect the end result from a licensing perspective.

GNU GPL

The GNU General Public License (GNU GPL or GPL) is the most widely used free software license. It grants end users the freedom to use, study, copy and modify a piece of software. Originally written by Richard Stallman of the Free Software Foundation in 1989, the GPL is now in its third iteration with the GPLv3. The GPL is based on the idea that nobody should be restricted by the software they use. To meet this goal, every user should have the freedom to: use the software for any purpose; change the software to suit a particular need; share the software; and share changes to the software. To this end, GPL-licensed software requires that source code be made available to all users. Furthermore, users have the right to use and modify that source code. Should those modifications be distributed, the source code of that distribution must also be licensed under the GPL.

Derivative Work

Under Title 17 of the Copyright Act, a derivative work is defined as “a work based on one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, …, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a ‘derivative work’”.

The question that both legal scholars and developers grapple with is what is a derivative work in the context of computer software code? While a full review of the legal history of software code is beyond the scope of this article, the following three cases Midway Mfg. Co. v. Artic International, Inc.; Lewis Galoob Toys, Inc. v. Nintendo of America, Inc.; and Micro Star v. Formgen Inc. provide a framework for understanding how the courts approach the determination of derivative work in the context of software.

  1. The derivative work must in some way incorporate the protected work (See Micro Star, 154 F .3d at 1110-11);
  2. Courts will defer to an analysis that resembles the substantial similarity test familiar under the reproduction right (See Midway Mfg. Co., 547 F.Supp. 999 at 1012);
  3. Courts will examine the market impact of the work. A derivative that doesn’t displace the existing demand for the original will be less likely to be held infringing; (See Nintendo of America Inc., 964 F .2d 965 at 16);
  4. Courts recognize that an over-broad definition of a derivative work may result in a chilling effect on the market for follow up innovations (See Nintendo of America Inc., 964 F .2d 965 at 19).

How does this apply practically?

For developers looking for guidance, the GPL does not require the release of a modified version of an original GPL-licensed software. Modifications may be made to such software for private use. So long as the modified code is never released, no license is necessary. Once the developer plans to release the modified code, however, the question arises – must the modified code be released under the GPL license? The answer depends on the type and nature of the code.  The situation of static versus dynamic linking nicely illustrates this issue.

Modifying the Original Source Code:

In the case where a developer adds, removes or edits a few lines of the source code with the intention of distributing the code, the modified code qualifies as a derivative of the original. It incorporates much, if not all of the original work, and could be viewed as a replacement for the original. In this instance, the modified code is a derivative of the original code. Adhering to the GPL requirements of the original code, the derivative work must also be licensed under the GPL.

Adding a File to a Collection of Files:

Several reviews of the following scenarios have been compiled, including the Rechtswinkel de Clinic’s Working Paper on the legal implication of certain forms of Software Interactions (a.k.a linking),  the University of Washington School of Law’s Software Pluralism, and Andrew Katz of Moorcrofts LLP’s GPL – The Linking Debate. These reviews provide several scenarios and analysis detailing possible differences that may occur when compiling code. The following is a sampling of examples of static and dynamic linking are described below.

Static Linking
Distribution of a Single Complied Executable

In the case of static linking, the original program G is a collection of source files.  A developer modifies the original program G simply by adding a new source file, X’, which adds new functionality to the original program. The original program will likely be edited to invoke X. These two pieces (original code G with minor modification + new source file X’) are packaged as an executable at runtime and made ready for distribution. The result is a new program, G+. In this instance, the executable G+ is described as statically linked – the original GPL’d code is combined with the new source file. Is the executable considered a derivative work of the original GPL’d code?

The Copyright Act states that “translations” are considered derivatives of original works. This particular fact pattern is what the drafters of GPL were most likely envisioning when they created the license. In this scenario, G+ meets the requirements of what is considered a translation:

  • G+ incorporates much if not all of the original work G;
  • G+ is substantially similar, assuming that only a few lines of code were added to the original program to invoke the new file X; furthermore
  • G+ can be viewed as a replacement for G is it retains all of the original code.

This process of static linking transforms the library of code into G+, thus creating a derivative work, G+ must be distributed under the terms of the GPL, and the source code must be made available for both the original code with the minor modifications and the newly added source file.

Dynamic Linking
Distribution of Multiple Executables

What if, in the prior instance, instead of releasing the modified code as one executable, the developer released the code as two separate packages? First, the original code with minor modifications is packaged as an executable G+. This modified code has the same functionality of calling the new source file, but that new file is not packaged in the executable. A second executable is created encompassing the functionality of the new source file, X+. This approach is described as dynamic linking. According to the Software Pluralism analysis, the executable G+ comprising the original code with minor modifications would clearly fall under the GPL as it is a derivative of the original code.

It is not so clear, however, whether the executable X+ containing the new source file would be required to be licensed under the GPL. Further analysis shows it would depend on whether the new source file is considered a derivative work of the original code.  The executable containing the new source file calls for the first to be invoked, yet does not involve a transformation or compilation of the linked code at development or build time, but only at run-time. Under the Copyright Act, for a work to be derivative it must be based on a preexisting work … or any other form in which a work may be recast, transformed, or adapted. In this case, X+ does not necessarily create a derivative work of G+, because G+ is only reproduced and distributed, rather than transformed and distributed.

This is where the specifics of each fact pattern serve to determine whether or not the new source file is covered under the GPL. Some arguments in favor of a copyleft GPL propose that in cases of dynamic links, GPL would apply to both executables if the new source file relies on the original code, and is not an independent and separate work in itself. Furthermore, if the new source file depends on the original code to work, an independent compilation has been created, which would fall under the GPL.

Conclusion

It is important for software developers to understand the basics of open source licensing. It is not always a clear-cut determination as to when dynamically linked code will require the GPL license. Knowing how and when the issue may arise, however, may provide developers with the tools to address any questions or problems early on, and gain legal council should the need arise.

 

Share this article: Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin
Email this to someone
email

Add Comment

Your email address will not be published. Required fields are marked *