Mold linker may not switch to a source-available license

I received lots of responses for my mold 1.7.0 release notes and my docs post (Hacker News, Reddit, and Phoronix). Thank you to everyone who gave me valuable feedback! I also share many of you guys' concerns that switching to a non-open-source license would make many users away from our mold linker. Even though I reserve the right to change the license, I agree that that’s a real concern.

The problem boils down to how to keep it open-source while making for-profit companies pay for it. Switching to a commercial license is an idea to make the project profitable and viable. I want to share another idea in this post to keep it open-source. The proposed scheme is based on commercial and open-source dual licensing. Here is how it works:

  • Commercial license: We sell a commercial license on our website and provide a download link there. Let's call the commercial version of mold sold (pun intended.) mold and sold are two different products, while they work the same except the version strings they embed to an output file. mold embeds “mold x.y.z" while sold embeds "sold x.y.z". sold is a usual commercial developer tool, and its license is nothing special. It would be available under a per-seat per-month license, and you would be able to use it for anything as long as you have purchased a license.

  • Open-source license: mold stays in AGPL, but we claim AGPL propagates to the linker's output. That is, we claim that the output from the linker is a derivative work of the linker. That's a bold claim but not entirely nonsense since the linker copies some code from itself to the an output. Therefore, there's room to claim that the linker's output is a derivative work of the linker, and since the linker is AGPL, the license propagates. I don't know if this claim will hold in court, but just buying a sold license would be much easier than using mold in an AGPL-incompatible way and challenging the claim in court.

    There's one more trick: we don't want to affect the original license if it is already open-source. So we will make an open-source exception: if a linker's output is licensed under an OSI-approved open-source license, you can release it under terms of your choice even if it contains propagated pieces of code of mold. This exception should allow users to use mold for any open-source projects.

    Making an exception to a toolchain’s license isn’t new. GCC for example has such exception. GCC links its runtime code to almost all GCC-generated binaries, and it gives users an exception in addition to GPL so that the compiled binary is not requested to be released under GPL. See GCC Runtime Library Exception for the details.

This dual licensing scheme essentially separates software into two realms: open-source and non-open-source. You can freely use mold for open-source programs, and that doesn't affect your license. If you build a non-open-source program and distribute it or provide a network service with it, you want to purchase a sold license.

I’m not a lawyer, so I’m not entirely sure the above scheme works as I intended. There’s also an obvious loophole. If you use mold to link a program, license the result to someone else with a permissive license such as MIT, and that party releases it under a proprietary license, we can’t stop it. But that’s probably fine.

Let me know what you guys think. Thanks!

Rui Ueyama