| 7 Jan 2026 |
 emily | I think in the limit (6) would legitimize linking against the Xcode libclang and driving it to reproduce all the header declarations including the names required for interoperability | 15:33:52 |
| emily | which would be exceedingly silly but hey | 15:34:01 |
| emily | btw Mozilla explicitly tell people to copy declarations out of SDK headers and vend them in Firefox source: https://firefox-source-docs.mozilla.org/widget/cocoa/macos-apis.html | 15:35:50 |
| emily | although the author seems confused about TBDs | 15:36:17 |
 Randy Eckenrode | The problem with fair use is it’s a defense you have to assert. You’d still have to go through with the case if someone wanted to sue. | 15:42:07 |
| Randy Eckenrode | They fell off a truck. 🥸 | 15:43:24 |
| emily | applies even if we had a blanket "all APIs are uncopyrightable" ruling, right? they can always sue you and argue about whether the header file contents or Swift interface files or whatever constitute "uncopyrightable APIs" | 15:45:01 |
| emily | nothing you can do to stop anyone suing you ultimately | 15:45:30 |
|  @masrlinu:matrix.org left the room. | 15:45:55 |
| emily | I do think the fact that we treat the cache as being under EU law is more relevant though, yesh | 15:46:10 |
| emily | * | 15:46:15 |
| emily | Oracle v. Google mostly matters for American users doing weird stuff or mirrors | 15:46:42 |
| Randy Eckenrode | If we had an “APIs are not copyrightable” ruling, I assume it would be possible to argue that there’s no case and get it dismissed. | 15:46:46 |
| emily | I can imagine a "well Swift is different from Java you know, we are the experts after all!" 😅 | 15:47:21 |
| emily | but yeah agreed that the line is further out because of that | 15:47:39 |
 eveeifyeve | So would it be considered fair use? If so do I still link the licence or just have license.publicDomain? | 15:48:32 |
| emily | "we are not even reimplementing like Google did, this is pure interoperability for use with Apple hardware and software" is also pretty strong otoh. | 15:48:47 |
| eveeifyeve | Because it is important to have a meta.license if it's public domain and also a comment explaining the reasons to it. | 15:50:24 |
| eveeifyeve | * Because it is important to have a meta.license if it's uncopyrightable/fair use and also a comment explaining the reasons to it. | 15:50:43 |
| emily | if we are going to tag it, I would probably go with lib.licenses.free with an explanatory comment that we strip the SDK to only the symbol lists and header files required for interoperability and remove all the encumbered binary code | 15:50:43 |
| emily | public domain is not quite right | 15:50:52 |
| emily | SPDX is reviewing an "uncopyrightable" licence IIRC | 15:51:04 |
| emily | but I don't think it has an assigned identifier yet | 15:51:26 |
| emily | I'm wary of making explicit copyright/licensing assertions here though. free is generic enough to hopefully be fine | 15:52:59 |
| emily | btw there are like, thousands of packages without licenses tagged in the tree | 15:53:15 |
| emily | would be good to fix, but we definitely have way more dubious stuff than the SDK | 15:53:35 |
| emily | until last release we accidentally had entire encumbered Android system images gigabytes big getting pushed into the cache 🫣 | 15:54:22 |
| eveeifyeve | 💀 | 15:55:58 |
| emily | FWIW preemptively: the Windows SDK has many proprietary binaries that would need to be stripped (like MSVC) for similar arguments to apply there, as well as DLLs (LIB import libraries for those DLLs should not be copyrightable, but not every LIB is an import library), and I believe it also has a lot of C++ which is much more likely to contain substantial copyrightable program logic in header files | 15:56:46 |
| emily | and I believe that those DLLs are things you actually need to redistribute for programs to work rather than being able to use them from the OS like macOS system APIs | 15:57:30 |
