3 ms·

My understanding is that they basically got FSF to provide them a statement that regardless of what GPLv3 might be read to require, the FSF indicates it could n

My understanding is that they basically got FSF to provide them a statement that regardless of what GPLv3 might be read to require, the FSF indicates it could not be used to force key disclosure in the Ubuntu situation. This worked, because FSF ALSO owned the copyright to Grub2 - so was allowed to modify (if needed) the copyright license or give up rights. So by having FSF as copyright owner provide them this statement - I think they (reasonably) felt covered in case FSF later changed their mind. The FSF I think also had to do this with GCC - didn't they do a runtime license exception or something because there were lots of concerns about using GCC when license moved up (CLang benefited at the time). I think FSF realized it was just a terrible look if the GPLv3 drove a group like Ubuntu onto a microsoft solution. Illustrates a bit how tricky / scary the (relatively long) GPLv3 can be.

comex 5y ago
> This worked, because FSF ALSO owned the copyright to Grub2 - so was allowed to modify (if needed) the copyright license or give up rights. Oh? Ubuntu's blog post at the time [1] doesn't characterize the discussion as involving a license exemption. Are you saying this happened behind the scenes? > The FSF I think also had to do this with GCC - didn't they do a runtime license exception or something because there were lots of concerns about using GCC when license moved up (CLang benefited at the time). The existence of a runtime exception, itself, dates to least 1997 [2], probably earlier. The original idea was to allow using GCC to compile proprietary software, even if the compilation process caused runtime bits to be statically linked into the output executable, which would otherwise force it to be GPLed. Along with GCC's switch to GPLv3 around 2009, the runtime exception was updated to try to leverage it as a workaround to an unrelated problem: the possibility that someone would incorporate proprietary bits into GCC. Doing that the normal way, by modifying GCC and not releasing the source code to the modifications, would just be a GPL violation. But people observed that someone could hypothetically work around the license as follows: write a proprietary optimizer or code generator as a separate executable, then modify GCC to dump its intermediate representation to disk (this modification itself would be distributed under the GPL), and write a wrapper that combines GCC and the proprietary executable into one Frankenstein compilation process. To prevent this, the runtime exception gained an exception of its own, that it would not apply to a program compiled using such a process, so that the franken-compiler would be hobbled by having all of its output licensed under the GPL. As far as I know, the runtime exception change itself never really caused any drama, because there were never any major compilers that attempted the "dump to disk" workaround (although some obscure examples allegedly existed prior to the license change [3]). However, GCC also had a longstanding policy of trying to discourage GPL workarounds by technical means: by (a) forbidding functionality that would dump an intermediate representation to disk and (b) intentionally making it difficult to combine GCC with other code. In particular, the updated runtime exception was a prerequisite for GCC adding support for plugins [4], and even once plugin support was added, it wasn't very nice to use compared to LLVM/Clang (and still isn't). LLVM was designed from the start to be used as a library. Its clean-slate design would have already given it a leg up on GCC for that use case, but GCC's active reluctance to be used that way was the nail in the coffin. Anyway, that situation has nothing to do with people being scared of the GPL – if anything the opposite, Richard Stallman being worried that the GPL was not scary enough. On the other hand, LLVM and Clang being developed at Apple into a production-quality compiler was a direct result of Apple being scared of the GPLv3, but that's a different issue and not related to the runtime exception. [1] https://ubuntu.com/blog/quetzal-is-taking-flight-update-on-ubuntu-secure-boot-plans https://ubuntu.com/blog/quetzal-is-taking-flight-update-on-u... [2] https://github.com/gcc-mirror/gcc/blob/6599da043e22e96ac830fb50a61c1b6d95d1b142/libiberty/clock.c#L19 https://github.com/gcc-mirror/gcc/blob/6599da043e22e96ac830f... [3] https://www.fsf.org/news/2009-01-gcc-exception https://www.fsf.org/news/2009-01-gcc-exception [4] https://gcc.gnu.org/wiki/GCC_Plugins https://gcc.gnu.org/wiki/GCC_Plugins
- the_why_of_y 5y ago
  Historical franken-compiler example: https://en.wikipedia.org/wiki/Solaris_Studio#GCCFSS https://en.wikipedia.org/wiki/Solaris_Studio#GCCFSS

comex 5y ago

> This worked, because FSF ALSO owned the copyright to Grub2 - so was allowed to modify (if needed) the copyright license or give up rights. Oh? Ubuntu's blog post at the time [1] doesn't characterize the discussion as involving a license exemption. Are you saying this happened behind the scenes? > The FSF I think also had to do this with GCC - didn't they do a runtime license exception or something because there were lots of concerns about using GCC when license moved up (CLang benefited at the time). The existence of a runtime exception, itself, dates to least 1997 [2], probably earlier. The original idea was to allow using GCC to compile proprietary software, even if the compilation process caused runtime bits to be statically linked into the output executable, which would otherwise force it to be GPLed. Along with GCC's switch to GPLv3 around 2009, the runtime exception was updated to try to leverage it as a workaround to an unrelated problem: the possibility that someone would incorporate proprietary bits into GCC. Doing that the normal way, by modifying GCC and not releasing the source code to the modifications, would just be a GPL violation. But people observed that someone could hypothetically work around the license as follows: write a proprietary optimizer or code generator as a separate executable, then modify GCC to dump its intermediate representation to disk (this modification itself would be distributed under the GPL), and write a wrapper that combines GCC and the proprietary executable into one Frankenstein compilation process. To prevent this, the runtime exception gained an exception of its own, that it would not apply to a program compiled using such a process, so that the franken-compiler would be hobbled by having all of its output licensed under the GPL. As far as I know, the runtime exception change itself never really caused any drama, because there were never any major compilers that attempted the "dump to disk" workaround (although some obscure examples allegedly existed prior to the license change [3]). However, GCC also had a longstanding policy of trying to discourage GPL workarounds by technical means: by (a) forbidding functionality that would dump an intermediate representation to disk and (b) intentionally making it difficult to combine GCC with other code. In particular, the updated runtime exception was a prerequisite for GCC adding support for plugins [4], and even once plugin support was added, it wasn't very nice to use compared to LLVM/Clang (and still isn't). LLVM was designed from the start to be used as a library. Its clean-slate design would have already given it a leg up on GCC for that use case, but GCC's active reluctance to be used that way was the nail in the coffin. Anyway, that situation has nothing to do with people being scared of the GPL – if anything the opposite, Richard Stallman being worried that the GPL was not scary enough. On the other hand, LLVM and Clang being developed at Apple into a production-quality compiler was a direct result of Apple being scared of the GPLv3, but that's a different issue and not related to the runtime exception. [1] https://ubuntu.com/blog/quetzal-is-taking-flight-update-on-ubuntu-secure-boot-plans https://ubuntu.com/blog/quetzal-is-taking-flight-update-on-u... [2] https://github.com/gcc-mirror/gcc/blob/6599da043e22e96ac830fb50a61c1b6d95d1b142/libiberty/clock.c#L19 https://github.com/gcc-mirror/gcc/blob/6599da043e22e96ac830f... [3] https://www.fsf.org/news/2009-01-gcc-exception https://www.fsf.org/news/2009-01-gcc-exception [4] https://gcc.gnu.org/wiki/GCC_Plugins https://gcc.gnu.org/wiki/GCC_Plugins

the_why_of_y 5y ago
Historical franken-compiler example: https://en.wikipedia.org/wiki/Solaris_Studio#GCCFSS https://en.wikipedia.org/wiki/Solaris_Studio#GCCFSS