9 ms·

Mold linker: targeting macOS/iOS now requires a commercial license

145 points by Kukumber 4y ago

IshKebab 4y ago
Well fair enough if they're trying to make enough money for this to be a business. I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.) But I hope we don't see any tedious comments here about how this is a moral outrage because all software should be fr£e. Also `sold` is a genius name.
- spockz 4y ago
  I don’t necessarily think software should be free. Info think that it is beneficial for discovery and for use of the software itself is for free. Exactly for the reason you mention, the administrative burden of paying for a license. Having to understand what it means if I want to run the software on build servers/ci/cd. How do I get lelicense files there etc. If it just works and I need to make sure I shell over the appropriate amount for our usecase it will already be easier. If I need to pay up front to see how much real world gain we would get I am much likely not to do it. (Looking at you EE graalvm specifically now.)
- terafo 4y ago
  Isn't compilation mostly linker constrained in realistic scenarios? I mean first compilation time is quite long, but then it's often linker who is to blame for most of the compile time.
  - jupp0r 4y ago
    It depends. Optimized production builds are dominated by compile times but developer local builds are mostly only compiling a hand full of files but need to link the whole binary (other compilation objects can be reused as they have already been compiled in the past and haven't changed).
  - _0w8t 4y ago
    Chromium build time after changing a single source file is about a minute completely dominated by link time. And this is with a development component build when most of the code is split into separated DLLs.
- LukeShu 4y ago
  > But I hope we don't see any tedious comments here about how this is a moral outrage because all software should be fr£e. All software should be free-as-in-freedom, but not nescessarily free-as-in-£; though I acknowledge that the former without the latter is often problematic. Plus, even beyond the "moral should", practically speaking, going non-FOSS this means it gets excluded from GNU/Linux distro packages, which IMO would be a fatal hit for something like this. But honestly, I'm fine with this move. It's still FOSS for FOSS-systems, while support for non-FOSS systems is non-FOSS. The folks who care about free-as-in-freedom won't be affected by this. And even then, the non-FOSS `sold` is source-available, which covers 3 of the 4 freedoms; and IMO that missing freedom is the least important. > I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.) A reasonable amount of software is "free-as-in-£ for personal use, paid for professional use." Lots of orgs are willing to ask individual devs "are there any dev tools you use that we should be paying for" and are willing to pay the $50/mo for IntelliJ, so $10/mo for `sold` seems to me like it stands a chance? Note that `sold` is still free-as-in-£ for use in CI/CD, and is only paid for individual-developer use.
  - rav 4y ago
    > Note that `sold` is still free-as-in-£ for use in CI/CD The relevant part of the EULA [1] states: > Individuals who use the Software only occasionally, or non-interactive use of the Software that is not explicitly invoked by an individual such as CI/CD (continuous integration/continuous delivery), are not considered Active Interactive-use Users ("AIUs"). No additional fees are required for such uses. I had to read it multiple times to understand the CI/CD bit. It's not clear to me whether the EULA says that CI/CD is an example of "use that is explicitly invoked by an individual" or if it's an example of "non-interactive use that is not explicitly invoked by an individual" - the wording is unclear to me and can have either of the opposite interpretations. At my day job, we occasionally test C++ code changes by compiling in a CI/CD system to obtain a container image that we can push into a staging environment. This means we have a develop-compile-test cycle where the "compile" step involves pushing to a merge request branch, waiting for CI/CD to finish, and then running a deploy script to push out the newly-built image for testing. I wonder if this would be considered "Active Interactive-use Use" or not. [1] https://github.com/bluewhalesystems/sold/blob/main/LICENSE.md https://github.com/bluewhalesystems/sold/blob/main/LICENSE.m...
- wyldfire 4y ago
  Apple themselves could take note and decide to negotiate a license for the sake of their customers. Businesses are often willing to pay for something that would ordinarily take an R&D team some NRE to develop. And Apple has a great deal of money. They could free it up for adventurous customers as soon as they negoiate terms. And the amount of work it would take to integrate it into the next generation of XCode (as a tested/verified alternative to ld64 via -fuse-ld=mold) would probably be pretty modest.
  - saagarjha 4y ago
    Apple would probably prefer to improve ld64?
