I have no idea, unfortunately. On the other hand, the trademark doesn't seem to be a problem to guys behind Racket, which has the most advanced contracts system

I have no idea, unfortunately. On the other hand, the trademark doesn't seem to be a problem to guys behind Racket, which has the most advanced contracts system out there; the canonical book for programming classes in Racket, "How to Design Programs", teaches you everything you need to know about DbC without ever mentioning the term itself, IIRC. Even if you don't want to touch Eiffel due to it being proprietary, there are many languages which support DbC you can choose from: already mentioned Racket, Ada, Clojure, Scala, D, Nim, Haxe, Elixir, and many more. Also, there's a difference between DbC and simply using contracts - it's similar to the difference between writing tests and doing TDD. Many people might not be convinced that the benefits of DbC are worth rethinking the development process, and so they dismiss all contracts as "too many asserts, don't need". But, like with tests, you can benefit from a solid test suite even if you don't do TDD; similarly, you can reap a lot of benefits from simply ensuring that precondition violations are caught at the boundary of a subroutine, because it makes it easier to find the reason beind the problem. I'm convinced that in the next 10-15 years we will see gradual typing (with type inference) embracing contracts as a way to extend the guarantees from compile time to runtime. Maybe we will finally get the best of all worlds: rapid prototyping, great performance, and verifiable program correctness.