Permissive License

[0x0ece]

Hi, we really like multichain and would like to use it as part of a new open source custody solution we're building.
However the current license is a major blocker for us.

Would you consider relicensing MIT or Apache2?

We'd be happy to contrib back more chains & assets and possibly even some "business logic" like "transfer n assets from x to y", depending on where you'd like to take multichain. Also happy to hop on a call if you prefer to discuss more.

[jazg]

Hey @0x0ece, how does LGPL sound? It should mean you don't need to modify the license of any part of your project that uses Multichain.

[0x0ece]

Thank you @jazg, unfortunately LGPL doesn't really help much in practice.

Our plan is to release apache2, so anything with permissive license can easily be added in, no question asked. Anything else would be extra work to evaluate with the legal team.

Furthermore, if this were a py or js project I feel we could find a workaround, but with go it's a bit more complex. For example, we make big use of protobuf/grpc, and I saw you built surge which is slightly different (I really like your approach btw). To mix proto & surge we'll have to make changes to how multichain serializes objects like addresses, inputs, recipients... including in some cases rename the Unmarshal function because go doesn't permit overload.) Or, alternatively, rewrap every single object with our own but this kind of defeats using multichain.)

How does this all play with LGPL? Very unclear. Will I be able to discuss this level of detail with a legal team? Even more unclear. :) So in summary, a permissive license would make our life much much easier.

[jazg]

@0x0ece I created a PR to update to MIT, but as far as I can tell we will need the permission of all third party contributors to do so. Let me see if I can reach them.

[0x0ece]

👋 any updates on this?

[jazg]

@0x0ece Haven't been able to reach out to them unfortunately. May need to get a legal opinion to gauge our options.

[0x0ece]

Happy new year! Some exciting updates on our side: we're officially testing our new product with real money and we plan to open source it by end of Jan.

So... now we have to make a call say in the next week max two. Either we can use a MIT fork of multichain, or we'll have to spend the remaining weeks to rebuild our own. Clearly I'd like the first one.

Specifically, we're using bitcoin, dogecoin, ethereum and evm. We would like to add solana soon.
This is to say that if we can't get to an agreement on the full multichain, maybe we can start with a fork with a subset of the chains?

On the contributing side, we have already extended multichain to use erc20 and we plan to add litecoin and SPLs on solana. We also have a draft "api" layer that unifies the chains without distinguishing account vs utxo, and a "factory" that creates clients, builders, etc. on the fly to make it simpler to use. (As these are kind of bigger changes, we don't expect you want to merge them. We put them in an independent package, but clearly happy to discuss what you think should be merged vs not).

In summary, we're pretty invested, would like to use and contribute to multichain. We're good with a subset of the chains to start, if that can speed up the process. Please lmk, @jazg