Confused about licenses of crates (eg: MIT vs LGPL)

In Short

If crate A is LGPL-licensed, and B is its dependent (B uses A), could B be MIT-licensed?

Details

I read the original text of LGPLv3, and in its Q&A, it said:

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

    (1) If you statically link against an LGPLed 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.

    (2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Ref: Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation

In most cases, Rust crates are statically linked.

So, how could I "provide my application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application"?

And, is there any famous project which has to statically link to a LGPL-licensed library and it is MIT-licensed (or Apache-2.0)?

Summary

What I understand is that:

  • If crate A is LGPL-licensed, and B is its dependent (B uses A), B has to be LGPL-licensed.

Is this correct?

I am not a lawyer, or much experienced with licenses, but the text you quote alone sounds (to me) like B being open-source is sufficient to meet the requirements. So MIT licensed code would work, too; B would not need to be LGPL. Of course if you distribute the source of B and A together, it should be indicated that A doesn't have the MIT license.

Unlike typical software under MIT license, the dependency would probably disallow others to modify B into a proprietary app, or use B in a proprietary program, because of the transitive dependency on A. Someone who would want to do this could probably re-use and modify the source-code of B, but would need to remove (e. g. replace with a differently licensed alternative) the dependency A that has an incompatible license. Or they would need to intruduce a layer of dynamic linking, and ensure everything below the dynamically linked interface stays open-source[1].

The text you quoted mentions "object format" and I'm not familiar with this term. I think this sounds like it doesn't actually have to be open-source, but merely in any format that allows others to redo the linking. The term may be referring to the binary format that compilers output before feeding the files into a linker.


  1. not necessarily actually open-source, see the next paragraph ↩︎

1 Like

Thanks for your reply.

I have such a question, because I saw some LGPLv3-licensed crates in crates.io, some dependents of them are MIT-licensed, Apache-2.0-licensed and so on.

But:

  • Does those MIT-licensed crates would work well without those LGPLv3-licensed crates? No!

  • Can we know if those MIT-licensed crates has LGPLv3-licensed dependencies clearly in crates.io? No!

As you said:

it should be indicated that A doesn't have the MIT license.

Maybe there were some, but I didn't see any.

When executes cargo build or cargo install, cargo will download those crates as dependencies, dependencies' dependencies and so on; but no crate indicates the licenses of its dependencies.

I have no doubt in PyPI, NpmJS and some other communities, because they are dynamically linked, you can replace them with libraries which have some APIs.

And I forget which, but I remember there exists a package management tool will let users input a YES to accept some licenses when builds.

I'm writing Rust in my works for a few years.
Almost all of our projects are MIT-or-Apache-2.0-licensed; there are too many dependencies.

I just want to figure out this, to make sure no offense to those original authors.

Of course we do! The are cargo-license you may install and use or cargo-deny.

Not true, too. Supposed you are using SQLx and tokio in your procmacro crate. This may bring hundreds of other crates, some of these may be LGPL or even GPL.

But what's actually in your binary doesn't depend on code of these crates, but only on code of what was in your procmacro crate!

Licensing is complicated, you wouldn't find an easy answer on forums.

If you are making proprietary software and need a legal advice… ask a lawyer!

And don't expect them to present you an easy to follow algorithm which would allow you to determine whether something you are doing is legal or not.

Law just doesn't work like that!

That's meaningless question to ask in a world of licenses. The only question worth asking is “can anyone successfully sue you and how much money they may kick out of you in damages”.

And it's perfectly fine to have MIT module built on top of LGPLv3 module: even if it's effectively LGPLv3 today (because if static linking) it may not be LGPLv3 tomorrow (someone may write a different backend for your module or it may just be relicensed, etc).

Heck, it's even fine to MIT module built on top of GPLv3 for the same reasons!

1 Like

Of course we do! The are cargo-license, you may install and use or cargo-deny.

I use cargo-deny, I know it, but, does all crates used them?

Not true, too. Supposed you are using SQLx and tokio in your procmacro crate. This may bring hundreds of other crates, some of these may be LGPL or even GPL.

Off topic. Generated code are different.

In fact, lots of licenses have explained that, for example: Bison exception.

Law just doesn't work like that!

I'm not talking about laws.

Lots of authors are individual, and live in different countries.
It's very hard to sue a person who may live in another country.

In fact, I have no worry about the laws.
That's duty of my boss.

No offense, just an example: if I scold you here, any laws could punish me?
Delete my account? I don't care, I just registered before 5 hours ago.

But I won't scold you, because of morality.

As I said, I just want to make sure no offense to those original authors.

Licensing is complicated, you wouldn't find an easy answer on forums.

Because licensing is complicated, so we could disrespect others' works when we won't be punished by the laws?

I don't think so.

That's meaningless question to ask in a world of licenses.

I just ask a question. I know not all questions have solutions.

I have to ask then I could know whether this question has a answer or not.


I think I have got an answer: just ignore that (unless I could be punished).

Although I don't like your answer, but still thank you for your reply!

1 Like

Legality aside, I think typically the reason someone would choose LGPL over the more restrictive GPL or AGPL would be to allow the code to be used in non-GPL programs, and the reason for selecting LGPL over the less restrictive MIT/Apache/etc would be to prevent the code from being used in proprietary closed source software. I can't say for certain, but as long as your project is open source I imagine the authors would be fine with that.

First, let me note that I am not a lawyer, nor have I ever consulted with one on this topic— Everything that I say here could be completely wrong or only applicable in certain jurisdictions.

The way that I understand the state of copyright law wrt. open-source software is that the license covers:

  1. The source code
  2. Any "derivative work" made from that source code.

In general, the source code for a crate B that depends on another crate A will not itself contain anything copied or derived from the source code of A, and can therefore be distributed under whatever license the author wishes to use. The compiled version of a program that uses both crates A and B, however, is a derivative of both and must therefore comply with both licenses.

In some cases, these licenses may contain contradictory requirements that prevent you from legally distributing the compiled version. If this happens, you'll need to either pick only one or the other to use, or else negotiate an alternative license with one or both crate authors— The grant of an open-source license to the public doesn't mean that the original author can't also offer the same code under a different license.

3 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.