BUSL-1.1 license dependency question: is Wasmer open source?

[hishamhm]

We are working on developing a product that may include Wasmer as one of the Wasm VM options. While doing the licensing review, we observed that while the main Wasmer repository uses the MIT license, the current master version depends on the webc module, which uses the BUSL-1.1 license, which is explicitly labeled as not open source. The upstream repository for this module as reported in its crates.io page does not seem to be publicly available (though the code is published via cargo and readable via docs.rs).

This module implements WebContainer, which is not something we intend to use. As of Wasmer 3.1.1, an earlier version we have tested, it was possible to build the Wasmer dynamic library without WebContainer support, which removed the webc dependency. However, as of the latest master branch, dropping this dependency requires also disabling support for WASI, which severely limits the usability of Wasmer.

Two points are of concern:

• BUSL-1.1 restricts the use of the code to non-production use, making the combined Wasmer binary effectively not open source
• it also includes a clause stating that on the fourth anniversary of the availability of the version, recipients of the licensed work may transition the module's license to GPLv2 — which would effectively cause the entire project linking webc, that is Wasmer, and whatever code is linking Wasmer itself, to become a Derivative Work under the GPL, and subject to that license as well

I see that the BUSL-1.1 license for webc is explicitly mentioned in this repo, so I assume Wasmer authors are aware of its presence. I can understand its use in the context of WebContainer and Wasmer's WAPM initiative, but was it intentional to make it a mandatory dependency for anyone using Wasmer with WASI, effectively changing the licensing terms of Wasmer itself?

[syrusakbary]

Thanks for the question @hishamhm, I think it's completely fair to ask for a clarification here.

I can understand its use in the context of WebContainer and Wasmer's WAPM initiative, but was it intentional to make it a mandatory dependency for anyone using Wasmer with WASI, effectively

It was not our intention to make the webc dependency mandatory. Because, as you commented, has unintended side effects on the licensing of Wasmer itself.
We may end changing the license of the webc crate at some moment to something more permissive, but we oped to play the "safe" card while things are in flux.

There are two ways to move forward:

1. Change the webc dependency to be purely optional on WASI
2. Change the webc license to something more permissive

It might be worth doing a call to see if the first option may be fully suitable for your use case, as I want to make sure the license doesn't represent a problem for using Wasmer or the Wasmer CLI.
In case interested, I'll drop here a link in case you would like to chat about it further: https://calendly.com/syrus-wasmer

In any case, we will try to resolve this with a path forward asap.

[hishamhm]

@syrusakbary Thank you for the prompt reply — looks like we're on a way to a solution, happy to hear that! I have scheduled a call, looking forward to talk. I'll also make sure to update the outcome here to share with the community.

[hishamhm]

@syrusakbary Thank you for the call yesterday, especially for listening to concerns and learning about your use cases! Since I mentioned above I'd share a follow-up here, I thought it would be a good idea to jot down our conclusions. My understanding is that in the upcoming release, the webc dependency license is going to be changed to be more in line with the rest of the Wasmer project, can you confirm?

[syrusakbary]

We are going to use MIT license (as in the other packages) for the webc package , so this will be resolved officially in 4.1 @hishamhm

[hishamhm]

@syrusakbary Awesome! This is great news. Looking forward to Wasmer 4.1!