Dynamic Linking, the GPL and the LGPL
Can I dynamically link software subject to the GPL, make my code proprietary, and not violate the GPL? How about the LGPL?Wikipedia defines dynamic linking thusly:
Dynamic linking systems place the majority of the linker code in the underlying operating system, in which case it is known as a loader. At compile time the linker only writes down what libraries the executable needs and checks to make sure they are being called properly. When that program is then executed, the loader finds these libraries and links them at that point, either at loadtime or during runtime
when the library is actually referenced.
[Quotes from Wikipedia are subject to its license.]
From the GPL FAQ, the Free Software Foundation thinks so, at least respecting the GPL. Quoting from the FAQ:
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
What are your thoughts?
5 Comments:
Section 117 protects dynamic linking in memory unless
contractually prohibited. Why do I say unless contractually
prohibited?
In 1976 Congress created The Commissionon on New Technological Uses:
"This is the area of computer uses... the The Commission on
New Technological Uses is, among other things, now engaged
in making a thorough study of the emerging patterns in this
field and it will, on the basis of its findings, recommend
definitive copyright provisions to deal with the situation."
--- House Report No. 94-1476
http://digital-law-online.info/CONTU/contu6.html
(See the last sentence below)
"Because of a lack of complete standardization among
programming languages and hardware in the computer industry,
one who rightfully acquires a copy of a program frequently
cannot use it without adapting it to that limited extent
which will allow its use in the possessor’s computer. The
copyright law, which grants to copyright proprietors the
exclusive right to prepare translations, transformations,
and adaptations of their work, should no more prevent such
use than it should prevent rightful possessors from loading
programs into their computers.51 Thus, a right to make those
changes necessary to enable the use for which it was both
sold and purchased should be provided. The conversion of a
program from one higher-level language to another to
facilitate use would fall within this right, as would the
right to add features to the program that were not present
at the time of rightful acquisition. These rights would
necessarily be more private in nature than the right to load
a program by copying it and could only be exercised so long
as they did not harm the interests of the copyright
proprietor. Unlike the exact copies authorized as described
above, this right of adaptation could not be conveyed to
others along with the licensed or owned program without the
express authorization of the owner of the copyright in the
original work. Preparation of adaptations could not, of
course, deprive the original proprietor of copyright in the
underlying work.52 The adaptor could not vend the adapted
program, under the proposed revision of the new law,53 nor
could it be sold as the original without the author’s
permission.54 Again, it is likely that many transactions
involving copies of programs are entered into with full
awareness that users will modify their copies to suit their
own needs, and this should be reflected in the law. The
comparison of this practice to extensive marginal
note-taking in a book is appropriate: note-taking is
arguably the creation of a derivative work, but unless the
note-taker tries to copy and vend that work, the copyright
owner is unlikely to be very concerned. SHOULD PROPRIETORS
FEEL STRONGLY THAT {PAGE 14} THEY DO NOT WANT RIGHTFUL
POSSESSORS OF COPIES OF THEIR PROGRAMS TO PREPARE SUCH
ADAPTATIONS, THEY COULD, OF COURSE, MAKE SUCH DESIRES A
CONTRACTUAL MATTER."
*The courts follow these recomendations very closely*
Really, the quote from FSF does not seem to address the whole issue. I'd say there are two cases at least.
1). Program under GPL dynamically links in a non-GPL library.
2). Program not under GPL dynamically links in a GPL library.
I'd be interested if there would be a distinction in the law between the two cases.
It seems to me that a program written by me that uses a GPL module would not be a derivative, the other case may be seen as a derivative though.
The two cases seem to apply to static-linking as well.
-Dave
Dave,
I approach this issue using two principles as my guide. The first is the idea/expression dichotomy, which says that ideas are not protected under copyright, but expressions of ideas are. The second is my view that the GPL takes a very copyright-centric view of the world and of its license, i.e., that what the GPL is trying (at least) to restrict is the creation and distribution of works that are derivative works of code subject to the GPL.
From those two principles, it seems to me that the question is whether expressive elements of one code are placed in the other code. If so, there's a derivative work created, and, assuming that one of the pieces of code is subject to the GPL, the GPL will require the derivative work to be subject to the GPL (assuming the usual suspects of enforceability of the GPL, etc.).
In either the example of the GPL code dynamically linking to a non-GPL'd library or the GPL library being dynamically linked to the non-GPL'd main code, the issue is whether the resulting work has expressive elements of the GPL'd code in it. If so, it's a derivative work of the GPL'd code and subject to the GPL.
Another interesting question is whether the main code and the dynamically linked library are one "work" for copyright purposes or two. This issue is mooted, however, if the main code incorporates expressive elements of the GPL'd library into the main code in order to work with the main code.
Also, the answer may be different under the LGPL.
Between dynamic and static linking, the change is essentially little more than the timing of address resolution.
I cannot see that change as being integral to the definition of a "derivative work" and I think this whole issue is a red herring.
I am struggling with using code, licensed under the LGPL, that is converted to be employed as a dll to be called by a proprietary program.
The LGPL clearly covers the dll itself as a "work based on the Library" (the code is an image library). The stated purpose of the LGPL is to lessen the impact of the GPL to allow free libraries to be used and distributed with proprietary software. However, the sections addressing "works that use the Library" seem to make the proprietary software free nonetheless.
Section 5 provides that works not derivative of the Library but designed to be used with the Library are outside the license. Once they are linked, however, they are subject to the, it seems either statically or dynamically, distribution requirements of Section 6 apply. Section 6 provides that works linked or combined with the Library may be distributed according to terms of your choice, but the terms must allow the recipient to reverse engineer the combined work.
It seems to me, whether dynamic or static, the LGPL fails to protect the proprietary software.
Does anyone else have a take on this issue?
Post a Comment
<< Home