All the power to OP. One thing I notice is how seemingly divorced they are to “sales”, though. If you are running a one person startup, even if it’s free software, you will need to be doing sales in some way or another.
This release disclaimer is just another form of sales — a bit clumsy one TBH — and it should link to a call to action on the startup website.
Conference talks, reaching out to the folks at BigCo et al. that can actually move the lever to get your free software to get sponsored.
Which is a shame. Sales is a completely different type of activity to development. And yet another time/effort sink cutting into making the actual product.
I’m not saying it’s useless. Just that it’s a shame that being good at one thing is not enough and actual success requires learning an entirely different profession.
I guess it’s a matter of semantics. You can “sell” your project in more ways than traditional sales.
But if you’re making something you’d like other people to use and give you money for, you’re going to be doing some kind of sales along the way — or associate with someone who will.
Most professions that involve launching your own work require multiple competences and skills to be in place for it to succeed. Making a profit from a product is the final step in a relay race by multiple professionals.
But here’s the problem from the payers side: I have money for 5 good things to fund and there’s 100 out there. How should I pick?
Sales is also not an entirely new profession, many things can be taken over. E.g. successfully funded projects give regular progress updates and label them as an accountability measure. Just enough sales is enough in a place where no one does any sales.
E.g. one basic that can be immediately applied: do pitch your ideas end of October/Beginning November. That’s when people do their budgets for next year. And if $bigco does find money in the cracks for something they find useful, it’s okay to ask for 5-6 figures.
But here’s the problem from the payers side: I have money for 5 good
things to fund and there’s 100 out there. How should I pick?
Start by picking all 100. Then designate the 5 you consider most
important, and allocate a percentage to them, such that the sum of those
percentages is less than 100. Then whatever the remainder is gets split
among the remaining 95.
I’m just brainstorming here. We’re a community of highly intelligent
folk, and I’m sure someone could come up with something much better.
Nobody wants to sit down and mark all of the things they use. The
distros can help here. For instance, a program could scan your package
database and give you a list of possible funding candidates to choose
from.
It would be nice to have all of this decentralized. Maybe the way to do
it would be with some sort of proof-of-stake cryptocurrency. A
project interested in funding publishes an address where it can receive
funds. I’m talking out of my ass here, because I’m a fairly anti-crypto
kind of person.
What we really need is the equivalent of the email address for making
frictionless payments to individuals and small organizations.
What I’m getting at with all this stream of consciousness brainstorming
is that I think it’s a solvable problem.
The real longterm solution is UBI, but we aren’t there yet, and we may
not be in my lifetime. So a stopgap is needed.
Even companies that want to support open source aren’t going to do micro-donations to a hundred projects. Companies are going to make larger donations to one flagship thing they use, or maybe to a handful of them, and call it a day.
And every service that’s sprung up to try to be an intermediary has had massive red flags, at least in my opinion. Way too many of them run on the model of:
Collect donations “on behalf of” anything with a public GitHub URL
Don’t mention that those projects have never heard of this “helpful” service
Require projects to come explicitly sign up in order to receive money collected “on their behalf”
“Redistribute” donations targeted for any projects that don’t come sign up within a certain short window of time
People have been reviving this “helpful” service about once every eighteen months for the past decade or so. I’ve repeatedly pointed out how they’re the opposite of helpful and may actually cause massive tax and legal problems for the developers and projects they’re supposed to “help”, but for some reason the people running these services never seem to care much about that.
A linker is something of a special case as it’s mostly used in a way where the business use is not hindered by (A)GPL in any way. Typically AGPL is great at getting companies to consider paying for a license.
IANAL, but I think the author is making the right decision. I love FLOSS but I just don’t know of a FLOSS license that would work for a case like this.
Should there be a more copylefty license that worked in a case like this? Is it even reasonably possible?
Google, like many others, will pay for an alternative license if they want to use the project
Are there actually many cases of companies like Google paying for alternative licenses? When I was working at Google, it was rare and cases I saw were old legacy projects that nobody wanted to touch. For new projects, it was extremely uphill to get start procurement for a private licensing agreement. In practice, it’s often easier to just rewrite the [subset of the needed] software from scratch.
I wouldn’t call either of RHEL or Oracle particularly “interested in open source”. They both do release some open source stuff, and also some not, and are also so huge and have such a mix of business models to go along with it that it’s not really comparable here.
That said, I was replying to my parent comment, not to the post itself. The mold maintainer here does not seem to have been attempting to sell licenses before now, and is considering it for the future (and looking at BSL so the code is still open source in the end).
Well, RH sponsors development of a ton of things, from systemd to podman, so that would be an incorrect assumption. Also Oracle sponsors OpenJDK and MySQL so again, incorrect.
For the mold author, as someone else said, AGPL is a difficult license because of the software itself. So can’t blame them for looking for other options.
I’m not well versed in the legal world but how does it work with GPL? Can one build non-GPL/prioprietary software using GPL compiler (eg. GCC) and link it with GPL linker (eg. GNU ld) and keep their license? Is it because of the GPL exception? AGPL licensed linker does not have this kind of exception so special license grant is required?
No, the linker does not need the license exception. GCC both inserts fragments of code (for example for things like population count or count leading bit on architectures without instructions for these operations) and also inserts calls to and links several libraries that are part of the GCC codebase. As such, without the exception, everything spat out by GCC would need to comply with the GPL (it would not be GPL’d, it would simply need to convey the same rights as the GPL). In contrast, the linker just copies and pastes things from the input into the output and executes a small amount of code from the inputs to resolve relocations. It does not embed any of itself in the output and so it does not need the exception (in the same way EMACS does not need a GPL exception to avoid everything that you write in it from being GPL’d).
Thinking locally, the author should do what’s needed for their project to succeed. I’m sympathetic.
Thinking globally, I guess this is posted to Lobsters to discuss the larger philosophical issues? Okay, what would the world look like if the entire toolchain used by the author for their project was licenced as BSL (and always had been). Linux, gcc/clang, vi/emacs, etc. Or should all those other projects also now move to BSL, since they are clearly valuable to large parts of the software industry? What are the consequences for society? Do things get better or worse? If Open Source had been defined as “BSL” back in the day, then would the open source landscape today have even more and better choices, with better funding and salaries for developers, or would open source today be a wasteland?
While I have mixed feelings about the BSL, and it’s not clear what their plan is int this specific case, it’s also important to note that BSL is an actual attempt at a compromise, unlike Commons Clause or other nonfree licenses. The code ends up as open source eventually, which is a big step up from some things they might be considering.
I am almost completely sure if BSL were more popular back in the day, we would have even more and better choices, with better funding and salaries for developers.
I think you’re posing a wrong question. BSL and alike are not the enemy of Open Source. After all Open Source was a “business-friendly” response to Free Software. Like Free Software was a response to proprietary software. Each solved its own problem.
Free Software tried to make software accessible. And it succeeded. However, there was a problem. Business was reluctant to use that free software because of its viral lienes. No one knew what to make of it and tried to stay on the safe side. So FS was left mostly to hobbyists for the time.
Open Source came along to directly address adoption. By being more permssive OS licenses allowed the whole idea to spread beyond idiologic users and researchers. And OS succeeded.
However, now we have another problem. software widely adopted and used but there’s a lack of resources on the mantenance/development side of it. Too many requests from users, too much demand of developers’ time. BSL is an obvious thing to try. It’s hard to tell whether it will solve the issue but at least it’s a capitalist solution to a capitalist problem so there’s hope.
Now, let’s take your proposed scenario. I think it’d be just different. Maybe slightly better. The hole FOSS boom would’ve probably took a little longer as there would be some financial pressure agains software adoption but otherwise nothing would’ve changed much. There still would’ve been great demand for software. However, maintainers would’ve been in a much healthier position. And the whole idea of paying for software would be a little bit more acceptable. We probably wouldn’t see as many rants denouncing great software for authors wanting to pay their bills.
Just to reiterate. BSL is not an enemy of FOSS. Facebook would still push React under Open Source License, as would Google push Kubernetes and so on. Corporations are getting completely different thing out of it and for them Open Source licenses are as good as it can get.
Free Software tried to make software accessible. And it succeeded. However, there was a problem. Business was reluctant to use that free software because of its viral lienes. No one knew what to make of it and tried to stay on the safe side. So FS was left mostly to hobbyists for the time.
I think this oversimplifies the history of these two camps to the point of false abstraction. The free software movement was never interested in business use of free software; they only cared about the agency of individual users. GNU was born out of a situation where commercial software was already taking over, commercial software will always be fine.
Open Source came along to directly address adoption. By being more permssive OS licenses allowed the whole idea to spread beyond idiologic users and researchers. And OS succeeded.
You make this sound as if free software underwent a licensing change to increase adoption, but this is not the case. No one can dispute that the Linux kernel is probably the most successful free software project in history. It remains GPL licensed. This has not changed since it’s inception.
The commercial adoption came first, and then more permissive licenses became more fashionable as using free software in business became normal. If permissiveness of licensing was the core issue, then surely a BSD derivative would have succeeded over Linux.
Open Source came about by a faction of people who wanted to commercialize free software. The new language was a rhetorical change intended to assuage the fears business had about viral licenses and open development. It was an attempt to sever the material differences in how software was developed under free licenses from the moralism of the FSF.
I’m not sure - Ghostscript did this before with its dual license scheme. It makes one think twice before contributing - because now you’re contributing for free to something that makes money for someone else. It would also typically require you to sign a copyright assignment agreement so that the original author can legally continue doing what they are doing. For the original author(s), it also makes the decision to add someone to the core team more difficult, assuming it means they would now have to pay them. And I would expect so, because who would willingly spend more of their free time and work to fatten another man’s wallet?
On the whole, I don’t think open source would be a wasteland, per se. On one hand, it would slow down contributions, so maybe we wouldn’t be where we were today and have a lot less choice and products that are a lot less polished. On the other hand, it might mean people got paid and didn’t burn out so easily, and perhaps give them the opportunity to work on free software full-time, so like you said it might also be that we’d have more and better choices now, and more software would be source-available (so basically achieving the FSF’s goals, if in a somewhat diluted form)
It makes one think twice before contributing - because now you’re contributing for free to something that makes money for someone else.
I don’t mind that they make money, I mind the asymmetry: they can make money in a way that I cannot, from a project that we both contribute to. This principle of fairness is critical in most F/OSS licenses: if you and I collaborate on something then we both have the same rights to the result. There are a few exceptions but they tend to be unpopular.
This issue becomes especially relevant when the original project becomes abandoned and someone has to start a fork to keep it alive. There is no clause in BSL that covers that. If the original authors do not explicitly re-license the code (which they may not even be able to do, in case of a hostile takeover, for example), then forking isn’t a practical possibility at all.
I suppose it may even make companies that have popular products under BSL attractive targets for takeovers, since communities cannot do anything to keep the open-source version alive — everyone who wants to keep using the software has to buy it from the new owner on their new terms.
That’s an excellent point. From a corporate perspective, the ability to create a second source if none exists is one of the key values of F/OSS. If a company takes a project in a direction that you, as a customer, don’t like then you can pay any other company that is willing to bid to maintain a fork that goes in the direction that you want. That’s a last resort, but the fact that it’s possible is generally enough of an incentive to stop the maintainers going too far off the rails. With dual licensing, you lose this. You may be happy to pay for version X, but if version X + N drops features that you depend on, has show-stopper bugs for you, or whatever then you can’t just pay someone to fix the open version you need to negotiate with the maintainers to add the features that you need. That makes it much higher risk than a real F/OSS license that is sufficiently permissive for whatever you want to be able to do with it.
I think we need a specific term for BSL-like licenses. “Dual licensing” is broad and includes situations like licensing the code under two different FOSS licenses (like GPL + MPL), which isn’t harmful at all. Any dual licensing where one of the licenses is FOSS and both are applied at the same time also doesn’t prevent forks.
Maybe “delayed dual licensing” could be a good term.
Sorry, I was thinking of the GhostScript case, where it was GPL’d or proprietary.
A lot of F/OSS dual licensing is probably not legally binding, because one license grants a superset of the rights of the other. This means that the ‘reasonable person’ test that the court would use will assume no one would ever choose to receive fewer rights and so the licenses are equivalent to the most permissive one. In cases where the licenses are incompatible (e.g. GPL + CDDL), then it’s far more complex and you probably need to take it to court to figure out what it actually means.
The problem mentioned in this document by the mold author is that big companies “don’t know how to support a project except by buying a license”.
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?
This begs the question: why not sell licenses to your project? You develop it as AGPL and distribute it for free, but you can sell licenses that are also AGPL, or just GPL, BSD, whatever you like. Developers that don’t want to support you financially will not buy the license, and just use the software for free. But it does make it easy for other developers to support you through their organization, by just asking to buy a license through the usual process. (If you switch to a proprietary license, a larger proportion of users will buy a license but the userbase will be much smaller, so it is really unclear that it is more interesting financially.)
You assume a corporation that desperately wants to support the developer but doesn’t know how to put a donation on the books. I think usually it’s the other way around. They’ll find a way to book any expense they want but they don’t want to pay for what can be obtained for free. And every FS license demands free distribution. For corporate users it’s cheaper and easier not to pay for FOSS.
Paid license doesn’t mean smaller userbase. Specifically, OP goes for Adobe-like model. Software is free for individual use so that people could learn it and get used to it but for the business it will cost. The whole arrangement is more complex but I think incentives are better aligned. People/users still can learn the tool, business has money and desire to improve productivity/quality of their product/whatever and has money to throw at the problem, and the developer gets paid through an unambiguous channel.
In my experience it is not uncommon for engineers in wealthy companies to be aware that their employer could better support the tools they rely on, and to be willing to go through corporate channels to send some money downstream. But they need an easy process to do so, that their higher-up and expense people understand (and lawyers, if non-standard licenses are involved).
Of course most people are going to use the tool for free, but you don’t need everyone to pay as long as those who pay are paying enough.
An efficient linker sounds like something that is used by expert engineers in large companies with very-large codebases (and so probably a good amount of funding), so that could be a good fit. If I was the author I would try this first before more invasive changes to the licensing terms and business model.
For a concrete example of a related situation I am aware of, some people inside Facebook wanted to support a workshop organized about a technology they liked (the OCaml programming language), but the path from their good intentions to “the company decides to sponsor this external event” was organisationally too hard to achieve, and they let the workshop organizers know. So the organizers instead setup a “support ticket” option that was priced sensibly higher than the usual (rather cheap) workshop registration, and the handful of Facebook employees that attended the workshop chose this option. The workshop got around the same amount of money that they would have gotten from direct sponsorship, with a much easier inside-company path.
The root issue here seems to be that the author expected to be able to build a business around a piece of open-source software, and found that this is actually a very, very difficult thing to do (and requires a whole panoply of skills that have little to do with “good at writing code”). And so, like many others who have trod this path previously, the author is now looking at making the software proprietary, or proprietary-ish, as a way to force the creation of a revenue stream.
I don’t think this has worked out particularly well for any of the prior entities that tried this – many of which were already better funded and had the whole roster of corporate roles to do all the important not-just-about-writing-code stuff – and I’m not sure it will work out particularly well for this author.
The simple truth is: many businesses don’t succeed. Doubly so for businesses based around things that are given away free of charge, which really want a ton of careful thought and planning into how they’re going to work.
To accept these terms, you must be enrolled to make regular payments through any of the payment platforms pages listed above, in amounts qualifying you for a tier that includes a “patron license” or otherwise identifies a license under these terms as a reward.
How long does one have to be a patron? Indefinitely?
It does not seem to have been written or edited by a lawyer. The language is rather weak and I would be extremely hesitant to use this for anything of value.
I don’t see what purpose that would serve here. Few are going to be concerned about mold being AGPL, those that are would probably just as satisfied with a non-open dual-license option.
And in general, putting a GPL version out there means any buyer can just redistribute it to the rest of the world, effectively making it GPL for everyone, so why bother with AGPL in the first place?
Because the problem the author of mold has is that companies know how to buy things not how to donate to open source projects. Selling a different licence is something that fits into that paradigm.
This is not a critical project. It’s a faster linker. LLD is already fast enough that linking stopped being a bottleneck that I care about years ago, so mold would not save me a measurable amount of time.
While I agree with you that mold is not critical, it is still a significant productivity boost in the same sense that an IDE might be, and people willingly pay licenses for those.
For any kind of iterative work where a small change means 1 compilation unit + linking (or linking of multiple libraries, in case others depend on the one being modified), it really significantly improves the development experience.
The problem here is that this is so broad that any organisation with legitimately ask “why should I foot the bill and not someone else?”. And there’s always 100 open places where you could make gains of that kind.
Not taking away from your general point, but that’s something that’s hard to work through and find the people on the other side willing to help you succeed, because it needs to be a specific kind of person with a specific kind of mindset.
How does changing the license of such a large project work? Do you need permission from all the contributors, or did the previous license allow for relicensing?
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.
All the power to OP. One thing I notice is how seemingly divorced they are to “sales”, though. If you are running a one person startup, even if it’s free software, you will need to be doing sales in some way or another.
This release disclaimer is just another form of sales — a bit clumsy one TBH — and it should link to a call to action on the startup website.
Conference talks, reaching out to the folks at BigCo et al. that can actually move the lever to get your free software to get sponsored.
This. Changing the copyright license isn’t a magic replacement for having a solid sales process.
Which is a shame. Sales is a completely different type of activity to development. And yet another time/effort sink cutting into making the actual product.
I’m not saying it’s useless. Just that it’s a shame that being good at one thing is not enough and actual success requires learning an entirely different profession.
I guess it’s a matter of semantics. You can “sell” your project in more ways than traditional sales.
But if you’re making something you’d like other people to use and give you money for, you’re going to be doing some kind of sales along the way — or associate with someone who will.
Most professions that involve launching your own work require multiple competences and skills to be in place for it to succeed. Making a profit from a product is the final step in a relay race by multiple professionals.
But here’s the problem from the payers side: I have money for 5 good things to fund and there’s 100 out there. How should I pick?
Sales is also not an entirely new profession, many things can be taken over. E.g. successfully funded projects give regular progress updates and label them as an accountability measure. Just enough sales is enough in a place where no one does any sales.
E.g. one basic that can be immediately applied: do pitch your ideas end of October/Beginning November. That’s when people do their budgets for next year. And if $bigco does find money in the cracks for something they find useful, it’s okay to ask for 5-6 figures.
Start by picking all 100. Then designate the 5 you consider most important, and allocate a percentage to them, such that the sum of those percentages is less than 100. Then whatever the remainder is gets split among the remaining 95. I’m just brainstorming here. We’re a community of highly intelligent folk, and I’m sure someone could come up with something much better.
Nobody wants to sit down and mark all of the things they use. The distros can help here. For instance, a program could scan your package database and give you a list of possible funding candidates to choose from.
It would be nice to have all of this decentralized. Maybe the way to do it would be with some sort of proof-of-stake cryptocurrency. A project interested in funding publishes an address where it can receive funds. I’m talking out of my ass here, because I’m a fairly anti-crypto kind of person. What we really need is the equivalent of the email address for making frictionless payments to individuals and small organizations.
What I’m getting at with all this stream of consciousness brainstorming is that I think it’s a solvable problem.
The real longterm solution is UBI, but we aren’t there yet, and we may not be in my lifetime. So a stopgap is needed.
Even companies that want to support open source aren’t going to do micro-donations to a hundred projects. Companies are going to make larger donations to one flagship thing they use, or maybe to a handful of them, and call it a day.
And every service that’s sprung up to try to be an intermediary has had massive red flags, at least in my opinion. Way too many of them run on the model of:
People have been reviving this “helpful” service about once every eighteen months for the past decade or so. I’ve repeatedly pointed out how they’re the opposite of helpful and may actually cause massive tax and legal problems for the developers and projects they’re supposed to “help”, but for some reason the people running these services never seem to care much about that.
A linker is something of a special case as it’s mostly used in a way where the business use is not hindered by (A)GPL in any way. Typically AGPL is great at getting companies to consider paying for a license.
IANAL, but I think the author is making the right decision. I love FLOSS but I just don’t know of a FLOSS license that would work for a case like this.
Should there be a more copylefty license that worked in a case like this? Is it even reasonably possible?
AGPL is also exceptionally good at making companies not consider the software at all, eg Google: https://opensource.google/documentation/reference/using/agpl-policy
Yes, that’s the point. Google, like many others, will pay for an alternative license if they want to use the project:
Of course the software needs to be exceptionally good to be considered exceptionally. I believe mold is.
Are there actually many cases of companies like Google paying for alternative licenses? When I was working at Google, it was rare and cases I saw were old legacy projects that nobody wanted to touch. For new projects, it was extremely uphill to get start procurement for a private licensing agreement. In practice, it’s often easier to just rewrite the [subset of the needed] software from scratch.
That’s why the typical practice is for the software owner to license it to the business under a commercial license for a fee.
Yes, if you’re trying to get someone to “pay for a license” you’re obviously not interested in open source, so I guess going nonfree is no surprise…
That’s not obvious at all, plenty of people in open source sell licenses for their software, e.g. Red Hat Enterprise Linux, Oracle.
I wouldn’t call either of RHEL or Oracle particularly “interested in open source”. They both do release some open source stuff, and also some not, and are also so huge and have such a mix of business models to go along with it that it’s not really comparable here.
That said, I was replying to my parent comment, not to the post itself. The mold maintainer here does not seem to have been attempting to sell licenses before now, and is considering it for the future (and looking at BSL so the code is still open source in the end).
Well, RH sponsors development of a ton of things, from systemd to podman, so that would be an incorrect assumption. Also Oracle sponsors OpenJDK and MySQL so again, incorrect.
For the mold author, as someone else said, AGPL is a difficult license because of the software itself. So can’t blame them for looking for other options.
For what it’s worth, they’ve explicitly been trying to sell licenses to businesses since at least May: https://github.com/rui314/mold/commit/9fbd71ec6bb315c6fd4bfefbfcde821a4737b9e0
Interesting that in the comments there they had the idea to maybe weaken to an MIT license but are now considering the opposite.
I’m not well versed in the legal world but how does it work with GPL? Can one build non-GPL/prioprietary software using GPL compiler (eg. GCC) and link it with GPL linker (eg. GNU ld) and keep their license? Is it because of the GPL exception? AGPL licensed linker does not have this kind of exception so special license grant is required?
The GCC runtime library exception is required because runtime support code is copied into the final binary. The same is not true of a linker.
So if GNU ld is used for linking, project must use GPL? Assuming its binary is distributed.
No, the linker does not need the license exception. GCC both inserts fragments of code (for example for things like population count or count leading bit on architectures without instructions for these operations) and also inserts calls to and links several libraries that are part of the GCC codebase. As such, without the exception, everything spat out by GCC would need to comply with the GPL (it would not be GPL’d, it would simply need to convey the same rights as the GPL). In contrast, the linker just copies and pastes things from the input into the output and executes a small amount of code from the inputs to resolve relocations. It does not embed any of itself in the output and so it does not need the exception (in the same way EMACS does not need a GPL exception to avoid everything that you write in it from being GPL’d).
Thinking locally, the author should do what’s needed for their project to succeed. I’m sympathetic.
Thinking globally, I guess this is posted to Lobsters to discuss the larger philosophical issues? Okay, what would the world look like if the entire toolchain used by the author for their project was licenced as BSL (and always had been). Linux, gcc/clang, vi/emacs, etc. Or should all those other projects also now move to BSL, since they are clearly valuable to large parts of the software industry? What are the consequences for society? Do things get better or worse? If Open Source had been defined as “BSL” back in the day, then would the open source landscape today have even more and better choices, with better funding and salaries for developers, or would open source today be a wasteland?
While I have mixed feelings about the BSL, and it’s not clear what their plan is int this specific case, it’s also important to note that BSL is an actual attempt at a compromise, unlike Commons Clause or other nonfree licenses. The code ends up as open source eventually, which is a big step up from some things they might be considering.
I am almost completely sure if BSL were more popular back in the day, we would have even more and better choices, with better funding and salaries for developers.
I think you’re posing a wrong question. BSL and alike are not the enemy of Open Source. After all Open Source was a “business-friendly” response to Free Software. Like Free Software was a response to proprietary software. Each solved its own problem.
Free Software tried to make software accessible. And it succeeded. However, there was a problem. Business was reluctant to use that free software because of its viral lienes. No one knew what to make of it and tried to stay on the safe side. So FS was left mostly to hobbyists for the time.
Open Source came along to directly address adoption. By being more permssive OS licenses allowed the whole idea to spread beyond idiologic users and researchers. And OS succeeded.
However, now we have another problem. software widely adopted and used but there’s a lack of resources on the mantenance/development side of it. Too many requests from users, too much demand of developers’ time. BSL is an obvious thing to try. It’s hard to tell whether it will solve the issue but at least it’s a capitalist solution to a capitalist problem so there’s hope.
Now, let’s take your proposed scenario. I think it’d be just different. Maybe slightly better. The hole FOSS boom would’ve probably took a little longer as there would be some financial pressure agains software adoption but otherwise nothing would’ve changed much. There still would’ve been great demand for software. However, maintainers would’ve been in a much healthier position. And the whole idea of paying for software would be a little bit more acceptable. We probably wouldn’t see as many rants denouncing great software for authors wanting to pay their bills.
Just to reiterate. BSL is not an enemy of FOSS. Facebook would still push React under Open Source License, as would Google push Kubernetes and so on. Corporations are getting completely different thing out of it and for them Open Source licenses are as good as it can get.
I think this oversimplifies the history of these two camps to the point of false abstraction. The free software movement was never interested in business use of free software; they only cared about the agency of individual users. GNU was born out of a situation where commercial software was already taking over, commercial software will always be fine.
You make this sound as if free software underwent a licensing change to increase adoption, but this is not the case. No one can dispute that the Linux kernel is probably the most successful free software project in history. It remains GPL licensed. This has not changed since it’s inception.
The commercial adoption came first, and then more permissive licenses became more fashionable as using free software in business became normal. If permissiveness of licensing was the core issue, then surely a BSD derivative would have succeeded over Linux.
Open Source came about by a faction of people who wanted to commercialize free software. The new language was a rhetorical change intended to assuage the fears business had about viral licenses and open development. It was an attempt to sever the material differences in how software was developed under free licenses from the moralism of the FSF.
I’m not sure - Ghostscript did this before with its dual license scheme. It makes one think twice before contributing - because now you’re contributing for free to something that makes money for someone else. It would also typically require you to sign a copyright assignment agreement so that the original author can legally continue doing what they are doing. For the original author(s), it also makes the decision to add someone to the core team more difficult, assuming it means they would now have to pay them. And I would expect so, because who would willingly spend more of their free time and work to fatten another man’s wallet?
On the whole, I don’t think open source would be a wasteland, per se. On one hand, it would slow down contributions, so maybe we wouldn’t be where we were today and have a lot less choice and products that are a lot less polished. On the other hand, it might mean people got paid and didn’t burn out so easily, and perhaps give them the opportunity to work on free software full-time, so like you said it might also be that we’d have more and better choices now, and more software would be source-available (so basically achieving the FSF’s goals, if in a somewhat diluted form)
I don’t mind that they make money, I mind the asymmetry: they can make money in a way that I cannot, from a project that we both contribute to. This principle of fairness is critical in most F/OSS licenses: if you and I collaborate on something then we both have the same rights to the result. There are a few exceptions but they tend to be unpopular.
This issue becomes especially relevant when the original project becomes abandoned and someone has to start a fork to keep it alive. There is no clause in BSL that covers that. If the original authors do not explicitly re-license the code (which they may not even be able to do, in case of a hostile takeover, for example), then forking isn’t a practical possibility at all.
I suppose it may even make companies that have popular products under BSL attractive targets for takeovers, since communities cannot do anything to keep the open-source version alive — everyone who wants to keep using the software has to buy it from the new owner on their new terms.
That’s an excellent point. From a corporate perspective, the ability to create a second source if none exists is one of the key values of F/OSS. If a company takes a project in a direction that you, as a customer, don’t like then you can pay any other company that is willing to bid to maintain a fork that goes in the direction that you want. That’s a last resort, but the fact that it’s possible is generally enough of an incentive to stop the maintainers going too far off the rails. With dual licensing, you lose this. You may be happy to pay for version X, but if version X + N drops features that you depend on, has show-stopper bugs for you, or whatever then you can’t just pay someone to fix the open version you need to negotiate with the maintainers to add the features that you need. That makes it much higher risk than a real F/OSS license that is sufficiently permissive for whatever you want to be able to do with it.
I think we need a specific term for BSL-like licenses. “Dual licensing” is broad and includes situations like licensing the code under two different FOSS licenses (like GPL + MPL), which isn’t harmful at all. Any dual licensing where one of the licenses is FOSS and both are applied at the same time also doesn’t prevent forks.
Maybe “delayed dual licensing” could be a good term.
Sorry, I was thinking of the GhostScript case, where it was GPL’d or proprietary.
A lot of F/OSS dual licensing is probably not legally binding, because one license grants a superset of the rights of the other. This means that the ‘reasonable person’ test that the court would use will assume no one would ever choose to receive fewer rights and so the licenses are equivalent to the most permissive one. In cases where the licenses are incompatible (e.g. GPL + CDDL), then it’s far more complex and you probably need to take it to court to figure out what it actually means.
The problem mentioned in this document by the mold author is that big companies “don’t know how to support a project except by buying a license”.
This begs the question: why not sell licenses to your project? You develop it as AGPL and distribute it for free, but you can sell licenses that are also AGPL, or just GPL, BSD, whatever you like. Developers that don’t want to support you financially will not buy the license, and just use the software for free. But it does make it easy for other developers to support you through their organization, by just asking to buy a license through the usual process. (If you switch to a proprietary license, a larger proportion of users will buy a license but the userbase will be much smaller, so it is really unclear that it is more interesting financially.)
You assume a corporation that desperately wants to support the developer but doesn’t know how to put a donation on the books. I think usually it’s the other way around. They’ll find a way to book any expense they want but they don’t want to pay for what can be obtained for free. And every FS license demands free distribution. For corporate users it’s cheaper and easier not to pay for FOSS.
Paid license doesn’t mean smaller userbase. Specifically, OP goes for Adobe-like model. Software is free for individual use so that people could learn it and get used to it but for the business it will cost. The whole arrangement is more complex but I think incentives are better aligned. People/users still can learn the tool, business has money and desire to improve productivity/quality of their product/whatever and has money to throw at the problem, and the developer gets paid through an unambiguous channel.
In my experience it is not uncommon for engineers in wealthy companies to be aware that their employer could better support the tools they rely on, and to be willing to go through corporate channels to send some money downstream. But they need an easy process to do so, that their higher-up and expense people understand (and lawyers, if non-standard licenses are involved).
Of course most people are going to use the tool for free, but you don’t need everyone to pay as long as those who pay are paying enough.
An efficient linker sounds like something that is used by expert engineers in large companies with very-large codebases (and so probably a good amount of funding), so that could be a good fit. If I was the author I would try this first before more invasive changes to the licensing terms and business model.
For a concrete example of a related situation I am aware of, some people inside Facebook wanted to support a workshop organized about a technology they liked (the OCaml programming language), but the path from their good intentions to “the company decides to sponsor this external event” was organisationally too hard to achieve, and they let the workshop organizers know. So the organizers instead setup a “support ticket” option that was priced sensibly higher than the usual (rather cheap) workshop registration, and the handful of Facebook employees that attended the workshop chose this option. The workshop got around the same amount of money that they would have gotten from direct sponsorship, with a much easier inside-company path.
The root issue here seems to be that the author expected to be able to build a business around a piece of open-source software, and found that this is actually a very, very difficult thing to do (and requires a whole panoply of skills that have little to do with “good at writing code”). And so, like many others who have trod this path previously, the author is now looking at making the software proprietary, or proprietary-ish, as a way to force the creation of a revenue stream.
I don’t think this has worked out particularly well for any of the prior entities that tried this – many of which were already better funded and had the whole roster of corporate roles to do all the important not-just-about-writing-code stuff – and I’m not sure it will work out particularly well for this author.
The simple truth is: many businesses don’t succeed. Doubly so for businesses based around things that are given away free of charge, which really want a ton of careful thought and planning into how they’re going to work.
Somewhat related: over on one of the reddit threads for this story, an author of Lombok has a pretty critical take.
Sounds like a job for https://patronlicense.com/versions/1.0.0.html
How long does one have to be a patron? Indefinitely?
Yes. Your license terminates if you stop being a patron.
It does not seem to have been written or edited by a lawyer. The language is rather weak and I would be extremely hesitant to use this for anything of value.
It was written by a lawyer who specialises in software licensing, @kemitchell.
Made my day.
What strikes you as weak about the language?
most free software legalese is excessive in it’s verbosity.
Maybe the solution when you start an agpl project is to always sell gpl licences for businesses?
I don’t see what purpose that would serve here. Few are going to be concerned about mold being AGPL, those that are would probably just as satisfied with a non-open dual-license option.
And in general, putting a GPL version out there means any buyer can just redistribute it to the rest of the world, effectively making it GPL for everyone, so why bother with AGPL in the first place?
Because the problem the author of mold has is that companies know how to buy things not how to donate to open source projects. Selling a different licence is something that fits into that paradigm.
Related: http://phk.freebsd.dk/VML/
I feel like @mperham might have some worthwhile input as a developer that is: financially successful, and supports open source. Any ideas?
Yes! More power to OP!
Every maintainer of critical open source projects has a right to get funded.
This is not a critical project. It’s a faster linker. LLD is already fast enough that linking stopped being a bottleneck that I care about years ago, so mold would not save me a measurable amount of time.
While I agree with you that mold is not critical, it is still a significant productivity boost in the same sense that an IDE might be, and people willingly pay licenses for those. For any kind of iterative work where a small change means 1 compilation unit + linking (or linking of multiple libraries, in case others depend on the one being modified), it really significantly improves the development experience.
The problem here is that this is so broad that any organisation with legitimately ask “why should I foot the bill and not someone else?”. And there’s always 100 open places where you could make gains of that kind.
Not taking away from your general point, but that’s something that’s hard to work through and find the people on the other side willing to help you succeed, because it needs to be a specific kind of person with a specific kind of mindset.
This seems to be old news?
https://bluewhalesystems.blogspot.com/2022/11/mold-linker-may-not-switch-to-source.html
How does changing the license of such a large project work? Do you need permission from all the contributors, or did the previous license allow for relicensing?
That was mentioned in the post linked in the Licensing section (https://docs.google.com/document/d/1kiW9qmNlJ9oQZM6r5o4_N54sX5F8_ccwCy0zpGh3MXk)