The problem is similar with the FreeBSD code (at least it solves the licencing problem I think).
The main problem is this is a lot of code and is tightly coupled with many parts of the OS (memory allocation, device drivers, etc). Thus, the compatibility layer may be large and require invasive changes. I don't know how much of FreeBSD code is also using their own compatibility layer with Linux, and how much of it they wrote themselves. During the project the DragonflyBSD code was also investigated, as this one seemed to be more free of Linux code.
However, note that the drivers are not the complex part in this stack. The point of DRM is to move as much of the complexity as possible in Mesa/Gallium3D, and outside the kernel. The drivers are then reduced to low-level primitives which are reasonable to implement ourselves. Also note how this is similar to the architecture BeOS and Haiku are already using, with the driver/accelerant separation for our graphic drivers. So the way I see it, we could just extend the driver<->accelerant interface to provide some DRM functionality, and then plug Mesa/Gallium on top of that. There is still some low level work in the drivers to do (queueing commands to the card, etc), but it does look more reasonable than trying to port a complete driver from Linux or FreeBSD kernel to me (looking at their drivers and using a similar structure, but using our own kernel facilities is a way to achieve this).
@cosmogatokat: I think there was a lot of hype around the project, but clearly, if getting 3D accel to work was just 3 month worth of work, it would have been completed a long time ago already. The goal of the project was just to lay the bases for it.