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.
> 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.
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.
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?
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.