The first example of dual-licensing was probably Ghostscript, which Peter Deutsch licensed first under the GPL and later under the Aladdin Free Public License, but also under a proprietary license.
Inspired by his idea, David Axmark and I released MySQL under similar dual-licensing terms. Dual licensing has since become one of the most common and popular ways to create profit centers around Open Source/Free Software, in addition to support and services around the product.
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.
This is still reflected in the MySQL FAQ on this topic.
This is what I personally think is the appropriate way to dual-license open source software and how we intend to do it in my new company, Monty Program Ab, for the software we produce.
The MySQL OEM License
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:
(Sun has, of course, all rights to put any restrictions on their code, but as this is not how dual licenses used to work with MySQL or how it works with other Open Source projects (See for example, the license information for Ghostscript and .) You should however be aware of these issues if you intend to ever acquire a commercial license for MySQL)
- 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).
Recommendations to licensees and those considering the purchase of a MySQL license
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.
If you are running an old, modified, community, or forked version of MySQL at your company, you need to be aware that the default OEM agreement is not applicable to you. This also the case if you modify MySQL code to implement a new storage engine, MySQL extensions or if you are a hardware vendor that wants to to tune MySQL for your setup.
If you need to buy a commercial license, because you cannot use the GPL, you need to seriously consider if you can accept the default restrictions. If not, then you should contact Sun and renegotiate the terms. I know there are examples where MySQL licensees have been allowed to change MySQL code and also have the right to publish those changes (Infobright openly advertises that they've done so). You should ask to get those same rights.
If you plan to do dual licensing yourself, you also need to make sure that the license allows you to use an Open Source version of MySQL with your Open Source product.
When agreeing to a license, ensure that you get enough freedom to do what is required for your business and you are not completely dependent on one vendor for your success!
Recommendations for companies doing Dual-Licensing
I believe one should be very permissive when doing dual licenses with Open Source as otherwise you lose many of the business advantages you get from being Open Source. The Open Source community is a very effective ecosystem and if you allow it to participate with your business you have a better chance to succeed.
The only restriction you need when re-licensing is that the licensee should not be able to change the license of your code and they can only use and/or distribute the pre-negotiated number of copies of it.
- Allowing changes to the licensed code allows the licensee to combine community code and their own code in creating a better product. It also gives your customer more trust in your product as they don't feel locked into only one vendor for things like bug fixes and enhancements.
- Make it easy to use your product or part of your code with other products.
- Allowing re-distribution of the product creates a market for people doing addons, enhancements and totally new products based on yours.
- Don't be afraid of forks; They enlarge your ecosystem and anyone that wants to buy a license for these forks also has to buy one from you.
- Don't limit the license to a specific version; If you allow changes this is meaningless anyway as one can easily go around it. In the long run it's not a winning proposition to sell the same software over and over again to the same customer. Instead work on the software and with the customer to increase the usage of the software.
- Don't limit in any way how the product/code can be used; it just forces people to choose or develop other products that will compete with you and will limit the business you can create.
- Make the end-user license transferable. This is already allowed in many countries, it is what normal people expect from most things they buy and will create opportunities for new business by others. If you got paid for any copy of your software that exists, do you really care who uses it second hand ?
By being fair to others, you will get a reputation as a trustworthy business partner and you will get more business in the long run.
Recommendations to Community contributors
I assume for this blog that it's clear why it's beneficial for you to donate code to an Open Source project. (If not, then this could be a topic for another blog post).
However, 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. (Our contributor agreement wasn't clear in this aspect, so I recently added: "Each submission must explicitly be marked that it's donated under the MCA". You can of course also mark the code to be under BSD.)
If you agree with the above and you have signed contributor agreements that do not include such a note, you should consider contacting those projects and asking for a new one with such a clause or get some other public guarantee that the project re-licenses code in an appropriate manner.
Note that releasing your code as BSD for a project that has or may have GPL code doesn't protect your code from being dual-licensed in an unfavorable way. The only way to ensure full freedom for others is to only donate your code under a contributor agreement with a clause as suggested below or to a project that has agreeable guidelines for how they license their code!
To assure our users, contributors, and customers of how we at Monty Program Ab intend to re-license the code we produce or the code people donate to us, I have added the following note to our contributor agreement:
"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code."
If you have any comments/ideas around this, feel free to join the the maria-discuss Launchpad team and its associated mailing list and discuss this topic.
Interesting... I reckon a few companies won't be buying an OEM license from Sun if they aren't allowed to modify the source. I know of several companies which are using custom storage engines.
The GPL would suit them just fine anyways since they are not distributing source code nor binaries.
thanks for the good blog post. You have been inspired by Ghostscript's licensing model for MySQL - and so have we been inspired, but by the (old) MySQL licensing model when it ca,e to choosing the right model for our Open Source CMS (papaya CMS).
However, I feel that the current strategy of Sun might be doing harm to MySQL's licensing revenue. They are not what you'd expect from a company that has so much backing and from the open source scene (and has also gained so much from that community).
Let's hope that Sun simply needs some time and experience to find out that this is not what their clients (well, the MySQL clients) would expect...
Best regards from Germany,
From Sun's perspective, nothing has changed in our Dual Licensing implementation for many years. It has been substantially the same since you Monty were actively part of fine tuning the first principles that you and David established.
The restrictions of the commercial MySQL license are industry standard and talk about what others can do with MySQL code. Contributors under both SCA and CLA grant rights to us, but continue to own their own code and may thus do whatever they please with it -- including releasing and using it under the rules of the GPL. Those are all basic tenets of dual licensing (commercial rules for commercial licensees, GPL rules for GPL licensees) which I believe are widely understood and accepted.
What exactly is your new company going to dual license? Unless I'm mistaken, you can't dual license the Mysql fork, because you are using the GPL license from Sun/Mysql.
Are there additional utilities and such that are going to be independent enough of the Mysql codebase to allow a dual license?
About what Monty Program Ab could Dual-license:
Over time we at Monty Program Ab will produce a lot of code, tools and extensions for MariaDB and other products that could be dual licensed. I want to keep the options open to dual license these.
It's true that we can't dual license MariaDB as such (as part of it is owned by Sun). This doesn't however stop anyone from buying a license from Sun for the MySQL part and then buy a license from us for the MariaDB part.
The same is true for MySQL/MariaDB storage engine vendors and those companies that provides Dual-licensed extensions to MySQL/MariaDB.
In response to Kaj's comment that 'Nothing has changed':
The current MySQL OEM license was updated September 2008, after MySQL was bought by Sun. I don't know how the previous copy of the OEM license looked, but I do know that when I was part of deciding the OEM licensing scheme in MySQL Ab, it was very liberal (as described in my blog). I don't know when things changed (at least I was never consulted or even informed about it), but I know that the current one does not match my principles of how to do dual-licensing of Open Source software.
As you, Kaj, should know, one of my basic principles in doing business is that one should never write or propose an agreement that you would never want to receive or sign yourself. It should be more than clear to you that the current OEM agreement is, for me, not such a document.
As my blog already describes, the current commercial MySQL license does not follow the "industry standard" of dual-licensing (where did you get this idea?); MySQL Ab were much more open in the beginning (and for a longer time than the current limitations have existed) and other dual-licensed project are much more open. It's also clearly not what people expect from an Open Source project as it seriously limits other peoples possibilities to work, use, and do business around the product. I have gotten lots of comments about this, so that part is easily verifiable.
I strongly disagrees with the notion that you can have commercial rules for commercial license, GPL rules for a GPL license. People donate code in to a product because they are using it and intend to recommend and use it in the future. If the commercial license is not agreeable to them, there is no reason for them to donate time and effort to help the project. Why help someone that doesn't understand your needs and is working against you?
Because of that, I strongly recommend anyone doing dual-licensing take their users and contributors into account when defining how they dual-license their software. It's to everyone's benefit to have a liberal dual-licensing policy to create a working developer ecosystem around products that benefit a large number of people.
Does the OEM agreement allow the use of plugins? Does that include storage engine plugins?
How do you get bug fixes under this license? Is that covered when you also buy a support contract?
I understand the need to limit the agreement to a particular release as there should be different prices for a customer who only wants a license for 5.0.84 versus someone who wants a perpetual license for all future releases of MySQL. Without such a limit, it is not as easy to define the difference between fixing a bug, using the Percona patch, and upgrading to new versions of official MySQL.
However, I also think that opportunities are being squandered by Sun. If their agreements preclude external developers from having a chance at making money, then I suspect that many of those external developers will stop contributing via the CLA/SCA.
Monty, I think you're spreading FUD. You admit "I don't know when things changed (at least I was never consulted or even informed about it)" but you're spreading *FEAR* that Sun changed the OEM license.
You don't actually know that Sun changed it.
I think it would be best if you retracted the part of the post that slams Sun for changing the license, since you don't know that Sun actually changed it.
Thanks for the informative blog post, Monty. I think it's time for my company and myself to get away from MySQL, before Sun/Oracle decides to destroy it further.
Since PostgreSQL is the other major supported OSS DB, along with it's BSD license, that seems like a vastly better option. I don't need nor want commercial support, but Legal disagrees with me. Fortunately, PostgreSQL doesn't do support, they leave it up to other companies. Good luck with MariaDB!
In response to Sheeri:
Please read my post/comment again; There is no FUD involved, only facts. I did not say that it was Sun who has made the OEM license as restricted as it's now; I just said that, contrary to what Kaj implied, that I was not part in doing such a change.
When it comes to Sun, the only thing that is clear is the OEM license has been changed after Sun bought MySQL (just check the date in the license) and Sun has thus approved of the current content of the license.
The main point is however not if the change was done before or after Sun bought MySQL. The important thing is that the current OEM license for MySQL is something that in my mind is unacceptable when doing Dual-licensing on Open Source software. I think that people contributing code to an Open Source project should be aware of how they code are used and why it's important to know this.
I know that Sun is not the only company that is doing this wrong. However, now when the Oracle / Sun deal gets a lot of attention, it's important to know what Sun is doing so that we can help DOJ to and the EU commission to understand better where MySQL stands now and what they should do to ensure that MySQL stays free in the future. For this to happen, we need to be able to discuss things openly, instead of staying silent. This makes it difficult, since any criticism against Sun can always be called FUD, but anyone in the MySQL community must be allowed to have an opinion and to talk about it in public - that is how Open Source works after all. You can spread more FUD by not saying anything than by being transparent!
A final word about Monty Program. Our business model targets those who use the GPL version of MySQL (or MariaDB). We don't have a self interest in this topic. Sure if things were different, maybe we could do some other business too, but things are what they are. The only reason to bring this up for public discussion was that we were made aware of these problems by people affected by them. After publishing this we have also got feedback from other leaders in the community, that told us they did not know about this and they did indeed assume dual licensing worked differently and were thankful for the blog post.
In response to Mark:
If you use the standard OEM agreement, you can't use any non default storage engines, you can't fix bugs yourself or ask anyone to fix the bugs for you. You can get a separate support contract from Sun and hope that they fix the bugs you report in the version that you bought the EOM contract for.
I don't think there is a reason to limit an OEM agreement of Open Source software to a particlar versions as if you are all; It's gets too hard to define what changes you can apply or not apply without having to change the version number yourself. I think it's a better business model when you combine Dual-licensing with a separate support offering. This will allow you to get the money from the customer over time when he uses the product for new things instead of trying to get the customer to pay over and over for almost the same code (just because he wants to have the latest bug fixes that is just in the latest release)...
Via archive.org, one can see that the default OEM agreement included restrictions on modifying the source since at least June 2005.
I'm less worried about Oracle buggering MySQL than most. First, if Oracle creates a next generation version that is closed source, then a strong and very large community will assuredly branch off using the GNU GPL version.
Second, if Oracle follows the model that other 'commercial support of OSS' organizations are succeeding with, they could be very instrumental in helping MySQL become even more successful through 24/7 support line, quality assurance, centralized product management, and training/support/materials resources. These would be fee-based products and services, just like other successful OSS support companies have been offering.
The third notion is that more database applications are going to be emerging as strong competitors to MySQL in the coming years. And that is good for the marketplace. MySQL is awesome, but its far from perfect!
Look, ORCL can't do any worse for MySQL than SUN has...
Do you know if I have a library or framework under the GPL license and someone builds a proprietary software(custom web site) for just 1 customer, and hands over the source to this customer, can we say he is distributing the framework ? I mean in this situation do I have a right to ask him to publish the source for everyone or to buy a commercial license from me ?
Post a Comment