With open source software (OSS), there seem to be 2 major misconceptions, one by end users and the other by developers. As to users, it may be helpful to understand that restrictions and compliance burdens do not apply to the end user’s own use, but only upon subsequent transfers of the software. As to developers, a major misconception involves what kind of newly-created work – say, a library or module component – is “derived from” the OSS and therefore bound by its same open source license.
First, with users, there is first the question of what use is restricted. And in a big sense the answer is “none”. So, for example, “Open source does not place a compliance burden on the end user, does not mandate acceptance of an end-user license agreement, does not subject [the end user] to para-police action from [any software industry trade group].” Simon Phipps wrote that in 2010, adding that “If you move beyond use of the software and study the source code, there is also no compliance burden. There is no risk associated with using the knowledge you gain for other purposes.”
Of course, the phrase “using the knowledge” is significant, because using the software (i.e. the code) is a different story. An end user’s use of ideas and know-how and processes is not subject to OSS license restrictions, at least not under a typical OSS license. But such use may be subject to restrictions under patent law.
Christopher Sloan, an attorney in Nashville, writes that “By its own terms, the [General Public License (GPL)] only applies to copying, distribution, and modification. So, in theory, the GPL (including its disclaimers of liability) does not apply to mere internal use, or to modifications that are never released to the public.” And this is true for other open source licenses generally: Modifications in and of themselves do not subject OSS to compliance burdens, which are triggered by distribution. Although the actual compliance burdens will vary based on the type of OSS license involved.
This is also true for uses of OSS that might “taint” proprietary software with some of the more aggressive OSS license obligations, particularly those of Section 2b of the GPL, which states:
You must cause any work that you distribute or publish, 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 the GNU Project’s own FAQs for the GPL make this same point:
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
OK, so an end user’s internal use of OSS – without more – does not trigger OSS license compliance obligations. What does trigger compliance is distribution or publishing. And that applies to both modifications of the OSS itself and “any work that … in whole or in part contains or is derived from the Program or any part thereof” (GPL Section 2b, emphasis added). Much controversy surrounding the GPL focuses on the ambiguity of “contains or is derived from” as it applies to works developed and distributed by software vendors.
GPL’s “Derived From” vs. Copyright Act’s “Derivative Works”
I will focus here on the meaning of “derived from”. Christopher Sloan argues that the GPL’s use of “derived from” is meaningfully different than “derivative works” under US copyright law. Sloan argues that the GPL’s “derived from” language looks to the physical distribution or publishing of the module or library with the program, rather than the functionality of the aggregated software, module or library. So, for example, if a newly-created module or library to a software program is distributed separately from the program itself, Sloan’s view is that “the GPL would seem to permit this without requiring the release under the GPL; however, if the module or library is hooked into the GPL program, then any further release would, according to GNU, have to be subject to the GPL.”
This right to freely distribute – and without GPL encumbrances – may be so even where stand-alone functionality of the module or library by itself is impractical. This is the distinction from copyright law: Sloan writes that “Under U.S. copyright law, it is possible to create a module of a software program or a library for use by other programs that is not a derivative work,” while under the GPL, “any such module or library, if distributed as part of a larger program, would have to be distributed under the GPL.” (emphasis added)
As Sloan sees it, it is the act of distribution of the work with the larger work that triggers the GPL’s “derived from” clause. The emphasis under the OSS license – and its coupling of open-source rights between base software programs and newly-created libraries and modules – is thus dependent on the joint physical distribution of the components with the base program.
In this view, the GPL diverges from copyright law. “Derivative Work” is defined under the US Copyright Act (17 U.S.C. §101) as
a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, 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’.
In 2006, the University of Washington School of Law’s Software Pluralism Blog published the example of a developer working from an original OSS (called Program “A”), modifying that original program by adding a new source file (called Program “B”), which contains some new functionality to be added to the existing functionality of the Program A. In very simple terms, “it is useful to think of the resulting work as the sum of its constituent parts”: A + B.
(Software Pluralism’s full analysis, including further variations and examples, can be found here.)
In Software Pluralism’s example, the developer slightly modifies the source code of Program A in order to allow Program B to use certain functionality of program A. So, at that point, a “new” version of Program A exists, called Program “A*”. A* is clearly a “derivative work” (for Copyright Act purposes) and “derived from” (for GPL purposes) of Program A.
Now the developer has a new program, called Program “A* + B”, which the developer would like to distribute as an executable (that is, without the source code). The question is whether that new program – Program A* + B – is “derived from” the original program (Program A) and must be licensed subject to the GPL. Or … is Program A* + B not derived from program A, and therefore need not be licensed subject to the GPL.
The author first points out that an executable should be properly viewed as a “translation”, which under the US Copyright Act is a “derivative work” of an original work. (17 U.S.C. §101). Here, that would mean that the executable component part of A* (i.e. the executable version of A*) is a “derivative work” of program A*. And since program A* itself is a derivative work of the original program A, therefore the executable version of program A* would also be a derivative work of program A.
Program A > Program A* > Program A* executable (where “>” means “derivative”)
But if even if Program A* is a “derivative work”, the new work here is A* + B, not just A*. How does that affect things? The author notes that the new program (A* + B) is “statically linked”, meaning “at the time of distribution it literally incorporates the executable of [A*]”. Since the executable of program A* is a derivative work of the original work A (see above), the resulting executable of A* plus B – if indeed statically linked – must be considered a derivative work of A. And if program A* + B is a “derivative work” of program A, then (if distributed) program A* + B must be distributed subject to the GPL.
(Why would “static linking” make a difference? If program A* + B is statically linked, why does that make this program necessarily derivative of its component parts A* and B? I will discuss this separately in later post on this subject.)
Software Pluralism points out that the GPL allows for at least one possibility for distributing program B separate from the combined program A* + B without being subject to the GPL. It might easily be the case, for example, where a developer could physically distribute an executable of a component module of a combined program. This illustrates Christopher Sloan’s same argument (see above) that the Copyright Law’s meaning of “derivative work” and the GPL’s meaning of “derived from” diverge.
This all gets further confusing when drilling down into the Section 2 of the GPL itself, which states,
If identifiable sections of that [modified] work are not derived from the [original open source] Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
So, the GPL is really quite clear on this point, because it still relies on whether the separately distributed work is “derived from” the original, regardless of its independent distribution. The supposedly independent component must be “not derived from” the original and “considered independent and separate” in itself. Incidentally, Section 2 also later states:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
Nonetheless, a nice body of caselaw on “derivative works” (though under the Copyright Act, not under the GPL) seems to weigh heavily the significance of a program being capable of standing alone in determining whether a new development is “derivative”. Since the GPL requires separate analysis of the independence of the program from whether the latter program is “derived from” the original, the GPL would seem to discount the significance of this same independence factor in determining derivation.
Software Pluralism adds that, “according to GNU”, if a newly created module or library “hooked into” the GPL program, then any further distribution would be subject to the GPL. In a later blog post, I will separately discuss this issue of the derivative nature of programs “hooked into” and “statically linked” with original programs as relates the requirement to distribute subject to the GPL.
Add Comment