Mold linker creator considers changing the license | Hacker News Reader

Mold linker creator considers changing the license

twitter.com

51 pointsmshockwave19 comments

Everywhere I worked getting a commercial license for software was only a matter of asking IT or filing an expense. OTOH from position of an employee getting the company to donate any amount of money was nearly impossible. There's no process for it. There's nobody responsible for doing it. Legal/Accounting will have a ton of questions about (why? is it taxable? where's the paper trail?). The quickest route may be through Marketing dept, but then it's viewed as an ad/sponsorship.

All seems like reasonable points, it's highly project-dependant but since switching to mold I've seen solid overall speedups. If I was to put a saved time value on that for me alone it would be huge. At $1200/month in donations for full time work, the value large companies get out of it is huge.

The actual meat of the title buried down in the tweets:

> Given this situation, I'm seriously considering changing the mold/macOS license (not mold/Unix license) from AGPL to a commercial, source-available one. Something like individuals would be able to use it for free but companies have to pay.

It‘s incredibly sad that companies worth literal trillions of dollars don‘t have a couple thousand dollars to spare for open source developers who create insanely valuable software for their employees. I remember that brew‘s (the defacto standard macos package management tool) maintainer had similar projects in the past.

Bad tools grind operations to a halt and feel incredibly dissatisfying to work with. Mold is insanely fast and pushing further in a problem space (linking) that can‘t be avoided and has in the past been dominated by slow tooling. Corporations save real dollars when their developer uses free software by open source maintainers, but due to their greed and their top heavy management which lacks insight on what speeds up development they give nothing back.

—-

One solution I would propose is that industry giants form a general OSS funding collective, which selects interesting / helpful oss projects and grants funding to their developers.

Perhaps the idea of creating open source hoping that these trillion dollar companies pay you is misguided and naïve.

It's like being an employee and hoping that your boss gives you a raise once in a while. In my experience you have to demand it, and often get it (yet most people are terrified at the idea of doing so), but otherwise the big boss wouldn't try to pay more for something they're already getting (for free).

It's not big business' fault, it's how people behave in general. It's basic human psychology.

If you want to make a living out of your software, don't make it open source, hope it's complex enough you'll get hired as a consultant, or build a company out of your open-source project. Relying on donations it's like busking every day hoping a music executive offers you a record deal.

I've seen far too many brilliant engineers having a hard time scraping by because they have no sense of business. It's a valuable skill to learn.

I think it's probably the right path for Rui (creator and maintainer of mold) to use specific licenses that forces big-tech companies to pay so Mold as a project can be self-sustained long term.

However, this problem showcases a bigger issue on the dev ecosystem. Right now, the sponsorship model force OSS devs have to implore/beg for money from big corps. I think there should be better ways for OSS devs to monetize their projects

I prefer the model of making it properly free and opensource, but charging money for precompiled binaries and a support contract.

I'd add a simple startup banner saying "This program is UNSUPPORTED by @rui314. For a paid supported version, contact foo@bar.com".

The paid support would entitle one access to a forum of other paid support users, where bugs and feature requests can be posted and rui might prioritize them over regular bugs.

Simple approach:

Set up a page saying that support costs a quarter hour of engineering average salary for the country/year/employee who uses Mold. Eg. in a company in the USA, with 30 in the engineering department, that would be $600/yr. Let them know that the license continues to be valid if the company grows during the year.

When a company pays for a license, you give them a license code like "2023-06-Vmware-7676". Tell them to put that code into ~/.mold/license, or to set the env var MOLDLICENSE= to that. The same code lets them into a discussion forum.

When the linker starts, it prints a string saying "Mold Linker, Licensed to Vmware. Support license expires June 2023. See https://github.com/rui314/mold/wiki/support for details".

If there is no license, or the license is expired, it prints "This program is UNSUPPORTED by @rui314. For a paid supported version, see https://github.com/rui314/mold/wiki/support".

But obviously it still works just fine, license or no license.

Does no one else have copyrights preventing a license change? That's one thing I like about contributing to projects (at least those without license assignment), is once you do that the main author(s) can't re-license the project at all without your consent. They could re-write all your code instead, but it at least makes it harder.

That's not entirely true, the "threshold of originality" is relevant. Contributing typofixes or even things like minor non-functional refactorings (i.e. renaming methods or variables) isn't going to qualify as an original contribution. A common mistake is thinking stuff like relicensing is some kind of binary 1-or-0 thing. It's not. It's a legal concern, not a technical one and is therefore subject to many messy human interpretations of ownership, law, et cetera.

In any case it does not matter here because contributing to mold requires your changes to be available under both AGPLv3 and MIT, and so any derivative proprietary works can be considered derivatives of the MIT licensed version. It therefore isn't "changing the existing license", it's "making a proprietary derivative, which the existing license allows."

>> Given this situation, I'm seriously considering changing the mold/macOS license (not mold/Unix license) from AGPL to a commercial, source-available one. Something like individuals would be able to use it for free but companies have to pay.

That is assuming Apple would need to use mold in the first place.

It is probably easier to crowdfund $1-2M from companies and turn the source to MIT or BSD. But then the idea is generally not well received on HN and by its author.

I've donated to FOSS projects before. I have never and will never donate to any proprietary software projects.

Paid software support and seems to be the way to go, but I don't think this really works for this project.

How do GNU and LLVM maintain linkers while staying financially solvent without going proprietary? Why won't the same strategy work in this case?

Companies pay employees to work on them.

If you know of a company who could support Rui, then please let him know.

He was working for Google but he left recently, no? I doubt Google would have any problem if he works on mold linker full time.

I believe he decided to do things this way.. one man show is always problematic (atleast it is easy to go back to lld if anything happens to the author or the project itself)

He doesn't want to work on mold as part of Google or another large company like that because then Google would take ownership of the whole program; he wants to maintain ownership of it. It's mentioned in a tweet of his

Doesn't Google pay people to work on the Linux kernel, even though Google can't take ownership of the whole Linux kernel?

Google owns employee code outside of work if I understand things correctly.

So Google only has copyright over the portions their employees have contributed.

> Part of a reason is because most companies don't have an internal process to start supporting an open-source project. If they need to buy a license, that's fine, that's part of a usual business. But giving money away to "free" software? There's no precedent and hard to justify.

The author already sells licenses, so I am not sure that is the case.

Reply on news.ycombinator.com