On 2021-02-03 at 23:13:10, brian m. carlson wrote: > On 2021-02-03 at 15:50:45, Ansgar wrote: > > Hi brian, > > > > On Wed, 2021-02-03 at 14:31 +0000, brian m. carlson wrote: > > [...] > > > Note the phrase "unless that component itself accompanies the > > > executable." It's long been my interpretation, as with other > > > contributors, that this applies to distribution from the same mirror > > > archive. In any event, it's obvious that it applies to the same > > > distribution medium, and Debian ships DVD and disk images from its > > > infrastructure. > > > > I'm curious what you think of GPL-2 software linking libraries that > > cannot be distributed under terms compatible with the GPL-2 such as > > GCC's runtime libraries? > > > > For example the following libraries are licensed under the GPL-3-or- > > later and their source code cannot be distributed under terms of the > > GPL-2 (part of gcc): libgcc, libatomic, libstdc++-v3, libobjc, > > libgfortran? > > > > If you think the system library exception should not apply to any > > library in Debian, would Debian need to stop linking any GPL-2 software > > against any of GCC's runtime libraries? > > Yes, Debian would indeed need to do so. It violates the license to > distribute, on the whole, a GPLv2 program linked against code which is > not compatible with the GPLv2, unless an exception applies (which it > does not here).
Actually, it appears that the GCC Runtime Library Exception appears to allow distribution under "terms of your choice", so I'd say that's not a problem. We can convey the result under the GPLv2 and so there's no problem. I think this is qualitatively different than OpenSSL, which has a deliberately incompatible license with respect to the GPLv2. -- brian m. carlson (he/him or they/them) Houston, Texas, US
signature.asc
Description: PGP signature
