VirtualGL | About / Deciphering the wxWindows Library License

DISCLAIMER: I am not a lawyer, nor do I play one on TV.

The wxWindows Library License is essentially the LGPL (Lesser GNU Public License) v2.1 with an exception to the LGPL's provisions regarding static linking with closed source code. It was chosen as the license for VirtualGL because we wanted the project to be as "commercially-friendly" as possible yet still retain some copyleft provisions to encourage the formation of a healthy open source community. There is some ambiguity-- not to mention a lot of misunderstanding and blind dogma-- regarding how certain open source licenses apply to static and dynamic linking. Most of these licenses have never been put through a rigorous legal test, and thus it is often incumbent upon project developers and not lawyers to clarify their intent with regards to using a particular license. That being the case, this article was written to state our understanding of what the wxWindows Library License requires and how we wish it to apply to VirtualGL and its components. Our understanding seems to match that of the wxWidgets project, who created the license. If your understanding of the license differs, then please contact the project admin.

LGPL v2.1 Background

As with most open source licenses, the LGPL governs only distribution, not usage. Basically, you can use the code or binaries however you want. You can experiment with them, build internal solutions from them, etc. However, if you publicly distribute the code or any software that leverages it, then you must comply with the terms of the license.

Much of the LGPL v2.1 hinges on the definition of a "work based on the Library", because only such works are subject to the terms of the LGPL. Section 0 defines a "work based on the Library" as "either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language." Thus, whenever the word "derivative" is used in other parts of the license, this equates to "work based on the Library."

Examples of "works based on the Library":

Another library that uses some or all of the same source code as the original Library (Section 2.) In this case, both the source code (either in its original form or modified) and any object code built from it are "works based on the Library" and can only be legally distributed under the terms of the LGPL. This does not mean that when you add new source code to the Library, the new source code has to be explicitly licensed under the LGPL. It can instead be licensed under a less restrictive license, such as a BSD-style license. When distributed with the original Library, however, the provisions of the LGPL apply to the new source code.
A binary built by linking the Library with code that is "designed to work with the Library" (Section 5.) Sections 2 and 5 clarify that when code not derived from the Library is linked with the Library, the non-derivative code does not become a "work based on the Library", but the resulting binary does. The binary must thus be distributed under the terms of LGPL Section 6. If the binary is built by statically linking with the Library, then its distribution is also subject to the terms of LGPL Section 4, since it contains a portion of the Library in object code form.
If a piece of source code is not derived from the Library but calls significant portions of inline functions from one of the Library's header files, then object code built from this source may be a "work based on the Library", even though the source is not (Section 5.)
A new library that is built from the combination of the Library and other independent code (Section 7.)

So, what does this mean in terms of distribution requirements?

If you distribute a binary version of the Library, or if the Library is statically linked into any other binary you distribute, then you must distribute the source code for the Library as well, including any modifications you may have made to it (Section 4.) Your distribution of the source code falls under Section 1, which additionally requires that you distribute a copy of the license and keep any existing copyright notices in tact.
If you distribute a modified version of the Library's source code, then:
1. Your modifications must be clearly marked (Section 2b.) This is generally satisfied by adding your own copyright notice at the top of any modified source files.
2. Your modified version of the Library must, as a whole, be licensed under the LGPL (Section 2c.) That means that any new source files must either be explicitly licensed under the LGPL or they must use a license that is compatible with the LGPL.
3. Your modifications must work properly regardless of whether the Library is linked with a specific application (Section 2d.)
If you distribute a binary that is built by statically linking with the Library, then you must
1. Permit the binary to be reverse engineered (Section 6.)
2. State in your documentation, as well as run-time copyright notices, that the Library is used (Section 6.)
3. Provide either source or pre-compiled objects that allow users to rebuild your binary with a modified version of the Library (Section 6a), or provide a 3-year written offer for same.
If you distribute a binary that is built by dynamically linking with the Library, then 3b above still applies, but not 3a or 3c.

The wxWindows Exceptions

The wxWindows Library License contains four exceptions to the LGPL, the most notable of which is Exception 2:

"you may use, copy, link, modify and distribute under your own terms, binary object code versions of works based on the Library."

Per the previous section, when the Library is linked with other code not derived from the Library, the resulting binary becomes a "work based on the Library" and is subject to either Section 6 or Section 7 of the LGPL. Our understanding is that Exception 2 effectively nullifies both of these sections, which is equivalent to nullifying Requirements 3 and 4 above.

It was not our intent in using the wxWindows Library License to nullify any other sections of the LGPL. Thus, it was our intent that when you distribute a binary version of the Library (or any other binary that statically links with it), you should also distribute the source code for the Library (including any modifications you made to it.) However, you may license the binary in any manner you wish, including placing restrictions on reverse engineering, and you do not have to include object code for the closed source portions of the binary.

VirtualGL Specifics

VirtualGL is designed to plug into an application at run time. Thus, the application is not "designed to work with the Library" and would not, under any circumstances, be subject to the provisions of the LGPL. Even if the application could, under some wild stretch of the imagination, be considered a "work based on the Library", then Exception 2 of the wxWindows Library License would nullify any distribution requirements for the application. In other words, VirtualGL's license applies only to distributing VirtualGL itself or to distributing other applications/libraries that directly incorporate VirtualGL's technology.

It was our intent from the start to allow commercial products to be built using VirtualGL's source code. It was also our intent that the only requirements for distributing such products would be that the modified source code for any components of VirtualGL that were used would be distributed along with the product.

Scripts

Scripts that are incorporated into the VirtualGL distribution are explicitly licensed under the wxWindows Library License, even though this is a bit awkward. The intent here was for the scripts to be treated as source code and be subject to the terms of the LGPL governing the distribution and modification of said source code. If the scripts are compiled into an executable, then the resulting executable can be distributed under your own terms, per the wxWindows Library License.

As an example, let's say that you modified vglrun such that it called a proprietary script to set up an environment specific to your commercialized version of VirtualGL. Per LGPL Section 2d, vglrun must still work even if your proprietary script is not available, thus your modifications must check for the presence of the proprietary script. If you compiled both of these scripts into a single executable, however, then you would only be required to distribute the uncompiled version of vglrun, not the uncompiled version of your proprietary script. The usefulness of protecting a proprietary script in this manner is questionable, but we wouldn't mention it if someone hadn't already asked about it.

Makefiles, build scripts, and packaging scripts do not generally have a license header, but these are considered part of the source code per LGPL Section 0.

Test Programs

Many of the test programs included with the VirtualGL distribution are also licensed under the wxWindows Library License, even though these programs are not libraries. This is so that these programs can easily be rebuilt as libraries and used within larger programs (including proprietary programs.)

Other Licenses

The VirtualGL Configuration program (vglconfig) uses FLTK, which employs a slightly different derivative of the LGPL v2.1. The FLTK exceptions are compatible with the wxWindows Library License exceptions. The only additional requirement of the FLTK License is that the use of FLTK must be acknowledged in your documentation. The VirtualGL documentation includes this acknowledgement, so if you distribute the VirtualGL documentation along with VirtualGL or your application, then that satisfies this requirement.

In VirtualGL 2.3.x and earlier, the distribution package for the VirtualGL Client for Exceed includes xauth and PuTTY, both of which use a BSD-style license.