License file for Windows API DLL files

Question

My friend is currently in preparation of distributing his software and wants to cleanup on the licenses of software he uses. The strategy is that he collects all the files that provides the licensing text.

He finished collecting all the "obvious" licenses, such as the Qt license of the Qt libraries he uses. However he also uses some of the Windows DLLs that come with Windows, such as kernel32.dll and advapi32.dll.

Where can he find the license files so that he can publish it with his software? The first DLL file, kernel32 appears to be automatically linked to his software based on an http://en.wikipedia.org/wiki/Auto-linking directive. The second file, advapi32.dll is linked explicitly to his software, and he wants to cleanup the situation of that file by collecting the file that provides the license.

For debian linux for example, he knows that the files are below /usr/share/doc/<package of the library>/copyright.

Answer 1

You may not redistribute Windows system DLLs. This includes kernel32, ntdll, advapi32, and a couple of others. The exact list is not fixed but basically, it includes almost anything in the system32 directory. (This list may be a good start.) These files are considered to be part of Windows and thus covered by Windows EULA.

What you may redistribute depends on your compiler and/or any third-party (non included in Windows) libraries you're using. For Microsoft Visual C++, see redist.txt in the installation directory. It usually has a text similar to following:

Visual C++ Runtime files

Subject to the license terms for the software, you may redistribute the .EXE files (unmodified) listed below. 
These files can be run as prerequisites during installation.

vcredist_x86.exe
vcredist_x64.exe 
vcredist_IA64.exe

Subject to the license terms for the software, you may redistribute MSM files listed below unmodified as a part of your installation package:

[...]

See here on the specifics of redistributing MS C runtime.

For other compilers/libraries you will need to consult their documentation.

Answer 2

Not an option, distributing those Windows components cannot work. Different Windows versions have very different implementations of these DLLs. Even computers with the same version may have different DLL versions, these runtime components are often updated by Windows Update. Forcibly overwriting them would be normally disastrous, but the File System Protection feature in Windows recovers the damage.

There simply is no need to distribute these DLLs. Every Windows machine already has them, along with a solid promise from Microsoft that they will be compatible with the program as long as the programmer set the _WIN32_WINNT macro correctly in his code. Which selects the minimum Windows version that he chooses to support, it prevents accidentally taking a dependency on winapi functions that are only available in later versions. Getting that wrong simply prevents the program from starting.

Answer 3

Since you mentioned GPL in the comments, you need to know that GPL has special language concerning system libraries.

The GPL FAQ says

Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

Naturally you should rely on the actual legal language of the license, not the FAQ. Hopefully any infectious non-GPL licenses take a similar approach.

The license that applies to Windows system DLLs is the end-user license for the desktop or server OS that they came with. There are many variations on these, such as volume licenses or development subscription licenses. So your friend needs to just chalk those up as "system library, non-distributable, source not distributable, governed by OS license".

Contrary to Alex's assertion in the comments, the Windows license does (or at least attempts to) govern use in addition to redistribution. Running the application in, for example WINE, where there may not be a valid license for certain required system libraries would present a problem, even if the system libraries were placed onto the hard drive during installation/patching of a licensed copy of Windows. I am not a lawyer, but I'm pretty sure that problem falls on the administrator of the WINE environment who caused those DLLs to be loaded, not the third-party application developer.