Well, they're kind of the same issue.
My opinion is, for a mudlib intended to be public domain...well,n I was going to write a mudlib. I came to the conclusion that just writing the mud in c++ would be best. I never did get further in that decision, mostly because college is taking up time. This wasn't because of licensing, it was because c++ is better documented, etc, and has a whole lot less overhead. This is where people start chiming in and saying "lpc is good enough", and yes, it is. But this was the conclusion I came to when I wanted to write a mudlib: there's a ton of undocumented stuff on that path, and you need to know about it all. I have nothing against lpmuds, that's just my thought on new mudlibs. [1] And, my project ideas tend to be things that would eat ram like candy, and probably the cpu, too.
That said, you should probably pick a driver first. What you're probably looking for is a driver that allows code to be public domain. I doubt you're going to find one that lets you distribute the driver with it, as that's basically declaring the driver public domain too, i.e. "Here's my public domain mudlib with driver bundle", and then people go off and start treating the driver like public domain too. That said, maybe none of them forbid it.
How much do you know about compiling? That's another big question here. Dgd compiles out of the box on windows and linux. For windows, you just get visual studio and open the project, and that's it. FluffOS will compile under cygwin, but it was a big deal for Cratylus to make the copy that comes with Dead Souls, which involved MinGW and stuff that I don't have full details on. Cygwin has licensing issues for redistributing the dlls, i.e. everyone who wants to run it, iirc, needs to install Cygwin. Ldmud may also build out of the box on windows; I am not sure about that one.
1: Dgd offers a whole lot of stuff that's hard to do elsewhere, including automated disk swapping and persistence. If you're going to use the features of dgd that make it dgd, then use dgd--I've not totally convinced myself that a mud shouldn't be written on top of dgd, because implementing full persistence and disk swapping is not really trivial. In dgd, if you let go of some of the standard mud idiomes, i.e. area resets in the usual way, you can have a mud that, from the perspective of the mud if not the user, never ever shuts down. You have to be smart to code that way, though, really, really smart (at least, in my opinion).