Adding support for `bzip3` in `Ouch`

[marcospb19]

Hey!

I'd love to use this to add bzip3 support to Ouch.

It's a fairly new crate, so I wanted to politely ask if you'd trust its current state, Ouch is shipped to a couple of distros so I just wanna be a bit cautious and hear from you if you'd trust it as it is right now, or if I need to wait, idk.

Also, do you need any help with any specific issue right now? I'm willing to help :) .

[bczhc]

Hello. I'm amazed this crate gets noticed. This is my first ffi-wrapper crate, so I may lack some experience with this.

For the current state, I've made some unit tests, and I'm basically sure they should work properly. If you're interested please review and critique these code, I'll appreciate it a lot!

So far this crate hasn't implemented parallelism. I have not even given that a try... I will manage it in the future.

Also license could be a trouble, I think. libbzip3 is under LGPL. Now in build.rs it will search for the system library libbzip3 and link against it; another way is to add bundled feature and it will compile bzip3 as a bundled library. I set the repository license to LGPL, but I know due to the way Cargo works, this seems to be problematic for Rust apps and essentially equivalent to GPL. See https://github.com/rpm-software-management/librpm.rs/issues/21.

Anyway you are very welcome to contribute to this repo. I will feel very grateful!

[marcospb19]

I'm intrigued by the LGPL issue :smile:.

It prohibits me from shipping a binary even though Ouch is non-profit and open-source. That might or not be what the bzip3 creator/contributors intended.

Well, I'm allowed to support bzip3 and ship my code around, I just wouldn't be able to ship the binary to (for example) Arch Linux.

I can create an issue in the repo to politely ask if there's any chance of considering MPLv2 (or modifying LGPL) to make it compatible with Rust and also to turn your crate more useful and accessible to everyone. What do you think?

(I've found the license distribution of crates in 2020, and the vast majority is incompatible.)

[bczhc]

Ehh well, sorry but actually I don't know about licensing very well. I'll be willing to change it to a more permissive license. Currently the -sys crate is just a simple FFI wrapper to the underlying C library, and should I just make the higher-level Rust part under the MPL, keep the -sys crate the LGPL, or do for the both? For the compatibility should we make extra notes in the license terms? Any ideas?

[marcospb19]

should I just make the higher-level Rust part under the MPL

the way I see is: there's nothing you can do right now to mitigate the license problem, because first we'd need it to be fixed upstream, and then you can do something about it

that's because you can't relicense their code with MPLv2, just yours, but this library uses theirs, so nothing really changes

MPL source code files can be directly copied into a (possibly) proprietary software project (static linking), while LGPL licensed code must be dynamically linked

from https://softwareengineering.stackexchange.com/questions/221365/mozilla-public-license-mpl-2-0-vs-lesser-gnu-general-public-license-lgpl-3-0

[bczhc]

Ah I see. But what if the upstream won't change it? An idea for Ouch (and all Rust apps that use crates under LGPL like this one), bzip3 can be an optional dependency. When libbzip3 is present at compilation, it dynamically links, otherwise not providing bzip3 (de)compression capability.

[marcospb19]

But what if the upstream won't change it?

Then we'll do what we can! I do like your plan B, but if you're OK with that I'd like to ask upstream first :) .

[kspalaiologos]

Hi!

Check out this section of the LGPL wiki page: https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL.

Basically, static linking to an LGPL library is allowed, but you must make the source (or linkable compiled version) of the library available. Linking to either type of library will not pollute the rest of your project so long as you make the source or object files available and include a copy of the LGPL.

Using LGPL for a Rust library license is fine, but it generally pushes people away due to the complexity of the license as a large majority of Rust libraries are licensed under MPL, Apache2, or MIT.

[marcospb19]

Awesome!

So I need to copy-paste the license file contents and make your source code available.

About providing source code, can I:

1. Add a link to this repo in Ouch's LICENSE file?
2. Add a bzip3-rs-source-code.tar.gz to my GitHub releases?

I guess Ouch can link to bzip3-rs and bzip3-rs link to bzip3.

If so, I'd suggest we try that, and if someone complains, well, we figure it out! :) I'd be willing to make changes if necessary.

Would one link be enough though? It's better than copying everything because you can see the whole repository, but it seems like the license wants me to provide Source to the "Library Code" in a specific version.

Whatever that means, the license isn't very specific.

[kspalaiologos]

Providing the link to the source code of the version you use is completely fair by my interpretation of the LGPL license

[marcospb19]

Thank you!!

@bczhc all unblocked, fortunately, I don't have to use the bundled feature. And on your side, I believe you must add a link to the official repo.

[bczhc]

Happy to know. For my understanding of LGPL, this does make sense. For making the bundled (if using bundled feature) bzip3 C library source and version publicly known, actually git submodule clearly shows that, like bzip3 @ 539278b. But I'll still write it in README.

[bczhc]

I'm still new to Rust and now the code "just works". I need still to learn more and improve the code. :sweat_smile:

[kspalaiologos]

By the way, please make sure to periodically update the library and use only the officially pushed out tags. Otherwise you may end up using a copy of bzip3 that doesn't work (and it doesn't have to, because it's not a release.)

[bczhc]

Alright. I've updated it and link to bzip3 1.3.1.