In fact, any company that uses the DDK/WDK/LPL license would be sued if their driver worked on ReactOS.

So the real issue is to make sure we are clear that the drivers are designed to work on Windows -- not on ReactOS. It is ReactOS that is designed to run Windows drivers, not the other way around. Obviously, including such drivers in our:

1) Tree

2) Using our build system makefiles/hacks/resource files (all of which talk about "ReactOS").

3) Packaging them as part of the standard ISO/build image

4) And hacking them to work around ReactOS issues

All weakens the legal case.

I think it would be beneficial to have a project, call it "React Drivers" or something, which is a distinct tree/etc from the mainline. React Drivers aims to, let's call it, "enable compilation of DDK/WDK/LPL sample drivers under clang/msvc/cmake/mingw". It links with an .rc file that makes no mention of it being anything else other than an open source Windows driver. You could then make whatever changes you wanted to the sources, such as reformatting/etc to fix warnings/cross-compiler errors, etc, as long as it keeps working on Windows.

This would, I believe, survive under scrutiny as fair LPL use.

The flip side of this is that now the ReactOS tree no longer has an inbox fdc driver. Just like if you want to use USB in VirtualBox, you need to download the "Virtual Box Extensions", ReactOS would need a similar system. We already have the ability during 2nd stage boot to ask the user to download the Gecko package -- we should probably ask something similar of users to download the "React Driver Package". This would drop all the .INFs/etcs as needed -- in the same way, and with the same compatibility as a Windows user could choose to do.