It depends what you mean by "allows them to". In the case of your choice of license, LGPL v3.0, it's ambiguous whether there is any permissible way to release Rust applications that link against LGPL libraries short of including full source code, and even if there is, there are other problems.
The first potential problem is that (like C++) Rust always 'inlines' generic code into whichever client crate makes it fully concrete (i.e. chooses values for all the type parameters). In this case, it would not be possible to relink against modified versions (as the LGPL normally requires), so you would have to rely on the header file clause:
- Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license document.
But of course, Rust does not have literal "header files". You would have to make an inference that for the purposes of Rust code, "material from a header file" means anything that would have to go in a header file in C or C++, including all generic code as well as functions marked
#[inline]. But it's unclear to me whether such an inference would be legally justified.
Any non-generic code still has to follow the normal requirements:
d) Do one of the following:
- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
- 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
0) would only be possible by manual hacking around with object files. 1) is easier, since Rust can compile crates as dylibs … although this is not particularly well supported (issues with rpaths) and prevents the output from being a fully static binary (which is otherwise possible on Linux). But substituting a modified dylib only works if the mangled symbol names are the same. Currently, mangled names depend on absolute paths on the build machine. Luckily, it seems like that will be fixed soon… though even then, since there is no ABI stability guarantee, you'd have to compile the modified library version with the same version of rustc as the original. Which isn't so bad, except that it means as an application distributor, you have to remember to document which rustc version you use - which is possible but annoying.
Once you've gotten past the Rust-specific issues, you're left with the usual [L]GPLv3 requirements:
The LGPL requires "terms that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications". In the FSF's opinion, this precludes distribution on Apple's App Stores; in my opinion, it also precludes distribution on Google Play (but nobody seems to have noticed). If you think that iOS is evil, that's your right, but obviously there are a lot of people interested in writing iOS apps.
It also inherits the GPLv3's requirement for "installation information", which prohibits use in locked-down systems (somewhat more sympathetic but still a restriction).
As well as the patent clauses, some of which arguably apply to the entire program, not just the library.
The last two also count as "additional restrictions" for the purpose of the GPLv*2*, so it is not permissible to link the library into GPLv2 programs.
All of these restrictions can be justified in one way or another, but at the least they're a bit much for a few hundred lines of code...