I'm looking for an existing library license which satisfies the following conditions:

  • GPL-compatible
  • Can be statically linked with closed-source programs
  • Binary modifications of the library, including cases where the library is statically linked with another project, must be accompanied by the library source code

Licenses which are close but not quite what I need:

*: The LGPL allows static linking with some specific technical conditions - specifically, it must be possible to make modifications or use newer versions of the library, and to do that one would need to make available the object files and build scripts for the non-free components. Generally speaking, this is technically difficult and sometimes impossible (in the case of e.g. templates or inlined functions), and very often (as is my case) the underlying reasons for which static linking is required conflict with these LGPL requirements. For this reason, LGPL is unsuitable for my use case, and frankly I've yet to see a project which used static linking with an LGPL library in this manner, considering all the associated technical and legal (templates/macros/inlining) problems.

  • Why not the GPL itself?
    – jk.
    Commented Aug 22, 2011 at 16:00
  • I would like to use the library in a closed-source project, and allow others to do so. Commented Aug 22, 2011 at 16:01
  • Why does it need to be GPL-compatible if you're trying to use it in a proprietary project? The MPL (which is not GPL-compatible) sounds like exactly what you need: You can use it in a proprietary project, but if you modify the MPL code itself, you're required to distribute the source for the changes you made. Commented Aug 22, 2011 at 16:11
  • The proprietary project is not the only use of the library I envision. Perhaps dual-licensing is the best solution, though. Commented Aug 22, 2011 at 16:13
  • The licence used by glib, the gnu c library. I don't remember which one, but if was written by FSF, is gpl compatible, and allows building of proprietary software. Commented Aug 26, 2013 at 13:21

5 Answers 5


From your comments, it appears that you're looking for a way to license a library that you wrote so you can use it in a proprietary project but still have the license be GPL-compatible.

First off, this is a bit nonsensical. The GPL carries a whole lot of anti-proprietary-software ideological baggage with it. It's designed that way; the whole point of it is to make it as difficult as possible to integrate GPL or LGPL code into a proprietary project.

However, licenses are for other people. They don't apply to the copyright owner, which is you, the person who wrote the library. You can use your own code however you want to, regardless of the terms of the license you put on it. So you can make it GPL or LGPL and still use it in your proprietary project and you'll be fine.

On the other hand, if you want people in general to be able to use it in GPL projects or also to be able to use it in proprietary projects but still be required to publish the source to whatever changes they make, try dual-licensing it as (L)GPL and MPL.

  • 7
    +1. But I would also like to add that if he accepts contributions to his original work and attach a GPL license to those, he is not the original owner of the contributions. He will have to be careful. GPL is very much anti-commercial products. You can use GPL in closed-source projects, as long as you never give that project to anyone else. The "distribution" is the key aspect of GPL. There have been loop holes but they fixed most in AGPL and GPLv3. It's a hostile license. Commented Aug 22, 2011 at 17:31
  • @Andrew: Yes, that's an important point to keep in mind. You can only treat the code as code you own if you own all of it. Commented Aug 22, 2011 at 17:32
  • Thanks, I was leaning towards this solution as well. Note that if I chose to make it GPL publicly, I wouldn't be able to use other people's contributions to the library in my own project, so I'd need to fork the library code if that were to happen. Commented Aug 22, 2011 at 17:34
  • 1
    @CyberShadow Really, what you want is a way around the GPL license. GPL code can use any of the other licenses that are available. The problem is when you release yours under a license such as MIT but utilize another piece of code that is under GPL. If your code doesn't use any GPL code/libaries/etc then you are ok. Just release under MIT/Apache v2. If it does use something that is GPL you are trying to work around a license they seemed to of dedicate their lives to prevent you from doing. Personally (could it not be personally?) I recommend abandoning the GPL code you are using. Commented Aug 22, 2011 at 17:51
  • 1
    I'm not using any GPL code. My goal is a license which allows my library to be used in both GPL software, and statically linked to non-free software with the condition that they distribute the library source code (or modifications) as well. Commented Aug 22, 2011 at 18:02

