Between two consenting corporations...

Is proprietary software really that bad? Or is it a fair contract between consulting corporations? The answer is "It depends" and "Not really." Both depend on the strictures a vendor puts in place to inhibit its ability to lock a customer into its software. In MySQL's case, MySQL has no intention to lock customers in, as far as I can tell. It just wants to convince customers to pay so that it can prove its worth.

MySQL is contemplating introducing extensions to its core database that are only available to paid subscribers, for compelling reasons. This is not, as has been suggested, in and of itself proprietary. Red Hat does the same by providing an initial gate to its RHEL code which only a paid subscriber can access unless they get it from an existing customer of Red Hat's.

The question is not the open-source legitimacy of an otherwise open-source binary wrapped in a closed contract. This is simply a way of preventing services (like the Red Hat-provided compilation of that binary from source code) from free redistribution.

The question is one of redistribution of binaries.

There are actually ways to do this that let MySQL balance open source with closed permissions. I've drafted language for a license grant below that I think does this. It's not open source, but might be a way to balance its need for more cash growth with continued emphasis on community growth.

Grant to Licensee. For the term of this Agreement and subject to Licensee's payment of the Subscription Fee, Licensor grants Licensee: 1) the right to a non-exclusive, non-transferable, non-sublicensable, license to use and modify the Software only for Licensee's own internal use of the Software and limited to the number of Licensed Servers and 2) the right to receive Support Services and Maintenance for the Software. For the avoidance of doubt, this Agreement grants to Licensee a perpetual license to install and use the Software on the Licensed Server(s), including viewing and modifying the source code of the Software, but Support Services offered in conjunction with the Software must be purchased on an annual subscription basis.

Not open source, of course, because it prevents redistribution, which is a cardinal requirement of the OSI Definition.

Still, it's a step in the right direction from proprietary software (albeit a step in the wrong direction from open-source software), because it allows for free access to source code and the ability to modify it. Such rights are perpetual. The right to redistribute, alone, is withheld, which hurts competitors but not customers.

The question for me is whether it also hurts community. The question is not immaterial. There's a suggestion that MySQL and others don't monetize enough of their downloads, but this overlooks the other side of the issue: Perhaps they wouldn't have any monetization at all (or not nearly as much) without deep, free distribution, as MySQL has.

Open-source companies have at least three choices:

1. Proprietary extensions that don't allow the licensee to view, modify, redistribute, etc. the code;
2. Extensions (or the core) that are GPL'd (or licensed under some OSI-approved license) and which are initially gated to paid subscribers but which can be redistributed (as RHEL is) and which allow subscribers to also view and modify the source code;
3. Extensions (or the core) that are licensed under a non-open source license (as I drafted above) but which allow source code to be viewed and modified, just not redistributed.

Of the three, I prefer the second option, but the third is also better than the first. Much better. It leaves customers free to modify code to their requirements.

Back to community. Open-source companies that opt for a hybrid approach will always have the temptation to close off the very things that the customer cares most about, which tends to lock the customer in. The best way around this is to institute a licensing regime that doesn't lock a customer in, even if it gates initial access. The second and third options above do this.

What about those in the would-be user community that might not be willing to use a project that has closed extensions? Most won't care, I suspect (which is not necessarily a good thing). For the vast majority, they will almost certainly never experience this as the extensions are selected to only cater to true enterprise applications of the code. Done right, these commercial extensions will only be needed once a developer has fully vetted the project to ensure it meets her needs.

This, however, is the problem: It's very hard to determine if the project "meets one's needs" without the ability to fully vet it. Perhaps MySQL could accomplish this through a 30-day evaluation period of the extensions....?

Andy Astor of EnterpriseDB has taken comfort in MySQL's move, suggesting that we'll all be hybrid someday. But arguably EnterpriseDB started with the wrong end of the hybrid. Adoption, as Simon Phipps suggests, is the first order of business. Not control and absolute monetization. I believe EnterpriseDB's cool technology would be all the better for having open adoption.

Does this suggest that open-source companies will go through phases of varying levels of openness? Perhaps. But if the way to succeed is by becoming the very thing we disrupt than who is ultimately going to care about open source?

At any rate, it's a compromise. MySQL, in this case, or any open-source company employing this strategy, trades widespread adoption of its extensions in order to get a lesser (but it hopes significant) contingent that will pay for them.

Time will tell if it is giving up more than it gains.