apple-sdk: add license to be in complaince

[Eveeifyeve]

This pr adds the apple sdk license to be in compliance that has been missed.

See this comment for issues around why it needs to be added

I did a simple nix eval and found it missing:

nix eval --json --impure --expr '
  let 
    pkgs = import <nixpkgs> { 
      config = { 
        allowUnfree = true; 
        allowBroken = true; 
      }; 
    };
    lib = pkgs.lib;
    
    # Safely check for meta.name and the absence of meta.license
    checkMissingLicense = name: value: 
      let 
        res = builtins.tryEval (
          # Check if it is a derivation and has meta.name but NO license
          lib.isDerivation value && 
          (value ? meta.name) && 
          !(value ? meta.license)
        );
      in 
        res.success && res.value;

    # Filter the entire package set
    missingLicense = lib.filterAttrs checkMissingLicense pkgs;
  in 
    builtins.attrNames missingLicense
'

Link to license: https://developer.apple.com/support/terms/apple-developer-program-license-agreement/

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

CC @NixOS/darwin-core

Add a 👍 reaction to pull requests you find important.

[Eveeifyeve]

To note: I am not a lawyer, please take my advice with a grain of salt. If you need advice please go look for a professionally trained lawyer.

Under the agreement the apple-sdk is defined as apple software.

Under 2.4 Copies:

You agree to retain and reproduce in full the Apple copyright, 
disclaimers and other proprietary notices (as they appear in the Apple Software and Documentation provided)
in all copies of the Apple Software and Documentation that
You are permitted to make under this Agreement.

Which this clearly broke.

But also at 2.6 No Other Permitted Uses:

Except as otherwise set forth in this Agreement, You agree not to rent, lease,
lend, upload to or host on any website or server, sell, redistribute, 
or sublicense the Apple Software, Apple Certificates, 
or any Services, in whole or in part, or to enable others to do so.

We might need to look into about the redistribution terms of this.

[eclairevoyant]

As CI already points out, this breaks eval and will prevent hydra from building everything - all darwin users will have to rebuild the world every 2 weeks.

       error: Package ‘apple-sdk-14.4’ in /nix/store/rqv586g486jhg3s61x71b27cahi9b8bn-source/pkgs/by-name/ap/apple-sdk/package.nix:108 has an unfree license (‘apple-developer-program’), refusing to evaluate.

       a) To temporarily allow unfree packages, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNFREE=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnfree = true; }
       in configuration.nix to override this.

       Alternatively you can configure a predicate to allow specific packages:
         { nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
             "apple-sdk"
           ];
         }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnfree = true; }
       to ~/.config/nixpkgs/config.nix.
Command exited with non-zero status 1
Attribute eval done [18103104KB max resident, 0m 16.87ss elapsed] nix-instantiate --eval --strict --json --show-trace /nix/store/rqv586g486jhg3s61x71b27cahi9b8bn-source/ci/eval/attrpaths.nix -A paths -I /nix/store/rqv586g486jhg3s61x71b27cahi9b8bn-source --argstr extraNixpkgsConfigJson {} --option restrict-eval true --option allow-import-from-derivation false --option eval-system x86_64-darwin
error: Cannot build '/nix/store/g840ahxd3m50hg86wb6zpbz1vnqxxv9g-attrpaths-superset.json.drv'.

[Eveeifyeve]

As CI already points out, this breaks eval and will prevent hydra from building everything - all darwin users will have to rebuild the world every 2 weeks.

       error: Package ‘apple-sdk-14.4’ in /nix/store/rqv586g486jhg3s61x71b27cahi9b8bn-source/pkgs/by-name/ap/apple-sdk/package.nix:108 has an unfree license (‘apple-developer-program’), refusing to evaluate.

       a) To temporarily allow unfree packages, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNFREE=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnfree = true; }
       in configuration.nix to override this.

       Alternatively you can configure a predicate to allow specific packages:
         { nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
             "apple-sdk"
           ];
         }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnfree = true; }
       to ~/.config/nixpkgs/config.nix.
