On 7/15/26 8:16 PM, Soren Stoutner wrote: > On Tuesday, July 14, 2026 8:23:50 AM Mountain Standard Time Bjørn Mork wrote: > >> Soren Stoutner >> [<[email protected]>](mailto:[email protected]) >> writes: >> >>> However, if there is some reason why a developer should never use the > > GPLv3, > >>> please put it forward. >> >> I don't think there are reasons for never <anything> :-) >> >> But if you want reasons why a developer should consider other licences >> in specific contexts, then the FSF lists a few good ones along with >> their recommendations: >> https://www.gnu.org/licenses/license-recommendations.html > > I see you included the exact same link I included in the part you snipped. > Needless to say, I find no problems with these recommendations. That is why I > mentioned the link myself. > >> And there are other reasons too: >> https://lkml.org/lkml/2007/6/13/289 > > If you would really like to make the Tivoization argument, I would recommend > you do so with your own words, and I would be happy to debate it with you. > Regarding Linus, he says: > > “Rms calls it "tivoization", but that's a word he has made up, and a term I > find offensive, so I don't choose to use it. It's offensive because *Tivo > never did anything wrong*, and the FSF even acknowledged that. The fact > that they do their hardware and have some DRM issues with the content > producers and thus want to protect the integrity of that hardware. > > “The kernel license covers the kernel. *It does not cover boot loaders and > hardware*, and as far as I'm concerned, people who make their own hardware > can design them any which way they want. Whether that means "booting only > a specific kernel" or "sharks with lasers", I don't care.” > > Notice above where I have highlighted how Linux came to this conclusion > because he doesn’t care if hardware is free (as in freedom). > >> We don't have to agree that any of those reasons are valid or anything. >> But I hope we can agree that the people behind those concerns can't be >> classified as "fundamentally disagreeing with the principles of the >> DFSG"? > > I think Tivo *did* do something wrong. Their use of DRM to prevent users from > installing new software on their hardware is fundamentally in conflict with > the principles of the DFSG. Specifically, it is in conflict with #3, derived > works, because Tivo was using DRM to prevent derived works from being > installed on the hardware.
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. Best Regards, Marek
