Hacker News Reader

Comment by berelig | Hacker News Reader

Can someone explain what this means? Does it benefit those working on Linux support for M1?

It doesn't have much significance. Apple does this for all (major) macOS releases. macOS and iOS are built off of open source components, for which Apple releases the source code now and then. It's a courtesy for the most part - most of these are BSD licensed and therefore don't strictly require source code to be released.

These notably don't include much of mac/iOS proprietary user interface components, drivers, or system frameworks - basically everything that makes macOS/iOS remotely interesting. The source code drops are helpful for the creation of other Unix-like operating systems based on the open source macOS kernel (see also the defunct Open/PureDarwin projects), and the released apps are sometimes ported (e.g. the GnuStep project has some older version of Chess.app and others ported over). There's some off and on efforts in the FreeBSD community to port Apple's open source launchd init system [1]. All in all though, there's really not all that much interest in reusing the code from these code drops by the open source community and any efforts seem to lack staying power.

The released source most practical value is most likely derived by researchers investigating macOS/iOS internals and being able to inspect the source code for some of it. As a curiosity it looks like you're able to build and run your own XNU kernel on macOS [2] (what is this, Linux?), but I can't personally attest to the process.

[1]: e.g. https://github.com/freebsd/openlaunchd

[2]: https://kernelshaman.blogspot.com/2018/12/building-xnu-for-m...

"BSD licensed and therefore don't strictly require source code to be released"

Broken promises of liberal freedom.

What? The BSD license is 30 years old, it has never required the release of source code of derived works.

What kind of promise do you feel you have been given?

Not really, this is done for every OS release. It's a completely routine nothingburger with an iffy HN title.

Yeah, the real title should be “Apple abides to the letter of opensource licenses, like every year, while largely continuing to ignore the spirit of them”.

You’re confusing Open Source and copyleft, I think.

Some of this is Apple Public Source Licensed I think which is at (partial) copyleft - at least accoding to the FSF.

Apple had no problem including "copyleft" code in their OS for the longest time... but GPLv3 is a no-go due to the closed nature of their other platforms (iOS). GPLv3 adds the requirement that code for derived works not only be released, but that someone should be able to build their own modifications on that platform for free, won't work with the way the the iOS developer agreement works ($99 a year.)

And it wasn't worth the complexity of having different software for each of their OS's, so they just banned all GPLv3 software from the OS.

Apple's use of open source could have totally worked with "copyleft", but only the GPLv2 usage of the word. GPLv3, not so much.

> GPLv3 adds the requirement that code for derived works not only be released, but that someone should be able to build their own modifications on that platform for free, won't work with the way the the iOS developer agreement works ($99 a year.)

I don't see anything in GPLv3 about people having to be able to build derived works for no cost.

What GPLv3 adds is a requirement that your provide "Installation Information" to allow you to install and run the code once you build it. Installation information is things like keys to sign the code if the platform it is for only runs signed code.

The installation information requirement only applies when the object code was conveyed "as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized)". A "User Product" is "either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling".

GPLv3 object code that is not conveyed as part of a change of possession of a User Product is not subject to the installation information requirement. This requirement was added to GPLv3 specifically to stop what TiVo was doing--shipping GPL code on their boxes that could not be replaced by the user--and it was narrowly drafted to only cover that situation.

Hmm, I guess there's two arguments happening here...

- Apple can't include GPLv3 software in iOS because it only runs signed code, and the keys needed to sign system components are kept secret by Apple. From this perspective, the developer agreement is a red herring.

- App Store developers can't include GPLv3 code in their apps, because then Apple would be breaking the terms of GPLv3 by not providing the "Installation Information" as you put it, which would be required for users to freely modify the app. (This "Installation information" being the iOS SDK and a Developer signing key needed to run your own code on your device.) Keep in mind that when Apple distributes your app via the app store, they take on the responsibilities to adhere to the terms of its license as they pertain to "redistribution", since that's exactly what Apple is doing.

> GPLv3 object code that is not conveyed as part of a change of possession of a User Product is not subject to the installation information requirement. This requirement was added to GPLv3 specifically to stop what TiVo was doing--shipping GPL code on their boxes that could not be replaced by the user--and it was narrowly drafted to only cover that situation.

