2

I have a native application I would like to release under a copyleft license. The application embeds a Lua interpreter and exposes an application-specific interface to Lua code. I would like to release the application under a copyleft license and the Lua code under a proprietary license.

According to the GNU FAQ I can't use the GPL as the native application and Lua code have intimate communication and therefore constitute a single combined work. The LGPL might work as it defines a separation between the GPL and proprietary component.

My question is: is the terminology defined in "0. Additional Definitions" of the LGPLv3 literal or abstract? i.e. Given the definitions of "Application" and "Library" can I assign them to the components based on their role? Or are the terms literal i.e. "Application" literally means executable program and "Library" literally means linkable library?

15
  • 1
    Lua appears to be under MIT License, which is compatible with GPL. Why do you think your application cannot be published under the GPL license? Jul 15, 2023 at 8:05
  • 1
    There is the Lua interpreter and then there are the Lua scripts that run against it. The former is embedded in the native application, the latter are separate/loose files that are loaded by the interpreter and depend upon an API exposed by the native application. I want to release the native app under a copyleft license and Lua scripts under a proprietary license. I'm asking about the LGPL because according to the GNU FAQ the GPL requires programs with intimate communication, which the native app and Lua scripts appear to have, to both be GPL which is not what I want.
    – hgs3
    Jul 15, 2023 at 14:25
  • 1
    GNU explicitly OK's this usage however, they also state "...when the interpreter is extended to provide 'bindings' to other facilities...the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way." In my case, the application not only embeds a Lua interpreter but also exposes a Lua API to app-specific data structures.
    – hgs3
    Jul 17, 2023 at 4:12
  • 1
    I understand I can't use the GPL which is why I'm asking about the LGPL. The LGPL allows copyleft code to interface with proprietary code. My issue is the LGPL license terminology specifically describes the copyleft component as a "Library" and the other (proprietary) component as an "Application" which is the reverse of my use case. My question is: given the LGPL definitions of "Application" and "Library" (see section "0. Additional Definitions" of the LGPL) can I assign the terms to the components based on the license definitions or will I risk legal issues with this interpretation?
    – hgs3
    Jul 17, 2023 at 17:06
  • 1
    "Do you also desire that clients should be able to distribute these plugins..." Clients should be able to license and distribute plugins completely under their own terms. "you write about 'your plugin'..." We have our own 1st party Lua plugins we would like to distribute under our own terms. There is only one executable. "given the source of the application, and a copy of the running binary, would it be possible for clients to write plugins...": yes - using the docs and source as reference. We also have starter plugins and samples under a public domain license to further help them.
    – hgs3
    Jul 19, 2023 at 15:45

2 Answers 2

2

I think the solution is to release your application code under LGPL, but not alongside the binary. When a paying customer buys the executable, convey the whole thing (binary, application source, your Lua scripts) to them under the proprietary licence that you intend should cover your Lua scripts. However, also tell them that documentation and full application code, under LGPL, can be found at such-and-such a git repository, along with your "starter plugins and samples under a public domain licence".

This sidesteps the whole issue of (L)GPL expectations associated with the receipt of the binary, while making it clear that the LGPL codebase doesn't contain your Lua scripts.

On the offchance that a customer wants to sell or otherwise distribute their plugin, which you want them to be free to do, the LGPL as I read it will permit this - but you can add an explicit "plugin exemption" if you want to make it as clear as possible.

And as ever, IANAL/IANYL, so if you're going to bet a business on this, take professional legal advice.

1
  • I appreciate both the answer you and @ruben2020 gave. Unfortunately this doesn't appear to be a common situation so it will ultimately be a lawyer question. While I like their answer too (for all I know a GPL exception will be what the lawyer suggests) I'm accepting yours because you engaged with me for many many many days. Thanks again.
    – hgs3
    Jul 22, 2023 at 4:11
2

Another possibility is to release your native application (including the MIT-licensed Lua interpreter) under the GPLv2 or GPLv3 with the Classpath exception (quoted below). It is also used in a similar way to your use case, by OpenJDK for running Java applications on top of the OpenJDK JVM.

The Lua apps can be proprietary, and it doesn't matter if they have "intimate communication" with the native application. There is also no requirement to provide the recipient with a way to relink the "independent modules" to the GPL-ed software, after modifying the latter.

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

As for your second question with respect to "Application" and "Library" in the LGPL, I would say "Library" refers to the LGPL-licensed library and all its dependencies, while "Application" refers to any software, possibly an executable or even another library, that makes use of the LGPL-licensed library. The "Application" programmatically depends on the "Library", but the "Library" must not depend on the "Application". The "Application" must not be derived from the "Library", but merely using it.

IANAL.

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.