8

I want to sell a closed-application that depends upon a certain command line tool. Am I allowed to distribute my software including this command line tool?

For example, as a separate binary accompanied by the proper NOTICE file and if needed the source code.

Do I need to explain how I call this binary, so the user could swap it?

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Nick Russler
  • 191
  • 4
  • 2
    Depends on it in what way? How is the LGPL code invoked? – cpast Dec 11 '14 at 19:49
  • To preserve spitit of LGPL, you should also allow the user to override the command-line tool if he wants (i.e. not check the signature or checksum of the tool). – Vi0 Dec 12 '14 at 10:02

4 Answers4

12

LGPL allows you to link or embed binaries without opening your own source, so long as you provide the source code for the binaries and publish any changes you make to the libraries.

You must also deploy your application in a way that allows someone to replace the LGPL'd library, if they so choose. In practice, this means that you must dynamically link to the library, so that a compiler and your source code are not required to perform the linking.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • So you think i don't need to explain to my user how to exchange the binary? E.g. by explaining the params i use to call the binary. – Nick Russler Dec 11 '14 at 16:35
  • 3
    No, that's not a requirement of the LGPL, AFAIK. – Robert Harvey Dec 11 '14 at 16:35
  • 1
    No need to explain how it works: the purpose of the lgpl is to allow someone to take the source to the lgpl component, modify and recompile it, and then use the modified version with your program. It's assumed that in order to do this they'll need to understand how the original lgpl component works, but not how your program does. – Jules Dec 11 '14 at 18:58
  • 2
    @RobertHarvey: You missed one requirement that the LGPL puts on you: It must be possible for the end-user to replace the LGPL code with a compatible version of his/her own. – Bart van Ingen Schenau Dec 12 '14 at 10:04
  • @BartvanIngenSchenau: Can you cite the specific part of the GPL/LGPL combination that has that stipulation? In practice, does that simply mean that the library cannot be statically-linked? – Robert Harvey Dec 12 '14 at 16:38
  • @RobertHarvey: It is LGPLv3 clause 4d. And it in practice indeed means that you can't statically link a LGPL library in a non-GPL program. – Bart van Ingen Schenau Dec 12 '14 at 17:02
  • @BartvanIngenSchenau: Technically you can statically link a LGPL but you would have to provide openly the means for a customer to replace the LGPL lib and re-generate the exe. Could lie a tad bit outside the comfort zone of a closed source app though. – Newtopian Dec 12 '14 at 18:47
  • 2
    @Newtopian: That is right, and because it is such a hassle to replace a static library, the LGPL for all practical purposes requires dynamic linking with a non-GPL application. – Bart van Ingen Schenau Dec 12 '14 at 19:35
11

Do consult a lawyer for this, anything you get from this site (such as the answer that follows) will not free you from any liability nor guaranteed that you will be safe from prosecution. This site is most definitively NOT a proper replacement for any sort of legal advice.

Now to the matter at hand, from what I understand, LGPL will allow inclusion of a licensed library if the user of your proprietary software can replace, on his own, the LGPL components with his own. This implies that either you used it directly without modifications or provide the source code with your modifications to the component and that you provide sufficient means for the customer to perform the modifications.

In other words the LGPL must guarantee that the customer remains free to do whatever it pleases to the LGPL covered parts that are shipped with your application without going though you first.

The wikipedia page is a pretty good place to get started to understand this http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

you could try browsing groklaw see if they covered the subject

http://www.groklaw.net/index.php

Again this is NOT legal advice in anyway do get yourself a lawyer to help you through this properly.

Thanks to GpN to fin this FAQ that pretty much covers what you are looking for.