- asveikau 4y ago
  > this is a moral outrage because all software should be fr£ Forget that for a moment. Economically speaking, there's tons of free competition and it doesn't have any real problems. That means the market price for a linker is $0. As you point out, people aren't going to pay for a faster one.
- Incipient 4y ago
  The only "moral outrage" here would be if they released experimental code (as they called it) into the gpl version, got people to test out, make prs for it, then yanked it out before it was complete and moved out to the paid version. No clue how it actually went here.
- kvakvs 4y ago
  Businesses may be not constrained with the link times, but they for sure are worried with growing executable sizes. And large dev teams rarely reduce the code size, they just keep adding layers and layers of code as the time goes, eventually running beyond the permissible app size on the appstore. Can it solve such growth problem? Many large companies will be "sold" on this idea instantly https://twitter.com/stantwinb/status/1336890442768547845 https://twitter.com/stantwinb/status/1336890442768547845
- mariusor 4y ago
  There's at least one compiler whose developers are complaining about the slow speeds of LLVM's linker. As far as I remember the only thing keeping them from using mold was the absence of a Windows version. Why they didn't sponsor it though, I'm not sure, it looks like Rui would take on some paid work.
- inkyoto 4y ago
  > How many businesses are so constrained by link times on Mac […] Long link times are not specific to OS X / iOS. Large C++ codebases are some of the worst offenders and emit obscene numbers of relocations and DWARF symbols (or similar) into object files that bog linkers down. KDE, Firefox and Chrome browsers instantly come to mind. Rust and GHC generated object files also take a whiiiiiiiile to link[0]. On the businesses being constrainted by the link times subject more specifically. Über posted an article a while back enunciating the shenanigans they have to go through to build their iOS app (the app download at some point measured in a 300Mb+ vicinity): https://www.uber.com/en-GB/blog/how-uber-deals-with-large-ios-app-size/ https://www.uber.com/en-GB/blog/how-uber-deals-with-large-io... . From the «Build Times» section of the blog post: > The default pipeline builds the app in 21 minutes; the new pipeline with no machine outlining takes 53 minutes, which includes about 7 minutes of llvm-link, 14 minutes opt, 11 minutes of llc and 3 minutes of the system linker. One round of outlining takes about 7 minutes in llc, and 2 rounds take 9 minutes. Each additional round adds progressively less extra time, usually under 30 seconds. Overall, 5 rounds of outlining builds in 66 minutes — a 45-minutes addition to the baseline. So, a default CI/CD build with no outlining heuristics applied spends 10 mins (7 + 3) out of a total of 53 mins in the linker. That is for a single CI/CD run. And, since at least company has funded the work on fixing relocatable file generation in mold, there is indeed at least some demand: > GHC (Glasgow Haskell Compiler) in particular uses re-linkable object files as dynamic libraries instead of real .so files, and it didn't work with mold. Now, mold can produce object files that GHC can load. Note that this work was funded by Mercury, so thanks to the company to help us improve the product. [0] Fun fact: I have measured the memory throughput at the GHC linking time (via LLVM lld); it averages 65Gb/sec, and it can occasionally shoot over 70Gb/sec. So a faster linker still matters.
catiopatio 4y ago
That’s an interesting business direction to attempt — it’s not as if Apple’s linker is lacking in any particularly obvious way.
- rafram 4y ago
  mold is very, very fast.
  - sacnoradhq 4y ago
    Doesn't matter how fast or amazing it is if no one wants to use it.
    - Grimburger 4y ago
      What monetary value would you place on hours of compile time daily holding up your dev team?
      - sacnoradhq 4y ago
        Why would CI/CD hold up a dev team if it's done asynchronously? What kind of dev team doesn't multitask? Apart from edge-cases involving linking large projects synchronously, there's no competitive advantage and the feature set is far less than lld, bfd, or even gold. It's a niche "product" most people don't need.
        terafo 4y ago
        Why do you assume that compilation only happens in CI/CD?
        sacnoradhq 4y ago
        Because professionals don't wait around synchronously for local builds when they can do distributed builds async.
