6 ms·

GPL3 closes what was considered a loophole, where device makers would ship a product derived from GPL’d code, and release the source, but provide no ability for

GPL3 closes what was considered a loophole, where device makers would ship a product derived from GPL’d code, and release the source, but provide no ability for users to actually compile and run that source on the device (this was called “tivo-ization” at the time, because TiVo did it.) So for iOS, it’s pretty obvious why they don’t use gplv3… because it would violate the terms. For macOS they could certainly get away with shipping gplv3 code, but they do a lot of code sharing between iOS and macOS (and watchOS/tvOS/visionOS/etc) and it doesn’t make much sense to build on a gplv3 foundation for just one of these operating systems and not the others. So it’s simpler to just not use it at all. It also means they’re more free to lock down macOS from running your own code on it in the future, without worrying about having to rip out all the gpl3 code when it happens. Better to just not build on it in the first place.

KerrAvon 2y ago
No, this doesn't quite scan, because there's no reason they couldn't ship a current of `bash` or any number of other GPL3 things. Aurornis is probably closest to the mark: it is legally ambiguous, and Apple probably does not want to be a test case for GPL3 compliance.
- ninkendo 2y ago
  If they shipped a gpl3 version of bash on iOS, they would be in violation. This isn’t really a question: gpl3 requires you to not only provide the source if you use it in a product, but the ability to modify it and run your modified version. Which iOS doesn’t let you do. Now, macOS would be fine in shipping a gpl3 bash. But not iOS. (Yes, iOS has bash. Or ar least they used to, they may be all on zsh now, I’m not sure.) So, the question becomes to Apple, do we ship different bash versions for different devices, and treat macOS as being different, and have to worry about only using newer bash features on macOS? Or do we keep the same old version on all platforms, and just eschew the new bash everywhere? It’s a pretty simple decision IMO, especially because users can just use brew on macOS and put their own bash on there if they want. Others are pointing out that gpl3 is less tested in court and that lawyers are just more uncertain/afraid of gpl3 than gpl2, especially with respect to patents… but I don’t think these are mutually exclusive. It’s clear that they can’t ship gpl3 on 4 out of their 5 operating systems. macOS is an outlier, and from an engineering standpoint it’s a lot simpler to just keep them all the same than it is to ship different scripts/etc for different platforms. It can be both reasons.
jitl 2y ago
> It also means they’re more free to lock down macOS from running your own code on it in the future, without worrying about having to rip out all the gpl3 code when it happens. Better to just not build on it in the first place. how does locking down macOS have anything to do w/ GPL compliance? Apple is free to do whatever BS with the OS they ship in terms of terminal access, user permission level, etc regardless of GPL of any code on the device. I could ship a GPLv3 system tomorrow that disallows user root access and as long as I make the OS source freely available and redistributable, it's fine.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- ninkendo 2y ago
  If you make a device which uses GPL’d code, and provide all the covered source code you used, but prevent users from putting any modified code on the device, you are in violation of GPLv3, but not GPLv2. That means this sentence: > I could ship a GPLv3 system tomorrow that disallows user root access and as long as I make the OS source freely available and redistributable, it's fine. Is not true for gpl3. It’s called the “tivo-ization” loophole, and it’s one of the principal reasons the GPL3 was made in the first place. I think you’re just wrong. (Note: I’m not claiming Apple is would be in violation for shipping e.g. a GPLv3 bash on macOS, today, only that they would be in violation for doing that on iOS today, or if in the future they locked down macOS in the same way that iOS was, then for macOS too.)
  - pabs3 2y ago
    Correction, that is a GPLv2 violation too. Some discussion: https://lwn.net/Articles/858905/ https://lwn.net/Articles/858905/
- NewsaHackO 2y ago
  [flagged]
duskwuff 2y ago
Current versions of macOS use a signed system volume [1], much like iOS - under a standard system configuration, the user can't replace system executables or other files, even as root. Unlike iOS, the user can disable SSV, but I'm not certain that's sufficient for GPLv3 - and I can't imagine Apple feels comfortable with that ambiguity. [1]: https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web https://support.apple.com/guide/security/signed-system-volum...
- chongli 2y ago
  Sure, though there's little point in replacing executables such as rsync when you can install your own version (perhaps through a package manager and package repository / database such as Homebrew [1] or MacPorts [2]) and use the PATH environment variable to decide which version of the executable you'd like to use in which context. [1] https://brew.sh https://brew.sh [2] https://www.macports.org https://www.macports.org
  - __float 2y ago
    This might be true for the most part as an end user, but from a licensing perspective regarding the original binaries, this is irrelevant. You must be able to modify and change the code, not merely append to the PATH: > Tivoization: Some companies have created various different kinds of devices that run GPLed software, and then rigged the hardware so that they can change the software that's running, but you cannot. from https://www.gnu.org/licenses/quick-guide-gplv3.en.html https://www.gnu.org/licenses/quick-guide-gplv3.en.html
    - chongli 2y ago
      My claim is entirely from the end user perspective. We should not really care which tool Apple includes for their licensing purposes. If we have a dependency on a particular tool then we have the ability to install and use it ourselves. The signed system volume does not interfere with our ability to do that.
    - duskwuff 2y ago
