On Wednesday, July 15, 2026 12:57:19 PM Mountain Standard Time Marek Benc wrote: > I think the fundamental disagreement here is about freedom zero, > the freedom to do anything you want with the code. In this case, > the freedom for a hardware manufacturer to use the code in a way > that is compliant with laws and contractual obligations > with regards to copy protection, and often laws with regards to > radio emissions and certifications. > > Under the GPLv2, the code is still free and available, and you're free > to audit it and create your own derived product based on the Tivo > set-top boxes. You can design your own board based around the same > SoC and load up your own, custom modified GPLv2 Tivo firmware on it, > and it's not even that difficult, we have tools like KiCAD > at our disposal to design such boards, services like JLCPCB and PCBWay > to get the boards manufactured at an affordable price, and then > you just need a steady hand with some tweezers and a soldering iron, > perhaps a heat gun too if you also want to use QFN / BGA components, > and bam, you're able to make use of all 4 of the fundamental freedoms > as defined by the FSF as well. > > Personally, I see nothing wrong with this. The Tivo products are meant > for end consumers, designed to be plugged in and used with a television, > along with certifications and a warranty that are needed for it to be > put onto the market. It is not designed to be tinkered with, but if > you do want to tinker with it, there are still ways to do it > while voiding the warranty through hardware modifications, or making > your own Tivo-derived box, and you have a lot of resources > at your disposal to do so. > > The GPLv3 extends its scope beyond software freedom to consumer > protection concerns. These are valid and important concerns, > but I think you can probably understand that in some cases, it makes > things impractical, and perfectly good code that could've been used > to make a piece of hardware more free and transparent can no longer > be used under certain circumstances. > > > Now the DFSG was written for sofware before the free hardware movement > > existed, and, as such, does not specifically mention hardware. That is why > > I > > very carefully said arguments against the GPLv3 was in conflict with the > > *principles* of the DFSG and not with the DFSG itself. However, if you > > extend the *principles* of the DFSG to hardware as well as software, I > > think it is completely accurate to say that anyone who thinks it is > > generally bad for a developer to license their software under the GPLv3 (as > > was stated by Ansgar earlier in this thread) fundamentally disagrees with > > the *principles* of the DFSG. > > > > Ultimately, there is no free software if all our hardware becomes completely > > locked down. > > And that's the key, this idea of "all our hardware becoming locked > down". I don't think we're nearly as helpless in this regard > as you might think, since there are very pragmatic reasons for things > like workstations and servers to allow users to boot custom code, > since by their very nature they're meant to be universal devices > for general-purpose computation. People and companies are willing > to pay good money to be able to use the software they want to use > on these general-purpose machines. > > As for devices which have to be locked down for contractual or legal > reasons, I still think it's huge win if we do have access > to the source code and can audit those devices, e.g. by making > a ROM dump and confirming that we're able to reproducibly create > the same ROM with the source code, to make sure it hadn't been > tampered with to insert spyware, but also to learn how it operates > and to create our own version if need be.
I understand all of the above and agree with part of it. I do disagree about how much danger we are in of general purpose computers becoming locked down at the hardware level. I think that movement is being driven by authoritarian regimes who want to control the hardware so they can control their citizens, and I think in the next few years we are going to see the power of law used to enforce hardware lockdowns. At that point, it won’t matter very much what our licenses say, because the law will preempt them. But more directly to this discussion, nothing you have written comes down to: Don’t license your code under the GPLv3. That was the original sentiment I was objecting to. Like I said earlier, I don’t have any objection to any developer choosing to use any DFSG license. What I object to is people making blanket statements that the GPLv3 is bad and developers should avoid it. There are a number of people inside of Debian who hate the GPLv3, but I think they are a very small number of people. There are a much larger number of people outside of Debian who hate the GPLv3. They hate it because it doesn’t just allow people to use the freedoms of the DFSG, but it *enforces* those freedoms in derivatives. These people generally feel that they can make more money by constraining user freedoms rather than encouraging them. And they are right. Generally, you can make reasonable amounts of money while granting all your users all the freedoms in the DFSG. But if you want to make truly obscene amounts of money, you need to somehow lock your users in. Nobody gives obscene amounts of money to a company if they have the option of fully exercising all of the freedoms described in the DFSG. That is the core difference between the GPLv2 and the GPLv3. When the GPLv2 came out, nobody had ever used hardware and DRM to lock down software. Now, that is fairly common. The GPLv3 was updated to address that. If the DFSG were written today, I can’t imagine any scenario in which it would not specifically address that as well. -- Soren Stoutner [email protected]
signature.asc
Description: This is a digitally signed message part.
