5 ms·

Yes and no. Apple is perfectly willing to maintain, say, Swift and LLVM as Free projects; but they also have a proprietary fork with extra bits exclusive to th

Yes and no. Apple is perfectly willing to maintain, say, Swift and LLVM as Free projects; but they also have a proprietary fork with extra bits exclusive to their own hardware. For example, their proprietary GPU drivers compile shaders with it. LLVM being permissively licensed and owned by them means they have no reason to release those bits. This is not a hypothetical problem; it causes real harm to downstream users of LLVM. Rust has to support the current version of Apple's LLVM fork as well as the LLVM they ship with specifically just so you can compile watchOS apps, since that platform requires a proprietary bitcode format Apple never documented and only supports in their proprietary fork. Had Apple stuck with GCC they wouldn't have the legal ability to do this. Even if they had used GPL on LLVM, that license alone means that any contributions they take would also bind Apple to the same license. That's why people are extremely apprehensive about CLAs, because they're basically one-sided. The project vendor is free to sell exceptions or maintain proprietary forks, but you still have to comply with GPL.

deleted 5y ago
[deleted]
Gaelan 5y ago
> proprietary bitcode format Apple never documented and only supports in their proprietary fork IIRC, the bitcode format isn't proprietary—it's part of the open-source LLVM. The only issue is that it's not a stable format, so they need to use Apple's LLVM version and not an earlier or later open-source one.
- saagarjha 5y ago
  Note that there is lowercase-b bitcode, which is part of LLVM, and uppercase-B Bitcode, which is Apple’s thing built on top.
- pjmlp 5y ago
  Apple uses a special version of LLVM bitcode as deployment format for watchOS and iOS. This variant wasn't and will never be upstreamed.
stephenr 5y ago
As Apple own it anyway, what difference would releasing it as gpl make? They could still do as they like, as it’s theirs. Do they accept significant code from the community? This is why I find the “use agpl” claims about projects run by a company disingenuous- they’re using the licence restriction to prevent competition while they have the freedom to offer “enterprise” editions however they wish.
- kmeisthax 5y ago
  Apple licenses their software as Apache 2 so a CLA isn't necessary, everyone is free to make proprietary forks. Companies that want to release software as GPL but also sell exceptions or make forks either cannot accept third-party contributions (as then they'd be bound by the contributor's derivative copyright interest in the code) or have to require contributors sign CLAs. Projects with distributed copyright interest and a copyleft license governing all of that, like the Linux kernel, practically cannot relicense or sell exceptions. That's the power of the GPL: everyone has to contribute on a level playing field.
  - stephenr 5y ago
    You’re missing the question I asked though. Does Apple accept significant code contributions from outside the project? Because if they don’t, the gpl wouldn’t help. But regardless of that - I think this is the perfect example of the copyleft crowd not understanding the concept of compromise. Apple creates something, releases it as open source but also maintains some private extensions, and the response is: well why didn’t you give it all to us?
    - Qwertious 5y ago
      >Does Apple accept significant code contributions from outside the project? Yes, they do. LLVM has a large number of non-Apple contributors.
- lmm 5y ago
  > As Apple own it anyway, what difference would releasing it as gpl make? Apple don't own it. They piggyback off a lot of other people's work in LLVM.
twic 5y ago
Even if Apple had basd their watchOS toolchain on GCC, and had published the source code for it, it is quite likely that their fork would have remained separate to upstream: upstream might not care about watchOS support, and Apple's fork might be based on an old version of GCC. In that case, Rust would still have to support two versions.
rodgerd 5y ago
> Had Apple stuck with GCC they wouldn't have the legal ability to do this. They tried. rms lost the email.
- pjmlp 5y ago
  Yeah, if they actually wanted they would have been a bit more pushy than just shooting an email away.
