undefined | Better HN

0 pointsdathinab4y ago0 comments

> I don't think it matters that it is impractical.

But it does matter, it practice it matters more then what is legal if we are honest.

> It isn't the FSF's job to write Rust tooling

Yes, but it doesn't mean that it's not a bad license for the given use-case.

If it's impractical, then in practice there is not much difference to the license simply forbidding the usage (iff the company cares about what is legal).

Through the question is is it a bad license for the given use-case? I.e. does Sequoia provide a rust API or do they provide a C-API written in rust.

Licensing a rust "for-rust" library as LGPL is in practice so close to GPL, that you just could have made it GPL. But a rust C-ABI library/program (e.g. a system library) is a different matter and binding in a LGPL C-ABI library into a rust project still somewhat practical doable (but still quite annoying).

0 comments

3 comments · 2 top-level

_jal4y ago· 1 in thread

> But it does matter, it practice it matters more then what is legal if we are honest.

To the first part, I meant simply "impracticality does not effect the legal analysis here". Of course it matters for writing code.

To the second part, "if we're honest", it doesn't matter at all, because people are going to do what they're going to do, right?

dathinabOP4y ago

Yes

lmm4y ago

It's still meaningful. When I worked with an F500 corporation they wouldn't allow using GPLed libraries in internal tools without specific review from legal, but LGPL was fine. And it gives someone who wants to use the library in a proprietary product the option of improving rust toolchains to support dynamic linking better; given that proprietary code authors have done things like writing a wrapper for a GPL library that then uses pipes to talk to their main code, this gives them a better route.

j / k navigate · click thread line to collapse