I am working on building an app for desktop deployment. I am using an open-source platform that, for the purposes of this question, can be considered to use a CopyFree license. That platform itself links multiple external libraries though. Some of these libraries are under BSD license, some under LGPL license, and some under GPL license. I want my product to remain closed source. I know GPL requires users of a GPL component to also release there source under GPL, but as far as i know, BSD permits me to remain closed source; I am unsure about the requirements of LGPL for end user deployment.

Assuming i can find a workaround for the GPL component, is it legal for me to remain closed source while incorporating external libs that are both BSD and LGPL?

Also, I have not made any changes to any of these libraries. Would it change the ability for me to stay closed source if i were to use an altered version of one of these libraries?

Also, what is the legal effect on static vs dynamic linking?(I want to be cross platform)

Thats 3 questions. I hope this is not too broad?

  • low rep. see /r/kipplebits for definitions of CopyFree, BSD, LGPL, GPL
    – user10975
    Feb 19, 2017 at 19:58
  • also can i suggest tags for lgpl and copyfree
    – user10975
    Feb 19, 2017 at 20:00
  • This might get better answers on Open Source. Do you want it migrated?
    – feetwet
    Feb 19, 2017 at 20:59
  • still trying to figure out the nuance. people might find this useful maybe: github.com/kipbits/GNU-GENERAL-PUBLIC-LICENSES-COMPARISON
    – user10975
    Feb 21, 2017 at 18:04
  • Thankyou @feetwet , I looked at opensource.stackexchange.com and was overwhelmed by numerous contradictory answers. I therefore am hesitant to post my question there. I intend to read through all versions of GPL in my own time, and will post an answer to my own question when i have it figured out. I just don't want my question/answer to get lost in the pile
    – user10975
    Feb 22, 2017 at 15:06

2 Answers 2


Ok here is my go at answering my own question: (see comments above & below for links)

Depending on what you want to do, GPL can be a bit complicated, with multiple versions, version numbers, and added exceptions over the years. it can be a headache. However, for this purposes of app development incorporating GPL/LGPL libraries, it is fairly straightforward. Keep in mind to check version numbers on all relevant documents, although they are most likely v3.0. As far as I know linking to a GPL library binds you to also releasing your code under GPL. So that is a no-go for closed source, but that brings me to my 1st question.

is it legal for me to remain closed source while incorporating external libs that are both BSD and LGPL?

and I think the answer to that is yes provided that I dynamically link to said component (.so .dll .dylib .framework). Permission of this is granted under section 4d of LGPL v3.0.

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

My 2nd question

Would it change the ability for me to stay closed source if i were to use an altered version of one of these libraries?

It is my interpretation that in this case the only source you would need to provide is that of the modified library, and that the application itself can remain closed source. I'm basing this on grounds that nothing has changed from the situation for my 1st question other than the fact that the modified component library is now a derivative work under standard GPL v3.0.

finally my 3rd question

what is the legal effect on static vs dynamic linking?

This seams to be a bit iffy. Again see section 4d of the LGPL v3.0. By this wording dynamic linking is much preferable, and there are basically no requirements. If you choose to link statically though(in other words as part of the project build) things get complicated. To fully understand see LGPL definition of "Corresponding Application Code", and then see sections 4 5 and 6 of the GPL document. Full source is not required, but as far as i can tell you are required to provide all necessary materials for someone to build the project from scratch, so they can use a different version of the library if they so choose. This, in my opinion, would not be closed source.

I hope that is clear enough? I did quite a bit of looking around the internet in coming up with this answer, and in the end even some reading of the license, though I'm not sure I've actually read them through in there entirety. Keep in mind that there are multiple version of each license, and you should check version numbers for each LGPL library you use. There is a lot of good information on on opensource.stackexchange, although much more than one can process in a single sitting, and with occasional disagreement on finer points.

Below are some related links.









  • This looks good. Do you need help embedding the links you're putting in comments into the answer?
    – feetwet
    Feb 23, 2017 at 16:07
  • I think you've nailed a lot of the key points, just want to point out that you can statically link the two, but a lot of people say you can't since it's a real pain to do so. When linking statically, you have to distribute the library's object and source (not your own) in a retrievable format that would allow the user to modify and rebuild the library, then attach it to your program. It just so happens that for many languages, doing so is a royal pain. A lot of the confusions are why I really dislike the LGPL (and prefer the MPL).
    – Zizouz212
    May 10, 2017 at 23:36
  • More confusion stems from the fact that things can be vastly different in licensing across jurisdictions, and people take that and then confuse innocent people. The new version also switched up many things. This is s. 6 of the LGPL 2.0: As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
    – Zizouz212
    May 10, 2017 at 23:40
  • So just the different structure of the license (I mean heck, they even changed the name of the license) just threw many people off. But all that aside, you really got to the key points. I know they address the LGPL 2.0 specifically here, but Teem made a pretty good write-up addressing these usage quirks, and they've written it really well. Worth a read if you have the time.
    – Zizouz212
    May 10, 2017 at 23:45

A program which is a derivative work of GPL content must generally be distributed in open-source fashion. On the other hand, the GPL expressly grants global irrevocable permission for anyone and everyone to do a few things, with no restrictions other than those expressly provided:

  1. Anyone may produce derivative works of GPL works for any purpose that does not involve distribution of the derivative works.

  2. Anyone may distribute storage media containing copies of GPL releases via any means for any purpose that would allow the unmodified content of those releases to be readily extracted. Media containing such copies would, for purposes of the GPL, not be regarded as derivative works of the GPL content therein.

A key distinction between static linking and dynamic linking is that any potential "derivative work" produced via dynamic linking will be inherently ephemeral, making it almost impossible to avoid satisfying the first requirement listed above, while compliance with the gcc would require that one "manually" prevent any distribution statically-linked programs.

Note that the fact that a collection of files could be linked with some other set of files does not make the former set of files a "derivative work" based upon the second. If one were to statically link the files to produce an executable, the resulting executable would be a derivative work. A set of machine instructions, however, that would direct a recipient's machine to acquire or extract GPL software and perform such linking would not be a derivative work of that GPL software if it didn't contain any copyrightable content or aspects from the files to be linked with.

You must log in to answer this question.