Linking libraries and the GPL
The GPL (General Public License) allows developers to apply source code freely, but once they modify and distribute the executable, they must provide the
source code of the modified version as well.
Section 2 of the GPLv2 states the following in this regard:
” 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) …
b) 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.
”
Problems arise when GPLed and proprietary software is mixed, in particular when
a proprietary application uses GPL libraries or the other way round. In these constellations
the question is usually whether even the proprietary code needs to be distributed with source code as required by the GPL.
Mixing applications
When you operate application type software on the GPLed operating system, you use
operating-system functions. However, your application need not distribute its source code. This has
been the general consensus and the GPLv3 states in its section 1 in this regard:
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The GPL then provides that system libraries needn’t be published.
Related to this issue is whether you might want to open-source an application which statically links GPLed libraries
into an executable.
The reply is that, yes, certainly, such a developer ought to publish the base code of his or her program. Before everyone panics, however,
take into account that most GNU libraries are not licensed under the GPL but under the LGPL, the “Lesser
GPL”. The lesser GPL allows a non-(L)GPLed application to be linked to the LGPL library without every requirements for
distributing source code. This non-(L)GPLed program are able to be distributed using any chosen terms if it is not a derivative work. A developer improving on a LGPLed library, and thus creating a derivative work, has to distribute the improved version under the LGPL.
A standalone executable which dynamically links to a library is typically accepted as not for a derivative work (in LGPL). It would be considered a “work that uses the library” and paragraph 5 of the LGPL applies.
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
Dynamic Linking
Tricky issues arise when proprietary together with GPLed software usually are dynamically linked. Under the GPL the legal issue is, whether the new software is a “derivative work” of the GPLed portions or an independent work.
Some believe that intent in the developer is vital to answering this question: was the program intended as a library or did linking occur to unmodified off-the-shelf programs. In either case the resulting software needn’t be GPLed.
The Free Software Foundation distinguishes between statically linked libraries (yes the complete software has to be GPLed) and dynamically linked libraries which share data structures with the calling application and call back (they are considered one work and ought to be GPLed if either the library or the application are GPLed).
If the dynamically linked library (aka shared library) fails to share datastructures and is only called to its main function, then it might not need to be GPLed.
Fascination and Frustration are nearby: on the one hand I am amazed how to analyze technical details according to legal concepts, on the other hand I am frustrated that the results are unpredictable.
In any event, this will remain an area involving uncertainty where all parties will tread lightly.
Click here, if you are interested in technology law.
Processing your request, Please wait....