Command exited with non-zero status 1
Attribute eval done [18103104KB max resident, 0m 16.87ss elapsed] nix-instantiate --eval --strict --json --show-trace /nix/store/rqv586g486jhg3s61x71b27cahi9b8bn-source/ci/eval/attrpaths.nix -A paths -I /nix/store/rqv586g486jhg3s61x71b27cahi9b8bn-source --argstr extraNixpkgsConfigJson {} --option restrict-eval true --option allow-import-from-derivation false --option eval-system x86_64-darwin
error: Cannot build '/nix/store/g840ahxd3m50hg86wb6zpbz1vnqxxv9g-attrpaths-superset.json.drv'.

Someone did point this out already over at matrix, however I am not sure if it's uncopyrightable/fair use to use API Stubs or Headers. There was a case discussed in matrix Google LLC v. Oracle America the court stated it was "fair use" using the Java SE API. Which relates to the previous discussions about this over at RFC:

• [RFC 0185] Redistribute redistributable software rfcs#185 (comment)
• [RFC 0185] Redistribute redistributable software rfcs#185 (comment)
  But however I am a bit skeptical about this being potentially legal issue and what we have done in the past to handle these sort of legal issues.

There is conversations atm going on in the matrix starting here

[Aleksanaa]

See what?

[Eveeifyeve]

It's a TODO.

[leona-ya]

I still don't think it's a good idea to add this here, as none of the licenses we have in Nixpkgs really describe the situation perfectly. WIthout a solution that Hydra doesn't upload the output of apple-sdk we don't have a benefit really. At the end I'm not the person who should decide that, so I won't review this.

[Aleksanaa]

I think lib.licenses.unfreeRedistributableFirmware sorts of can, as it's considered as "free" to make us build it. We use it for linux-firmware too. Indeed, before we "redistribute redistributable packages", there is no way to solve this problem unless we added an additional option to the license, such as "allowHydra" or something like that.

[reckenrode]

Under the agreement the apple-sdk is defined as apple software.

Where is this from? We do not source the SDK from Xcode or the CLT. The SDK is not downloaded from any source that requires an Apple Developer Program membership or agreement to its terms. The package is sourced the software update catalogue and can be downloaded with curl (which is essentially what fetchurl does).

The package itself does not come with a license. If one opens it in the Installer app, no license is presented. It contains mostly the same things that are included in the apple-sdk. We attempt to remove things other than stubs, headers, and Swift modules (as well as vendored those from vendored packages). If any have been missed, that’s a bug in the packaging.

The remaining files are text-based stubs or Swift modules, which are generated upstream by tooling, and headers.. The headers have a mix of open source and other notices. What is the correct license to set on the SDK? I don’t know. When I added the package for the new SDK pattern last year, I followed historical practice in Nixpkgs by leaving it blank.

To note: I am not a lawyer, please take my advice with a grain of salt. If you need advice please go look for a professionally trained lawyer.

This PR isn’t using the right license agreement. I don’t think this is straightforward. There are questions about what we are allowed to do for interoperability purposes (and potentially how we can continue supporting Darwin in Nixpkgs).

[Eveeifyeve]

software update catalogue

WARNING: I am not a lawyer, and this is not legal advice!

I found a better license agreement here: https://www.apple.com/legal/sla/docs/xcode.pdf that seems to clear about the API's. I think I found potentially the wrong link, but this is very similar. Under 2.7 it says this:

2.7 Restrictions; No Other Permitted Uses
The grants set forth in this Agreement do not permit You to, and You agree not to, install, use or run the
Apple Software or Apple Services on any non-Apple-branded computer or device, or to enable others to
do so. This Agreement does not allow the Apple Software or Services to be made available over a
network where they could be run or used by multiple computers at the same time, unless otherwise
Page 5 of 15
expressly permitted in writing by Apple. Further, unless otherwise expressly permitted by Apple in
writing, You agree not to rent, lease, lend, upload to or host on any website or server, sell, redistribute,
or sublicense the Apple Software and Apple Services, in whole or in part, or to enable others to do so.
You may not use the Apple Software and Apple Services for any purpose not expressly permitted by this
Agreement. You may not and You agree not to, or to enable others to, copy (except as expressly
permitted under this Agreement), decompile, reverse engineer, disassemble, attempt to derive the
source code of, modify, decrypt, or create derivative works of the Apple Software or Services

