Between permissive licenses, which allow almost anything, and the GPL, which extends copyleft to the whole derived program, there is a middle way: weak copyleft. The idea is simple. The library stays free, and whoever improves it must share the improvements; but the program that uses it can have a different license, even a proprietary one. The two most widely used licenses of this kind are the GNU Lesser General Public License (LGPL) and the Mozilla Public License 2.0 (MPL). They reach the same goal through very different mechanisms.
LGPL: the boundary is the library
The LGPL thinks in terms of a library and an application that uses it. Changes to the library must remain under the LGPL. The application that links to the library, on the other hand, can have any license, provided some conditions are met.
Dynamic and static linking
The most important practical distinction concerns how the library is joined to the program.
- Dynamic linking: the library is a separate file (a
.soon Linux, a.dllon Windows) loaded at startup. This is the simplest scenario: users can replace the library with a modified version without touching the application. - Static linking: the library is embedded in the executable. This is allowed, but the distributor must let users relink the application with a modified version of the library, for example by providing the application's object files.
The underlying principle is that users must be able to replace the LGPL part with their own version. For the same reason, LGPLv3 requires that the terms of use do not forbid the reverse engineering needed to debug such modifications.
What has to be provided
Anyone distributing an application that uses an LGPL library must, in short:
- state that the library is used and is covered by the LGPL;
- provide the license text;
- make the library's source available, including any changes;
- allow the library to be replaced as described above.
MPL 2.0: the boundary is the file
MPL 2.0, published in 2012, takes a different and very concrete approach: copyleft applies file by file. If you modify a file released under the MPL, that modified file stays under the MPL and its source must be made available when you distribute. New files you write yourself, even if compiled together with the others into the same executable, can carry whatever license you prefer.
This makes the MPL easy to apply: to know what must be published, you just look at which files with an MPL header have been touched. There is no need to decide whether a component is "linked" or "derived".
Compatibility with the GPL
MPL 2.0 contains a "secondary licenses" clause: unless the author has marked the code as "Incompatible With Secondary Licenses", MPL code can be combined into a larger work distributed under the GPL, LGPL or AGPL. This was one of the most important changes from the previous version.
Quick comparison
| Aspect | LGPL | MPL 2.0 |
|---|---|---|
| Unit of copyleft | the library | the single file |
| Proprietary software using it | allowed | allowed |
| Static linking | allowed, with ability to relink | no specific requirement |
| Changes to the free part | under LGPL, source available | under MPL, source of files available |
| GPL compatibility | yes | yes, unless marked otherwise |
| Patent grant | in v3, via GPLv3 | yes, explicit |
When to use them
The LGPL suits libraries that you want to make usable by any program while keeping the library itself free. Many system and multimedia libraries chose it precisely to allow widespread use.
The MPL suits projects where a company wants to allow proprietary extensions but wants fixes to the core to remain public. It is also handy in projects mixing many languages or build systems, where the concept of "linking" is blurry.
A practical example
A company develops proprietary photo editing software and uses an image decoding library.
- If the library is LGPL and shipped as a separate dynamic file, the company includes the library's license and source, and the program stays closed. If it fixes a bug in the library, it publishes the fix.
- If the library is MPL and the company modifies two decoder files, it publishes those two modified files. The rest of the program, including new files that call the decoder, stays proprietary.
In my work, when I analyse a product's dependencies, weak copyleft licenses are the ones that raise the most questions: they are not hard, but they require knowing exactly how the component is built and distributed.
In short
- Weak copyleft keeps the component free while allowing its use in software with other licenses.
- The LGPL draws the line at the library and requires that users can replace it.
- MPL 2.0 draws the line at the single file: only modified MPL files are published.
- Both are compatible with the GPL; for the MPL this holds unless marked otherwise.
- Applying them correctly requires knowing how the component is linked and distributed.