carterschonwald 4y ago
I remember reading that something related to function sections wasn’t supported? If it actually works as an alternative linker option for static linked Haskell builds using ghc on osx I will happily pay for this. But I need more info about the suport surface area they are committing to!
sacnoradhq 4y ago
[flagged]
deleted 4y ago
[deleted]
pdpi 4y ago
Given than mold is developed under the AGPL, I wonder if this move will lead to a fork for those people who don't want to a commercial licence
- TAForObvReasons 4y ago
  or the core ideas from mold [1] make their way to gold and other linkers. [1] https://github.com/rui314/mold/blob/main/docs/design.md https://github.com/rui314/mold/blob/main/docs/design.md
  - matthews2 4y ago
    gold is dead. lld (which the author of mold also contributes to) is adopting some of the ideas from mold.
up2isomorphism 4y ago
AGPL for a linker? No thanks.
poulpy123 4y ago
I'm nzithze using linkers or macos, what is the rationale of selling it just for macos ?
- fragmede 4y ago
  Because that's where the money is. Linux users are going to scream bloody murder and Windows users are just going to put up with it being slow.
up2isomorphism 4y ago
Since some people are down voting my post without given a reason, let me ask this here? Why should I forgo all the robustness that gnu ld gives me and use an AGPL linker to save some cpu cycle while relying perhaps my most important build component on this thing? No, thanks. And no amount of downvotes will help that , either.
- insanitybit 4y ago
  That's pretty well addressed by the readme
- sagarm 4y ago
  If incremental compiles aren't part of your development cycle, I guess you aren't in the target audience.
csomar 4y ago
Honestly, kudos for the author. This seems to be a one man's effort (https://github.com/rui314 https://github.com/rui314). He is making a free (as in money and freedom) AGPL product for general purpose usage (linux) and he is selling a particular integration for a particular audience (mac users). I honestly hope he succeeds in this endeavor. It shows you can do a one-person open source project and still live off of it.
- pjmlp 4y ago
  He almost gave up, if it wasn't for Uber's sponsoring the project. https://twitter.com/rui314/status/1593464571586830336 https://twitter.com/rui314/status/1593464571586830336 See Licensing on https://github.com/rui314/mold/releases/tag/v1.7.0 https://github.com/rui314/mold/releases/tag/v1.7.0
bananapub 4y ago
when did github stop requiring code they hosted to open source, anyway?
- 411111111111111 4y ago
  That was never a requirement.
- croes 4y ago
  You couldn't make private repositories on the free tier, so they were either public or you paid.
eps 4y ago
I see no problem with the switch to a commercial license, however making it a subscription is a very short-sighted move. This instantly kills a lot of goodwill and puts "sold" into "unavailable" rather than "expensive" bucket.
- fortyseven 4y ago
  I've abandoned some of my favorite tools and libraries because they went to a subscription format. A license for a major version number? And then buy a new license for the next major bump up? Okay fine. But a never-ending fire hose of money coming out of my bank account is big nope. I have enough small monthly recurring charges, thanks.
  - temp2022account 4y ago
    I'm a huge fan of SublimeText the editor, but not a huge fan of SublimeText the company behind it. The balancing act they did was sell licenses that are good for an entire major version (eg SublimeText 2, 3, etc.) that never expire. I'm comfortable enough to pay $50 for a good IDE major version even though I dislike the company's development direction (eg, I'm probably not going to buy SublimeText 4 because of the plugin chaos). EDIT: "Sublime Text license keys are no longer tied to a single major version, instead they are now valid for all updates within 3 years of purchase" - looks like I'm a pirate then.
    - eps 4y ago
      > looks like I'm a pirate then. Why? This is an altogether better arrangement unless they take over 3 years to release the next major version.
