> The new license would be something like individuals can use it for free but corporate users have to pay. mold started as my personal project, and I've been working on this full time for two years so far. I thought that I could earn a comfortable income if mold become popular, but unfortunately, I'm still losing my money. I think I need to take an action to make the project sustainable long term.
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.
In a way, shareware, public domain and demoware have won, after the FOSS hype cycle, as it appears to be the only way to secure a source of income, and not everything can be done via selling support.
Nah, FOSS is going stronger than ever. But just as before, it's the ones that are playing the 'commodify your complement' game that are winning, while those that think that FOSS by itself is a business model are struggling.
> If big boys take out the funding from key projects, meaning stop paying their employees to contribute, everything would crumble.
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.
You think so? I always saw it as Open Source won, and a huge part of it being how RMS is a bit of a repulsive individual even many Free Software proponents are disgusted by. I don't want to sling mud, but some of his stances are not good.
I meant FOSS as in "Free and Open Source Software". Which I would interpret as software licensed under FOSS-compatible licenses, while at the same time not making any statement wrt subscribing to FSF or RMS politics (or RMS opinions on what constitutes rape of a teenager).
So yeah, "Open Source won" is one way of saying it, I suppose.
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
The code he developed will still be licensed under the old license, just going forward new changes won't be. You can fork it right now and keep a FOSS version if you'd like.
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.
> 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 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.
> 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
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?
Sure, I think you don't have an obligation to work forever. Equally I think your moral obligation is not zero. "continue developing until the money runs out, or return the remaining money" sounds like a good answer.
It is a bait and switch, because he will still be still maintaining the software, but under a proprietary license. If he stopped maintaining it altogether (as in your "imagine" examples), then you'd be right that it wouldn't be a bait and switch.
What’s the switch? You have everything he’s done up to this point as FOSS. You could continue to develop it yourself, if you wanted. If you were using the software expecting free updates into perpetuity… that’s on you.
We shouldn’t think of it as a bait-and-switch if nothing was promised. The license applies to the current version. It doesn’t represent a commitment for future versions, and shouldn’t be taken as such.
He tried something. He failed. Sometimes the license has to change even if we don’t want it to. Having the project around in altered form is better than not having it at all.
No it won't. It will be unsupported. Bugs and security vulnerabilities will accrue making it less and less valuable over time. It's funny how the very people whose livelihood depends on perpetual software growth and maintenance are the first ones to claim FOSS is okay stuck at a particular version. Every company keeping their stack stuck on the permissive license is risking a log4j style event in the future.
That's true, but also very much independent from whether a once-free software went non-free or not. Log4j was absolutely a free software when that event happened. The same thing would happen if the maintainer don't see any more value in maintaining an FOSS software (including but not limited to monetary reasons) and stops doing so.
> It will be unsupported. Bugs and security vulnerabilities will accrue making it less and less valuable over time. [...] are the first ones to claim FOSS is okay stuck at a particular version. Every company keeping their stack stuck on the permissive license is risking a log4j style event in the future.
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.
That would be a much more relevant concern if we were talking about a database or library or something. In this particular case, mold is a linker, and I think people here are dramatically overestimating how likely there are to be security vulnerabilities in a linker or how little work is needed to keep it working at it's current level.
The problem in this case isn't with the copyleft licenses. It's with the CLA (i.e., "even though my project is copyleft, if you want to contribute to it, you have to give me a pushover license to your changes too"). Without the CLA, this project would indeed be safe from him doing this.
I'm confused. Copyleft doesn't grant a right to contribute upstream. It's perfectly reasonable for a maintainer of a copyleft project to say "I only accept contributions if you give me $1,000."
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.
It's rare for an important software project to be 100% a one-man show. Combined with the difficulty of removing contributions, wouldn't rejecting CLAs basically keep this kind of thing from happening at all?
That have always been clear from the beginning that is why you get everyone using GNU/Linux instead of the BSDs, although Apple and Sony enjoy using parts of them on their platforms.
I mean, the alternative is that the lead developer runs out of money and just drops the project altogether. If they have an enterprising personality, I see no reason why they shouldn't chase this opportunity as an alternative to letting their project fall apart/get "adopted" by an abusive maintainer.
I think the parent's point is that, if they weren't able to make money off it before, they almost certainly won't by slapping a more restrictive license on it.
I think with the exception of MongoDB, it's too early to ascertain the impact of this on the profitability of these projects.
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 )
No, that's just wishful thinking so FOSS developers can get on a high horse and not look in the mirror. "Seeking donations to support development" and "Making large users pay for a license" are completely different income models. A few licenses for commercial software with ongoing support can easily cover years of community donations, in my experience. Coincidentally, guess which one of those two models is the most successful as far as "allowing independent software developers to support themselves" goes?
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.
> Corporate, commercial software development, for money, and licensing software under pay-for-use terms, is how almost all software developers make money.
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.
That doesn't really end up going well either. There are many such cases where Red Hat/Microsoft/Apple/Facebook/Amazon buys up a sterling young FOSS developer and makes them spend the rest of their life fixing the issues for [PRODUCT] while their project becomes less-and-less relevant by the day (see: CUPS, Clang, Minix).
CUPS is still great but mostly because it's initial implementation was so straightforward. It's existence today is mostly maintenance-mode with a priority for fixing Mac bugs, which is understandable but also occludes the possibility for future improvement or adding support for other platforms.
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.
> CUPS is still great but mostly because it's initial implementation was so straightforward. It's existence today is mostly maintenance-mode with a priority for fixing Mac bugs, which is understandable but also occludes the possibility for future improvement or adding support for other platforms.
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.)
I'm of a mind to agree with GP, but I also agree that lack of funding and motivation will kill the project.
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?
I love mold and wish the author all the best, but I don't think this will work.
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?
> 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 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?
> 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 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.
As a corporate open source developer, we would be forced to switch off mold immediately if we were using it, for at least two reasons:
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."
Why would you need to switch off immediately? You can still use the version you're using in perpetuity with the license you agreed to.
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.)
Is the maintainer is the only copyright holder? If not, and other authors have contributed under the AGPL, the maintainer can't switch the license.
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.
> 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.
He can relicense everything except the code from those patches, while keeping that code under the MIT license. He will be required to preserve the MIT copyright notice and license text, and if he wanted to initiate a copyright lawsuit he would have to exclude those bits from what he's suing over, but otherwise there's no problem. GPL-family licenses have a stronger need for "any later version" than permissive licenses, since the virality rule means you can't just combine code under different GPL licenses in the same program.
(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.)
I think this is fine. The author has the right to do whatever they want with their own product. Bummer for me as I like this linker, but probably wouldn't use it if this change is made, as my small one person company wouldn't be able to pay.
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.
>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.
I think one thing that would definitely help the mold project is to have a clearer price and licensing model. The only thing I can find is https://opencollective.com/mold-linker.
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."
I feel for the maintainer, but looking at the performance chart in the readme, I think any engineer will have a hard time getting their company to approve paying a license for such a small improvement over LLVM ld.
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.
If that were true, the author would have retired, because they were a Google engineer when they wrote lld, which is bonkers fast compared to gold, Google's previous linker.
There are hundreds of people in platforms, language tools, ads, search, and probably everywhere in the company that have saved Google way more than they ever got paid. The thing to understand is that Google's scale is not your scale, as an employee. You make a change that saves the company a million dollars per month. The number is large because the company is large, not because you're amazing.
I think a single employee netting even a single digit percentage in a year's worth of effort in improved performance for all of Google is an astonishing accomplishment. Trivializing a "million dollars per month" improvement just says so much about how little programmers here realize their worth to technology companies, and intellectualize ways to justify it.
The guys that improved dependency download time by up to 80% at my company (Amazon) sure as hell are enjoying the 3% raise they got like everyone else.
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.
Nobody only spent 10s on linking. For any reasonable sized binary (in the range of 100 to 200 MiB) it is somewhere around 50s to 60s before mold. People regularly links 1GiB binary for living during their development cycle. If you use small binary or primarily using Go, probably not the target audience of mold.
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)
I work in video games, and all the game projects I've worked on for the last 10 years or so have been multi minute link times. We predominantly iterate on windows with MSVC, and it's usually "server" binaries that are produced for linux.
Afraid I don't know how long it takes with mold, sorry!
Yeah, businesses are often cheapskates, and a couple seconds’ worth of speedup aren’t worth any money, especially if you’re removing 10-20 seconds from a multi-hour build pipeline running on dedicated build boxes.
Given the horrible performance of the LLVM compiler and linker I'd think Apple or one of the other LLVM backers would jump at hiring/funding this guy. Making the LLVM compiler/linker faster should be a top priority given how important it is to developer UX and productivity.
> Given the horrible performance of the LLVM compiler and linker
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.
I think there is a prima facie case that nobody* cares about linker speed. bfd is a terrible linker written by weirdos and it's still the default linker on every mainstream Linux. You'd think that an organization like Canonical would benefit from faster builds, but they still use bfd. Not even gold, which has been available for 16 years. Definitely not lld, which has been around for 5 years. The amount of performance they are already leaving on the table is huge, so who would expect them to be suddenly interested in build performance?
Games dev cared, at least up to the playstation 4. The Sony linker was much faster than the Microsoft one (plus built to an unreasonable QA bar) and that cut turnaround times for builds enough that it was worth developing against the playstation and testing against the xbox, which Sony considered a competitive advantage.
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.
do you mean its better for build performance or for the final output?
Better across the board. Currently we translate to machine code and tables of extra data saying how to patch said code, store it in an elf/coff/other, then read it back in and use the extra data to work out what to do with it.
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.
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.
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.
> 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.
yea, i had some idea in my head of early unix/c and all the constrains they had to deal with must have informed the compilation model like that... interesting!
That's just not true. Every c++ project I've worked on has cared about linker and compiler speed. Unfortunately I work in windows-land where we use MSVC, but stuff like [0] makes our lives so much easier.
No, because excluding commercial users is a field-of-use restriction, and you're not FOSS if you only offer a license which imposes a field-of-use restriction. Which is fine! Just don't call it FOSS.
Furthermore, it's really hard to define what non-commercial actually means. Creative Commons spent something like a decade trying to scope a reasonable definition and eventually ended up essentially punting. With a few exceptions like (arguably) secondary public education use, pretty much any non-trivial use has some commercial component.
There is no semantic game, open source software is a term of art with a much more specific meaning than the source being available. If you find this draining then you can simply stop trying to misappropriate the term.
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.
The AGPL is not a non-commercial license, but it essentially functions as one, as most companies aren't willing to comply with it. There are some projects that make their code available under the AGPL, and also let users pay to get access under a different license. Grafana is an example.
GPL 3 has similar (in spirit and mechanism) usage restrictions as the AGPL.
GPL3 cracks down on TiVo style lockdowns:
Here is an encrypted binary and source code. No existing computer will run either without a secret key you cannot have.
AGPL cracks down on Google style lockdowns:
You can't have binaries or sources, but you can use this GPL software as long as you agree to a long and ever changing EULA that includes clauses for surveillance, binding arbitration and worse.
BSD licenses are only freer for developers, not for end users. The F in FOSS refers to the users' freedoms, not the developer's / vendor's freedoms.
The AGPL maximizes both freedom overall and freedom for one individual, so there is no actual tension or equivalence with the paradox of tolerance. The key misunderstanding here is the belief that being able to keep other people from doing things is freedom. That's actually power, and that's all that copyleft licenses take away. See https://www.gnu.org/philosophy/freedom-or-power.en.html for more details.
Source-code freedom is user freedom. It's effectively a sort of guarantee.
The additional freedom that BSD licences provide is freedom for developers to do what they like, not anything to do with users.
(The biggest practical advantage of a BSD licence for most developers is that if you use one when publishing your code while you work for a company, you yourself will still be able to reuse that code after you leave.)
By definition there aren't any, but MAME used to be distributed under such a license. I think Debian in particular has been pretty successful at exerting pressure to either relicense or replace software with non-commercial restrictions.
> 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.
I'm sympathetic but this is an uphill battle unworthy of fighting, in my opinion. Canonicalization of "open source" (versus "OSI Approved Open Source") is overreach of a an organization suffering from declining relevance. OSI is not helping to move the needle on licensing, and has effectively caused the industry to become frozen in time with the same stagnating licenses we had 10-15+ years ago. There's no innovation here, and I'm just tired of this. Instead we have demonic machinations like the BSL growing in relevance because there's no better alternative. I'm just so sick of it.
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?
The reason to defend the definition of "open source" as it currently stands is to prohibit organizations from profiting from the accumulated goodwill of the open source community and movement without actually adhering to the ethical standards of that movement. We've seen in the past that companies will release source under an encumbered license and claim to be "open" as a result -- the FSF and OSI were founded in response to that type of maneuver.
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.
> It's not necessary for the OSI to approve a license for the software to be open source
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.
Why is wanting Open Source to have a single, well-defined meaning a bad thing? If you let everyone who uses words make up their own meanings, isn't https://xkcd.com/1860/ where you end up?
Because it's gatekeeping. If the OSI rules my license doesn't meet the OSD am I going to be socially exiled for labeling my software as open source?
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.
This seems like a hypothetical concern. Has anybody actually had a problem with a clearly OSD-compliant license not being approved? Has anybody been "socially exiled" for not using an OSI-approved license?
Should people who sell food get to make up their own definitions of "kosher", "halal", "vegan", etc., without being "socially exiled"? If not, what's the difference between that and this?
And this is nothing like what Adobe and Pantone did.
That's a pretty terrible analogy. Etymologically they bear no resemblance to "open source". A better analogy would be "low fat" or "sugar free".
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.
> A better analogy would be "low fat" or "sugar free".
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?
Ghostscript used to have the most recent version under a non-commercial license (AFPL) and older versions relicensed to GPL, before they switched to AGPL only.
So is this a copyright agreement or a EULA? Copyright agreements only cover distribution and if you something internally, it doesn’t cover your usage. Only if you distribute the code does it come into play.
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.
I think this is totally fine, but they will need a better definition of what is and is not permissible. “Corporate” is a word that has many meanings. What about other entity types-sole proprietorships, partnerships? How about for-profit vs non-profit? Educational use? By students vs. schools themselves and faculty? Etc.
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.
The BSL (the proposed license) is fairly clear about this if you read the license. Most sole proprietorships and corporations of all types that make money or sell a product using it would have to pay. It's not clear that any of this is legally enforceable, though.
> It's not clear that any of this is legally enforceable, though.
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.)
Conservancy v Vizio (in the USA) argues that the GPL is also a contract and that they are entitled to GPL compliance as a third-party beneficiary of the GPL contract:
As others have pointed out, a lot of common law jurisdictions require that contracts have consideration from both parties. This is the key issue with non-permissive open-source licensing (and it's an issue with the GPL/AGPL too).
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.
> require that contracts have consideration from both parties.
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).
I think the issue is that not using it commercially may not actually be consideration depending on how you frame it. Your last sentence could easily be reworded as: "in exchange for nothing, you get the right to use the IP non-commercially." This is definitely not an enforceable contract as constructed under any theory.
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.
Contracts in the US also require consideration (IIRC from my intro biz law class). IANAL, but I think that the consideration is allowing you to use the IP (in exchange for your compliance with the license).
I'm not sure if English laws allows substitution, but technically in US law this contract indeed don't have a consideration. While mutual consideration makes it enforceable, the lack of it doesn't automatically make the contract void. You could argue that there's promissory estoppel:
> 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.)
The software project gives the other party IP to use, and gets nothing in return. Might not even be told the other party is using their software.
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.
Ah. Going at it from the other side, wouldn't compliance with the rules regarding distribution / improvement etc be what the project is getting in return?
So if I work for a commercial company, but exclusively use the software for internal, non-sold activities is that ok? It is only when the software is used within a commercial product directly or is it anything that enable a commercial company to keep the lights running?
I remember a program once that used a model kind of like this. The main program itself was FOSS, and so were the Git and SVN plugins for it, but the ClearCase and SourceSafe plugins for it were proprietary and very expensive. (Unfortunately, I don't remember what the program was.)
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.
Guess he'll be slapping himself in the face...seeing as if you read the blog post you'd know that he can change the license because he wrote essentially all the code...
That's not the point, breaking trust, manipulation and betrayal are, if you don't care about that, then you should not complain when one random dude changes his popular library to spread a political malware [1]
It is not a break of trust, maniupulation, or a betrayal. A FOSS license is not a guarantee or promise of perpetually working on a project, for free - in fact it is specifically never guaranteeing anything.
You will always be able to use the version of Mold right before the license is switched.
Right, if the project is no longer financially viable in its current form, the moral thing to do would be to walk away entirely. Then nobody wins, but hey, at least he did the right thing. Or would that be disgusting too?
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!"
Deeply and needlessly cynical. rui tried to fund a high-value software infrastructure project on its own merit and it's not feasible long term. So a change is required.
Well, maybe going all-in in building a "high-value software infrastructure project on [your] own" is not a good idea if you don't have any concrete plans for funding right from the start? Changing the license to a non-FOSS is basically the most knee-jerk reaction you can do in that case. Find a maintainer. Give the project to the community. Become a regular contributor in your own spare time instead of the main (and sole) developer.
There are so many better ways to handle such a situation.
If you replace "building software" with "building a road" (or some other similar real-world infrastructure project), everyone would agree that it's a self-made problem and that there are other ways out rather than just "from tomorrow on this will be a toll-road". You can turn the road over to your city/municipality. Or you could let other take over the maintenance. If the road is useful, there will be others. If it isn't, well, everyone moves on.
Why? Did the community give to him? It certainly sounds like it hasn't. What obligations does one have to a community that doesn't give back?
> There are so many better ways to handle such a situation.
Better for who? You? Or him?
If open-source communities want open-source, they're going to need to come to grips with the need for people to eat, and to do that they are at minimum going to need to pass the hat. If they're not going to do that, this happens, and telling somebody who isn't you what they should do for "the community when "the community" doesn't support them is, frankly, wrong verging on immoral.
You are 100% free to fork the last permissively licensed commit and maintain it yourself. Looking forward to seeing you put in some work with the same enthusiasm that you use to tell people how to run their projects.
> Changing the license ... Give the project to the community
Wrong - this is a false dichotomy. "changing" license is not retroactive. Older releases are still available to the community and anybody can fork the project and carry on a new release train.
"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."
He's giving it away for free and then expects multi-billion dollar companies to pay for it. When they don't because they have no legal requirement, he feels gypped.
They are anticipating a version of the software they want to use to become available (which would save them money) without contributing in any way towards it.
If he's going to keep doing the work, somebody has to pay for it. If a company wants him to keep doing the work, then they should provide funding in order to ensure that it happens. Otherwise, the company risks not actually getting the thing he's giving away for free, which is exactly what's happening.
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.
License?
Only one guy to handle the support?
Dev is an Unknown quantity?
Bad economy?
Cost he's asking is too high?
Cheaper for companies to build it themselves?
I have a lot of questions about it too. But it's clear there's something wrong in his business model here.
One cannot provide AGPLed software to their customer without releasing the whole service code under the same license. Like, one cannot build cloud complier/linker to process one's customers' code. But one can link their compiled code using this linker and then sell that binaries or employ them in the SaaS all right.
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.