MySQL founder tries a new software licensing model
techcrunch.com
techcrunch.com
The TechCrunch article didn't address this specifically, but the license for MaxScale requires a MariaDB Enterprise Subscription if you use MaxScale with just 3 or more database servers at your company.
Since MaxScale is a proxy, it isn't particularly useful for companies that only have 1 or 2 database servers, except as a very limited trial. So this move effectively makes MaxScale commercial software for most production use. This is a strange business decision, considering there are other third-party proxies available, such as ProxySQL, that have same (or better) functionality and no requirement for purchasing a commercial license.
I also wonder how MariaDB Enterprise Subscription pricing works for companies that just want to use MaxScale to connect to stock Oracle MySQL or Percona Server MySQL? Seems strange to tie the licensing to MariaDB Enterprise even for companies that just want to use MaxScale alone. Although a good proxy takes a lot of development work, it's still tiny compared to building a relational database. I wouldn't expect the two to be priced the same.
MaxScale is usually included in the MariaDB enterprise subscriptions and one can also get standalone licenses for MaxScale.
There was a culture of fear for open source promulgated by proprietary vendors and major consultancies in the early 00's - the "know the facts" campaign by Gartner and Microsoft springs to mind.
Although this idea is generally dead now, the scars live on in the purchasing and licencing approval flows at many large enterprises.
I am familiar with several organisations where a paid for software licence can be acquired with nothing more than trivial approval for the spend. Yet adoption of an open source product requires multi layer approval of the licence and recording of licence risk against the project.
There is a valid case for that due diligence but its not a particularly strong case and if it were the reason for this situation, then proprietary software licences would be subject to the same scrutiny.
Open source software comes "AS IS", WITHOUT WARRANTY OF ANY KIND. So, who is promising that the software will run, that people will be able to use it and that it does something actually useful to the large enterprise?
If the enterprise has never used that software, long time employees have usually no professional experience with it, so it is risky have them install and run it.
In my limited experience, adoption of open source software by large enterprises comes most of the times through consultants, hired not to install the software but to solve a business problem. The consultants promise to solve the problem with the software, and that the software will run etc.
As far as I'm aware, most proprietary licenses have the same disclaimer. Have you ever seen Oracle getting sued when their database segfaults and loses data (in a similar way that a contractor would get sued for building a bridge that crashes)? You usually pay for support contracts with big enterprises, which have external guarantees and experts on call. Luckily, free software companies provide the same services without taking the freedom from the users of that software.
The same goes for FOSS when a consulting company is involved: they say that the software will work; my point is that that's the most likely way in which a large enterprise can run FOSS.
There are other ways, of course: the decision can come from a high enough manager (or even from the CEO or CTO) who's willing to take the risk, but, indeed, they are taking a risk.
Not all types of software are profitable with consulting, books or donations.
This is one of the reasons for Dual licensing. You can use the open source version or procure a license.
Dual licensing on GPL works by having users that want to redistribute the software under another license to pay. BSL works by having users that uses the software in more extreme conditions than normal to pay.
Since there was "always" MySQL available, Postgres wasn't in need of development, for most people MySQL was sufficient. If MySQL had been less open, Postgres might have gotten momentum years earlier to fill that gap on the low web-end.
I can imagine Postgres popularity in recent years is because people are replacing Oracle databases with Postgres, they are looking for a way out of that. Or even more, newer companies don't even look at starting with Oracle, but start on Postgres right away.
Postgress did exist at that time. Was called Postgress95. I compiled and ran it on a linux machine. And it crashed as soon as I tried to connect from a remote host.
> Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
[1] https://web.archive.org/web/20010601152026/http://mysql.com/...
David and I always planned to make MySQL Free Software, but we needed first to get enough momentum to be able to afford it. We also needed to come up with a business model that would work with GPL. MySQL was the first software that was using Dual Licensing on GPl.
I worked at a startup and companies would want us to put a version of the software into escrow and were wary of us going under, giving them something like this would have been perfect.
If you want unencumbered, you pay for commercial license.
After all, companies using your software wants just to be sure that they can continue to use it as before if you stop supporting it. For this purpose BSL works perfectly as a default. If they need more, then you make an explicit contract just for them where you give them more rights to the software.
My one concern is that the thrifty users will ride the expiration line, installing versions that don't cost money but which are outdated. I can see where that would be an acceptable tradeoff in many situations where the latest-and-greatest is not required. But from a security aspect I wonder if that also means that vulnerability fixes would only be available to the paying users. They are definitely worth paying for, no doubt; but would that then foster an ecosystem of not-really-patched installations out there?
(Then again, that might not be that different from the current situation.)
The link in the article points to a FAQ, which also does not appear link to the text of the license:
https://mariadb.com/bsl-faq-adopting
A Google search did not turn up the text of the license itself.
So, how to balance that versus wants of OSS community that might test, contribute code, and so on? One thing I posted was that the license would come with source, allow fixes, allow local extensions, and simply block redistribution unless its to paying customers. Covers most OSS benefits. To address lockin, I suggested provisions to cap what they can charge for given software and (relevant here) make it go GPL if it's abandoned.
Only got two reviews on this so far. I'm interested in getting some more. I think I've gotten pretty close to getting almost all benefits of OSS software while ensuring it stays paid for. Btw, one can also give out free or supported-at-cost copies to those help out in docs, debugging, whatever. One could also do free, AS-IS licenses for small businesses or startups so long as their revenue is below certain point.
The only thing I didn't try to do is restrict by number of CPU's, servers, whatever. It seems natural in mainframes, clouds, enterprise, whatever. I'm just concerned about its effects on how product is used in terms of innovation or robustness. One example is desktop virtualization at level of individual apps for security or failure isolation purposes. Your user experience at OS level is still about the same given you're using same OS to run same apps. The deficiency of OS in isolation means you had to add a virtualization solution. So, should people be charged an extra $100+ an instance to make up for that deficiency? Or same thing in high-availability setup where extra nodes don't contribute to throughput? So, I'm undecided on usage licensing.
No it doesn't, it's not even close. Other companies tried to bring this same argument but failed. Some people think that the primary benefit of Open Source is having some level of access to the source code and fortunately this didn't fly, in spite of the effort of companies, such as Microsoft with their "shared source" initiatives. Open source [1] brings with it two major benefits:
1. the ability to use the software for any purpose, any field of endeavor, with no discrimination, for any business model. By your own admission, your license would be incompatible with such a contract.
2. open source can be forked, just like Monty here forked MySQL and (arguably) kept it from dying. The importance of this cannot be overstated.
But more to the point, you say you'd allow "fixes" and "local extensions", yet restrict redistribution to paying customers, but well, you clearly have boundaries in mind for derivate works, as you clearly only want to allow small improvements. Can those improvements be redistributed as source code, for the benefit of others? And if not, then clients could find themselves in a gray area. For example what happens if these clients hire contractors to provide those improvements? That's always possible with open source, just like how it is (still) possible to take your car to any repair shop. You can quickly see how this can go out of hand.
And the restriction for paying customers sounds awful - first of all, what's a "paying customer"? Do money need to exchange hands? Are trial versions permitted? What if you want an alternative business model, ads-based or whatever. Etc.
But the biggest benefit of Open Source is the right to fork. First of all, this implies that ownership over such software is achieved by anybody that wants it. And it's an important right, especially if things go wrong.
You say that you could maybe have a clause somewhere, or a promise, to make the software GPL should it become abandoned. Oh well, what is abandonment? Plus, abandonment is not the only bad thing that could happen. You could also steer the project in a direction that people don't want, you could intentionally cripple it, you could raise prices so much as to make it unfordable and when you get bored of it, you could simply sell it to another company. Notice how neither of these conditions do not classify as abandonment.
Now don't get me wrong. I have nothing against proprietary software, heck, I would be a hypocrite if I wouldn't admit to developing and making a living off of proprietary software myself.
But I see marketing attempts to redefine what Open Source means, only because Open Source is marketable, being extremely attractive at least to developers and for good reasons. And look, I get it, we need to make a living, but it's dishonest. Your product can survive and flourish as proprietary, but stop with the bullshit and call a spade a spade.
I said they could use, fix, or extend it with new versions shared with paying customers. I don't see how I've admitted it would be limited to anything you stated. The only limit is you have to pay to use it unless a free license was granted. Now let's move onto other points as you had some interesting ones.
"you say you'd allow "fixes" and "local extensions", yet restrict redistribution to paying customers, but well, you clearly have boundaries in mind for derivate works, as you clearly only want to allow small improvements."
The boundary is more clear than it appears: if the code is in your product or service, you are paying a license for it. That simple. You can always clean-slate an implementation of whatever subset of the features you need if that's too much. I should modify it to say the API can be used in compatible clones given Oracle's activities.
"Can those improvements be redistributed as source code, for the benefit of others?"
Yes. The software itself is distributed as source code with optional binaries for convenience. Any paying customer can receive it in this model.
"For example what happens if these clients hire contractors to provide those improvements?"
Then contractors provided the improvements. The user is still a paying customer. What's your question?
" first of all, what's a "paying customer"? Do money need to exchange hands?"
A paying customer is almost always formed in business by one party giving another money in exchange for some good. So, a paying customer is... someone who pays.
"Are trial versions permitted?"
Didn't think about that. Shareware was a big thing... a good thing... back when I started in computers. Gave us a taste of what the software was like with little to no money. I'd consider doing a trial period so long as the software was for a long-term, use case. With one-offs, they could just use the trial software. If no trial, then getting good reviews and a sales team would be solution like with most profitable software.
"First of all, this implies that ownership over such software is achieved by anybody that wants it. And it's an important right, especially if things go wrong."
Last I checked, the copyright situation for ownership of OSS software was more complicated than that. Has a lot to do with whether copyright was assigned by a contributor or something. Way better than proprietary situation with hardly anyone going after forks in practice. I give you that much.
"Oh well, what is abandonment?"
I thought you'd say that but don't have a good answer yet. As I wrote it, I remembered the record labels and others that do one minor thing with the copyright just to maintain it. Last time I thought through this, I figured the contract could be amount of developer time that goes into adding features, adding documentation, or fixing bugs. Project is abandonware if it goes under a certain amount for a certain period of time. Idea being owner is incentivized to keep improving it or drop it when investments no longer make sense. As others have stated, one can still charge for it even if it's free. There's many companies that do. So, money will come in at lower rates over time for any given project.
"You could also steer the project in a direction that people don't want, you could intentionally cripple it, you could raise prices so much as to make it unfordable and when you get bored of it, you could simply sell it to another company."
Prior discussion dealt with the selling part. I speculated these kind of deals would be best in nonprofits, public benefit companies, and so on whose charter maintained fair pricing, no acquisitions (or GPL on acquisition), perpetual licenses for each shared-source version (to avoid crippling), etc. I'm still wondering how much can be handled at that level. Far as steer in bad direction, that's a possibility that OSS has an advantage on. So, trust in the team is a pre-requisite for this model to work if you're worried about that. It's also a risk in FOSS in practice, though, given most software accumulating crud doesn't get forked, forks can break things in one way to improve in another, and forks might need critical mass of contributors to develop at similar pace. They're harder in practice than just pushing a fork button.
"our product can survive and flourish as proprietary, but stop with the bullshit and call a spade a spade."
Who is bullshitting? I'm calling it shared-source, paid software with certain benefits similar to OSS. I've also found tricks for approximating new advantages or dealing with new problems as you bring them up. I can't call a spade a spade if it's not a spade. I think OSS vs proprietary isn't a spectrum of benefits and tradeoffs instead of binary decision. So, I'm investigating new models. Definitely not saying they equal open-source: just can have many of same benefits for a proprietary product.
I've seen sites do this like readme.io but can you do that for a software library?
Found this to be a good overview:
I mean, it's genius from the business side. Unless i got the story wrong, he sold MySQL after people helped him create it. Forked it, and now it's turning the fork into MySQL/Oracle profit cow.
Either somebody correct me, or I'm going to assume "for as long as there's are sheep..."
Monty sold MySQL to Sun, he believed Sun would be good steward of the project, provide it the resources it needed, and allow it to flourish remaining Open Source
When Oracle bought Sun, Monty and most of the MySQL devs where very very very very very concerned that Orcale would be detrimental to MySQL going forward so they forked it and founded MariaDB to replace Oracle's mySQL
Some of their fears never came to be, but Oracle has closed the development of mysql is many ways, it is not as bad as it was orginally feared, but it no where near as open as it was under Sun.
To believe that MySQL was Sun downfall is extremely ignorant. Mysql was not even Sun's largest project.
Further mysql is still extremely popular where mariadb is less so.
It doesn't matter how popular it is, if you are going to spend $1bn of your shareholders money on it, it needs to generate the revenue - and Sun never figured it out.
It's not particularly relevant to the discussion.
This is a business and commercial issue, not a 'details of the license' issue. The text could take on so many forms, and it's not particularly useful unless you're a very startup and can't afford a lawyer.
Example:
What is the price? What are the terms of payment? What about discounts? What is a 'CPU' when you're using virtualized hardware? How do the terms hold up against IP rights in the rest of the world? (Europe has very different laws for Software).
It's great that there's some text that a company can grab, but any company that is going to be licensing software should eventually consult a lawyer about this.
Sold. I will be moving my project searchcode server over to this within a week.
Would also be a great motivation for developers to not test things in production, as it's cheaper to test them in the development/testing environment.
It's the responsibility of the licensee to make sure they are in compliance with the licensing terms (buy enough licenses to cover the number of CPU cores they are running in production), otherwise the copyright holder will sue them.
This idea of licencee self-compliance is not an innovative concept, it's how most licensing in large enterprise companies already works (and that's where this license is targeted), the company checks how many copies of the software they are running and pay that much.
It's not quite an honer system. Companies conduct regular audits (done by an external company) to prove they have everything licensed correctly.
However, it actually sounds like a great idea to me, and a great way for companies to make money licensing software to commercial users while still keeping it free and open source for individuals, while providing a safety mechanism in case the company goes belly-up.
If you want to redistribute, then you need to use the old buggy version. I don't really see a problem here.
If you want to use the latest-and-greatest in a non-commercial capacity, you can do just that. And it's open-source, so you can modify it all you want and use it. You just can't distribute it.
What's the problem?
No, it's not as Free as GPLed software, nor is it meant to be. It's meant to allow a company to make a profit on software licensed to other businesses or for commercial use, while still allowing it to be open-source, and allowing private individuals to use it without paying a license fee. (At least, that's how I read it from the article.) It sounds like a great way to balance the competing interests of a commercial software company, the users (both non-commercial and commercial), and the community at large. It would be a terrible license for basic infrastructure software like OpenSSH or PostgreSQL, but for business-oriented application software, it sounds absolutely perfect.
(Note, again, what I've written above about the way the BSL works is what I've gleaned from reading the article; if I'm incorrect, someone please feel free to correct me.)
The MariaDB corporation is also happy to accept contributions to the GPL and BSL code, so there is really no reason to do a fork, except for ones own personal gains.
When it comes to code, it's usually very easy to see if code was backported or created independently, so this shouldn't be an issue.
At this point I don't understand why anyone needing a MySQL solution wouldn't use Percona's packages.
Edit: yes, Percona not persona.
The open source freemium is cool, though. Those are two powerful forces.
Are we supposed to take this seriously?