pachouli-please 4y ago
get that bread

145 points by Kukumber 4y ago

Well fair enough if they're trying to make enough money for this to be a business. I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.) But I hope we don't see any tedious comments here about how this is a moral outrage because all software should be fr£e. Also `sold` is a genius name.

spockz 4y ago
I don’t necessarily think software should be free. Info think that it is beneficial for discovery and for use of the software itself is for free. Exactly for the reason you mention, the administrative burden of paying for a license. Having to understand what it means if I want to run the software on build servers/ci/cd. How do I get lelicense files there etc. If it just works and I need to make sure I shell over the appropriate amount for our usecase it will already be easier. If I need to pay up front to see how much real world gain we would get I am much likely not to do it. (Looking at you EE graalvm specifically now.)
terafo 4y ago
Isn't compilation mostly linker constrained in realistic scenarios? I mean first compilation time is quite long, but then it's often linker who is to blame for most of the compile time.
- jupp0r 4y ago
  It depends. Optimized production builds are dominated by compile times but developer local builds are mostly only compiling a hand full of files but need to link the whole binary (other compilation objects can be reused as they have already been compiled in the past and haven't changed).
- _0w8t 4y ago
  Chromium build time after changing a single source file is about a minute completely dominated by link time. And this is with a development component build when most of the code is split into separated DLLs.
LukeShu 4y ago
> But I hope we don't see any tedious comments here about how this is a moral outrage because all software should be fr£e. All software should be free-as-in-freedom, but not nescessarily free-as-in-£; though I acknowledge that the former without the latter is often problematic. Plus, even beyond the "moral should", practically speaking, going non-FOSS this means it gets excluded from GNU/Linux distro packages, which IMO would be a fatal hit for something like this. But honestly, I'm fine with this move. It's still FOSS for FOSS-systems, while support for non-FOSS systems is non-FOSS. The folks who care about free-as-in-freedom won't be affected by this. And even then, the non-FOSS `sold` is source-available, which covers 3 of the 4 freedoms; and IMO that missing freedom is the least important. > I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.) A reasonable amount of software is "free-as-in-£ for personal use, paid for professional use." Lots of orgs are willing to ask individual devs "are there any dev tools you use that we should be paying for" and are willing to pay the $50/mo for IntelliJ, so $10/mo for `sold` seems to me like it stands a chance? Note that `sold` is still free-as-in-£ for use in CI/CD, and is only paid for individual-developer use.
- rav 4y ago
  > Note that `sold` is still free-as-in-£ for use in CI/CD The relevant part of the EULA [1] states: > Individuals who use the Software only occasionally, or non-interactive use of the Software that is not explicitly invoked by an individual such as CI/CD (continuous integration/continuous delivery), are not considered Active Interactive-use Users ("AIUs"). No additional fees are required for such uses. I had to read it multiple times to understand the CI/CD bit. It's not clear to me whether the EULA says that CI/CD is an example of "use that is explicitly invoked by an individual" or if it's an example of "non-interactive use that is not explicitly invoked by an individual" - the wording is unclear to me and can have either of the opposite interpretations. At my day job, we occasionally test C++ code changes by compiling in a CI/CD system to obtain a container image that we can push into a staging environment. This means we have a develop-compile-test cycle where the "compile" step involves pushing to a merge request branch, waiting for CI/CD to finish, and then running a deploy script to push out the newly-built image for testing. I wonder if this would be considered "Active Interactive-use Use" or not. [1] https://github.com/bluewhalesystems/sold/blob/main/LICENSE.md https://github.com/bluewhalesystems/sold/blob/main/LICENSE.m...
wyldfire 4y ago
Apple themselves could take note and decide to negotiate a license for the sake of their customers. Businesses are often willing to pay for something that would ordinarily take an R&D team some NRE to develop. And Apple has a great deal of money. They could free it up for adventurous customers as soon as they negoiate terms. And the amount of work it would take to integrate it into the next generation of XCode (as a tested/verified alternative to ld64 via -fuse-ld=mold) would probably be pretty modest.
- saagarjha 4y ago
  Apple would probably prefer to improve ld64?
