I've a project in which I would like to use an LGPL licensed library, in this case FFmpeg without changes. I've run through questions and answers regarding LGPL in commercial products with conclusion that it should be possible to use such licensed library in closed commercial product.

But here comes the question - as far as I've understood, I've to use dynamic linking for libraries (in case for example user wants to replace the libraries), Windows Store ap comes as a closed package which runs in sandboxed environment, I can put dll's as content in package, but user won't be able to get to them (at least without jailbreaking the device) - how to deal with that? How to comply with the license for Windows Store apps? Or maybe I understand something wrong? - those licenses can be quite confusing.

  • 1
    Welcome to Open Source SE. Great question!
    – Zimm i48
    Oct 18, 2016 at 8:16

3 Answers 3


First, let's imagine what the situation would be like if your app was open source.

The user cannot modify the app on the store in any way (they cannot change the libraries it uses) but say the app provides a link to the code. Then they can modify the code (change the dependencies for instance), recompile it, republish it as their own app on the store. So, the user is not actually limited to use or distribute a modified version (even if they cannot modify the version that you distribute).

Now, let's come back to your problem. LGPL does not force you to use dynamic linking. You can instead, for instance, provide object files for your software that the user will be able to link (statically) to any version of the library. Thus, suppose that the user wants to build this alternative version. You could make the object files available on the internet; or if you want to sell the app through the store, you could include a written notice that if someone has bought your app, they can request for the object files. The user won't be allowed to republish your app with alternative version of the library on the app store. But at least in the case of Windows apps, there is a developer option that allows you to run these apps without going through the store (mostly for testing). The user could use this mode to run their alternative build of your app and that would not contradict the terms of LGPL in any way.

Note that the same applies to Google Play (a similar developer mode exists) but not to Apple Store (where you have to pay a fee to Apple to use such a mode). Thus, you cannot use a LGPL library in an iPhone app.

EDIT: let me add some more details to convince you that I'm not merely giving an opinion.

Here is the relevant part of the license:

4. Combined Works.

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:


d) Do one of the following:

0) 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.

1) 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.

As you can see, I'm not inventing my claim. LGPL is often known as the license which allows dynamic linking but all too often it is thought as the license which forces dynamic linking. This is not correct and an alternative solution is possible (solution (0)).

Additionally, from the GNU FAQ:

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

(2) If you dynamically link against an LGPL'd library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPL'd library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

  • Hi Zimm, thanks for the answer. The problem is that everything here depends on one's opinion. I will try to get some information how much lawyer's opinion would cost, then maybe will go that way.
    – Romasz
    Oct 18, 2016 at 19:44
  • @Romasz My answer is not based on opinions. I've expanded it so that you can judge for yourself.
    – Zimm i48
    Oct 18, 2016 at 21:30
  • I've just realized that I cannot publish the source code for the app just like that - there are other parts like graphics and translations that would require its own licensing. This sandboxed environment becomes quite a hassle.
    – Romasz
    Oct 20, 2016 at 17:33
  • Well, you don't need to "publish" any of that. You just need to give your users access to it on request and you could very well accompany that with an explanation that they can use these graphics only for re-building the app and that they are not allowed to redistribute them further. As for source code, you are not forced to distribute it either, you could give the non-linked object code to the users who ask. Finally, you should realize that all of this is just giving notice of a possibility to your users, but most if not all are never going to use it.
    – Zimm i48
    Oct 21, 2016 at 9:41
  • I'm not sure if giving someone graphics, even only for rebuilding the app, won't be a violate to the license. In fact, you are in that case distributing it.
    – Romasz
    Oct 21, 2016 at 10:54

that is one corner case of the LGPL. The spirit of the LGPL is such that a user of your app should be able to drop in a replacement of his own without needing to access your code.

It would seem to me that if a process outside your app locks down this ability your app is in fact going against the spirit of the licence, indirectly yes, but the end result is the same.

