option-ext dependency

[crepererum]

dirs-sys 0.4.1 was just released and comes w/ a new dependency option-ext. I think this is a bit unfortunate due to two reasons:

1. dependency bloat: dirs-sys is a rather low-level crate and just pulling a unused dependency just for a bit of Option convenience seems a bit excessive. Note that option-ext was basically unused by the Rust ecosystem prior to this release:
   
2. license: while dirs-sys (and all other dirs-dev project) are licensed under Apache2 + MIT (which is the de facto default for the Rust ecosystem), option-ext is MPL which is a copyleft license.

I can file a fix PR if this is OK w/ the maintainers.

[soc]

Hey @crepererum,

1. I previously had a project-local implementation of Option::contains when I still had hope that the standard library would add it. As that's not the case anymore, I rolled my own crate as I'm not planning to keep the copy-and-pasted option_contains function forever.

2. MPL is my preferred license, projects under any other licenses are pretty much a historical accident that I may or may not correct as time permits, see directories-jvm and dirs-cli-rs.

So thanks for your offer, but everything works as intended.

I'm closing this for now, but feel free to reopen if you have new information!

Cheers,

Simon

[joeroback]

yea, falling into this same problem, MPL-2.0 is not allowed (easily) by company, so we would basically have no other option but to use something else.

edit: basically moved to etcetera this morning. easy enough. this crate is kinda GNU / stallman now with this sort of random licensing change. good luck

[soc]

yea, falling into this same problem, MPL-2.0 is not allowed (easily) by company, so we would basically have no other option but to use something else.

edit: basically moved to etcetera this morning. easy enough. this crate is kinda GNU / stallman now with this sort of random licensing change. good luck

This is very bold coming from a company with a market cap of 2 TRILLION dollars.

[Jasper-Ben]

FWIW, I don't think that the usage of MPL is an issue in this case. Unlike the GPLs, MPL copyleft is limited to the source files that are explicitly licensed under these terms.

Thus, you can use MPL within a permissive (or even proprietary) project without any licensing issues, as long as you adhere to the responsibilities mentioned in the license, which mostly boils down to providing the Licenses for the MPL licensed files as well as a link to the source code.

If that is considered "too much" of a responsibility, just as a side-note: many permissive licenses also carry some heavy-hitting responsibilities, e.g. Apache:

You must give any other recipients of the Work or Derivative Works a copy of this License;
and
You must cause any modified files to carry prominent notices stating that You changed the files

[joeroback]

yea i don't think the MPL is much of a problem, but i am also not the legal department and i think most larger companies will just tend to avoid gray areas. its not ideal, its not my preference, but it is what it is, just like this project is free to use whatever license they feel is best for their project. i don't have any ill will towards the project, but it doesn't change the reality of the licensing situation with most large companies.

personally, i have never had issues with licensing open source stuff with BSD, MIT, or Apache and for very low level libraries, i personally think using more permissive can make them more popular, etc. i dont know the reason for the MPL in case, so its difficult to say if its the right choice or not. Rust is generally made wit MIT/Apache, https://www.rust-lang.org/policies/licenses, so low-level rust libraries probably should follow similarly, unless there is a good reason not to, otherwise it does have a cascading effect shrug .. again, just IMHO

i mean, option-ext is an extension to std::option::Option which is itself licensed MIT/Apache, so it probably makes more sense to license it the same, yes/no?