asveikau 4y ago
> this is a moral outrage because all software should be fr£ Forget that for a moment. Economically speaking, there's tons of free competition and it doesn't have any real problems. That means the market price for a linker is $0. As you point out, people aren't going to pay for a faster one.
Incipient 4y ago
The only "moral outrage" here would be if they released experimental code (as they called it) into the gpl version, got people to test out, make prs for it, then yanked it out before it was complete and moved out to the paid version. No clue how it actually went here.
kvakvs 4y ago
Businesses may be not constrained with the link times, but they for sure are worried with growing executable sizes. And large dev teams rarely reduce the code size, they just keep adding layers and layers of code as the time goes, eventually running beyond the permissible app size on the appstore. Can it solve such growth problem? Many large companies will be "sold" on this idea instantly https://twitter.com/stantwinb/status/1336890442768547845 https://twitter.com/stantwinb/status/1336890442768547845
mariusor 4y ago
There's at least one compiler whose developers are complaining about the slow speeds of LLVM's linker. As far as I remember the only thing keeping them from using mold was the absence of a Windows version. Why they didn't sponsor it though, I'm not sure, it looks like Rui would take on some paid work.
inkyoto 4y ago
> How many businesses are so constrained by link times on Mac […] Long link times are not specific to OS X / iOS. Large C++ codebases are some of the worst offenders and emit obscene numbers of relocations and DWARF symbols (or similar) into object files that bog linkers down. KDE, Firefox and Chrome browsers instantly come to mind. Rust and GHC generated object files also take a whiiiiiiiile to link[0]. On the businesses being constrainted by the link times subject more specifically. Über posted an article a while back enunciating the shenanigans they have to go through to build their iOS app (the app download at some point measured in a 300Mb+ vicinity): https://www.uber.com/en-GB/blog/how-uber-deals-with-large-ios-app-size/ https://www.uber.com/en-GB/blog/how-uber-deals-with-large-io... . From the «Build Times» section of the blog post: > The default pipeline builds the app in 21 minutes; the new pipeline with no machine outlining takes 53 minutes, which includes about 7 minutes of llvm-link, 14 minutes opt, 11 minutes of llc and 3 minutes of the system linker. One round of outlining takes about 7 minutes in llc, and 2 rounds take 9 minutes. Each additional round adds progressively less extra time, usually under 30 seconds. Overall, 5 rounds of outlining builds in 66 minutes — a 45-minutes addition to the baseline. So, a default CI/CD build with no outlining heuristics applied spends 10 mins (7 + 3) out of a total of 53 mins in the linker. That is for a single CI/CD run. And, since at least company has funded the work on fixing relocatable file generation in mold, there is indeed at least some demand: > GHC (Glasgow Haskell Compiler) in particular uses re-linkable object files as dynamic libraries instead of real .so files, and it didn't work with mold. Now, mold can produce object files that GHC can load. Note that this work was funded by Mercury, so thanks to the company to help us improve the product. [0] Fun fact: I have measured the memory throughput at the GHC linking time (via LLVM lld); it averages 65Gb/sec, and it can occasionally shoot over 70Gb/sec. So a faster linker still matters.

catiopatio 4y ago

That’s an interesting business direction to attempt — it’s not as if Apple’s linker is lacking in any particularly obvious way.

rafram 4y ago
mold is very, very fast.
- sacnoradhq 4y ago
  Doesn't matter how fast or amazing it is if no one wants to use it.
  - Grimburger 4y ago
    What monetary value would you place on hours of compile time daily holding up your dev team?
    - sacnoradhq 4y ago
      Why would CI/CD hold up a dev team if it's done asynchronously? What kind of dev team doesn't multitask? Apart from edge-cases involving linking large projects synchronously, there's no competitive advantage and the feature set is far less than lld, bfd, or even gold. It's a niche "product" most people don't need.
      - terafo 4y ago
        Why do you assume that compilation only happens in CI/CD?
        sacnoradhq 4y ago
        Because professionals don't wait around synchronously for local builds when they can do distributed builds async.

