89

I have read on the web that following combination exists :

Proprietary Source code + GPL Source code - > GPL Source code ( All code has to be released under GPL)

Proprietary Source code + LGPL Source code - > Proprietary Source code ( All code remains Proprietary )

Now how does statically/Dynamically linking GPL and LGPL code works with the above combination?

Zoe
  • 27,060
  • 21
  • 118
  • 148
Raulp
  • 7,758
  • 20
  • 93
  • 155
  • 4
    **Propriety Source code + LGPL Source code - > Propriety Source code**, this is wrong, LGPL Source code stays LGPL. – wimh Apr 16 '12 at 17:30
  • 4
    I'm voting to close this question as off-topic because it is about licensing or legal issues, not programming or software development. [See here](http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964) for details, and the [help] for more. – JasonMArcher Jun 03 '15 at 04:14
  • 2
    I wonder is this should be migrated to https://opensource.stackexchange.com/. But it's really somehow important also for developers, thus not sure. – pevik Jun 08 '20 at 10:31
  • @pevik For the record, the question is far too old to migrate. There's a 60 day migration window, which you missed by a solid 8 years (and it's about 11 years too late now) – Zoe Jan 26 '23 at 12:04

1 Answers1

120

If you want to distribute a combined work, you'll have to use the following license;

Proprietary Source code + GPL Source code

Proprietary Source code + LGPL Source code

See also executing a (L)GPL program from proprietary Source code.

Update (November 2014): A Comprehensive Tutorial and Guide contains a clear an detailed description of the (L)GPL and its usage, including distribution. I recommend it for more details.

Community
  • 1
  • 1
wimh
  • 15,072
  • 6
  • 47
  • 98
  • About " *you must release both parts as LGPL* " part: Does not have to be LGPL, I think. Application source code released under any license should be fine, even a license which prohibits modifying, as long as it permits redistributing of the unmodified application source along with the LGPL library (so re-compilation is possible). – hyde Jan 07 '14 at 07:14
  • 1
    ...though, I suppose the " *provide everything that allow the user to relink the application* " part covers also providing source under other than LGPL, so it can be re-compiled and then re-linked. – hyde Jan 07 '14 at 07:23
  • I wanted to ship a game statically linked with SDL1.2. Do we actually have to ship the object files or whatever to allow re-linking, or only offer to provide them on request, like with copyleft source code? Might rather go with dynamic linking if I'd have to ship the .o files. – Sam Watkins Sep 04 '14 at 01:34
  • @SamWatkins I think [lgpl-2.1](http://www.gnu.org/licenses/lgpl-2.1.html) 6d says that if you offer a download of your game, you must also put the object file somewhere where it can be downloaded. 6c says it you physically ship something, a written offer to provide the objects would be sufficient. – wimh Sep 04 '14 at 20:57
  • 3
    I'm mostly sure this comment is absolutely correct. If you statically link a LGPL library, then the application itself must be LGPL. We have had our lawyer double-check on this in the past. Dynamically linking to a LGPL library is the only way to avoid becoming LGPL. – Stevan Jan 14 '15 at 16:02
  • I create a software and that send command to another program (FFmpeg), I don't change the FFmpeg! The FFmpeg is in LGLP license. What is considered "Statically" and "Dynamically" linking? FFmpeg need to be downloaded after install my software? I already create a way to the end user change the location of the FFmpeg, so everyone can use another version and variation of FFmpeg. I don't understand what is "Static" and "Dynamic". I need to share the source of my software and the source from FFmpeg? This is a noob question. :S – Inkeliz Jun 24 '16 at 17:28
  • 1
    @Inkeliz comments should not be used for (new) questions. But your question would now be considered off-topic. If you use a lgpl ffmpeg binary (for example on windows ffmpeg.exe), then you either do not link to it at all, or it would be dynamically. As you use the lgpl version, you don't need to share the source of your program in both cases. You must offer the ffmpeg source code, but because you don't change it, it is sufficient to point to the official website. – wimh Jun 24 '16 at 18:58
  • 1
    is there any difference using binary (static) or shared library in apk (Android app)? user can't easily replace library in apk in both cases anyway – user25 May 13 '18 at 19:48
  • How does this work LGPL libraries written in interpreted programming languages? (Where you import the libraries as scripts. Is that dynamically or statically linked?) – CMCDragonkai Oct 24 '18 at 07:19
  • How about `proprietary code` using `LGPL 2.1 plugin`, to be specific `maven build plugin`, does that affect the code license? – Bionix1441 Sep 01 '20 at 08:27
  • 4
    @Stevan Your comment directly contradicts LGPL's own official FAQ. That is now linked to by the answer, and the answer has also been updated with that info: you do NOT need to licence your code under LGPL if you statically link, just provide *some* way for users to update library code and relink your executable against it. That includes giving suitable unlinked binaries, or providing your source code under a proprietary licence. (I'm not sure what comment you meant by "this comment" - I think maybe you were referring to the answer (at the time).) – Arthur Tacca Apr 09 '21 at 10:46
  • @Authur Thanks for this extra info. I know at the time I was supporting an LGPL software driver product, we did not want to support any kind of build/linking process for customers. That said, it's good to know that statically linking LGPL code might be viable for commercial software as long as there is a way to relink executable against static libraries. I could be wrong, but I suspect that it would be rare that companies would mix static LGPL libraries with their closed source proprietary code. Unfortunately, I do not recall what I meant by "this comment" either. – Stevan Apr 10 '21 at 17:00
  • I think the important point here is that LGPL v2.1 and v3 differ in this regard. With v3, only dynamic linking is allowed if you want to choose your own terms. With v2.1 there is an exception if consumers can use your proprietary code with their own version of the lib by some means – Tim Oct 09 '21 at 18:05