Why relicense from MIT to LGPL?

### Affected APIs All ### Reason Completely missing ### Additional context See - https://github.com/zen-fs/core/commit/6dcab0df1701664deae8dd734f6013e89b1157a4 - https://github.com/zen-fs/core/releases/tag/v2.4.0 > Re-licensed under the LGPL. Most projects will not need to do anything, though any forks and patches (not dependents) of ZenFS must also use the LGPL in order to update. This does not extend to the rest of your code. Just like with the MIT license, distributing ZenFS requires inclusion of the license. Does the LGPL license not require applications, websites, etc. to allow users to switch the library with anything else they choose? To comply with the LGPL license, many distributed projects will dynamically link to the library or allow users to compile projects from scratch. While that’s fine with server usage, web usage is severely impacted by this change, as sending a JavaScript file over the network may count as distribution and impose additional license requirements. Modern bundling setups for the web do not make this easy. If your goal is for users to open-source library modifications while being allowed to use the library as-is in any project, consider the MPL 2.0 license instead or the LGPL with the static linking exception. One solution would be to have multiple licenses under the `LGPL`, `LGPL-3.0-linking-exception`, and `MPL-2.0`.