The swcdn.apple.com url I am not sure if it's governed by "this license".

And also under 2.5 it still says to still provide the notice:

2.5 Copies
You agree to retain and reproduce in full the Apple copyright, disclaimers and other proprietary notices
in all copies of the Apple Software that You are permitted to make under this Agreement. For clarity,
You may copy only the entire package or piece of the Apple Software and Services in its entirety and
only for use as permitted herein. You may not alter the Apple Software or Services in any way in such
copy, e.g., You are expressly prohibited from separately using the Apple SDKs or attempting to run any
part of the Apple Software on non-Apple-branded hardware. Images contained in the Documentation
may not be separately copied or used outside of the Documentation.

Under the definition under section 1 it defines apple-sdk as this:

“Apple SDKs” means the macOS SDK, and the Apple-proprietary Software Development Kits (SDKs)
provided hereunder, including but not limited to header files, APIs, libraries, simulators, and software
(source code and object code) labeled as part of the iOS SDK, watchOS SDK, iPadOS SDK, tvOS SDK
and/or visionOS SDK and included in the Xcode Developer Tools package for purposes of targeting
Apple-branded products running iOS, watchOS, iPadOS, tvOS or visionOS.

Quote: including but not limited to header files, APIs, libraries, simulators, and software
(source code and object code) Is a bit concerning. Idk if this is still considered fair use if your agreeing to it before installing.

[reckenrode]

WARNING: I am not a lawyer, and this is not legal advice!

Then don’t go ahead and play at it anyway.

[Eveeifyeve]

WARNING: I am not a lawyer, and this is not legal advice!

Then don’t go ahead and play at it anyway.

This was roughly done It's been resolved now.

[emilazy]

The arguments here are mostly recapitulating what was already discussed on Matrix without engaging with the substance of the points raised. There is a possible productive discussion to be had about the copyright of the macOS SDK and the limitations Hydra has around pushing builds to the cache, but I don’t think it’s going to happen on this PR.

To repeat my general position for the record, though: if the package output was encumbered by the Xcode EULA, then it wouldn’t even be lib.licenses.unfreeRedistributable, but even setting aside the fact that the software update package we source the SDK from isn’t gated behind that EULA, I believe that what we need from the SDK is most likely uncopyrightable or at least clearly fair use. The SDK primarily contains interface definitions and linker stubs rather than any executable code – the actual library code ships with the OS – but we strip it to remove all encumbered executable binary code like compiler tools. What we use from the SDK is almost entirely machine‐generated lists of symbol names for linking (.tbd files), interface definitions (hand‐written C/Objective‐C .h and .modulemap files, and Swift mapping glue in the form of .apinotes and .swiftoverlay files and machine‐generated .swiftinterface files), and general SDK metadata (.plist files).

The potential creativity here is limited to API structure and symbol names, which are of course required for interoperability and embedded in every binary for the platform. I believe that all of these are likely uncopyrightable in the EU and, although the status of the copyrightability of APIs is ambiguous in the US, I think they would easily clear the Google v. Oracle bar for fair use; in any case, we go by EU rules for the cache in practice, given the Foundation’s jurisdiction and the fact that we ship software encumbered by software patents. See Directive 2009/24/EC and some commentary for background on the EU law regarding software copyrights.

The main hesitation I would have around potential copyright is around documentation comments in .h and .swiftdoc files, and non‐trivial macro logic in .h files; we could potentially look into stripping these out, or regenerating header files from scratch with libclang, if necessary. (C++ headers that often contain non‐trivial implementation definitions would also pose a potential concern, but the macOS platform APIs make almost no use of it.)

Of course, it’s always possible we do not strip out everything we should, and we should fix any such cases, but that is true of various packages in the tree we strip out encumbered portions from.

The current state of the PR doesn’t make sense given the placeholder text; I was asked to provide an official written statement to link to in the comment, but it’s not a priority for me and I don’t really have time for that, so this PR is unlikely to progress; I’m making the call to close this, as it’s a time sink for Darwin maintainers. To be very explicit, this is in my capacity as a Darwin team member (and, I suppose, a lib/licenses.nix code owner), but not as a Nixpkgs core team member and certainly not as any kind of lawyer.