One of the knock-on effects of Oracle buying Sun buying MySQL is that Monty Widenius, co-founder of MySQL, has started offering some fairly pointed commentary on the goings-on in his old company. Here's the latest one, which notes something...
One of the knock-on effects of Oracle buying Sun buying MySQL is that Monty Widenius, co-founder of MySQL, has started offering some fairly pointed commentary on the goings-on in his old company. Here's the latest one, which notes something interesting:
To be able to bootstrap MySQL Ab, we originally had a license that allowed free usage, but a "pay-for" license if you used MYSQL for commercial usage or on the Windows platform. In 2000 we changed the free license to GPL, mostly to avoid having to explain our own license to everyone.
The basic idea for our dual-licensing was this: if you bought a license then we waived the GPL restriction that you have to redistribute your code as GPL. You could change, modify, extend, distribute, and redistribute the copy in any way you wanted (but of course not change the license of the MySQL code). The license was for any version and usage of MySQL, for now and forever.
I was recently made aware that the above is no longer the case with the standard MySQL OEM agreement. Sun is now, by default, putting the following limitations on their licensees:
You cannot modify MySQL in any way (for example to fix bugs, optimise MySQL for your applications, include publicly available enhancements (such as the BSD licensed "Google patch" or compile it with another storage engine) to improve your MySQL as part of your product.
You cannot use any forks of MySQL (such as Drizzle, ExtSQL or MariaDB).
You are tied in to the current major release of MySQL enterprise (i.e. you have to pay for upgrades). This may be normal in a closed source environment, but not normal when it comes to Open Source.
There are serious limitations for what kind of applications you can build with the MySQL code, for instance, the default agreement prohibits installations in hosting facilities or to use your version as a SQL server.
The end user can't transfer/sell the license to someone else (to be used under the same conditions).
Because of these fairly major changes, Widenius suggests:
With above limitations in place, you should consider if it's worth it to you to buy licenses for MySQL under the current terms. Also, if you are an old licensee of MySQL, you should be careful to review any new conditions when your license is up for renewal. Note that this warning is not something specific to Sun but applicable when working with any software vendor.
This is an important point. Although dual licensing has become perhaps the principal way of earning money from free software, not all dual-licensing schemes are equal. Indeed, as the MySQL experience shows, the dual-licensing terms are not even fixed, but might change according to the views of the company that owns the code's copyright. This makes it crucially important to review those terms on a regular basis in case there have been alternations that affect the value of the licensing deal.
He also has some very pertinent questions for anyone working in a company and contributing to dual-licensed open source projects – something that probably applies to a fair few readers of this blog:
when donating your code to a an Open Source project that is using dual-licensing, you need to also consider how the project is going to use your code when re-licensing it under a non-Open Source license. This is very important if you ever want to license the project yourself under a commercial license (not Open Source).
What are the restrictions on how you can use the re-licensed work? (Ideally it should be usable for any purpose and in any manner).
What changes can you make to the code when you re-license it? (Ideally there should be no restrictions, except that you can't change the license).
Can an licensing agreement be used to restrict the licensee's possibility to publish their own code as Open Source, or to include Open Source code in their product?
Is the re-licensing agreement tied to a specific version of the project.
Is the contributor agreement for the project clear in terms of how you may donate code to it? Can the project, for example, take any code you ever send to any related email list or do you need to explicitly sign every contribution separately.
It's really great to have Widenius' voice added to the debate around these issues: few have greater experience than he does, and he is not afraid to express his opinions, which makes for lively reading and discussion. I look forward hearing what Monty says in the future.