The LGPL does allow static linking, but you must provide the minimum source requirements for a user to build the derived work against his own version of the LGPL work. When static linking, you would need to distribute at least the compiled object files of the closed-source work, combined with any scripts required to perform the linking process.

The LGPL section 4.d states: do one of the following:

  • Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
  • Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.


For the technical problems with inline functions, templates, macros etc - the LGPL is a bit more flexible here, and allows you to incorporate code from the header files without being required to distribute the work using these headers under the LGPL - provided the following conditions are met.

  • Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
  • Accompany the object code with a copy of the GNU GPL and this license document.

You can use your own licence, or simply add an exception to the LGPL to allow static linking - as in the wxWidgets licence

wxWidgets is currently licensed under the "wxWindows Licence" pending approval of the "wxWidgets Licence" which will be identical apart from the name.

The wxWindows Licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWidgets, and also those producing proprietary software.

wxWidgets is Certified Open Source Software Participants in the discussion that led to this decision include the folk from Abisource, Robert Roebling, Julian Smart, Markus Fleck, Karsten Ballueder, and some advice from Richard Stallman. Richard has confirmed that the new licence is compatible with GPL'ed applications. However, there are no significant restrictions on proprietary applications.

The wxWindows Licence has been approved by the Open Source Initiative, and you can find the licence on their site here...

  • 1
    Don't write your own! Commented Aug 26, 2013 at 13:23

The LGPL will allow that.

From Wikipedia, "The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.1 The non-(L)GPLed program can then be distributed under any terms if it is not a derivative work."

Any changes to the library must be redistributed, but the library itself can be used without requiring distribution of the main program.

  • 2
    Wikipedia is being vague with regards to the kind of linking that's allowed in the segment you quoted. The LGPL requires the possibility to use never versions of the library, so one would need to either provide the source code of the main program, or linkable object files. Commented Aug 22, 2011 at 16:06
  • Upvoters: added clarification to question why LGPL is unsuitable. Commented Aug 22, 2011 at 16:28
  • Only LGPL 2.1 allows static linking you must add an exception to other versions.
    – Steve-o
    Commented Aug 23, 2011 at 4:46

Apache v2 satisfies all your conditions: Apache License v2.0 and GPL Compatibility

The Free Software Foundation considers the Apache License, Version 2.0 to be a free software license, compatible with version 3 of the GPL. The Software Freedom Law Center provides practical advice for developers about including permissively licensed source.

Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.

We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.

Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work...

  • I see nothing in the Apache license which requires redistributors to include the Source form or modifications to it when distributing derivative works of the Object form. Commented Aug 22, 2011 at 21:54
  • @CyberShadow That is true. How do you solve bullet 2 and bullet 3 being at odds with each other? They are opposing bullets. I imagine you are thinking, well they can keep their code but I just want their modifications to "my" code. Where is that line drawn? That is why the GPL license is the way it is with derivative works. It's very easy to play games with a license that satisfied bullet 2 and bullet 3 in which you'd never need to follow bullet 3. They can say, well it's our closed-source enhancements that aren't technically apart of the third-party project. Commented Aug 22, 2011 at 22:07
  • I don't see a problem with formulating a good definition for this (of course, I'm looking for an existing license which already does this). Trivially, "modifications to existing source files must be published". More involved formulations could impose the requirement that the published source code must be usable on its own, similar to the original library. I shouldn't have used the term "derivative work" in my first comment, since subclassing can be considered a derivative work but would be a valid use of the library. Commented Aug 22, 2011 at 22:21
  • Example: The MPL has a very precise definition of a "modification", although it does not cover new files added to the Original Code which do not contain content copied from the Original Code. Commented Aug 24, 2011 at 17:40
  • 1
    @AndyT I'm not a lawyer and I'm only going by what I see others doing and what I can glean from the License itself. I see no mention forbidding static linking but I have seen other projects add an additional extension to the Apache v2 allowing static linking which makes me think there is something in the v2 License that makes it difficult. This really only matters if you are building native binaries with languages that allows you to compile everything into a single binary. Most C# and Java applications dont have to worry about this. Commented Jul 2, 2012 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.