In the email you have linked to, he does not support tivoization. He simply says that he finds the term offensive (which is really funny coming from him).
Torvalds has also publicly stated that he doesn't think that tivoization benefits users, but it's not his battle to fight. More info on that topic can be found in the linked YT (linked at the precise time he is answering the question about tivoization, but the whole video is about GPL v2 vs GPL v3).
Because anti-tivoization doesn’t make sense in a software license.
Imagine you make a smart toaster, and you make it entirely out of open source software. You release all the changes you made too, complying fully with the spirit of open source. People could take your software, buy some parts and make their own OSS toasters, everything’s great.
But for safety reasons, since the software controls when the toaster pops, you decide to check at boot time that the software hasn’t been modified. You could take the engineering effort to split the software into parts so that only the “pop on this heat level” part is locked down, but maybe you’re lazy, so you just check the signature of the whole thing.
This would be a gpl3 tivoization violation even though the whole thing is open source. You did everything right on the software end, it just so happens that the hardware you made doesn’t support modifying the software. Why is that a violation of a software license?
This is what makes no sense to Linus, and TBH it makes no sense to me either. Would the toaster be a better product if you could change the software? Of course. But it seems to be an extreme overreach for the FSF to use their license (and that “or any later version” backdoor clause) to start pushing their views on the hardware world.
It makes sense in the context of GPL specifically when you remember that the GPL itself and the entire GNU stack and movement started from frustration with a printer, not a program.
> But it seems to be an extreme overreach for the FSF to use their license (and that “or any later version” backdoor clause) to start pushing their views on the hardware world.
Nothing is stopping the "hardware world" from developing their own operating system. But as long as they choose to come as guests to the FSF/GPL party, partake of the snacks and fill their glasses at the free-refills fountain, they're expected to abide by the rules. The doors not locked, they can leave any time.
No, actually anti-tivoization makes perfect sense, even in your example, and if you make this toaster then you are simply an evil anti-freedom company.
If you're afraid that modifying the software will make the toaster overheat, then include a hardware thermal fuse. You need to anyway, in case the manufacturer software fails or the processor fails.
> But for safety reasons, since the software controls when the toaster pops, you decide to check at boot time that the software hasn’t been modified.
As arguments go, this is a pretty weak one considering how obvious the solution is: Make the manufacturer not be liable for what happens when you operate the device with unauthorized software.
Manufacturers still may not go for it, due to the potential bad publicity. To go back to the toaster example, if some fancy open source software alternative has a critical issue and causes fires, the news will not report it with nuance. "SmartCo Toaster Fires on the Rise!" will be the headline, not "Niche Modding Community Sets Toasters On Fire, And The Manufacturer Had Nothing To Do With It".
Right, I'm saying I don't think codifying limitations on liability in law will be effective, because it probably wouldn't be absolute enough to satisfy the lawyers. You need a law that actually says "the user must be free to modify the device".
I have a toaster oven in my kitchen. It's a dumb thing with a bimetallic thermostatic switch, a simple mechanical timer (with a clockspring and a bell), and a switch to select different configurations of heating elements. The power-on indicator is a simple neon lamp. (It also certainly has some thermal fuses buried inside; hopefully, in the right places.)
And, you know, it works great. It's simple to operate and (so far!) has been completely reliable.
I can hack on it in any way that I want to. There's no aspect of it that seeks to prevent that kind of activity at all.
What would I hack it to do instead? Who knows, but I can think of a couple of things. Maybe instead of having some modes where the elements are in series, I want them in parallel instead so the combination operates at higher power. Maybe I want to bypass the thermostat with an SSR and use my own control logic so I can ramp the temperature on my own accord and finally achieve the holy grail of a perfect slice of toast, and make that a repeatable task.
Whatever it is, it won't stand in my way of doing it -- regardless of how potentially safe or unsafe that hack may be.
There are countless examples of similar toaster ovens in the world that anyone else can hack on if they're motivated to do so, and very similar 3-knob Black & Decker toaster ovens are still sold in stores today.
And yet despite the profoundly-accessible hackability of these potentially-dangerous cooking devices (they didn't even bother to weld the cover on or use pentalobular screws, much less utilize one-way cryptographic coding!), they seem fine. They're accepted in the marketplace and by safety testing facilities like Underwriters Laboratories, who seem satisfied with where the bar for safety is placed.
Why would a toaster oven (or indeed, just a pop-up toaster) that instead used electronic controls need the bar for safety to be placed at a different height?
> Why would a toaster oven (or indeed, just a pop-up toaster) that instead used electronic controls need the bar for safety to be placed at a different height?
It wouldn't. It's a thought experiment. I even said:
> Would the toaster be a better product if you could change the software? Of course.
The point is, nobody should be compelling you to make your products hackable. If you don't want to, that's your prerogative.
The problem is, before GPLv3 existed, the authors that picked GPLv2 never expressed that they wanted their software to be part of some anti-locked-bootloader manifesto... they picked it because GPLv2 represents a pretty straightforward "you can have the source so long as you keep it open for any changes you make" license. That's what the GPL was. But this whole "Or any future version" clause gave FSF carte blanche to just alter the deal and suddenly make it so anyone can fork a project and make it GPLv3. I can perfectly understand why this would make people (including Linus) very mad.
If an author wants, they can leave out the "or any future version" verbiage. If the author does not, then they are explicitly saying that they want their software to be part of whatever future manifesto the FSF puts forth, including the anti-locked-bootloader manifesto present in the GPLv3.
And that's why Torvalds left out "or any future version" when licensing Linux. So I'm not sure why he's "very mad" (I doubt he actually is?); his software remains on GPLv2 like he wanted.
> The point is, nobody should be compelling you to make your products hackable.
If you want to use my GPLv3 software on your product, then yes, I am requiring that you make it hackable. If you don't want to do that, tough shit. Either do so, or freeload off someone else's software.
You used the thought experiment as the foundation for the anti-anti-tivoization sentiment expressed. If the thought experiment is false, then the sentiment which might rest upon it is without basis.
> The point is, nobody should be compelling you to make your products hackable. If you don't want to, that's your prerogative.
I agree.
Nobody is compelled to use GPLv3 code in the appliances that they want locked-down for whatever reasons (whether good or bad) they may wish to do that. There's other routes (including writing it themselves).
They may see a sea of beautiful GPLv3 code and wish they could use it in any way they desire, like a child may walk into a candy store and wish to have all of it for free, but the world isn't like that.
We're all free to wish for whatever we want, but that doesn't mean that we're going to get it.
> But this whole "Or any future version" clause gave FSF carte blanche to just alter the deal and suddenly make it so anyone can fork a project and make it GPLv3.
This "Or any future version" part isn't part of the GPL -- of any version.
> Each version is given a distinguishing version number. If the Program
specifies a version number of the license which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
the license, you may choose any version ever published by the Free Software
Foundation.
The GPL itself does not in any way mandate licensing any code under future versions. An author can elect to allow it -- or not.
If they specify GPL 2, then they get GPL 2. Not 3. Not 4. Only 2.
Other versions of the GPL are ~the same in this way. (You know where to find them, right? They're easy reads.)
The law compelling you to make your products hackable is called "right to repair". Without this law, if my toaster breaks, my only option is to buy a new toaster. But if I'm allowed to change the toaster, I can fix the toaster.
Products have worked this way since forever. Only since modern microprocessors and cryptography have evil companies been able to deliberately add roadblocks that are impossible to overcome (without replacing so much hardware that you've made a new toaster from scratch) in order to maximize revenue. This is predatory and should be illegal. The only reason I can see that you'd support this, is it you work for a company that makes a lot of money selling new toasters to replace broken ones, and if this is true, your company deserves to be shut down by the government.
> But for safety reasons, since the software controls when the toaster pops, you decide to check at boot time that the software hasn’t been modified.
"For safety reasons" is every single claim. For safety reasons, I want to block the manufacturer's software from doing what it wants. Why do the manufacturer's safety reasons overrule my safety reasons?
> This would be a gpl3 tivoization violation even though the whole thing is open source.
Copyleft has nothing to do with open source. You haven't done everything right on the software end, because the GPL isn't about helping developers. To do things right on the software end, you should keep GPL software out of your locked down device that you are using to restrict the freedom of its users.
> Would the toaster be a better product if you could change the software? Of course.
You just said that it would be an unsafe product if you could change the software. Now you're using the "don't let the perfect be the enemy of the good" trope to pretend that you would of course support software freedom in an ideal, magical, childish, naïve dream world.
> it seems to be an extreme overreach for the FSF to use their license
People can license their software how they want. Is it an extreme overreach for Microsoft to not let you take their Windows code and do whatever they want with it? Why are you even thinking about GPL code when there's so much overreach coming from Adobe? They don't let you use their code under any circumstances!
All of your reasoning is motivated, and I would recommend that people not buy your toaster.
Hi. I don't know if you'll see this (I'm banned, so someone will have to upvote me if you have showdead off), but I would like to know what languages you personally like the most, or which ideas do you think a perfect language should have?
Incidentally, this is one reason why there's not so much open source hardware out there: people get pedantic about it and apply gradually more unreasonable levels of requirement, rather than accepting partially or substantially open source solutions.
I can be pedantically forgiving myself, admittedly, but this is one thing I'm staunchly behind. If I cannot read every character of every line of code, including packages/dependencies, that makes the hardware function and allows me to alter it as I see fit, then it is not truly open-sourced.
For me, the open-source movement is about keeping my software and hardware in alignment with my values and security concerns. If there is a part of that "open-sourced" software that is closed to me, I have no way to evaluate that and determine if I want to use it. Yes, this imposes some extremely strict limitations about what I end up with in my projects, but I'm okay with this since it forces me to think differently about certain problems.
I also don't mind that other people use product with closed-source portions or whatever, and in fact, find some of them quite good. I'm a wearer of an original Pebble to this day, and I'm fine with knowing some proprietary libraries are needed to make it go. I didn't build it, I'm not hacking on it, it's just serving my meager smartwatch needs in this instance.
What I do mind is misappropriation of what I consider a clearly defined term. I am not sure why we haven't come up with another term to mean "partially open-sourced" yet (or have we, and I am just not aware of it?) but I think it's time we did so more discerning users can delineate between the two when making a decision about products to purchase or build.
> These non-free software components are not required - you can compile and run Pebble watch software without them. This will always be the case.
This seems like a reasonable balance. They're shipping default distributions with these blobs included, but you can remove them and run the literally completely purely open source version directly instead if you prefer (although it sounds like you'd notably lose heart rate tracking, along with speech recognition & similar).
The reason why people get "pedantic" about this stuff, is due the ability in the future to get screwed over when the priority blob owner start to charge money or other pull other license crap
1. It's the other way around: because people don't care that much, that's why there is almost exclusively proprietary hardware around.
2. The people who require the "higher grades" of being open source are simply not a large enough market
3. Being open source is not a natural advantage of a product, in fact, it's more of a risk, liability, responsibility, and effort than being proprietary.
Read Reflections on Trusting Trust to understand why having little bits of binary blobs sprinkled all over your compute arch is actually a major problem. Just because it’s a hard problem doesn’t mean we’re gonna pretend it’s fine.
The general sentiment is that you cannot trust code you did not write yourself and that we need to be able to trust the person who did, but you can form your own conclusions about how that fits into the modern tech landscape.
One of the points made in that paper is that you can't even trust the compiler, even if you write the code yourself. I think this is one of the stronger points as it shows you it is unfeasible to require everybody to audit all source code before running it. Be pragmatic, know your threat model, decide who you trust and move on with more important things in your life.
FOSS enthusiasts are the worst customers imaginable. Not only are they pedantic to the absurd levels you mention, they are also political extremists and will start a witch hunt unless you and your entire company does exactly as they say in every matter imaginable.
And worst of all: They are incredibly cheap and don't want to spend any of their money on high quality products or services. Scream at every dollar they have to spend. "I'm better off with this hand-me-down computer that my sister gave me when her office job upgraded machines".
Trying to please FOSS people is like opening a five star budget restaurant for people with complicated allergies. You're going to deal with the worst of humanity and go broke in the process.
Given how easy is to put and keep hidden malware into devices, governments should demand openness in that field as well. By "putting malware" I don't mean script kiddies in their moms basement but malware/spyware planted by design, which is extremely easy to do if you're the manufacturer, extremely easy to demand/force if you're the government above that manufacturer, and extremely hard to detect if you're a different user in a different country under a government that didn't demand full openness. I know it's impossible as business rules go, but ideally it shouldn't be.
The thing is governments are the people doing it, and most governments want to be able to put backdoors in more badly than they want other governments to not put backdoors in.
Open silicon is a big leap beyond open hardware schematics and BOMs that allow people to repair boards, or redesign them to use alternative components.
Precursor is the most open personal computing device that can be built currently.
The comment I replied to was about being "fully open". That indeed goes beyond open hardware. Precursor could go further by at least using an FPGA that has great open source tooling support. It's also not impossible to fab an open FPGA but that's also another hard(and expensive) step.
Precursor goes far, but definitely not as far as currently possible.
The framework laptop , any hard drive ( meaning the hard drives , internal system software ) would not be open source.
the embedded software in a SSD , possibly, but the chips could have backdoors etc
> Above a certain complexity, there is basically no 100% open-source hardware out there.
>
> Like none of the Pinephone, Librem, Framework laptops are "open-source" to the bone.
As an aside, GNU Librephone aims to rectify that by reverse-engineering those blobs and develop their own firmware for baseband chips etc. But I am carefully optimistic about the success since it is a relatively new project and quite a moonshot, even though I would personally stand first in line to buy one if it would materialize.
Human speech is not mathematical formalism. What would even "open-source" mean in case of hardware, is there a consensus on it to begin with? Is it only 'every firmware is open-source and available', or would you want the whole floorplan of the chip?
So given that the word doesn't really apply to hardware, I believe they used it correctly (100% means the set of things where it makes sense to be used) and are not misleading. In fact I strongly dislike some of the "open-hardware" marketing of some previously mentioned devices, when that is obviously false and misleading.
I don't know, depends on a lot of stuff. If you are interested in this property from a security perspective, then no -- it's trivial to have hardware backdoors without any binary blobs.
This likely would also mean that it can't be flashed, so if you care about future maintainability, this is also a negative -- it can not be updated/fixed in the future, which may or may not make sense depending on what part we are talking about.
But if there are some kind of signature validation then it gets even more complicated (like e.g. iphone screens knowing if they are from apple or not).
> I don't know, depends on a lot of stuff. If you are interested in this property from a security perspective, then no -- it's trivial to have hardware backdoors without any binary blobs.
Well the Pebble specific parts are. This is an unfortunate state of affairs from hardware manufacturers, they are very late to the open source game, if at all.
Between the cross-licensing of hardware IP blocks and 3rd party software which never sees the light of the day, hardware manufacturers work like a secretive three letter agency to be able to control every part of their ecosystem.
I tend to understand where this comes from. It's part business, part continuation of old customs and the way they did it and being able to control obsolescence to be able push new things to the market.
However, if the periphery of the software you put out is closed source, even though this periphery is optional, it's not fair or ethical to say it's 100% open source.
From my perspective, it can be said it's open core, and it's pretty fair, and acceptable in my case, but writing 100% Open Source* (*: 100% of the open part of the software stack, exceptions apply) is not fair game. It's misleading.
Seems a bunch are angry about this, honestly, 100% of what they made/control is open source was a good enough bar for me. Specially if all closed components are optional. I value the flexibility of being able to use or not even closed stuff. It's unclear to me what the issue is, false advertisement ? This is as good as it gets for things like this, maybe the "100%" was indelicate, but I wouldn't go so far as misleading. I can also understand the hardware companies, history has shown that the vast majority of industry actors have a purely parasitical relation to open source, and have no qualms copying/stealing IP.
Personally, I'm not angry. On the contrary, I'm pretty neutral about closed-source, optional add-ons. I started playing/working with computers pretty early, and the current state is an utopia when compared to olden times in terms of Free and Open Source software (OTOH, both Free Software and Open Source is under heavy attack because of many reasons I won't enter here).
What bothers me is "100%" part of the open source claim. I personally like the Debian model a lot. It's DFSG compliant by default, and if non-free software is needed, it's attainable. Debian is "as Free as you want, as closed as you need".
I see, new Pebble follows the same model, and it's perfectly fine, but branding it as 100% Open Source is not.
I'll not discuss hardware companies. It's a can of worms that doesn't belong to that reply. Let's say while I understand some of their reservations, these reservation doesn't change that they're greedy and selfish (beyond acceptable limits).
Hardware isn't that hard to copy paste really, to make it hard you need to use really expensive processes (extreme uv etc), but otherwise, mostly you can pretty much take a picture. (very grossly speaking here, but just saying, the software is definitely a critical part)
>Another important note - some binary blobs and other non-free software components are used today in PebbleOS and the Pebble mobile app (ex: the heart rate sensor on PT2 , Memfault library, and others). Optional non-free web services, like Wispr-flow API speech recognizer, are also used. These non-free software components are not required - you can compile and run Pebble watch software without them. This will always be the case. More non-free software components may appear in our software in the future. The core Pebble watch software stack (everything you need to use your Pebble watch) will always be open source.
Debian doesn't advertise itself as 100% open source, either.
Main and Contrib has to obey DFSG guidelines, and there's an optional non-free repository which you can enable if you prefer.
Firmware is a gnarly can of worms though, and while I prefer 100% free firmware myself, companies are not brave enough to open that part of their ecosystem, yet, if ever.
Companies typically move more and more functionality to closed firmware, so they can ”open source” a thin wrapper, like a driver, that is often completely useless, and often encumbered with cryptography restrictions, strict trademarks and software patents anyway.
NVIDIA does exactly what you said. Move everything to firmware and closed GL libraries, and open source a kernel module to facilitate communication. They even created different firmware versions to prevent open source drivers to use the whole card.
AMD did the inverse: They re-implemented a fully open driver from scratch, opened up the specs, made every part which they can make (legally) accessible, accessible, open sourced ROCm and send in packages to major distributions' (main / open source) repositories. Their firmware is closed source, but it's obtainable and doesn't require signatures to enable the card. They even clashed with HDMI forums to make a libre implementation of v2.1, but the forum basically threatened them.
Intel's graphics drivers are basically the same with AMD.
Broadcom / Intel / Realtek NICs work without their respective firmware blobs, yet their offloading capabilities are disabled. Either way, the drivers are completely open source and in the kernel mainline.
Same for most sound cards sans Creative Labs. I want to hit them with a foam cluebat so bad.
Logitech's all stuff works with open drivers. They are the primary contributor to V4L standard, standardize their webcam interfaces and provide drivers or help.
> More non-free software components may appear in our software in the future.
That sounds ominous.
I can understand not being able to remove non-free dependencies that were used previously, but that sounds like they intend to create new non-free components.
Closed verilog I can accept. But in general firmware is also software, for example it has become quite popular in the recent years to execute firmware on an embedded riscv cpu. And move more and more functionality to that kind of firmware.
I can confirm that (several years ago at least) free PDF libraries were lacking, and Telerik was always non-free.
However, aren't Moq, Avalonia and MassTransit free software?
As for Automapper and MediatR, their owner changed from a free software license to only an open source one (Reciprocal Public License), but these are probably the simplest libraries of the ones you mentioned and have either been forked (MagicMapper) or have alternatives.
Yeah pdf libraries are a bit of a mess, I work with a product that handles lots of PDF documents and I think we just recently added another PDF library dependency (I'm certain it's at least 3 now, but could be 4 or even 5 libraries loaded at startup).
Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Avalonia itself is opensource, but i'd put in in a fremium/shareware category since if you need to add an WebView or Media player you need to buy their commercial Accelarate additions.
> Moq has the appearance of free software but bundled some spyware stuff (seemingly "benign" "Sponsorlink" for getting donations).
Well they pulled back but the trust was broken in a lot of cases. I am still fine with it 'for now' but IDK NSubstitute always feels weird to me, maybe that's just how I was taught to use it tho.
> Masstransit went commercial recently
I mean good for them but thankfully it's also giving attention to other projects that are FOSS or Open Core...
As far as the other stuff, I've never seen AutoMapper used in a way that couldn't literally be handled with a static/extension method in 'real' code. Yes it can be useful but it is often grossly overused.
MediatR is cool but TBH I'd rather just reach for Akka.NET or MessagePipe instead; If you're abstracting out to keep processing backend 'swappable' you should be able to handle any of the above for the choice you make anyway.
I created a Moq lookalike in an evening a few months back, it's not a hugely advanced project honestly (if you're used to working with the reflection system).
If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. You can help by flagging it or emailing us at hn@ycombinator.com.
This! There is no reason Apple should be able to dictate how their software and devices can be used just so they can exclude other companies from their ecosystem. This measure is a clear example of anti-competitive practices. Free market sometimes needs regulation to be kept free.
While I appreciate criticizing bloat (why are we packing Chromium in every app again?), I would like to warn against watching every "pound". Images, for example, "weigh" a lot more than code but that doesn't mean they don't serve a purpose and add value.
That being said, the fact that quick maths can give you a 6 orders of magnitude difference between functional code and the package is probably reason for concern.
