A license covers copying and distribution. You can reject the FreeRTOS license and publish benchmarks. You will lose your ability to distribute FreeRTOS under their variant of the GPL.
They could alternatively add a clause that forces you to extract an agreement from anyone you distribute the source code to. That would require at least some sort of click through license agreement to be binding.
MUDs are the original MMOs. Zork but over the network.
D is a good fit for this because it simplifies my programming model. A MUD is typically heavy on scripting (or at least, it is if you want it to do anything interesting). These scripts need to be lightweight, since I might have one script instance for every player (to handle automated combat behaviors), several for each NPC, and even some rooms and items have scripts attached.
In order to simplify script writing, I want to be able to write my scripts in a simple, procedural way that lets me pretend that my current script is the only thing running. That means fibers. Not just fibers, but fibers that I have a fair bit of control over.
What languages have fibers? Not many. C/C++ have library support, but that means manual memory management and plenty more pain. Go's fibers are too opaque -- I want to have a watchdog that can ensure that every mob has an active behavior, for instance, and I want more control over scheduling. Mono used to have working continuations, but that was a long time ago, and they don't work anymore, as far as I can tell. Ruby and Python have fibers, but without static typing, I write code that is less reliable, containing more errors, that is harder to reason about.
I write. I want to create ebooks from what I write. Previously, my process was: write in LaTeX (primarily using a double handful of macros instead of using LaTeX builtins), use htlatex to produce HTML; use a script to inline CSS rules to work around a calibre problem; use calibre to generate the ebook. Four seconds total for a 75k word book, and it vomited a bunch of temporary files everywhere. I could do better -- primarily by doing less.
Initially the benefits for using D came from Pegged, an easy-to-use parser generator; that sped development enough to make me happy working on the tool. However, Pegged was relatively slow -- it dropped time by only about 20%. At first I thought it was my ebook generation code, so I changed it around to be more allocation-friendly and faster. This was trivially easy to do in D. But that had no effect on the execution time.
I looked into it a bit closer, and it turned out that the Pegged parser was taking almost all the execution time. So I shrugged my shoulders and wrote my own parser. It was shockingly easy.
One specific thing I wanted to do is figure out, when there's a parse error, which line and column it's on. Normally that means keeping track of line and column numbers during normal processing, which is quite annoying and gets in the way of everything you want to do. But it turned into about three lines of code in the end, without interfering with normal parsing. Similarly, it's usually a bit of annoyance to keep track of where you are in the input. D's array slicing again made it trivial -- I just maintained a slice of the input string representing the part I hadn't parsed yet. No off-by-one errors. No segfaults. No array bounds errors. It worked the first time.
Nothing I couldn't do in another language, but D puts it all at my fingertips.
That ebook that took multiple seconds with LaTeX? 0.04 seconds with Subtex. I had to double check to ensure that it actually ran the first time after I got my parser working.
My experience with D has been mostly positive, aside from missing libraries. But that's getting better with time.
They could alternatively add a clause that forces you to extract an agreement from anyone you distribute the source code to. That would require at least some sort of click through license agreement to be binding.