carterschonwald 4y ago

I remember reading that something related to function sections wasn’t supported? If it actually works as an alternative linker option for static linked Haskell builds using ghc on osx I will happily pay for this. But I need more info about the suport surface area they are committing to!

sacnoradhq 4y ago

[flagged]

deleted 4y ago

[deleted]

pdpi 4y ago

Given than mold is developed under the AGPL, I wonder if this move will lead to a fork for those people who don't want to a commercial licence

TAForObvReasons 4y ago
or the core ideas from mold [1] make their way to gold and other linkers. [1] https://github.com/rui314/mold/blob/main/docs/design.md https://github.com/rui314/mold/blob/main/docs/design.md
- matthews2 4y ago
  gold is dead. lld (which the author of mold also contributes to) is adopting some of the ideas from mold.

up2isomorphism 4y ago

AGPL for a linker? No thanks.

poulpy123 4y ago

I'm nzithze using linkers or macos, what is the rationale of selling it just for macos ?

fragmede 4y ago
Because that's where the money is. Linux users are going to scream bloody murder and Windows users are just going to put up with it being slow.

up2isomorphism 4y ago

Since some people are down voting my post without given a reason, let me ask this here? Why should I forgo all the robustness that gnu ld gives me and use an AGPL linker to save some cpu cycle while relying perhaps my most important build component on this thing? No, thanks. And no amount of downvotes will help that , either.

insanitybit 4y ago
That's pretty well addressed by the readme
sagarm 4y ago
If incremental compiles aren't part of your development cycle, I guess you aren't in the target audience.

csomar 4y ago

Honestly, kudos for the author. This seems to be a one man's effort (https://github.com/rui314 https://github.com/rui314). He is making a free (as in money and freedom) AGPL product for general purpose usage (linux) and he is selling a particular integration for a particular audience (mac users). I honestly hope he succeeds in this endeavor. It shows you can do a one-person open source project and still live off of it.

pjmlp 4y ago
He almost gave up, if it wasn't for Uber's sponsoring the project. https://twitter.com/rui314/status/1593464571586830336 https://twitter.com/rui314/status/1593464571586830336 See Licensing on https://github.com/rui314/mold/releases/tag/v1.7.0 https://github.com/rui314/mold/releases/tag/v1.7.0

bananapub 4y ago

when did github stop requiring code they hosted to open source, anyway?

411111111111111 4y ago
That was never a requirement.
croes 4y ago
You couldn't make private repositories on the free tier, so they were either public or you paid.

eps 4y ago

I see no problem with the switch to a commercial license, however making it a subscription is a very short-sighted move. This instantly kills a lot of goodwill and puts "sold" into "unavailable" rather than "expensive" bucket.

fortyseven 4y ago
I've abandoned some of my favorite tools and libraries because they went to a subscription format. A license for a major version number? And then buy a new license for the next major bump up? Okay fine. But a never-ending fire hose of money coming out of my bank account is big nope. I have enough small monthly recurring charges, thanks.
- temp2022account 4y ago
  I'm a huge fan of SublimeText the editor, but not a huge fan of SublimeText the company behind it. The balancing act they did was sell licenses that are good for an entire major version (eg SublimeText 2, 3, etc.) that never expire. I'm comfortable enough to pay $50 for a good IDE major version even though I dislike the company's development direction (eg, I'm probably not going to buy SublimeText 4 because of the plugin chaos). EDIT: "Sublime Text license keys are no longer tied to a single major version, instead they are now valid for all updates within 3 years of purchase" - looks like I'm a pirate then.
  - eps 4y ago
    > looks like I'm a pirate then. Why? This is an altogether better arrangement unless they take over 3 years to release the next major version.

pachouli-please 4y ago

get that bread