nemothekid 5y ago
>Rust has to support the current version of Apple's LLVM fork as well as the LLVM they ship with specifically just so you can compile watchOS apps, since that platform requires a proprietary bitcode format Apple never documented and only supports in their proprietary fork. I'm not sure I follow. Apple's LLVM fork could open source and Rust would still have to support two LLVMs if the WatchOS code wasn't upstreamed. Apple has no responsibility to upstream code on the GPL, nor do the LLVM maintainers. Given that Apple's bitcode would be proprietary / undocumented (GPL doesn't require you to document your code), it would take a dedicated individual to make sure the two projects are in sync. If Apple isn't doing that now, I'm not convinced they would do it under GPL.
- kmeisthax 5y ago
  Rust has it's own (Free) LLVM fork, too. If the watchOS/iOS Bitcode format were Free, they could merge that into their own LLVM instead of having to support two slightly-different compiler backends. The GPL would legally require Apple to publish source code for all LLVM forks they make, if they accepted third-party contributions under GPL terms. It doesn't require them to upstream it anywhere, you just have to let someone else do it.

deleted 5y ago

[deleted]

Gaelan 5y ago

> proprietary bitcode format Apple never documented and only supports in their proprietary fork IIRC, the bitcode format isn't proprietary—it's part of the open-source LLVM. The only issue is that it's not a stable format, so they need to use Apple's LLVM version and not an earlier or later open-source one.

saagarjha 5y ago
Note that there is lowercase-b bitcode, which is part of LLVM, and uppercase-B Bitcode, which is Apple’s thing built on top.
pjmlp 5y ago
Apple uses a special version of LLVM bitcode as deployment format for watchOS and iOS. This variant wasn't and will never be upstreamed.

stephenr 5y ago

As Apple own it anyway, what difference would releasing it as gpl make? They could still do as they like, as it’s theirs. Do they accept significant code from the community? This is why I find the “use agpl” claims about projects run by a company disingenuous- they’re using the licence restriction to prevent competition while they have the freedom to offer “enterprise” editions however they wish.

kmeisthax 5y ago
Apple licenses their software as Apache 2 so a CLA isn't necessary, everyone is free to make proprietary forks. Companies that want to release software as GPL but also sell exceptions or make forks either cannot accept third-party contributions (as then they'd be bound by the contributor's derivative copyright interest in the code) or have to require contributors sign CLAs. Projects with distributed copyright interest and a copyleft license governing all of that, like the Linux kernel, practically cannot relicense or sell exceptions. That's the power of the GPL: everyone has to contribute on a level playing field.
- stephenr 5y ago
  You’re missing the question I asked though. Does Apple accept significant code contributions from outside the project? Because if they don’t, the gpl wouldn’t help. But regardless of that - I think this is the perfect example of the copyleft crowd not understanding the concept of compromise. Apple creates something, releases it as open source but also maintains some private extensions, and the response is: well why didn’t you give it all to us?
  - Qwertious 5y ago
    >Does Apple accept significant code contributions from outside the project? Yes, they do. LLVM has a large number of non-Apple contributors.
lmm 5y ago
> As Apple own it anyway, what difference would releasing it as gpl make? Apple don't own it. They piggyback off a lot of other people's work in LLVM.

twic 5y ago

Even if Apple had basd their watchOS toolchain on GCC, and had published the source code for it, it is quite likely that their fork would have remained separate to upstream: upstream might not care about watchOS support, and Apple's fork might be based on an old version of GCC. In that case, Rust would still have to support two versions.

rodgerd 5y ago

> Had Apple stuck with GCC they wouldn't have the legal ability to do this. They tried. rms lost the email.

pjmlp 5y ago
Yeah, if they actually wanted they would have been a bit more pushy than just shooting an email away.

nemothekid 5y ago

>Rust has to support the current version of Apple's LLVM fork as well as the LLVM they ship with specifically just so you can compile watchOS apps, since that platform requires a proprietary bitcode format Apple never documented and only supports in their proprietary fork. I'm not sure I follow. Apple's LLVM fork could open source and Rust would still have to support two LLVMs if the WatchOS code wasn't upstreamed. Apple has no responsibility to upstream code on the GPL, nor do the LLVM maintainers. Given that Apple's bitcode would be proprietary / undocumented (GPL doesn't require you to document your code), it would take a dedicated individual to make sure the two projects are in sync. If Apple isn't doing that now, I'm not convinced they would do it under GPL.

kmeisthax 5y ago
Rust has it's own (Free) LLVM fork, too. If the watchOS/iOS Bitcode format were Free, they could merge that into their own LLVM instead of having to support two slightly-different compiler backends. The GPL would legally require Apple to publish source code for all LLVM forks they make, if they accepted third-party contributions under GPL terms. It doesn't require them to upstream it anywhere, you just have to let someone else do it.