`smartstring` has a less permissive license than `rhai`; consider another crate

[BatmanAoD]

smartstring is licensed under MPL-2.0, which is less permissive than the Apache-2.0/MIT dual license adopted by Rhai itself.

Two MIT-licensed crates exist that serve the same purpose:

• compact_str
• smol_str (also dual-licensed under Apache-2.0)

These crates are also actively maintained, whereas smartstring has not been updated in at least two years; and Rhai has an existing issue stating that smartstring is unsound.

Can one of the other two small-string crates be used instead?

[schungx]

Yes, I realize the status of smartstring also... However, the crate has worked well so far and it is a core part of Rhai, being exposed in the public API. So any change to this would necessitate bumping to 2.0, which isn't really that bad, except that we'd need to really test it out and fuzz it completely before affecting the change.

I have been waiting for some kind soul to pick up maintenance of smartstring, as obviously the original author is busy with other things.

The problem with smol_str is that it is not mutable... and sometimes we would want to mutate otherwise too many string copies got made. smol_str is more for compilers and parsers with large amounts of static strings...

compact_str I am not familiar with so I really need to test it out fully before doing anything...

[BatmanAoD]

Unfortunately, I don't think a new maintainer would be able to change the smartstring license to MIT or Apache-2, which is currently preventing me from using rhai.

Looks like the compact_str API surface is a superset of the smartstr API, though I haven't checked thoroughly: https://docs.rs/compact_str/0.8.0/compact_str/struct.CompactString.html

One alternative to releasing a full 2.0 would be to make compact_str a feature in 1.0. I haven't thought through the ramifications of this very much, but I'm hoping that someone using smartstring only via what rhai re-exports wouldn't actually need to change their code to use the feature.

[schungx]

Well, so far smartstring has worked perfectly and I'd be careful to change it unless there is a very good reason.

[rudderbucky]

My understanding is that the MPL is not viral, in which case it can be used as it already is by rhai without restricting its licensing. Is that incorrect?

[schungx]

Not sure... non-lawyer-type here, and proud of it.

[BatmanAoD]

@rudderbucky I'm not saying Rhai is doing anything wrong, merely that by being more restrictive than MIT, smartstr can prevent some (corporate) projects from using Rhai. That's not necessarily a bad thing, of course, but something to consider.

For my part, it looks like I'll be able to use it as-is in my current project after all.

[rudderbucky]

@BatmanAoD I'm not a lawyer either, but to my understanding rhai can remain Apache-2.0/MIT despite using MPLd libraries, which means there's no reason for any project to avoid using it (beyond whatever restrictions Apache-2.0/MIT already have) unless they have a vendetta against MPL for some reason.

[BatmanAoD]

@rudderbucky That's...not how licensing works. You're still using smartstr if you use Rhai, and therefore you must comply with its license. This is why tools like cargo deny perform recursive dependency license checks.

[rudderbucky]

@BatmanAoD my understanding is compliance with MPL does not require you to license your own software with MPL (hence it is non-viral). In MPL's /smartstr's case specifically, the restriction is on modifying the source of the MPLd libraries. Since rhai doesn't actually modify smartstr (to my knowledge) it can remain Apache-2.0/MIT. It should follow that there are no additional compliance restrictions on your project by using rhai (because the only restriction is on modifying smartstr, which is a restriction you have anyway just due to it being MPLd).

[BatmanAoD]

@rudderbucky Again, I'm not saying that rhai is being licensed incorrectly; it's fine for rhai to be Apache-2.0/MIT (as far as I know).

I may be misunderstanding what you're saying about there being "no additional compliance restrictions" due to smartstr's license. I thought you were saying that rhai's license effectively "supersedes" the licenses of its dependencies, but your parenthetical seems to acknowledge that the restriction on modifying smartstr itself is still in place.

[rudderbucky]

@BatmanAoD There are restrictions on modifying smartstr whether or not you use rhai is what I am saying. Since the MPL license doesn't restrict anything else (to my understanding), there are no additional restrictions levied on you by using rhai. Using rhai is not adding any limitations to your project because those limitations were there from the get go.

[BatmanAoD]

@rudderbucky My point is that I wasn't sure I'd be able to use smartstring at all, and therefore I wouldn't be able to use Rhai, because that entails using smartstring.

[ejaa3]

@schungx I'll just say that the string "this_is_a_very_funny_key" (24 bytes) will be “allocated” on the heap by SmartString, but not by CompactString or Option<CompactString>, which is great. 🙂 If Rhai ever uses compact_str in version 2.0 or as a feature, that will be great too. 🙂