Except the freedom of the people who bought a TiVo and want to modify Linux on it.
> Ubuntu went through an analysis and basic result was that this is a lie, lots of things may force secure boot key disclosures, so they avoided that by avoiding GPLv3.
Can you link to a source for this?
This is an old fight. The GPLv3 came out to allow developers who wanted anti-tivosation to get it. Practically it's really dead.
Sure on Ubuntu
Ubuntu Can't Trust FSF's Secure Boot Solution
https://linux.slashdot.org/story/12/07/06/1525240/ubuntu-can...
I followed this reasonably closely, and it was a total lie on FSF's part - Ubuntu looked at it and agreed. Sadly for those of us running Linux they had to adopt MICROSOFT's UEFI secure boot. Ugh.
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.
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-u...
[2] https://github.com/gcc-mirror/gcc/blob/6599da043e22e96ac830f...
Companies use and modify his code, building their businesses on them, and then are not distributing their changes back. Arguably the whole cloud revolution has been built on this. Better make a SaaS and freeload on other people's work than make client side software and be forced to share your work (and technical advantage)
Linus likely believes in the benefits of collaborative development, and that the GPLv2 creates a legal framework to allow for that development.
However he also likely cares more about the software aspects (getting contributions to make better kernel versions and have them be widely used) than the more philosophical aspects of software freedom.
The philosophy on binary drivers for example is one where the Linux kernel does not guarantee a stable binary interface - it isn't that you can't legally distribute a binary driver (with caveats), but he has stated he would like those developers to occasionally "wake up in a cold sweat" over their linux binary drivers breaking on minor releases.
Additionally - because of the velocity of the linux kernel, maintaining a substantial vendor fork is not simple. This creates an atmosphere where maintaining functionality outside the mainline kernel could be a technical/financial burden that justifies any IPR release needed for a L-K contribution.
The number of contributions also means that such forks are likely not a significant fractional contribution compared to the contributions which people are willing to make in the open. The success of the project no longer depends on enforcement of the publication clauses.
Finally, clauses in the GPLv3 and AGPLv3 do influence and even force technology choices. The community likely does not want to lose contributions by pushing people to other kernels, and the commercial interests contributing to Linux would have to account for lost customers.
AGPLv3 is often chosen by commercial entities to force distinct commercial licensing of a published-source code base, rather than an effort to protect a community of contributors. As none of the commercial interests in Linux have exclusive copyright assignment to do a non-AGPLv3 license, there is significantly less commercial benefit for them to support such a move.
[0] https://www.zdnet.com/article/linus-torvaldss-love-hate-rela...
[1] https://www.cio.com/article/3112582/linus-torvalds-says-gpl-...
[2] https://www.youtube.com/watch?v=PaKIZ7gJlRU
[3] https://www.zdnet.com/article/torvalds-battle-with-gplv3/
https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...
That's mistaken.
If you write Linux kernel code and release it, the GPLv2 obligates you to release your source. That is to say, you do not have the option of releasing only the binary. [0] You have the option of never releasing your work, and you can for instance run a cloud service powered by your modified Linux kernel without having to release your code. [0] (This is how the GPL licences differ from the AGPL licences. [1])
The Linux kernel has benefited enormously from this obligation to share. Torvalds certainly thinks so: [2]
> I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back
It's true that you aren't obligated to contact the Linux kernel maintainers and suggest they merge your changes, but I don't see that this would be desirable. As you say, such a requirement would be problematic.
[0] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htm...
[1] https://www.gnu.org/licenses/gpl-faq.html#UnreleasedModsAGPL
[2] https://www.zdnet.com/article/linus-torvaldss-love-hate-rela...
You're emphasising the distinction between making GPL'ed source-code available to your customers specifically, and making it available publicly online. In practice there is little difference. Few companies bother hoping no customer will post the source publicly (which the customers are permitted to do under the GPL).
In practical terms the decision is between not releasing, or releasing to the public including the source-code. In a world where the Internet didn't make distribution of software trivially easy, things might be different.
Of course, there are some notable exceptions, the most prominent being nVidia's probably-non-compliant proprietary graphics driver. A fair bit has been written about that.
> Therefore the sharing back that does happen is down to culture not to the license.
No, Torvalds has it right.
Proprietary freeware kernel modules are forbidden outright, as you are not permitted to publicly release the binary without also releasing the source. As I described, 'contained' distribution of source-code isn't a practical option.
The decision of what to merge into the mainline kernel is of course up to the kernel developers. There's no other way it could be.
Are they serious??
Many OSS developers always want to get a copy of the software and mods back, but are OK if others USE that software in diverse ways, including making locked down hardware that is rented, radios that are power limited and more. In this way the GPL preserves everyone's freedom to do what they want with the software. The GPLv2 has served a wide range of needs, from Linus and Linux to plenty of industry efforts.
Linus was asked about this in a talk and he said he a)gets value in terms of forcing vendors to release code even from players like Tivo and b) is not interested in setting lots of additional restrictions on how folks use the code.
The FSF / Conservancy keep on re-assuring folks that encryption keys don't have to be released. Ubuntu went through an analysis and basic result was that this is a lie, lots of things may force secure boot key disclosures, so they avoided that by avoiding GPLv3.
Can we just leave GPLv2 as it has been. If the FSF or whomever wants another bite at the GPLv3 apple create a GPLv4 and let folks adopt it if they want.