* Paolo Bonzini: >> But if I change the run-time library, I still have to license those >> changes under the GPLv3 if I want to distribute them, right? > > Yes. But if you change the runtime library and link something else > with the modified runtime library, the "something else" does not fall > automatically under the GPLv3, even if you distribute them together.
Yes---but we've been told repeatedly over the years that you cannot link GPLv2 programs with libraries under a GPLv2-incompatible license and ship both on the same media, even if the library license is not copyleft-like and does not prevent this. (If this was possible, it would be rather trivial to work around the copyleft character of the GPLv2.) > The runtime library must be accompanied by the preferred form for > modification (source code), the "something else" can even be > distributed as a binary. It's not the run-time library license that's the problem here. It's the GPLv2-only program whose license appears to be infringed by linking against the run-time library and distributing the combined result. Keep in mind that for a GPLv2-only program, the GPLv3 is like a proprietary license (quite similar in effect to the Apache License 2.0, or the OpenSSL license, or the QPL, or the BSD license with the advertising clause). I wouldn't object if the FSF publicly declared that under their interpretation of the GPLv2, the system library exception in the GPLv2 allows us to link against libraries shipped in a separate Debian package, dynamically or statically. We likely have that permission under copyright anyway. It's just against everything the FSF has told us over the years, so I don't think it will happen. (Legally, a placet from the FSF doesn't buy as anything, of course, because individual copyright holders may not share the FSF interpretation. But it would be a signal nevertheless.)
