I wanted to use a library which is licensed under LGPL (free, only for open source projects). I wanted to use that in a commercial project.

Is that possible that I can develop an open source wrapper library (with BSD or MIT license) and use the LGPL project inside that, and my commercial project use the wrapper library?

Something like this (it should say "LGPL" instead of "SGPL"):

  • 3
    You seem to badly misunderstand the LGPL; any project, whether open source or not, can use an LGPL library so long as you give the end users the ability to replace the LGPL portion with their own code. Feb 2, 2018 at 19:38
  • @PhilipKendall, here is the situation. I wanted to use TinyMCE in a non-open source, commercial project. And because of LGPL apparently, I cannot use that. So one idea comes to my mind is to write an open source wrapper for that and then my commercial project uses the wrapper to access the actual TinyMCE library. So this way we didn't violate LGPL. Please advise according to this situation. Feb 3, 2018 at 19:51
  • 6
    I think this question is valuable and useful and should not be closed. It is typical of the questions asked by parties who do not understand how aggregate and derivative works are defined under copyright law, and which licenses allow what use in such works. Feb 3, 2018 at 22:15
  • 4
    @MaziarAboualizadehBehbahani Why can't you use an LGPL library with your closed source application? LGPL is basically GPL + "you can use this with your closed source application as long you allow users access to and to change that LGPL code..."
    – Brandin
    Feb 5, 2018 at 7:25

2 Answers 2


I assume by "commercial project" you mean that you do not wish to disclose the source code for the product you are developing. Please correct me if my understanding is incorrect, as it is the basis of this answer.

I am not a lawyer, and this is not legal advice.

The LGPL 2.1, which appears to be the license of TinyMCE, is actually more permissive than the GPL. The LGPL 2.1 allows you to dynamically link against a shared library, and still keep the source code of your product "private" (closed source). Dynamic linking, in this case, would mean that you have a separate binary library that is TinyMCE (DLL for Windows or a .so file for Linux) that you ship to the end user of your product. TinyMCE and your "commercial project" cannot be combined into a single binary, unless you also intend to license your code under the LPL2.1. Your executable (which would be different binary from the TinyMCE binary) would then load this shared library at runtime in order to access the functionality of TinyMCE. You are NOT allowed to statically link against TinyMCE (i.e. build the functionality of TinyMCE directly into your application binary file) at build time and still keep your commercial project closed source.

The wrapper methodology that you describe is more applicable to the GPL (which does NOT appear to be the license of the library you are describing), where both static and dynamic linking require that your application MUST also be licensed under the GPL. If the library that you wish to use is licensed under the GPL, then you may choose to create a wrapper executable. Your closed source program should be able to send this "wrapper executable" data via the command line, sockets, or pipes.

From https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#MereAggregation :

Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program. Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

If you end up distributing a binary that is licensed under the LGPL 2.1 (which is the case for TinyMCE), then you must abide by ALL of the requirements of the LGPL 2.1. This would include providing the source code for TinyMCE. It does not require you to release the source for any other programs where are dynamically linking against TinyMCE. If you do not send a TinyMCE binary to the end user (e.g. they download the TinyMCE library from some other third party on the internet), then you are not required to provide the source for it.

Edit: Update to include information that you still must release the source code for TinyMCE, if you send TinyMCE to an end user in binary format.


These two web pages for LGPL 2.1 and 3.0 which answered my question:




For TinyMCE it would be v2.1 and it's going to be fine if we use that externally in our project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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