You misunderstand me. Most of the companies that use or make money off of open source don't employ people to actually work on that code at all. They simply use it and integrate it. For them, the fork is viable if it does what they need it to do.
If the fork does not see any development then it is pointless. And if the original does get updated unlike the fork, then the fork is non-viable as well.
Nonsense. There's plenty of software out there that is basically mature. Why would you think that this software suddenly becomes non-viable merely because it isn't getting changed?
Suppose, for example, that NGINX or Apache decided to switch to this sort of license. Both are mature products that are entirely usable right now. And apart from security fixes (which tend to be straightforward, and could very easily be replicated in a fork based on the original license, and almost certainly would be replicated in every fork if forks existed), there's no requirement that development continue to be ongoing for it to be useful.
The only way a fork will be viable is if it's being developed, and who will be developing on it for free when they could be paid working on the original?
Employees working for the companies that own the 4.6 million servers currently running NGINX or the 3.2 servers running Apache. After all, arguably most of them are part of a commercial product, in a manner of speaking.
Not sure what any of that has to do with how much 1% of their revenue would be.
1% when the the total OSS budget is 1% of revenue is certainly a lot (100% increase). But 1% when the budget is 50% of revenues, that much less (2% increase), and could be within the normal budget variation year-over-year.
But the total OSS budget for software licensed under this license always starts at zero. That's the whole point. This organization doesn't exist yet, and has no software licensed under its code. Therefore every company is starting at zero. Apart from companies that already *produce* open source software *and* have the right to relicense it under this sort of license (which is probably a very, very small number of companies), it really doesn't matter if the company is paying people to work on open source software already, because none of those expenses will go away under this regime. The only thing that matters is that the second they add one piece of software under this license, they give up 1% of their revenue.
None less, realistically. Companies employ people to improve the things that they want improved. Relying on outside parties to do the improvements means waiting for it to be somebody else's highest priority.
True to some extent. But the big reason it is like this in the first place is because the developers have limited time to spent on what is generally a pet project. Big or niche features will still need direct funding by corporation indeed, but bug fixes and general maintenance could be done by the developers instead of the employees.
While that's true to some extent, big features that corporation A wants still aren't going to be a priority for corporation B unless they have a contract with corporation B that says that they will provide that feature, and even then, only to the extent that the contract requires. In the grand scheme of things, it will still always be way faster to just hire people to do the work no matter how big the existing team working on the tool/library is.
In fact, I'd argue that the amount of time it takes to get interesting features added actually gets longer the more people are working on it, so if corporation A wants a feature added, it would likely take longer to get corporation B to add it than it would if that product were maintained by a solo developer. And that's triply true if corporation A could just hire that solo developer, as is often done.
The fastest way for a company to get things done in an open source project is to hire the lead developer. The second fastest way is to hire a team to do work on the project and contribute it back upstream. The third fastest way is to hire a team to do work on the project and fork it because the upstream maintainers are intransigent or unresponsive. The fourth fastest way is to hire a team of outside contractors. The fifth fastest way is to enter into a contract with the corporation that owns the project. And the absolute slowest is to just ask the corporation that owns the project.
the people licensing that code did so under permissive licenses with the understanding that this would happen
There is difference between understanding/accepting and liking. Currently their choices are limited: free/OSS or proprietary/custom license. And to be paid, they would have to deal with each and every licensee separately, which is time consuming and unappealing.
There's actually a third choice: dual licensing under the user's choice of a paid commercial license or GPL/AGPL, with copyright assignment requirements for all external submissions. People/companies that can live with the terms of the GPL or AGPL get it for free, and those who don't can pay a licensing fee for a less restrictive license that is negotiated on a case-by-case basis with the company that owns all of the rights.
The proof of their interest in a Post-Open like system is the popularity of Patreon.
From what I've seen, Patreon is more a way to turn software into a continuous income stream, mostly paid for by individual users who aren't making money with it. It's kind of the exact opposite of this.
The problem is that the incremental cost of going from zero covered software to a single piece of covered software is 1% of your revenue
It depends a lot of what that "single piece of software" is. A 1% increase because of a fast memcpy library is certainly too much to ask. A 1% increase just for the use the Linux kernel is certainly a steal.
Only if there are no other usable open source kernels out there. If the Linux kernel switched to this license, you'd see every commercial user of Linux suddenly switch to FreeBSD, NetBSD, or OpenBSD, and depending on how loosely "included as part of a paid product" is interpreted, that could even include all the companies that build single-board computers like Raspberry Pi, at which point Linux development would basically dry up overnight.
I mean if it is just 1% of the products that include that software, *maybe* some existing companies might just keep doing it because of momentum initially, but for any new companies entering the picture, they'll have to decide if the difference between Linux and *BSD is worth 1% of their revenue, and most will likely conclude that it isn't. And those new companies will undercut the companies that are still using Linux, which will likely force them to switch to a cheaper kernel just to compete.
"If I add this one piece of software that would cost me X engineer hours to rewrite, it will cost me 1% of my revenue,"
That quite a bit of an oversimplification and hopefully the companies won't fall into that trap. This is basically the same cost as those falling into the NIH syndrome, which is always way more expensive than one thinks.
Oh, but that is exactly how big companies see software development, or at least that's how every big company I've ever worked at has seen it. And you're right that it's not a good idea, but it is still the way MBAs think. I've never worked at a non-startup company that didn't behave that way.
IMO, it is likely to be much easier to convince companies to pay a specific fixed amount per licensed inclusion than a flat fee per unit, because a lot of those products won't derive 1% of their value from licensed inclusions, and all of those products' manufacturers will actively seek out cheaper or free alternatives, and won't end up paying anything into this fund, whereas if you made the fee be per licensed inclusion, then each individual included work (library, etc.) could set a reasonable price for that specific work, and those companies would see a reasonable price per product and therefore most of them would pay money into the fund. Thus, the free market would end up finding some sort of market equilibrium pretty quickly in a way that it just can't with a simple flat rate per product sold.
And even for companies where the cost just happens to end up being the same 1%, they'll still likely favor the per-product licensing approach, because that avoids unnecessary lock-in risk. Consider that from their perspective, a year from now, the fees could double or triple or quadruple. If they're paying on a per-tool/library basis, they could then consider each licensed product individually and decide whether they can cut some of them out to save money. But if they would keep paying the exact same fee until the licensed work count reaches zero, then it becomes an all-or-nothing deal, which is way riskier from a future budgeting perspective.
So whether you're looking at it from the perspective of human nature, corporate behavior, or market dynamics, every analysis favors a fixed cost per included work per sold product or service, rather than a flat fixed cost per sold product or service.