mappu 2y ago
> this was called “tivo-ization” at the time, because TiVo did it. It's not widely known but what TiVo actually did was something different than this, and both RMS and the SFC believe that both the GPLv2 and GPLv3 allow what TiVo actually did. Some discussion and further links via https://lwn.net/Articles/858905/ https://lwn.net/Articles/858905/
- imcritic 2y ago
  I'm just curious: do you have that link bookmarked?
  - skydhash 2y ago
    Sometimes you just remember the arricle and the right keywords can get it easily from a search engine.
harry8 2y ago
> So for iOS, it’s pretty obvious why they don’t use gplv3… because it would violate the terms. Apple using "openrsync" because they want to close the code more than the rsync license lets them.
- mattl 2y ago
  I’m not sure they care about rsync’s code, they probably just don’t want to maintain an old fork of rsync under GPLv2.
  - Aachen 2y ago
    Why should they? Apple isn't the maintainer of rsync or other third party software last I checked
    - mattl 2y ago
      This is what they have been doing for years since rsync was released under the GPLv3.
Someone 2y ago
> For macOS they could certainly get away with shipping gplv3 code Even limiting that to “in the USA” I would never say certainly for a license for which so little jurisprudence exists. Once you add in multiple countries, it doesn’t get clearer. And yes, that applies to GPLv2, too, but that ship has sailed. I also don’t see them add much new GPLv2 licensed software. For GPLv3, they also may be concerned about patents. If, to support some MacOS feature, they change a GPLv3 licensed program that uses one of their patents, GPLv3 gives others the rights to use those patents in versions of the tool that run on other platforms.
pabs3 2y ago
TiVo didn't do that, they broke their proprietary software when it ran on a modified version of the GPLed Linux kernel. Also, GPLv2 requires the ability to modify and reinstall, just like GPLv3. https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-the-gpl-right-to-install/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... Neither GPLv2 nor GPLv3 prevent what TiVo actually did. https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Safely-Copylefted-Cars-Reexamining-GPLv3-Installation-Information-Requirements-ALS-Bradley-Kuhn-Behan-Webster-1.pdf https://events19.linuxfoundation.org/wp-content/uploads/2017...
p0w3n3d 2y ago
> they’re more free to lock down macOS from running your own code on it in the future, without worrying about having to rip out all the gpl3 code when it happens. Better to just not build on it in the first place. That's actually quite scary what you wrote there. That's also even more scary to me, as I am really watchful for such restrictions which can IMO happen in current OSes any time now ...
- kijiki 2y ago
  This is really easy, just use Linux.
  - p0w3n3d 2y ago
    Easy unless web services start requiring you to use TPM or other things that limit your possibilities further
jeroenhd 2y ago
For iOS that makes sense, I suppose, but does Apple really ship the rsync binary to iOS? I suppose the way they prevent you from replacing system files could violate the GPLv3 clause, but still, it seems silly.

KerrAvon 2y ago

No, this doesn't quite scan, because there's no reason they couldn't ship a current of `bash` or any number of other GPL3 things. Aurornis is probably closest to the mark: it is legally ambiguous, and Apple probably does not want to be a test case for GPL3 compliance.

ninkendo 2y ago
If they shipped a gpl3 version of bash on iOS, they would be in violation. This isn’t really a question: gpl3 requires you to not only provide the source if you use it in a product, but the ability to modify it and run your modified version. Which iOS doesn’t let you do. Now, macOS would be fine in shipping a gpl3 bash. But not iOS. (Yes, iOS has bash. Or ar least they used to, they may be all on zsh now, I’m not sure.) So, the question becomes to Apple, do we ship different bash versions for different devices, and treat macOS as being different, and have to worry about only using newer bash features on macOS? Or do we keep the same old version on all platforms, and just eschew the new bash everywhere? It’s a pretty simple decision IMO, especially because users can just use brew on macOS and put their own bash on there if they want. Others are pointing out that gpl3 is less tested in court and that lawyers are just more uncertain/afraid of gpl3 than gpl2, especially with respect to patents… but I don’t think these are mutually exclusive. It’s clear that they can’t ship gpl3 on 4 out of their 5 operating systems. macOS is an outlier, and from an engineering standpoint it’s a lot simpler to just keep them all the same than it is to ship different scripts/etc for different platforms. It can be both reasons.

jitl 2y ago

