This seems totally reasonable to me, honestly. Guess what, companies building your product on top of high-quality FOSS software? Turnabout is fair play. If we're going to rot our software infrastructure to it's soul by adding endless SaaS subscriptions to everything, then why shouldn't FOSS developers get in on the fun? This is the software dystopia we've created, where marginal-utility products get built on the backbreaking work of unpaid contributors. If they don't like it, they can fork the AGPL version or use a different linker.
It's a very dog-eat-dog play, but realistically this is what our software industry has turned into. IMO, it's honorable to defend both your individual users and FOSS community while also charging your corporate users for the support they expect.
The FOSS label is an extremely powerful statement and draws in lots of users. To switch the license is very poor taste in my opinion, and not much different from a bait-and-switch.
It should be a maintainers responsibility to be very clear about their goals for this project. I feel that they jumped the full-time gun too quickly, and now users will be paying for it
But it's not a bait and switch because we don't have a right to his future work under whatever license we like. Imagine the developer was hit by a bus right now, or became a cloistered monk. Same difference.
If commercial entities can do it, so can the FOSS community.
It sucks. Whats happening now isnt fine. I wish so much the world could recognize value & merit & allocate some support for it.
But all the rationalization in the world doesnt change the base truth that this plan would mean death.
Sure, it doesn't sound like that's their goal
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.
Second I'm not sure the value proposition is great enough to warrant corporate payments. As awesome as mold and its performance savings are, I don't think they even register on the dashboard of corporations. Maybe a few companies selling build pipeline services could be persuaded, like Github and Gitlab, But for those I think it would make more sense to talk to them and get them to give money voluntarily.
In my experience companies don't just give you money. They do it if they are acutely aware of a problem, like when OpenSSL turned out to be massively underfunded and lots of corporations realized they are dependent on it. I don't think any company is dependent enough on mold yet.
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.
Also AGPL is already pretty restrictive. Are you sure there are corporations ripping you off? Could it be that they just never even heard of mold?
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.)
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.
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.
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.
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.
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.
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.
1) Whether or not we could get finance to pay for a license, we would not be willing to force the rest of our community to pay.
2) What is a "user"? A developer seat? What if CI / CD has a public facing github queue? Are people submitting PRs users? Do end users of our service count?
I'd strongly suggest a "call for pricing" model until you have good answers to the above. (Good == what the market will bear; figuring out will require you to initiate run ~ 100 customer calls).
Also, why revert to GPL, not AGPL3 or Apache? GPL is a weird middle ground these days. "Some users get Freedom, but unlike with AGPL, Google, AWS and *aaS users get to pound sand. Also, unlike Apache, maybe we will patent troll you later."
This stuff is hard. Good luck!
If the main developer died, would you feel the need to immediately switch off of it? Is anyone even tracking the liveliness of the developer in your org?
It is a commodity (there are other linkers), and the main reason to use it is developer productivity. Using a fast, bitrotting and unsupported linker is worse than using a slow, up-to-date linker.
We'd probably wait one release cycle to switch (maybe the replacement linker introduces bugs or something.)
Having said that, there is a clear line from "linking is 5x faster" to $10-100K annual savings for the business, so I'd support paying a substantial license fee. (I do not hold the purse strings, so that doesn't matter in my current gig.)
EDIT: I found this in the linked blog post:
> I can change the license (or sublicense) because I wrote almost all the code myself, and all remaining patches to mold are licensed under the dual license of MIT/AGPL.
He's wrong about that. That MIT license is not an attribution of copyright, which is what he needs to relicense external contributions.
This is why corporate-run projects make you sign a CLA where you renounce copyright. This is why GPL licenses have an "any later version" formula, to allow project owners to move to a newer version of the GPL license later on.
(Technically, the MIT license also grants the right to sublicense, so he actually could change the license, but only if the new license incorporated the MIT license's attribution requirement. Probably. The license is vague and I'm not a lawyer.)
That said, I personally don't see it being successful if this is done, and my suspicion is it might even be forked so an open source version could remain. It sucks that they aren't making any money, but I don't think this type of project works in any model except open source anymore. I could be wrong and hope for the sake of the author that I am.
https://docs.google.com/document/d/1kiW9qmNlJ9oQZM6r5o4_N54s...
>A major obstacle in getting financial support is most companies don't have an internal process to start funding an open-source project. If they need to buy a license, that's fine, that's part of their usual business. But supporting (or giving money away to) "free" software is almost impossible. It raises too many questions at every level of management. What is the accounting item it should be categorized to? Is there any legal implication? Who can approve it in the first place? And last but not least, why do they have to do it if it's available for free?
I would think you could work around many of these problems without going source-available. You could simply sell licenses to people despite already handing out an open source license for free (the sqlite approach iirc). Since the project is apparently otherwise AGPL licensed, I would think businesses would be quite open to receiving a normal commercial license instead. To sweeten the deal further, you could come up with some list of enterprise features that would be uniquely available in the commercial variant.
As a risk of using the BSL, I would cite the danger of the project becoming less popular among average developers, an effect that might compound in the long term ultimately killing the project. I don't personally use mold, so I don't know how strong this effect would be.
It would be much easier to be able to go to my manager with that kind of information. Right now the conversation goes:
"Hey, this linker could save us quite a bit of time on our enormous executable." "Okay, how much will it cost us?" "Well, there is this site where you can donate on a regular basis."
My big-tech company and my team don't care that build time for a small part of our application is 5 minutes (not a clean build, that would be an hour), so I know they wouldn't pay to save 10 seconds. And linking is not even all of the time to build your application.
From a financial point of view, the fact that the author is in Singapore and has a goal of $10K a month doesn't help.
Mold is an order of magnitude faster.
I agree with you that Mold is an order of magnitude faster than the competition (sometimes). However in that case the absolute value is more representative than the relative number. Your linking time going from 10 seconds to 1 or 2 seconds is only a tiny improvement.
lld is second only to mold in performance. Rui used to work on lld at Google. Apple has a significant investment in ld64 and probably doesn't want to abandon it.
Yep, Facebook and a few people in Google are actually the primary contributors to LLD's MachO support
* for values of "nobody" excluding Google.
Also people, at least those same users, had really strong views on bugs in linkers. If the game is broken because the linker trashed it, you've only worked that out after debugging through your own code and through the compiler output, by which point you're well past patient and understanding.
Sadly for this project I consider linkers to be a fundamental design mistake. Or at least obsolete. Lowering to machine code before combining files wins you runtime overhead and implementation obfuscation in exchange for reduced memory consumption. Linking an intermediate form then writing machine code (in elf if you like) from that single blob is better. I'm pretty sure it can be done in lower memory overhead than linking machine code if you're so inclined.
> Linking an intermediate form then writing machine code (in elf if you like) from that single blob is better. I'm pretty sure it can be done in lower memory overhead than linking machine code if you're so inclined.
[0] https://devblogs.microsoft.com/cppblog/faster-c-iteration-bu...
In practice, switching this kind of thing isn't trivial. The edge cases fall out as build failures. See for example: https://wiki.debian.org/ToolChain/DSOLinking
> don't call it FOSS
The grandparent comment clearly said OSS.
In the case of the Free Software Definition, this makes perfect sense: the FSF wants people to have certain freedoms at work, as well as freedom in their personal lives.
The other challenge is that turning an open source project into a proprietary project isn't as simple as changing the license and asking for money. You need to build an entire business from scratch, and learn to close sales somehow (or sell to consumers). This will take up at least half your time.
Copyright covers four rights, one of them being distribution. It also covers creating derivative works, copying, and public performance. Many licenses based on copyright put restrictions on use; indeed, the BSL (the same license the author is thinking of moving to) does exactly this.
In the case of the GPL, you only need to provide source code to those you distribute the software to; that may be what you're thinking of with respect to distribution, but that's more an artifact of the GPL (and its goals) than copyright.
If you start restricting things by type of use, you need an exceptionally thorough and clear license or you are going to wind up precluding many more people than you intend to.
I'm pretty sure that it is legally enforceable in most jurisdictions, B2B contracts are almost always stronger/more binding than consumer ones (since that protections granted under consumer protection laws are gone, and there is a reasonable presumption that the parties have read and understand the contract). The blurrier part is for sole proprietorships, since it depends on whether their specific jurisdiction considers them as consumers under consumer protection laws (which uniformly weakens contracts to the extent that it does not comply with the guarantees for consumers).
(Note that in most jurisdictions, most "copyright licenses" are considered as contracts. For example, multiple cases in French courts have resolved that GPL2 is considered a contract.)
Also, the license text: https://mariadb.com/bsl11/
In the absence of an enforceable license isn't the default no rights, not all rights? So why would a user make that argument?
This is one model of open core I can get behind: make everything FOSS except compatibility/integration with other non-FOSS things. It's a win-win: if you care about being 100% FOSS, you'd have no use for the proprietary plugin, and conversely, if you do need it, then you're already contaminated anyway.
If you wanted to monetize your project, you should have done it from the beginning with the proper license
Getting exposure and contributions only just to change the terms is just disgusting
[1] - https://arstechnica.com/information-technology/2022/03/sabot...
Also, if you don't like it, fork the last open source version. Your comment reads like "how dare this person not do free work for me!"
"It's even a bit ironic that I had been asked by
several big-name companies when mold/macOS would
become available, since they wanted to use it for their
multi-billion-dollar businesses. But none of them gave
me financial support."
This is kind of a dumb way to run your business.
This is kind of a dumb way to run your business.
It's the tragedy of the commons. Someone, anyone, has to pay for maintenance in the park. If nobody donates, then either the park shuts down or the park has to start charging visitors, and free access disappears.
I have a lot of questions about it too. But it's clear there's something wrong in his business model here.