LGPL and static linking when third-party tools are required - providing an alternate version that can accept a replacement LGPL library

Question

I've been through a lot of the LGPL questions here but haven't found this specific question. This is probably the closest to my situation: Dynamic linking LGPL library and licensing in Windows Store app

I'm building an application (free to download, but not open-source, in a fairly niche area of engineering) and would like to make use of an LGPL library (a Java library in this case). I'm not modifying the library in any way. The issue is that I need to release the application as a single statically linked executable using a proprietary third-party build tool. My understanding of the LGPL is that I need to be able to allow users to replace that library should they so wish.

Now I could provide the "object code" to my application, in a compiled form, but then a user would need to obtain this third-party build tool in order to rebuild the full application. As it happens there is a free-for-personal-use version of this build tool (free as in cost, not license), but I don't think that would properly comply with the LGPL.

As a solution, I could provide a "LGPL friendly" version of my application that just loaded the jar file from a directory at startup - I am assuming this would be compliant since the user can then replace the library jar with their own version. But there would be a performance loss (although functionality would be identical).

So two binary builds of my application - identical functionality, but only one variant would allow replacement of the LGPL libraries used.

Would this solution be considered acceptable? Are there any examples of this out there? Any pointers to documents that discuss this further?

Edit:

apsillers answer is very informative, and helped me clarify my question a bit (I think)...

The library I'm dealing with is licensed under LGPL2.1, and section 6 states (in the context of being able to use a modified version of the library) :-

the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it

In my case, I deliver my application as a single .exe file (call this build A). In order for the user to re-link with a modified library and produce a new single exe they would need to download a closed-source tool "X" from a third-party vendor (and register with them in order to qualify for a free personal use license). "X" is not a general-purpose tool, nor included with any operating systems.

Along with "build A" I could also provide the same application as "build B", configured to load LGPL libraries from separate files.

Build "B" would be LGPL-compliant, but build "A" would not be. And I don't think that simply providing the two builds would migitate against A being a problem.

I think I need to try and keep the library jar outside my exe if possible.

Answer 1

The GPL FAQ says:

If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

It sounds like you already understand this, but you are concerned specifically about the user's ability to "relink the application" while relying on a proprietary build tool. I do not think you need to be concerned about this -- let's look at the what the GPLv3 says (and therefore the LGPLv3 also says, as an extended form of GPLv3) about build tools:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work

It's not perfectly clear whether your build tool is a "general purpose tool," but in my opinion, this definition requires you to include configuration files for use in your build tool, not the build tool itself. Indeed, it is not customary or required to include build tools like make with your distribution, even when they are under a GPL-compatible license and including them could create no licensing issue whatsoever. Include build instructions and build scripts for your object-form software; if those instructions include the use of a freely-available proprietary build tool, so be it.

While free-software purists might balk at being required to download a proprietary build tool in order to build your software, it doens't look like a GPL violation to me. Free-software purists also looked askance at Java programs in general (whether GPL-licensed or not) before there was a free-software Java implementation, and at software written for a non-free operating system. ("Using free software on Microsoft Windows (or any nonfree operating system) is the first step towards freedom, but it does not get you all the way there.") This may impact your software's popularity, but not its legality.

I expect this may be a controversial answer and welcome other opinions in the comments (or as fellow answers, please. :))