"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.
One guy handling support doesn't stop them from using the product on Linux, does it?
Dev is the best quality in the world, as I said. I mean, there's no one who could be better.
If it's cheaper to build by themselves, why they didn't to that already?
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?
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.
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!"
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.
> 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.
Unfortunately, to me this just means the project will probably die. If the author is feeling burnt out and losing money on it, I don't think trying to pivot to a commercial license will help, since as others have mentioned, I don't think many businesses rely on mold specifically, and since the performance gap isn't astronomical, many companies will just drop in lld and be done with it.
At least, that seems likely to me. I guess we might find out?
You will always be able to use the version of Mold right before the license is switched.
They might have an argument against you if the software is at all part of your value chain.
Copyleft grants you the right to make changes and redistribute the resulting work under a compatible license. If you have a problem with CLAs, don't sign them. Many people do not care.
Even without a CLA the author could simply remove contributions and still relicense. This isn't novel, and has been done before.
Obviously it may be difficult to remove contributions.
Why do they pay? As means to drive ecosystems into the products that actually provide money, like cloud, SaaS and hardware, closed source.
What's your point? If Microsoft goes bankrupt, the MS ecosystem would crumble. And so on, ad infinitum. Nothing lasts forever. Since people aren't clairvoyant, they make an effort at evaluating risks vs benefits, and end up continuing to use both MS products and FOSS software.
> Why do they pay? As means to drive ecosystems into the products that actually provide money, like cloud, SaaS and hardware, closed source.
Yes, that's that whole 'commodify your complement' thing I mentioned. But so what? As long as those companies contribute free software that is useful, enjoy the ride. Maybe the current privacy-invading ad funded IT hegemons will fail one day and be replaced by something else, but at least whatever comes next will have a big pool of hopefully useful software to start building on top of.
So yeah, "Open Source won" is one way of saying it, I suppose.
Otherwise I actually agree mold is amazing but have limited commercialization potential unless author expands the scope (like RAD Game Tools) / take some VC money (much like Emerge Tools)
Your example shows the opposite of what you intended to show. It was the people stuck at a particular version of log4j (the old unsupported log4j 1.x branch) who avoided the vulnerability, while the ones who kept up-to-date with the maintained log4j 2.x branch were vulnerable. And it also shows the power of a permissive license: for those stuck at the older log4j 1.x branch, which had been abandoned by its maintainers, there's now a fork by someone else (https://reload4j.qos.ch/) which is being maintained.
But to your credit it does sound that rui saved Google (vastly) more money than they ever paid him.
If I can look at it, that's open source software to me, you can define that phrase however you want and I'm happy with that too :)
http://www.xent.com/FoRK-archive/fall96/0269.html
> an open source code model ... Individuals can use OpenDOS source for personal use at no cost. Individuals and organizations desiring to commercially redistribute Caldera OpenDOS must acquire a license with an associated small fee.
If you asked any reasonable person what the opposite of "closed source" is, you're going to get a uniform answer from the vast majority or respondents, and a small, irritating answer from a small, increasingly irrelevant group group of folks. I understand the distinction that "source available" aspires to achieve, but it's such an unappetizing term of art that you may as well call it "I can't believe it's not open source".
Champagne, Chocolate, Open Source... they're all noble but doomed uphill battles in colloquialism. Everyone knows what you mean.
If you want to be correct, be truly pedantic, instead of shifting the ambiguity: French Champagne, Belgian Chocolate, OSI Approved License.
Don't get me wrong, I'm a diehard FOSS supporter, I sponsor and contribute, I encourage my employers to be good global citizens with respect to FOSS and have complied with licenses by releasing modifications under appropriate licenses. I even pay Drew DeVault money. But ultimately he and everyone else arguing to enshrine the term "open source" will couple the fate of their opinions to that of the OSI and at best, it will all be a footnote in the pages of history.
Will we be using the same OSI approved licenses in 10, 50, 100, 1000 years? Will the OSI permit term "open source" to be used to refer to something other than the current licenses?
As far as I can tell, it's been a success. The recent batch of nonfree licenses have all had to emphasize that they are not open source in the face of public backlash. Making euphemisms like "source available" unappetizing is exactly the point.
Furthermore, the OSI is just a group, as is the FSF. If the OSI and FSF folded tomorrow the definitions of "open source" and "free software" would not change. It's not necessary for the OSI to approve a license for the software to be open source, so "OSI Approved License" is not sufficient. "Licensed on terms compatible with the Open Source Definition" might be more accurate, but "open source" seems like an adequate shorthand.
If instead you keep it in IR and combine that, e.g. llvm-link style, then emit machine code from it you don't need the tables of information for the linker. You can transform debug info before it has been compressed into dwarf. Optionally optimise across translation units. Then finally emit the same format the loader expects.
That should be simpler tooling (compiler & linker don't need the side channel relocation stuff, the linker doesn't need to disassemble and recombine dwarf), faster residual program, faster build times.
It's not totally theoretical either - amdgpu on llvm only passes a single file to the linker at a time, but lld is multi-architecture so doesn't get to delete the combining files code. A machine learning toolchain gave up on calling the linker at one point in favour of doing the data layout from the compiler directly. The latter because lld is/was too annoying to use as a library iiuc.
Whole program optimisation is difficult to do without enough memory. Given machine code linking as how things are done, things like debug info got spliced into the same model. Shared libraries are a similar sort of incremental memory saving scheme.
If he takes people's donation money with the implicit or explicit promise that he's going to make a good-faith effort to continue working on the code, he has a moral obligation to do that IMO. Getting hit by a bus wouldn't be his fault, but choosing to abandon it to become a monk would be.
In the absence of clear language I think it's unreasonable to expect a small amount of money to create an infinite obligation.
I'd expect a donation to be spent on development expenses, including time. I'd expect the developer to continue developing until the money runs out, or return the remaining money.
Imagine you have GitHub sponsorships providing $2,000/month. You use that money to cover all your expenses and work on OSS full time. Everyone stops donating today. Surely you'd get a job and stop working on OSS full time?
Also, Horizon 2027 has about 100 G€ in budget, the more you use it the more you can get. ;)
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]"
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...
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)
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.
> The current system lends itself well to memory constrained systems. Each source/ASM file gets turned into a single binary with just enough metadata to paste it together with another one. It caches nicely too.
Afraid I don't know how long it takes with mold, sorry!
Restrictive covenants on open source licenses might not be consideration, particularly because they apply to the IP licensed in the contract - something that the user/downloader of the software wouldn't have without the contract. In other words, you are giving them rights to use your IP in a few specific ways in exchange for nothing. They need to give up something of value that they wouldn't have otherwise had for it to undeniably be consideration.
Again (https://news.ycombinator.com/item?id=33587891), this is a misconception. Unless there's something in the contract that is outright illegal, mutual consideration automatically binds parties into the contract, but the absence of it does not automatically voids the contract (see one-way NDAs between companies and promissory notes). Worse, you've confused consideration with a monetary value. Consideration don't need to be a monetary value: often, it's performance. This can get confusing because often contracts have a monetary consideration for a performance consideration (for example, paying for mowing the loan), but in this case it has been inverted: for not using it commercially (performance consideration) you can use the IP (monetary consideration).
Courts haven't yet determined which construction is correct.
Edit: I will also add that I said "of value" not "of monetary value." Lots of things with value don't have well-defined monetary value.
> Promissory estoppel/detrimental reliance: A contract without consideration is enforceable if the nonperformance of the promisor will cause injustice. Elements of promissory estoppel are (i) the promise has reasonable, foreseeable, and detrimental reliance on the promisor, and (ii) the enforcement of the promise is necessary to avoid injustice.
In this case, you are nearly correct that the performance to honor the terms of the contract is essential, but technically not a consideration. (The IP code is consideration though.)
I don't think accepting a contract can qualify as consideration for that contract, as otherwise there would never be a need for consideration in any contract.
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.
just like MongoDB https://news.ycombinator.com/item?id=18229013
and docker desktop https://news.ycombinator.com/item?id=28369570
and Elastic Search https://news.ycombinator.com/item?id=25776657
Given the increasing number of restrictions and monetisation efforts for docker hub, I suspect docker desktop at least has not had the immediate effect they hoped.
As for elasticsearch, a lot of projects seem to be adopting a "wait-and-see" approach on the last open version, 7.10, while others have moved to Open Search (e.g. https://docs.graylog.org/docs/installing )
That said, mold I think is a difficult project to monetize broadly for a few reasons, but certainly nowhere close to impossible, and I do believe it's a project that can support a couple developers, with some clients. And I believe it's going to be vastly easier to do that than relying donations and draining your savings account, if I'm being honest, with a bit of experience in this realm.
Let's not tell ourselves lies. Corporate, commercial software development, for money, and licensing software under pay-for-use terms, is how almost all software developers make money. Not by GitHub donations and wishful thinking and pontificating on Hacker News. In fact many of these entities even use open source/free software to accelerate the development of their products, so they can be licensed for the same amount of money, yet they don't contribute anything back — despite the fact their production costs were lower than they would be otherwise. The idea here is to increase the "surplus value" (google it) that they can capture. I will leave readers to think about these words since they are relevant to this discussion and the story of mold.
Most software by far is developed and supported in-house, not sold as a COTS product. For in-house software that doesn't see any broader distribution, the distinction between "open" and "proprietary" is pretty much immaterial. Even the comparatively strict GPL license allows for private modification.
In practice, this usually means, "Do they want to mostly give up coding and learn how to sell to corporations?" It's not necessarily a bad thing! Corporations have money and selling to them can be an interesting challenge.
But it's not a thing that happens easily or automatically, unless you have a product which has achieved an extraordinary level of appeal to customers. It's hard work, and it doesn't necessarily leave time to code.
I agree with you, but this is a controversial opinion which is the root of my frustration. OSI tries really hard to own "open source" as a term and while I'm not against the OSD I am against the gate keeping I see.
Like any person or institution, the OSI is fallible. It's like saying that only a certain organization can define what Red is, and now look what we have with Pantone.
Clang is still relevant because LLVM is great, but as a compiler it's mired in a great deal of political hangups and general pickiness. I don't write C++ for a living, but my experience using the GNU C tooling has been much smoother than Clang and Cmake.
I'll admit that both of those projects aren't exactly dead, but it would be a shame if Microsoft/Google/Apple bought Mold and malformed it to their desires.
The CUPS lead author left Apple a couple of years ago, and CUPS development is now mostly focused on Linux under the auspices of the Openprinting organization. (I understand the CUPS lead author still has some side consulting gig in providing bug fixes to Apples version of CUPS.)
And this is nothing like what Adobe and Pantone did.
The more appropriate analogy would be if the Sugar Free Initiative defined "sugar free" and then you correct me by saying "actually that beverage isn't sugar free, it's artificially sweetened".
The world would be a better, more accessible place if we instead focused on what things are or are not, like preferring "OSI Approved License" over "open source" rather than needlessly conflate complex meaning with otherwise simple terminology.
Sure, let's go with "sugar free". Should I be allowed to decide that it only refers to cane sugar, and so sell food full of HFCS that's labeled as sugar free?