> Maybe a few companies selling build pipeline services could be persuaded, like Github and Gitlab

The problem is almost all CI/CD jobs use custom docker images bundled with distro provided compiler toolchains.

Replacing linker in CI/CD jobs transparently is extremely hard/impossible/undesirable.

Excellent point, it might run counter to the idea of building exactly as if on that platform! Didn't think of that.

You can package it up yourself, put it in a private repo like JFrog, and build a new Docker image.

> First of all, the usual suspects who rip off high quality open source projects have been known to just create a fork if the license changes (see Amazon and Elasticsearch). If you do this, you have to have the right license from the start.

It's probably not tested in court but I don't think Rui is obligated to continue to provide AGPL for old source code, just because he had before. Perhaps if you could determine when someone became a licensee, you could say that old/existing licensees can continue to use the old terms. But new licensees can be obligated to use new terms.

> I think the author should talk to the Linux foundation or the LLVM foundation and should get them to pay him a stipend or something. With this move he'll probably not help the situation much.

I doubt either of those organizations would fund Rui's work here. But it might be interesting to try and combine efforts with some of the incremental-compile/link ideas in Rust, Zig, and C++.

> Could it be that they just never even heard of mold?

This is likely the case. Maybe it would make sense to advertise it at conferences like OSSNA or similar.

> It's probably not tested in court but I don't think Rui is obligated to continue to provide AGPL for old source code, just because he had before. Perhaps if you could determine when someone became a licensee, you could say that old/existing licensees can continue to use the old terms. But new licensees can be obligated to use new terms.

Any old licensee that holds the source of the old code with the original AGPL license can distribute the code with the original license to anyone else. They have the license to do so.

That is anyone can just press fork on github, and keep distributing all the AGPL versions with the original license.

I wonder if AGPL is exactly the problem. There are certain large corporations that wouldn't touch anything with AGPL, and thus have little incentive to sponsor projects like mold because they see little benefit from it.

Dropping AGPL might be a step in making friends with some corporations while losing some open source friends, but the latter don't pay the bills.

This argument may make superficial sense if you talk about a library, which is not the case here.

The AGPL does not prevent Amazon from linking their proprietary code with mold. It prevents you from selling a linker service that is built on mold without giving people the source code to mold.

My understanding of AGPL is that Amazon wouldn't even have to open source their service. So the license is not in the way of commercial exploitation.

In fact, OP makes exactly that point, that he is thinking about needing a more restrictive license, not a less restrictive one.

As an example of a company that doesn't touch AGPL, Google's policy is to "maintain an aggressively-broad ban on all AGPL software": https://opensource.google/documentation/reference/using/agpl...

They make it sound like some kind of deadly disease.

It seems that this is why the author (ex-googler) chose AGPL. It's FLOSS but also works as a barrier for them.

> My understanding of AGPL is that Amazon wouldn't even have to open source their service. So the license is not in the way of commercial exploitation.

There's no linking exception in the AGPL. As Google says, the risk is clear.

    "The primary risk presented by AGPL is that any product or service 
     that depends on AGPL-licensed code, or includes anything copied 
     or derived from AGPL-licensed code, may be subject to the virality 
     of the AGPL license. [1]"

IANAL, but some will go further and say that merely looking at AGPL code would be enough to trigger the license, since at some point you could "derive" things from the AGPL'd code base which could then taint every other closed source SaaS project you work on.

This could happen if you wrote an closed source alternative to the original AGPL'd project, and wondered how a particular algorithm was written, e.g.

[1] https://opensource.google/documentation/reference/using/agpl...

Using mold to link your binaries is not the same as linking mold itself. GCC is GPL'ed, but things compiled with GCC are not.

I think it's worth pointing out that regardless of what is true or not true, Google has spelled out their interpretation, and their explicit and (exact quote) "aggressively-broad ban" on use of AGPL software within Google.

Beyond the legal implications of software, there are social ones too. I admit that I'm reluctant to use AGPL software when a differently licensed alternative is available, just out of a general stigma around it. I'm not defending that stigma, far from it, but I think it's fair to point it out, and point out that big corporations like Google are very, very allergic to AGPL (whether it's legally warranted or not)

AGPL only differs from GPL with regard to services provided over networks, which doesn't really apply here. Beyond that, AGPL is no more viral than GPL. So "there's no linking exception in the AGPL" is really irrelevant considering that there isn't one in GPL either, and I'm sure Google uses GCC.

Yes, there's a stigma against AGPL, but a blanket policy against using AGPL'ed software will occasionally ban something totally unproblematic, which is the case here.

>This argument may make superficial sense if you talk about a library, which is not the case here.

That is only the case if you are thinking it as a programmer.

The company doesn't want anything AGPL. It doesn't matter where you grant special permission, or your product fits the AGPL like what you describe. The company wants ZERO AGPL.

It is also not about what APGL said, or what you think APGL said, or what the court and lawyer thinks AGPL said. They dont want AGPL. Full Stop.

He is specifically explaining that big companies are using his code. They are not afraid of AGPL but they just don't want to pay him

Didn't the author already sell exceptions to the AGPL? If companies that refused to use AGPL wouldn't just buy one of them, why would they pay him under his new scheme?

> First of all, the usual suspects who rip off high quality open source projects have been known to just create a fork if the license changes (see Amazon and Elasticsearch).

Your moral connotations are backwards. Elastic did a bad thing by changing their product from a FOSS license to a proprietary license. Amazon did a good thing by forking the last FOSS version and maintaining that one. (Yes, it's weird to think of Amazon as the good guy, but even a stopped clock is right twice a day.)

I know various companies have been looking into sponsoring his work for iOS, since it can make a big difference in the edit/build/run cycle since linking times can be fairly high. I was even personally supporting it for those reasons for a number of months.

From what I understand, it is part way there to fully supporting what is needed on macOS/iOS, but then it is hard to throw money at it when it isn’t a replacement yet, especially since sponsorship isn’t guaranteeing work goes into your needs.

So sort of a chicken and egg situation. Recently it seems work has been focused on some mainframe architectures, and I wasn’t actually using it at all, so I stopped sponsoring.

All this to say is that it isn’t specific to mold, but open source projects in general. If the source is available and it works, there is no incentive to sponsor, and if it doesn’t yet do what you want, there isn’t a guarantee that your sponsorship will move the needle.