Newtopian
  • 7,201
  • 3
  • 35
  • 52
  • 1
    So a command line tool counts as a library? – Nick Russler Dec 11 '14 at 16:33
  • @NickRussler: It's LGPL anyway. The "arms length" stipulation only applies to GPL. – Robert Harvey Dec 11 '14 at 16:35
  • 3
    I think it would yes, akin to a dynamically loaded DLL, just more loosely coupled (Thus easier to respect the LGPL's terms). – Newtopian Dec 11 '14 at 16:35
  • @Newtopian, AFAIK, the nature of the linking does not influence if something is a dependent work or not, nor does the structuring in two or one executable. (That may help meeting the licensing requirement though, especially in the case of the LGPL). – AProgrammer Dec 11 '14 at 17:15
  • 1
    There is an additional constraint involving the ability to "swap-out" the LGPL tool for another one. This is trivially achieved by having the path in a config file. – Joshua Dec 11 '14 at 18:32
  • Having such a config file is unnecessary; the end user could just replace the existing file in situ, which is adequate to conform with the lgpl. – Jules Dec 11 '14 at 18:53
  • @AProgrammer: Linking actually does have an impact on LGPL. Dynamically linked libraries can be swapped in-situ while statically linked cannot. With statically linked libraries one would have to provide means for the customer to link again with a his own LGPL lib which implies distribution of more than just the final executable. – Newtopian Dec 11 '14 at 19:44
  • @AProgrammer I think that "what is a derivative" a matter of local copyright law, not the (L)GPL itself (so it depends where you are, and the actual determination is made by a judge). I'm also not aware of court cases determining that the differences you mention are irrelevant, in which case it's not necessarily clear whether or not a court would care (hence the first line of the answer). – cpast Dec 11 '14 at 20:01
  • @Jules: This should be true but might not be depending on other infrastructure (i.e. MSI). – Joshua Dec 12 '14 at 02:51
  • `you used it directly without modifications or provide the source code with your modifications` I believe you have to distribute the source whether you made modifications or not, as long as you're distributing the binary. – GnP Dec 13 '14 at 19:52
  • @gnp if you have not modified it technically the source code is already distributed elsewhere that said my response to your argument opens the door to nitpicking-land paved with flower painted carpets that we love tripping over so much :-) – Newtopian Dec 15 '14 at 17:06
  • @Newtopian I couldn't find a source for that statement, but I can see a few ways it could go wrong (e.g. original developer shuts down her site, automatically putting you in a position where you are distributing binaries of GPLed code without providing the source). I did find [this FAQ](http://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation) that seems to apply to OP's situation. – GnP Dec 15 '14 at 21:59
  • @GnP: Does indeed, nice find ! – Newtopian Nov 03 '16 at 13:40
5

The text of the LGPL is complex, as it attempts to define the term 'link', since the LGPL is intended to cover libraries. So it's a completely open legal question as to whether incorporating an LGPL executable (which is not a library) as part of a larger work is:

  1. the creation of a derivative work exempted from GPL provisions by the LGPL.
  2. the creation of a derivative work not exempted from GPL provision by the LGPL.
  3. the creation of a 'mere aggregation', and so not subject to the terms of the license at all.

It would depend on how a court decided to construe the exemption in the LGPL and how that same court would view what you've constructed. It may depend on exactly, technically, how you combine that executable with the rest of your stuff.

In case (1) or (3), you only have to make the source of the command itself available. In (2), you'd have to make all your source available.

In short, if there's a lot of money on the line here, you'll need legal advice.

bmargulies
  • 1,698
  • 1
  • 13
  • 20
0

AFAICT it is not forbidden to sell (L)GPLed software, as long as you provide a way to get its source; e.g. Red Hat does exactly this. I assume you don't make any modifications to the (L)GPLed tool, so linking to the canonical source code should be fine.

It looks like the tool is specifically designed to be included as a part of a non-GPL derived work. At least, so it works for LGPL libraries that you can link to a non-GPL binaries.

Note: IANAL.

9000
  • 24,162
  • 4
  • 51
  • 79
  • 3
    The question is not about selling. – Robert Harvey Dec 11 '14 at 16:22
  • 1
    Nor is it about **GPL** but **LGPL**. – Cody Piersall Dec 11 '14 at 16:24
  • 3
    @RobertHarvey: The question is basically whether the closed-source program is a 'derived work'. If the tool is covered with LGPL (not plain GPL), it looks like it is specifically designed to be included as a part of a non-GPL derived work. At least, so it works for LGPL libraries that you can link to a non-GPL binaries. – 9000 Dec 11 '14 at 16:25
  • @9000 exactly, but the main point of your answer seems to be that "it is not forbidden to sell [...] as long as you provide [...] its source". You also suggest that modifying the (L)GPLed tool would change the situation. It doesn't, it's the exact same thing, you have to distribute the source code for the tool. – GnP Dec 13 '14 at 19:58