Does GPL code linking with proprietary library depend which is created first?

Question

Microsoft creates their windows and MFC DLL library, etc. An open source develop write a new MFC application and release the source code as GPL. The app has to link with the MS DLL/libraries to run in Windows, but I don't think anyone can argue that we now have the right to force the Microsoft's GPL their DLL.

Does this mean the GPL license is really depends on which one is "created" first? If proprietary library is created first (such as Windows DLLs) that is published without linking and any GPL code and later a GPL program is linked with it, then the GPL program can't convert the proprietary library into GPL although the proprietary code is "linked" with the GPL code.

If this is the case, can company such NVidia or RealNetworks do the following? Let's assume they like to keep the proprietary HDDecoding media decoding engine library private, but they also want to "leverage" the opensource GPLed code to showcase their hardware.

1. They create a proprietary library to do media decoding and release some sample code.
2. Someone (opensource development) creates "plugin" that is linked into this proprietary library for GPLed code such as XBMC, Mplayer or VLC.
3. Can they argue that since they created the proprietary library first (just like MS create all the DLLs first), GPL programs that link with their proprietary code do not covert them into GPL code.

One can in theory argue that the opensource developer who creates the GPL vlc.exe file that link with the NVidia proprietary media decoder library is violating the GPL license.

Does that mean all the GPL programs running in Windows such as VLC, git, cygwin, etc are all violating the GPL license because they definitely need to link with the proprietary Microsoft Windows Libraries to run.

Case 2: What's wrong with this:

NVidia can create a new Hardware abstraction library that hides the latest graphics functions. They also create a FreeBSD driver with this library and release the source code of the BSD driver but not the library source code.

Someone (Linux developer) can implement the linux driver that links with this library to create a NVidia graphics driver for Linux. But since NVidia didn't do this, they can keep the library source "hidden" while enable the "Linux support".

It certainly violates the spirit of GPL.

Does it mean that running any exe created with GPLed source in Windows/Mac/Iphone/PSP3 also violates the spirit of GPL?

Answer 1

From the GNU GPL FAQ:

Can I apply the GPL when writing a plug-in for a non-free program?

If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program.

See also the question I am writing free software that uses a non-free library.

And:

What legal issues come up if I use GPL-incompatible libraries with GPL software?

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.

The criteria for what counts as a "system library" vary between different versions of the GPL. GPLv3 explicitly defines "System Libraries" in section 1, to exclude it from the definition of "Corresponding Source." GPLv2 says the following, near the end of section 3:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

...

Answer 2

IANAL, but the order of creation doesn't matter. If the linking two binaries would be a violation of the GPL, then it is not allowed by the GPL, regardless of which was created first.

Case 1 is addressed by the system library exception, as Michael Burr quoted. Note that it is not time-dependent - if it were not for the system library exception, it would be just as much of a GPL violation to run GPLed code written in 2003 on Windows 98 (which was written before the GPLed code) as it would be to run it on Vista (which was written after the GPLed code).

I agree that case 2 violates the spirit of the GPL, but, as the term is used by the GPL, that NVidia driver is not "linked" with the Linux kernel because it is loaded as a module. You wouldn't be able to distribute a Linux kernel with the non-Free NVidia binary statically linked into it, but who distributes statically-linked kernels these days anyhow?

Answer 3

You have a fundamental misunderstanding of the way in which the GPL restrictions enter force. Your first example is covered by the "system library exemption" - but even if it wasn't, it wouldn't have the effect you posit.

The GPL says that if you distribute the GPL'd program, or a derivative thereof, you have to also provide the source to the program or derivative under GPL-equivalent terms (to the people you distributed the program / derivative to).

This means that if I distribute your GPL program linked with some of Microsoft's code, I have to provide the source to the whole ball of wax, or risk being sued by you for breaking your copyright. Note that as long as Microsoft is a third party, this doesn't put any restrictions on them (of course!). If I don't have access to Microsoft's code, which is likely, then I can't distribute that derivative work without being in violation of your license.

Answer 4

You cannnot change other programs licences by linking to them, never. If your licence does not allow linking to non-open source programs you must either change your licence or stop linking to those programs. The situation would be different if the other programs linked to yours. In that case they must cahnge their licence or stop linking to your program.

Answer 5

What it means, simply, is that you can not apply the GPL on top of code or libraries that are not compatible with the GPL and distribute a compiled combined work, unless you apply a linking exception.

The linking exception provides a way for you to distribute compiled executables containing the non-free bits, while no special permission is needed to distribute the program in source format.

This exception, of course, depends on the non-free libraries allowing you to distribute programs that are linked against it (especially statically).

So, to answer your first question, no .. this is not a 'chicken or egg' scenario. What I recommend is when confronted with the possibility of having to write an exception, its probably better to just choose a license with fewer restrictions, like the Apache or 3 clause BSD license.

Secondly, no, you can't just apply the GPL to your code for the purposes of changing the license for something that you happen to link against. Again, we come back to the linking exception, which is your responsibility to provide.

The spririt of the GPL lives in a world where there is no such thing as proprietary software. RMS has stated this as the eventual goal on many occasions. What remains are practicalities that must be addressed for people who want to distribute free software on non-free platforms.

This is one of the biggest reasons that Linux (as in the Kernel) remains GPL v2 only.