My project is a command which is split in library modules (the logic) and a "main" module, which glues my lib modules to make the CLI command.

I don't really care about what people can write with the lib or the main module, but I want people to be forced to publish any modification they make to the lib, so I though I could double-license my project with LGPL3 + Apache2, the LPGL3 would be for lib modules. Would this be feasible? Would this result in what I described?

  • One obvious question: Is the main() really complicated enough to need a separate license? If it's "just" argv[] parsing plus function dispatch, then maybe it would be simpler to license it under the same license as the core lib. Anyone can just re-implement those things on their own anyway.
    – Kevin
    May 6 '19 at 16:29
  • It's a collection of subcommands actually, but they're not complicated at all. I though to use a double license since the "L" in LGPL usually stands for "library"... May 6 '19 at 17:07
  • Yeah, just license your program as Apache2. As long as you provide the source code of the LGPL library that you use (or just dynamically link to it), then you'll be fine. May 6 '19 at 19:33
  • @GregSchmit no I don't use any LGPL library; it's my lib that I want to license. May 6 '19 at 19:34
  • Oh, gotcha, that makes more sense. Then yeah you can absolutely license the library portion differently than the main file. May 6 '19 at 19:35

Sure, you can use such a construction. However, it would be much simpler if you license the command line wrapper under the LGPL as well.

The “L” in LGPL officially does not stand for “library” but “lesser” than the main GPL: it scopes its protections to the LGPL-covered component, and does not affect the entire program. For the FSF this is a matter of strategy: they want to increase the amount of free software in the world. The LGPL does not help as much as the GPL because it doesn't entice users of the component to publish their software under a free license as well.

The LGPLv3 is implemented as a section 7 exception to the GPLv3. If the conditions in that exception do not trigger (linking), then it behaves effectively identical to the GPLv3. It is therefore perfectly fine to use it for applications as well.

  • 1
    It seems that the OP's intent is that modifications to main shouldn't be required to be published. My understanding was that if you use the LGPL license then others can link to it but if they make changes to it then they must release those changes. Advising the OP to use the LGPL violates the OP's intent to avoid that requirement. May 6 '19 at 19:31
  • @GregSchmit No open source license (that I am aware of) requires changes to be published. GPL/LGPL only require that the corresponding source be provided alongside any binaries that are conveyed/distributed. It seems the main() will be fairly banal code, and it's probably not worth avoiding a copyleft license there if most code in the application is already under the LGPL.
    – amon
    May 6 '19 at 19:40
  • 1
    Sorry, that's what I meant, his intent was others being allowed to change the main and distribute the binary without source and suggesting copyleft violates that intent. But I agree that avoiding copyleft on that might not be worth it. May 6 '19 at 19:42
  • I really thank you for your answers. I got the message that the LGPL alone would suffice. Unfortunately, my project is written in Go which statically links, and that makes a child application a derivative work of it, thus nullifying my original intentions. For Go, LGPL is essentially equal to GPL, am I (kinda) correct? May 10 '19 at 12:31
  • @LivingSilver94 Static vs dynamic linking is not directly relevant – what constitutes a derivative work is for copyright law to define, not licenses. Anyway, the exceptions of the LGPL do trigger in case of static linking. The LGPL does not render the entire software subject to the LGPL, it is scoped to the covered code. However, LGPL requires that end users can modify the LGPL-covered parts. For Go, this requires that the entire source code is disclosed so that users can compile it themselves, however you are not required to publish the entire source under an open source license.
    – amon
    May 10 '19 at 13:51

@amon is mostly right, however my understanding is that you want others to make changes to main and not have to publish those changes upon distribution of the binary. In that case, license your main file as Apache2 (or something else that's permissive like BSD/MIT) and the library as LGPL.

Normally projects have a LICENSE file in the repository, however you might want to leave that out and then at the top of the files actually put the license for that file. Or you could have a LICENSE that explains the licensing of the project.

You could also split the project into the library portion and the executable portion that links to the library, or you could choose to license it all under a single license.

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.