Reducing licenses used in dependency tree

[aclysma]

Hello, a few of us are working on an OSS rust crate called distill. (https://github.com/amethyst/distill) We were looking to transition from tokio to some of the other smaller async crates like async-io and async-net.

polling is one of the dependencies, and it depends on wepoll-sys. However, the license (MPL) is technically a copyleft license and we want to avoid copyleft licenses in our dependency tree.

I know licenses can be a controversial topic, and I’m not looking to debate the merits of any particular license. However, it appears that other than this one dependency, the entire dependency tree of async-std is free from any form of copyleft licenses.

I’ve contacted the author of the crate, but I think they prefer to keep the license the same, and I fully respect their wishes!

Thankfully, it’s not much work to create new bindings for wepoll-sys. I’ve already done this and plan to release it under Apache-2.0 OR MIT OR BSD-2-Clause (wepoll itself is BSD-2-Clause). Functionally, the only thing missing was a patch from @stjepang that was discussed here: piscisaureus/wepoll#20. I’m not sure what it is for or if it’s still necessary. I’m also not sure if @stjepang is willing to have it included, or if I would have to reimplement it if it is still needed.

(I'm equally happy for these new bindings to be owned by someone in the smol-rs org, if someone would like to take ownership of them)

I wanted to ask what other people think before going further. Again, I know there is potential for controversy with this topic, so I’m very sorry if it leads to any sort of awkward discussion. My angle here is just trying to reduce the number of licenses a user has to accept, or a company’s legal team has to clear, in order to use this crate, either directly, or indirectly via other ecosystem crates like async-std.

[zeenix]

I’m not sure what it is for or if it’s still necessary. I’m also not sure if @stjepang is willing to have it included, or if I would have to reimplement it if it is still needed.

@stjepang is no longer working on smol-rs or anything related so they're very unlikely to be interested. Given that polling isn't (yet) dependent on the changes in that open PR, I think it's safe to assume that that is not a blocker (for now at least).

(I'm equally happy for these new bindings to be owned by someone in the smol-rs org, if someone would like to take ownership of them)

Given all the smol-rs crates have a very liberal license (including polling itself), at least I would be more than willing to accept this change but you'll need to commit to maintaining your wepoll replacement crate I'm afraid and provide the PR for it.

@smol-rs/admins WDYT?

[aclysma]

After taking a second look at the PR today, I think I understand what the patch does and why it was needed. So if people here want to include it (now or later), I can reimplement it based on the code in the PR. Currently the polling crate includes a similar patch (it was upstreamed to wepoll-sys.) I would lean towards sticking to vanilla wepoll unless we know that this is a necessary change, but I will add this modification if it's desired.

I'm happy to maintain this and PR the necessary changes to use it. (It's just auto-generated FFI bindings and a 5-line build.rs). I made the modifications locally to polling already to verify that the bindings work. Just wanted to see what other people want to do first before I went further :)

[aclysma]

Is there a timeline in mind for when this can be published?

[zeenix]

Is there a timeline in mind for when this can be published?

Tbh, no but I can roll-out a release soon unless there are any objections.

@smol-rs/admins it'd probably be a good idea to figure out a release schedule for all of smol-rs crates. Every 2 weeks if there are new changes perhaps?

[fogti]

I'm not sure... I think this should depend on what the changes affect. A simple formatting or documentation fix doesn't need to be published that soon, while code refactorings or such should maybe have a longer testing period...

[zeenix]

Thanks for your input @zseri.

while code refactorings or such should maybe have a longer testing period...

Fair enough but where is it getting tested between the merge and the release? If we did pre-releases, that would be a different thing but even then it'll only be useful if people use the pre-releases.

[fogti]

I think pre-releases are a good idea for larger changes, as the allow a larger amount of projects to test/use them (some project don't want to pull in git dependencies...). Especially as I'm not sure if the @smol-rs/admins team will be able to fully test every such change completely (e.g. when they cover rare platforms or such, which makes testing much more difficult/slower).

If there is no consensus when the next release should be done, we should do a pre-release rather sooner than later.

[zeenix]

I think pre-releases are a good idea for larger changes, as the allow a larger amount of projects to test/use them

For sure and I agree that we should do those for large/api breaking/behaviour changing changes but I don't think this PR is one of them. Moreover I don't anticipate a lot of such changes in the future.

For smaller changes like this and fixes, I think we should have either release schedule in place (2 weeks is good enough for that) or make a micro release after each change.

[zeenix]

@aclysma just fyi, Just published 2.1.0.