Options for complying with LGPL when building proprietary Rust binaries

Question

I'm looking at creating a proprietary USB driver in Rust to interface with a USB product via libusb.

I'm a big fan of Rust static linking because it simplifies deployment but it doesn't fit very well with LGPL dependencies.

It's obvious that the simplest way to comply with LGPL is to load libusb dynamically!

This exception in LGPL v2.1 leaves a few options:

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

I've seen suggestions that this means you can comply by providing a way for users to build their own libusb to use with the proprietary driver. This can apparently be achieved with Rusts rlib library files, but since Rust does not have a stable ABI this will be very tricky to use and doesn't seem in the spirit of LGPL.

The third option I'm currently considering is to ship a driver which statically links to libusb, but also allows users to dynamically load their own build of libusb at runtime via an environment variable. This would make deployment easy and would give users the option of using their own build of libusb, but would it comply with LGPL?

Answer 1

The third option I'm currently considering is to ship a driver which statically links to libusb, but also allows users to dynamically load their own build of libusb at runtime via an environment variable. This would make deployment easy and would give users the option of using their own build of libusb, but would it comply with LGPL?

From a licensing perspective, this would be compliant with the LGPL, if you can guarantee that there is no way that the dynamically linked version of libusb calls into the statically linked version of libusb.

From a technical perspective, it is no so easy to link a library both statically and dynamically into an executable. You will inevitably get multiple definitions for each symbol in the library.

This can apparently be achieved with Rusts rlib library files, but since Rust does not have a stable ABI this will be very tricky to use and doesn't seem in the spirit of LGPL.

Actually, the LGPL doesn't care about ABI stability. As long as the ABI is not so unstable that rlib files can't be transferred from one system to another, you are fine. You just have to mention which version of the Rust compiler to use.