Thoughts about Dual-licensing Open Source software

History

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.