Basically, he advocates a new license that he wants to develop that basically improves remuneration for open source developers. Use case: A "Post Open" software is used by a company, then this company has to pay a certain percentage (1 to 10%) of their revenue to the "Post Open" software. If it is using multiple "Post Open" packages this percentage is divided among them (according to usage).
Software in this scheme will be allowed to be modified, redistributed etc. and it will also contain a public API that defines the boundaries of the program (so it's not about linking anymore).
I hope that captures the key points.
Around 12:47 is where he finishes that and concludes we cannot fix open source, and talks about "Post Open". Here's a link to that point in the video [2].
He describes his vision for "post open source" license, which he is currently developing. His goals seem to be to to empower software developers to take back power from megacorps which have in his view subverted the nature of open source and turned it into a "resource extraction" scheme.
Clarification: for-profit users pay a percentage of end user revenue. non-profits and individuals pay nothing. Automated auditing envisioned.
This is a proposal, not nearly ready for roll-out.
The concepts are interesting, but only a rough framework exists at this time. The ideas are worth discussing. I wish there was a succinct blog post or something about them rather than this painful video.
I can't imagine why I'd want anything to do with this license either. It's an unnecessary burden. Just stay away from it.
Colour me unconvinced of the viability of this scheme.
For open-source projects that are the top level (e.g., PostreSQL) and being paid to work on it... it's often useful to have an enterprise market and support model.
Side note, open source works better business model wise when things are more distributed. More centralized with megacorp clouds is harder for open source based businesses.
For libraries that can be used by many projects, open source is a great way to go. I've done semver, vcs, and other libs this way. They aren't the business thing being sold but enablers of other things being build.
Interfaces are great and we need more standard interfaces. They make is possible to have open source and proprietary solutions that work with the same stuff. Businesses can compete and work with more freedom to do so with open interfaces.
Businesses trying to have an open source software SaaS that they run in public clouds are always going to be at a disadvantage. The public cloud provider can always do it cheaper and undercut the business. Businesses that try to go that route will end up having business issues.
Physical products are another space all together. It's the thing (hardware + software) that make it work. Open source software is great there, too. I see it in the car I drive.
Where we license things as open source should be coupled to our thought out business models. It's not an open source or post open source world. It's about the right tool for the job in front of us. We need more thought and talk on that.
- Usage auditing for and reporting for Post-Open software is required alongside the payment. This is a huge reversal. Not having to do onerous license compliance monitoring was a big selling point touted by FOSS advocates for the past two decades, pointing to horror stories about audits demanded by the Business Software Alliance and huge payments for license violations.
- It's called the "Post-Open" license for a reason: Bruce says FOSS has been defeated. He points out that corporations have both found ways to make money off of FOSS without contributing much and even hijacked the governance of FOSS for their own benefit. This is extremely startling to hear from someone so well known in open source.
First because involving all the chicanery of accounting to figure out my fee is asking for lots of resources just to calculate and audit fees.
Second, unpredictable costs are bad. If my company’s revenue doubles in a year, that doesn’t mean that my department’s budget doubles. Or that I even have enough earnings to cover licenses.
Finally, this is hard enough with a single product. My org uses thousands of products. If they all charge 1%, where does that leave me.
PS- morally this just seems dumb. If my grocery store charged me more or less depending on my income or the value I derive from a tomato, I won’t shop there. Just publish a price and let people decide to buy or not.
Even if there is only a single "post open" package which gets the full 1% of the rev share, what about one developer which contributes a whitespace or spelling fix, versus another developer which contributes a key part of the package? What if one developer contributes a huge number of lines of code, but it's for a feature which isn't actually used at all by a particular billion dollar use case of said "post open" package?
The devil is really in the details.....
We already have some copyleft licenses that prevent the kinds of proprietary SaaS usage that have prompted recent complaints. People and projects don't use those licenses; they use permissive licenses, and then get surprised when companies use their software under those permissive licenses. I've even seen people complain that if they use copyleft licenses, large companies won't touch their software. That's entirely the point! If you want companies to pay for an alternative license or an exception, you have to choose an Open Source license that they're not already willing to work with.
Before we even consider giving up on the Schelling point that is Open Source, perhaps we should make better use of the full spectrum of Open Source licenses we already have.
And he's going to achieve that with a software license?
I would suspect lots of Hollywood Accounting is likely; putting all the PostOpen software in a subsidiary that has no revenue, or developing your own software under PostOpen but not distributing it outside, so that the majority of the usage is apportioned to affiliated companies.
Plus, apportioning by usage is a negative incentive for optimization. If your DB reduces query runtime by 10% in the next version, it reduces its revenue, assuming other PostOpen software is in use and doesn't optimize.
I'm not sure if that's a fair statement because the notion of 'resource extraction scheme' is entirely subjective.
If people are using the software in accordance with the license that you afford it, then that's it, there's nothing more you can ask.
If it turns out that 80% of the value is going to be captured by 'Big Corps', well, then that's what it is and it's entirely up to the Open Source developer to contemplate why they would want to do this or not. To each their own.
I suggest however, that there should be a better 3rd option that frankly doesn't exist, which is to allow devs to get paid commensurate with the popularity of their software, which would technically be commercial, but wherein the terms would actually be fairly open by any reasonable measure.
I suggest this dichotomy between 'Stallman/GPL vs. Evil Corps' is completely false and that it's mostly grey in between. It's just that there's a little bit of a cliff between the more open license and harder commercial terms which make things quite difficult for everyone aka imagine your corporate lawyer asked to review every one of the weird commercial terms of the 300 or so Node.js packages you're using ...
So as a purveyor of post-open software, you must have a business proposition that closes the deal. Not impossible, but different from the way most OSS projects operate today. Your skepticism is reasonable. To separate a customer from their money, you need to provide obvious value.
It strikes me that once you take one post-open package into your stack, the incremental cost of the next N is zero. So maybe there is enough virality in that feature to drive adoption. One high-value post-open project could create a coat-tail effect.
Maybe there is a lesson there regarding human behaviour, and attitudes regarding the need of income in capitalist societies.
With the difference that demo versions are no longer time limited, and even with the demo version there is code available instead of being an option on the commercial product.
Companies just call it open source instead, regardless of what is stated at OSI website as definition.
The UNIX world and Windows would keep taking BSD code, assuming the court case would have ended the same way as it did, and that was it.
The GPL haters tend to forget that GCC was pretty much ignored until Sun started the trend to split UNIX into user and developer editions, and without GNU there wouldn't be a userland for Linus to plug into Linux.
Whatever, all UNIX clones that came after Linux (specially for IoT) are BSD/MIT based, so the long term roadmap is already quite obvious.
Actually, I like people to do more than the bare minimum that's legally required of them. Unfortunately corporations usually don't do that.
I still think its a weird business model. I can't imagine any propriatary software would work with that. Its very discouraging for small projects that do simple things, or for companies that want to try out software a little at first before committing to using it at a large scale.
Starting a new movement with a new license could be a way to escape the current dynamics.
_Why_ do mega corps like Google and Intel refuse to use it? There's nothing on Wikipedia [0], and the license is extremely short and clear.
From your description I expected a license that explicitly denies permissions for certain purposes or types of companies. It's very much the opposite of that! :)
(For non-English speakers, "scratch" was formerly popular slang for money in the US.)
The other part is interesting, but Crystal got my attention a lot
That's certainly true, but that's not a good reason to declare bankruptcy and throw away the whole movement.
> Starting a new movement with a new license could be a way to escape the current dynamics.
A new movement seems more likely to end up worse, by not maintaining compatibility with the definition of Open Source; that definition exists for a reason, and its requirements don't just facilitate participation by megacorps, they facilitate participation by everyone. Just about every new license proposal I've seen has failed to actually be an Open Source license. "Hey, as long as we're changing the requirements, let's just go full 'non-commercial use only'", or "Hey, as long as we're changing the requirements, let's try to define ethics in a legal document". All the same mistakes over again that people had to fight to reject the first time around.
We don't need a new movement. We might need an improved license that's still Open Source, and a better marketing plan around that license.
This also places an undue burden on the payment receiver as they have to get into the business of running enterprise audits to find out who is using what.
I’m not saying that PostOpen is impossible or can never be used anywhere. Just that it sucks and is not feasible for broad use.
But it doesn’t replace OSS and I think will produce different software. I can’t imagine many developers switching to this. I wouldn’t contribute to a project with this license because I don’t want to bother with some incremental level of income. I’d rather just donate time.
Naturally with a license that only allowed its use on the context of understanding the product, e.g. source code for the C and C++ libraries of a compiler for use in debugging sessions.
Corporations legal departments just found out a way to use non-copyleft licenses for the 2nd coming of shareware/demoware, while cutting down development costs in the process.
If a bunch of startups continue to love Ruby's initial expressiveness and productivity (early code write & read cycles), then unless Ruby improves on similar dimensions then Crystal adoption may pick up.
Of course, Crystal's adoption could be stopped if Ruby (and Rails) improves on the dimensions that Bruce Perens mentioned in his video; namely correctness, reliability and efficiency. Supposedly, Crystal is supposed to be faster, more reliable and just-as-efficient-to-write given the syntactic similarities that many developers love about Ruby.
I also wouldn’t buy software that had a cost contingent because I wouldn’t want that kind of relationship with my software vendor. Of course, this happens now with enterprise software where a big company will get a quote for $5 and a little company will get a quote for $1. But having something explicit is illogical since software is a near zero marginal cost product.
But even for real world stuff, I’d never hire a gardener who charged differently based on customers income.