Applying BSL to the MaxScale proxy is proving to be, so far, an unpopular decision among a large segment of the MySQL community.
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.
Most usage of MaxScale is one of the following:
- One Master with one Slave (for backup and high availability)
- Galera with 2 masters and the Galera Arbitrator
This covers possible 90% or more of the common usage cases.
MaxScale is usually included in the MariaDB enterprise subscriptions and one can also get standalone licenses for MaxScale.
You highlighted the limitations of the license: as soon as you're into commercial terms, and money starts changing hands - things start to get very situationally specific.
Its easier to procure paid for software than open source in many large enterprises.
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.
Paid for software usually comes in two flavours: turnkey or with consultants. In both cases the promise is that the software will in the end run, and those who need to will actually be able to use it. Also, that the software does something that should be useful to you.
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.
> Open source software comes "AS IS", WITHOUT WARRANTY OF ANY KIND.
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.
I'm not talking of the proprietary license, but of the exchange between buyer and seller. I've never talked to an Oracle salesperson, but I doubt that they'd say that the software isn't guaranteed to run and/or be useful.
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.
Agree. However Dual licensing (on GPL) only works with software that other companies want to embed into their Software.
BSD was created to give similar benefits as Dual Licensing for software, like MaxScale, that is not embeddable.
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.
I don't say this lightly, but wasn't the open source license of MySQL the main source of its success? As I recall, it didn't really get huge until they loosened up the licensing terms. And wasn't that one of the main reasons it made $1 billion? Not criticizing – his business is his business. Just curious.
Would PHP have become popular if MySQL had maintained a strict license? I wasn't a web developer at the time and am genuinely curious what the database landscape was like back then.
Postgre would probably been used instead. The demand for an easy to use Web scripting language existed, php fit the bill that's what pushed mysql to become popular.
I kind of doubt it. The Windows port of PostgreSQL was kind of lacking for a long time (8.0, released in 2010, brought the first native Windows server version) and a large group of PHP developers were Windows developers.
I don't remember Postgres having much traction around 2000 or before.
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.
MySQL replaced mSQL [miniSQL]. A bare minimum SQL server that didn't even have table joins. But was used with PHP on the web regardless. Because the alternate was to code your own text file database. MySQL was so much better over it all.
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.
PHP was supporting MySQL way before MySQL was Open Source.
MySQL was released in 1995 under a liberal but commercial license (You should pay if you make money with MySQL) but was changed to GPL in 2000 "when we had got enough money in the bank to be able afford the switch".
Did you read the article? It addresses this question and talks about the reasons to use the traditional style open source license that MySQL used vs. this new BSL license.
One of the HN Guidelines is to avoid that introductory bit:
> 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."
The article does not discuss the history of MySQL. MySQL existed for 5 years before it went GPL[1]. Understanding what license was used for the first 5 years of the company and whether that impeded success would be useful.
Not that MySQL was created before Open Source was coined.
MySQL was hugely popular (several millions of users) way before it was GPL.
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 think it is a great idea, you can charge when people use it in production and it reverts to oss on a specific date.
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.
As was pointed out elsewhere, it becomes GPL, which is not normally unencumbered enough for escrow, where you get unrestricted rights. You also want them immediately on failure, not after the timeout. So it doesnt work well for this use case.
But that's the point, top parent was suggesting this as a replacement for commercial escrow. Most people wanting commercial escrow would not be satisfied with this.
I have been in several business discussions regarding source code in escrow and in all of them they have agreed that having the code released as BSL or eventually Open Source would be ok with them.
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.
This is great from the perspective of contributing intellectual property back to the ecosystem. They are trying to balance the revenue aspect with growing an open community which benefits the product as a whole.
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 old versions of MaxScale will of course get security and critical bug fixes.
The MariaDB corporation will also accept patches to the GPL and BSL versions of the code.
This interesting given I brought up a similar model talking to people here. I agree with the founder that licensing trumps support agreements in terms of supporting development of the product. He didn't even mention amassing patent portfolios or defending patent suits. These are relevant given big tech uses them to stop competition. Development, sales to increase amount of it, and legal investments all take much money. Licensing from paid users is best way to get that.
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.
3. open source software projects (and distributions, e.g. Debian) usually don't want to be dependent on non-open source software. And they are usually very strict with licenses, so "almost open source" won't cut it. So I think BSL licensed software would get less adoption and less of the "free marketing" that open source software normally gets.
"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."
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.
This is a little off topic and maybe controversial because it is against the spirit of open source but in all earnestness if you make a software that you want to make available to all open source projects but then you want to charge a recurring monthly fees if the software is being used to make money - is there a standard license for that?
I've seen sites do this like readme.io but can you do that for a software library?
It's called a dual license. And yes, you can do it for anything. Copyright is automatic, and it grants you control over the right to copy your creation. You just need to make sure you're the one that created it.
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..."
WHile I despise this new licensing, your redition of history is not correct
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.
It was symptomatic of their lack of financial control thats for sure.
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 did not have enough time to become profitable. Sun bought Mysql in 2008, they were looking to sell to IBM in late 2008/early 2009, and by April 2009 had a tentative deal with Oracle...
This licence is the basis for a business model - and should not be considered along side gpl, mit etc..
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.
Going to be interesting seeing how they will figure out where to draw the line (in legal terms) between testing and production. Would health checks be considered as testing the system or production type work?
How can you accurately measure that via software though? What differentiates a developer from a user or a customer? IMO these are hard problems to solve and problems which are not worth the engineering effort to attempt solving.
It's not a software issue, the licensee has access to the source code and can modify it in anyway they want, including removing any software-enforced licencing restrictions.
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.
When I see the abbreviation "BSL", I can't help but think it stands for "bullshit license"....
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.
There is nothing the individuals can do with the open source version. It's old and has bugs and maybe security issues.
In theory they could look at the source of the "commercial" version, but then have to be careful - they can't change it and if they ever write code they have to be careful about not doing plagiarism.
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.)
This might create some complicated situations when the older versions become free and somebody decides to fork it to fix bugs that are present in the old (free) version, but fixed in later (not-free) releases. I believe then you end up with the question was this fix back ported from new version or did the developer come up with it independently.
When it comes to MaxScale, the older versions will get all security fixes and also critical bug fixes.
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.
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.