3 ms·

Not having third-party Snap servers is unfortunate, and something we probably should be forking Snap to add support for. Still, calling it "not freedom respecti

Not having third-party Snap servers is unfortunate, and something we probably should be forking Snap to add support for. Still, calling it "not freedom respecting" seems a little hyperbolic given that the actual part that runs on your computer is very much FOSS. It's not any different from, say, reading a website whose server software is unreleased, but whose client-side JS is all Free Software. As for sideloading... yes, I want it too. But the only thing that really gives me is the ability to run some emulation and virtualization tools Apple refuses to sign for reasons ranging from unfortunate to stupid. Epic Games did not sue Apple for my right to run old Nintendo games on my iPad. In fact, the videogame industry has been very explicit that users should not be allowed under any circumstances to format-shift games they own, and Epic has done nothing to indicate that they are less consumer-hostile than their peers. They also said they'd accept a two-tiered system where they got their Epic App Store but users still couldn't sideload. So, as much as Tim Sweeney is ideologically motivated to support user freedoms, Epic Games is still pushing their lawsuit from the perspective of a proprietary software vendor, just one that's willing to go rogue. You're right about RMS not being on the "same side" as Apple, and I misspoke. It's more like this is a three-sided fight between users (FSF, EFF, etc), proprietary developers (Epic), and platforms (Apple/Google). My point is that if you are extremely opposed to proprietary software in any form and for any reason whatsoever, then Apple's argument against sideloading is actually more reasonable, because it's the enemy eating itself. However, if you are at least slightly tolerant of proprietary software, then the argument Epic makes of Apple being anticompetitive makes a lot more sense. I'm still not convinced that Apple's end goal is to make the Mac just be an iPad with a mouse and keyboard. The whole owner override thing I mentioned above took a lot of time and effort, just so they could boil the secure boot frog less. It would have been far easier for them to just say "no, we're only allowing macOS to live in EL2". Nobody was expecting them to allow this, and Hector Martin still has to occasionally field questions of "why are you working on this when Apple is just going to block it" when they haven't for several years now. Furthermore, Apple's designer brainworms have insisted upon not converging their platforms in any way that would make having the same security policy make sense. >Aside from that, Mrs. Lincoln, how did you enjoy the play? There really isn't another way to implement this while providing the same security guarantees for Free operating systems. The part that actually checks to make sure the code you're running was owner-signed needs to be both immutable from the perspective of malware and updatable in case of security bugs. You don't want this burned into a ROM chip since it's extra attack surface, even though that technically satisfies some weird exception the FSF made decades ago for the proprietary ROM BIOS in IBM-compatibles. The only complaint I have about the way Apple did this is that they really should Free their boot chain code and have verifiable builds for it. However, there are very few, if any machines that actually have a Free boot chain. And the only harm a proprietary boot chain can do to Free Software is to refuse to load a Free OS. So as long as the boot chain allows us to do that, the crusade for a Free BIOS seems more of an academic or research concern than anything else. [0] You're supposed to be able to enroll new secure boot keys, but AFAIK this isn't really ever done.

josephcsible 5y ago
> It's not any different from, say, reading a website whose server software is unreleased, but whose client-side JS is all Free Software. I think that an important difference here is that there are FOSS Web servers that are compatible with your browser, but there's no FOSS servers compatible with your Snap client. > Epic Games is still pushing their lawsuit from the perspective of a proprietary software vendor, just one that's willing to go rogue. I agree that Epic is doing the right thing for the wrong reasons, but that doesn't make what they want wrong. > My point is that if you are extremely opposed to proprietary software in any form and for any reason whatsoever, then Apple's argument against sideloading is actually more reasonable, because it's the enemy eating itself. I still don't see how, since the ban on sideloading affects FOSS apps too. Remember the old issue with VLC in the App Store? > The whole owner override thing I mentioned above took a lot of time and effort, just so they could boil the secure boot frog less. It would have been far easier for them to just say "no, we're only allowing macOS to live in EL2". If they didn't do the owner override thing originally, then a lot of people might have jumped ship and forced them to backtrack. By taking the approach they did, they'll later say something like "look, our telemetry says 95% of Macs still have SIP enabled, so now we're going to make it mandatory". > The part that actually checks to make sure the code you're running was owner-signed needs to be both immutable from the perspective of malware and updatable in case of security bugs. > The only complaint I have about the way Apple did this is that they really should Free their boot chain code and have verifiable builds for it. But those requirements are fundamentally incompatible with freedom. I'd rather not have that sort of "security". And your complaint doesn't address the tivoization problem at all.
- kmeisthax 5y ago
  >Remember the old issue with VLC in the App Store? The issue with VLC in the App Store was that an older version of the App Store T&Cs had standard EULA language that said you weren't allowed to pirate the apps on the store; which contradicts every version of the GPL ever. VLC worked around this by relicensing their iOS port to MPLv2, whose copyleft is apparently weak enough that the App Store EULA does not conflict with it. I'm not entirely sure why. This, however, is a moot point. Apple fixed the problem by letting you just write custom EULA language specific to that app that says the GPL overrules the App Store EULA for that app. This is how iSH legally ships an entire x86 userland full of GPL software on the App Store, for example. Even things like the Installation Instructions requirement (either GPLv2 or v3's) is satisfied by the fact that Apple hands out free development accounts like candy and will likely continue to do so for as long as the App Store exists.

josephcsible 5y ago

> It's not any different from, say, reading a website whose server software is unreleased, but whose client-side JS is all Free Software. I think that an important difference here is that there are FOSS Web servers that are compatible with your browser, but there's no FOSS servers compatible with your Snap client. > Epic Games is still pushing their lawsuit from the perspective of a proprietary software vendor, just one that's willing to go rogue. I agree that Epic is doing the right thing for the wrong reasons, but that doesn't make what they want wrong. > My point is that if you are extremely opposed to proprietary software in any form and for any reason whatsoever, then Apple's argument against sideloading is actually more reasonable, because it's the enemy eating itself. I still don't see how, since the ban on sideloading affects FOSS apps too. Remember the old issue with VLC in the App Store? > The whole owner override thing I mentioned above took a lot of time and effort, just so they could boil the secure boot frog less. It would have been far easier for them to just say "no, we're only allowing macOS to live in EL2". If they didn't do the owner override thing originally, then a lot of people might have jumped ship and forced them to backtrack. By taking the approach they did, they'll later say something like "look, our telemetry says 95% of Macs still have SIP enabled, so now we're going to make it mandatory". > The part that actually checks to make sure the code you're running was owner-signed needs to be both immutable from the perspective of malware and updatable in case of security bugs. > The only complaint I have about the way Apple did this is that they really should Free their boot chain code and have verifiable builds for it. But those requirements are fundamentally incompatible with freedom. I'd rather not have that sort of "security". And your complaint doesn't address the tivoization problem at all.

kmeisthax 5y ago
>Remember the old issue with VLC in the App Store? The issue with VLC in the App Store was that an older version of the App Store T&Cs had standard EULA language that said you weren't allowed to pirate the apps on the store; which contradicts every version of the GPL ever. VLC worked around this by relicensing their iOS port to MPLv2, whose copyleft is apparently weak enough that the App Store EULA does not conflict with it. I'm not entirely sure why. This, however, is a moot point. Apple fixed the problem by letting you just write custom EULA language specific to that app that says the GPL overrules the App Store EULA for that app. This is how iSH legally ships an entire x86 userland full of GPL software on the App Store, for example. Even things like the Installation Instructions requirement (either GPLv2 or v3's) is satisfied by the fact that Apple hands out free development accounts like candy and will likely continue to do so for as long as the App Store exists.