Your best bet here would be to consult an actual lawyer who specialises in these questions. No advice you get online on some site, however reputable, will hold out in court.

  • My thinking is similar. Those licenses can make life really complicated. The best in this case that even if I make my app open-source, it will still be locked down by the system for normal user, who won't be able to replace libraries - which also means it's against license. The other thing is that the lawyer also can be wrong no matter how reputable. Therefore it seems that my users still will be limited.
    – Romasz
    Oct 14, 2016 at 15:54
  • True the lawyer can be wrong, but at least you can better defend that you made all necessary efforts to ensure compliance. As a judge there is a huge difference between "But I read on internet that it's ok" and "I here have a written opinion from Me xyz of x, y, z and associates that say it's ok" when trying to proove due diligence.
    – Newtopian
    Oct 14, 2016 at 16:02
  • You are right that it better sounds that I've got professional opinion rather than depending on internet. Nevertheless, as my app is a small project, which doesn't generate reasonable revenue, I will end with the way it's now. Especially that from my experience with lawyers, I won't get a direct answer - their opinions can sometimes complicate the problem even more and of course can cost lot of money.
    – Romasz
    Oct 14, 2016 at 16:30
  • 1
    they do tend to charge by the minute... :-P
    – Newtopian
    Oct 14, 2016 at 16:32

as far as I've understood, I've to use dynamic linking for libraries (in case for example user wants to replace the libraries),

FFmpeg has several build configuration flags: depending on which flags and codecs are activate, the resulting license may be one of LGPL 2.1 or LGPL 3.0 or GPL 2.0 or GPL 3.0.

I will assume that I use a build configuration that results in binaries being either LGPL-2.1 or LGPL-3.0-licensed. And that I use FFmpeg unmodified.

If my configuration is LGPL-2.1 or LGPL-3.0 I do not have to use a dynamic library, but if I link FFmpeg statically with my proprietary code then I would have to somehow make available to my users a static library of my proprietary code with build instructions (together in any case with the FFmpeg sources) such that they can modify FFmpeg and relink my application with their modified FFmpeg. If I link dynamically with FFmpeg I do not have to provide a source or object form for my own code.

Windows Store ap comes as a closed package which runs in sandboxed environment, I can put dll's as content in package, but user won't be able to get to them (at least without jailbreaking the device) - how to deal with that?

If my config is LGPL-2.1 there is no requirements that the relinked app be reinstallable on the device. But there is such a requirement if I use an LGPL-3.0 config of FFmpeg. In this later case I would consider that if I provide enough of my binaries and build instructions and scripts such that a new app can be created with a modified FFmpeg and then reinstalled then I have fulfilled my obligations (with my user eventually using the app store as the installation vehicle if this is the only way to reinstall).

There is no requirement in the LGPL 2 or 3 to ensure that code can be modified in place without any reinstall so supporting a reinstall with a modified FFmpeg should be enough

For some reference I would check this thread on FFmpeg (which is about the Apple App store but the context is the same). And this blog post from MSFT announcing support for FFmpeg on Windows.

  • Thanks for the answer. As for the link from MSFT - yeah, it is supported as it runs on Windows, though the developer has to take care of licenses. Sadly, there is another problem with publishing the source code of the app - there is some work, graphics, translations that is done by other people and I cannot publish it just like that. Damn, I'm spending more time on trying to understand licenses and avoid doing something illegally and keep other rights, than improving the app :| I think I will ask the lawyer how much his interpretation would cost.
    – Romasz
    Oct 20, 2016 at 17:31
  • Asking a lawyer is always a good idea if you can afford it. I would suggest Heather Meeker heathermeeker.com that I know personally and is excellent. Though this is a rather simple thing here. I do not have to publish the source code or object code of my app if I just link dynamically with an LGPL-2.1-licensed FFmpeg. I only need to attribute and redistribute the source code of FFmpeg proper which is easy enough. Oct 21, 2016 at 7:27
  • Thanks for the contact to the lawyer, I was looking for one, will give a try and ask how much it may cost. Thankfully, as you have already mentioned, the case seems to be simple, and it is before problems came out. If it was a desktop app, then I also won't have problem with dynamic linking.
    – Romasz
    Oct 21, 2016 at 10:52

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.