If Apple were to include GPLv3 code directly as part of iOS, they absolutely would be "shipping GPL code on their boxes that could not be replaced by the user"... something that is OK in GPLv2 (so long as you provide the source like they're doing in TFA), but not OK in GPLv3 (because of the tivoization clauses.)

To tie all this to my original point... macOS ends up having to kill all its uses of GPLv3 (even though you can replace it on device and build your own, on macs), because of the shared architecture and engineering with iOS. It's easier to just ban GPLv3 from the entire company really.

Please explain how they are ignoring the spirit of these opensource licenses in respect of this code.

Not really. They're not required to share their source or alterations to BSD and MIT works, which most of this is.

There is also some original work from Apple.

Apple isn't actually obligated to release any of this code. It's licensed under BSD-like terms.

Big Sur came out several months ago, so if this release contained GPL code Apple would potentially be in trouble. (But it doesn't, so they're not.)

Not really - they are obligated to provide it on request, and allowed to take a reasonable time to do so. If someone requested it, and they later uploaded it here, they'd be fine.

In what way does the BSD license obligate that?

I read that comment as saying that GPL wouldn't require simultaneous release, but would simply obligate them to release on request.

But I may also be misreading it.

Yes, I was referring to the GPL, not BSD licensed software.

It did come with bash, which is GPL. (sure, zsh is now the default, but bash is there too)

macOS actually comes with Bash 3.2, which is from 2007. it is the last version released before they switched to GPL. this is actually why they switched to zsh.

^ We all assume that's why, it should perhaps be said. Although I think the circumstantial evidence is pretty strong. :)

Well, the fact is, the version available on opensource.apple.com in macOS 11.0.1 is 123.40.1 and the version in 10.15.6 is 118.40.2... and they slightly differ.

Interestingly, the new version removed the dependency on the unavailable rootless.h header, making it (probably) buildable out of the box, now.

I would assume the version difference is from Apple updating it internally. They don't run into GPL issues unless they pull from newer upstream Bash code.

You post this every time this discussion comes up, even though it’s patently false and known to be false and you’ve been told it’s false multiple times here. Amazing.

> PowerManagement-1132.50.3

At least the name sounds promising.

None of this is licensed such that they can use it directly, but having the source available can speed up the reverse engineering process such that they can rewrite their own version of the code that interacts with the hardware.

Note that this requires a clean-room process - reading the original source code as inspiration usually taints any work derived from the observations.

This is why open source developers actively avoid reading leaked sources from proprietary projects for example. "open source" code with too restrictive licenses is no different from closed source code.

The relevant developers are of the opinion (one that I agree with) that it does not require a clean room process. A clean room process is a gold standard for preventing accidental copyright infringment, but is not necessary and is enough work they don't consider it worthwhile. Reading (and even to the extent that it's compatible with the license modifying) the original source code to learn how the underlying hardware works is not copyright infringment and does not make future works you produce derivative works of the original.

Source/explanation in their words instead of mine: https://asahilinux.org/copyright/ (See: "Reverse engineering policy")

The policy of those developers does not mean much, and while the policy of upstream kernel developers that need to accept the code can be interesting, but ultimately only a lawyer's opinion have any meaning here.

They might coincidentally be right of course, but their advice, policy and opinion in this legal matters mean as little as yours and mine.

> None of this is licensed such that they can use it directly

Not sure what you're referring to here?

All the interesting bits are Apple License [1], which isn't GPL compatible [2].

[1] https://opensource.apple.com/source/IOGraphics/IOGraphics-58...

[2] https://asahilinux.org/copyright/ - See "Referencing Other Open Source Code"

Interesting. I'm now doing some more Googling, and I can't seem to find a place that explains why the APSL isn't GPL compatible. (But it's almost certainly not, given that lots of authoritative sources including GNU[1] say as much. They just don't say why.)

1: https://www.gnu.org/philosophy/apsl.en.html

Probably (I haven't studied it) because of what the FSF says here "It is not a true copyleft, because it allows linking with other files which may be entirely proprietary." So it's apparently file-based copyleft, which is in the same vein as CDDL. (Which is also generally considered GPL-incompatible for that reason.)

It means the people who were breathlessly jumping the gun a few weeks back, saying Apple would never release open source Big Sur stuff may have been a bit over-excited.

Just a release of their use of GPL code which the would be required to provide if requested anyways. It does not have any impact on Linux support.

Quite a bit of this is sourced from within Apple under Apple's license.

There might be some useful things in there. If they released the code/ patches in an easier to review way. As it is, it's fairly difficult to see if anything

Apple in general doesn’t use gpl code. The vast majority of their work is BSD or BSD-like license.

It's interesting that because I said GPL instead of open source, my bad, I'm downvoted to -4. Shit.

Reply on news.ycombinator.com