Проблемы не только с gpl, скорее даже они особо с gpl не связаны.Дело в том, что при использовании KMS весь код связанный с переключением видео-режимов работает в режиме ядра, так что необходимо учитывать вопросы связанные с распределением памяти (просто s/malloc/kalloc не сработает), поддерживать новые API drm.ko и drm_fb_helper/drm_crtc_helper/drm_kms_helper, и оперативно реагировать на изменение API/ABI (что меняется довольно часто, увы). Ну и, конечно, поддерживать интеграцию с framebuffer на более низком уровне.
В случае UMS - тот код, что работал раньше, продолжит работать и при обновлении ядра, так как он от ядра не зависит (сервер/ddx обращаются напрямую к графической памяти), и можно использовать все плюшки которые есть в userspace. Но он сломается когда поменяется X server (что в ближайшем будущем и произойдет, когда патчи от airlied войдут в иксы).
Так что для перехода на KMS придется переписать бОльшую часть кода связанную с modesetting, подготовить ее для совместимости с ядром (через #ifdef'ы и тому подобные вещи, чтобы учитывать различные внутренности drm/kms api), и открыть бОльшую часть кода чем сейчас - как минимум для работы с i2c и sysfs - которые для KMS-based драйверов весьма даже нужны). Увы, в закрытых драйверах этого не будет.
В случае с BSD наблюдаются похожие проблемы, разве что кода открывать можно меньше. Но все что связано с modesetting'ом придется переписывать в любом случае. И я бы даже предположил что шансы получить KMS в *BSD в закрытых драйверах даже меньше чем под линуксом, так как детали работы видео-режимов в них сильнее отличаются...