> It also means they’re more free to lock down macOS from running your own code on it in the future, without worrying about having to rip out all the gpl3 code when it happens. Better to just not build on it in the first place. how does locking down macOS have anything to do w/ GPL compliance? Apple is free to do whatever BS with the OS they ship in terms of terminal access, user permission level, etc regardless of GPL of any code on the device. I could ship a GPLv3 system tomorrow that disallows user root access and as long as I make the OS source freely available and redistributable, it's fine.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
ninkendo 2y ago
If you make a device which uses GPL’d code, and provide all the covered source code you used, but prevent users from putting any modified code on the device, you are in violation of GPLv3, but not GPLv2. That means this sentence: > I could ship a GPLv3 system tomorrow that disallows user root access and as long as I make the OS source freely available and redistributable, it's fine. Is not true for gpl3. It’s called the “tivo-ization” loophole, and it’s one of the principal reasons the GPL3 was made in the first place. I think you’re just wrong. (Note: I’m not claiming Apple is would be in violation for shipping e.g. a GPLv3 bash on macOS, today, only that they would be in violation for doing that on iOS today, or if in the future they locked down macOS in the same way that iOS was, then for macOS too.)
- pabs3 2y ago
  Correction, that is a GPLv2 violation too. Some discussion: https://lwn.net/Articles/858905/ https://lwn.net/Articles/858905/
NewsaHackO 2y ago
[flagged]

duskwuff 2y ago

Current versions of macOS use a signed system volume [1], much like iOS - under a standard system configuration, the user can't replace system executables or other files, even as root. Unlike iOS, the user can disable SSV, but I'm not certain that's sufficient for GPLv3 - and I can't imagine Apple feels comfortable with that ambiguity. [1]: https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web https://support.apple.com/guide/security/signed-system-volum...

chongli 2y ago
Sure, though there's little point in replacing executables such as rsync when you can install your own version (perhaps through a package manager and package repository / database such as Homebrew [1] or MacPorts [2]) and use the PATH environment variable to decide which version of the executable you'd like to use in which context. [1] https://brew.sh https://brew.sh [2] https://www.macports.org https://www.macports.org
- __float 2y ago
  This might be true for the most part as an end user, but from a licensing perspective regarding the original binaries, this is irrelevant. You must be able to modify and change the code, not merely append to the PATH: > Tivoization: Some companies have created various different kinds of devices that run GPLed software, and then rigged the hardware so that they can change the software that's running, but you cannot. from https://www.gnu.org/licenses/quick-guide-gplv3.en.html https://www.gnu.org/licenses/quick-guide-gplv3.en.html
  - chongli 2y ago
    My claim is entirely from the end user perspective. We should not really care which tool Apple includes for their licensing purposes. If we have a dependency on a particular tool then we have the ability to install and use it ourselves. The signed system volume does not interfere with our ability to do that.
  - duskwuff 2y ago

mappu 2y ago

> this was called “tivo-ization” at the time, because TiVo did it. It's not widely known but what TiVo actually did was something different than this, and both RMS and the SFC believe that both the GPLv2 and GPLv3 allow what TiVo actually did. Some discussion and further links via https://lwn.net/Articles/858905/ https://lwn.net/Articles/858905/

imcritic 2y ago
I'm just curious: do you have that link bookmarked?
- skydhash 2y ago
  Sometimes you just remember the arricle and the right keywords can get it easily from a search engine.

harry8 2y ago

> So for iOS, it’s pretty obvious why they don’t use gplv3… because it would violate the terms. Apple using "openrsync" because they want to close the code more than the rsync license lets them.

mattl 2y ago
I’m not sure they care about rsync’s code, they probably just don’t want to maintain an old fork of rsync under GPLv2.
- Aachen 2y ago
  Why should they? Apple isn't the maintainer of rsync or other third party software last I checked
  - mattl 2y ago
    This is what they have been doing for years since rsync was released under the GPLv3.

Someone 2y ago

> For macOS they could certainly get away with shipping gplv3 code Even limiting that to “in the USA” I would never say certainly for a license for which so little jurisprudence exists. Once you add in multiple countries, it doesn’t get clearer. And yes, that applies to GPLv2, too, but that ship has sailed. I also don’t see them add much new GPLv2 licensed software. For GPLv3, they also may be concerned about patents. If, to support some MacOS feature, they change a GPLv3 licensed program that uses one of their patents, GPLv3 gives others the rights to use those patents in versions of the tool that run on other platforms.

pabs3 2y ago

TiVo didn't do that, they broke their proprietary software when it ran on a modified version of the GPLed Linux kernel. Also, GPLv2 requires the ability to modify and reinstall, just like GPLv3. https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-the-gpl-right-to-install/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... Neither GPLv2 nor GPLv3 prevent what TiVo actually did. https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Safely-Copylefted-Cars-Reexamining-GPLv3-Installation-Information-Requirements-ALS-Bradley-Kuhn-Behan-Webster-1.pdf https://events19.linuxfoundation.org/wp-content/uploads/2017...

p0w3n3d 2y ago

> they’re more free to lock down macOS from running your own code on it in the future, without worrying about having to rip out all the gpl3 code when it happens. Better to just not build on it in the first place. That's actually quite scary what you wrote there. That's also even more scary to me, as I am really watchful for such restrictions which can IMO happen in current OSes any time now ...

kijiki 2y ago
This is really easy, just use Linux.
- p0w3n3d 2y ago
  Easy unless web services start requiring you to use TPM or other things that limit your possibilities further

jeroenhd 2y ago

For iOS that makes sense, I suppose, but does Apple really ship the rsync binary to iOS? I suppose the way they prevent you from replacing system files could violate the GPLv3 clause, but still, it seems silly.