Incompatible license for dependency

[tdunning]

This is nice work. It's good to see an Apache licensed implementation of Raft.

In evaluating this code, however, I notice that you have this dependency:

github.com/hashicorp/memberlist

The memberlist code is under the MPL license which is incompatible with the Apache license if you use a source dependency due to being a "weak copyleft" license. You can find out more on the page that the Apache Software Foundation has created as a licensing guide for its own projects.

Good luck with your project!

[kevburnsjr]

Thank you for surfacing this potential licensing issue. What tool did you use to discover this?

---

One potential solution here to avoid implementing a new SWIM library to replace memberlist would be:

1. Move the GossipRegistry to a separate repository dragonboatgossip
2. Remove NodeHostConfig.DefaultNodeRegistryEnabled
3. Lift ExpertConfig.NodeRegistryFactory up to NodeHostConfig.RegistryFactory
4. Modify the documentation to recommend setting this to dragonboatgossip.NewDefaultRegistryFactory()

Given that dragonboat main is still in pre-release v4, now might be a good opportunity to introduce a breaking config change like this to clean up a licensing issue using the already pluggable registry interface. This improved licensing stance may even help drive adoption of dragonboat v4.

@lni What do you think? I'm willing to create a PR if you agree with the approach.

---

Presently, dragonboat requires either one or two dedicated ports depending on whether the default node registry is enabled. Moving gossip to a separate repository means that each repository would be responsible for a single port which makes sense to me as by importing dragonboatgossip, the user would be making a conscious choice to open and manage a second port.

[tdunning]

Thank you for surfacing this potential licensing issue. What tool did you use to discover this?

Glad to help!

The tool I used was (sadly) just basic eyeballs. I glanced at your go.mod file and the hashicorp dependency jumped out because they have had such a big history lately of relicensing to incompatible licenses. So then I verified their license and checked the Apache docs to make sure I was remembering correctly.

The good news is that I just looked and found that https://github.com/google/go-licenses seems to work pretty well. It was certainly able to produce a useful report for my own purposes. I would imagine that a normal workflow would be to produce the report (a csv) and scan for anything that isn't BSD, MIT or Apache and dig in to see if it is something you can live with.

[kevburnsjr]

Thanks. I just ran a go-licenses report against one of my other projects and found an Apache/MPL conflict there as well 😆

Cheers 🍻

[tdunning]

I wouldn't have known about it if you hadn't asked me directly about how to do it. I am starting to use it everywhere to be sure I understand what I have done.

It's great incentive to decrease the number of dependencies so that I don't have to ready as many licenses!

[lni]

Thanks for sharing the findings.

I now have a kademlia DHT implementation that seems to be pretty reliable. I might just replace the memberlist package with a DHT. To do that, I'd wait a little bit until some AI can write most of the glue code, so there is no ETA for that.