Hi Kaj Yes you did answer all my questions. Thanks for that. I disagree about point 2, precisely the "reasonable number of years" a server software should be supported. Even if a software is very old (say MySQL 5.0 for example) it is very possible that new security holes are found. That's why customers using servers/versions which reached their EOL should definitely upgrade to a more recent version. (yes there are exceptions, but I'm talking about the general case) Let's get back to your example: on 2019.01.02 MaxScale 3.0 could be out and GA. Should we expect the typical user to be ready to upgrade? Based on my experience, definitely not. They need time to decode, plan, test, etc. The possibility that 2.0 will be discontinued (or almost discontinued) immediately after the Change Date is scary, and your answer doesn't provide any guarantees that this won't happen. So, as much as I appreciate your honest answers, and as much as I like the software itself, I am seriously concerned. And also, let me add that I don't like to use a software that is not (yet) open source. I totally understand the problems explained by Monty in his blog post, but I don't like the solution you've found. However I am glad to hear that you don't have plans to do the same changes to connectors and storage engines. If I may give an advice, maybe the Foundation should officially "protect" that software to dissipate any doubt. Regards, Federico -------------------------------------------- Mer 17/8/16, Kaj Arnö <kaj@mariadb.com> ha scritto: Oggetto: Re: maxscale 2.0 bug fixes A: "Federico Razzoli" <federico_raz@yahoo.it>, maria-discuss@lists.launchpad.net Data: Mercoledì 17 agosto 2016, 20:23 Hi Federico, Thank you for your questions. Wed, 17 Aug 2016 08:15:33 +0000 (UTC) Federico Razzoli <federico_raz@yahoo.it>:Hi all I see that MaxScale 2.0 will not be open source until 2009.01.01. I have some questions. 1) I expect next releases to fix bugs, including critical and security bugs. When will these versions be open source? 1. Fixes to 2.0 will be in 2.0.1, 2.0.2, 2.0.3 and so on. All of these will become "GPLv2 or later" on 2019-01-01. 2) At some point MaxScale 2.0 will be open and 3.0 will be released but not open. When a software exists in both an open and a closed source, I expect the open form to be low-quality. This applies to all examples I can think of. I will feel a bit better if you could explain why you will maintain 2.0 for a reasonable number of years. 2. At some point (say: 2019-01-02), MaxScale 2.0 will be "GPLv2 or later", but another release (say: MaxScale 2.1 or MaxScale 3.0) will not yet be "GPLv2 or later" but still BSL, correct. MaxScale 2.0 will by then have gone through a list of bug fix releases. I don't expect there to be many bugs left in the MaxScale 2.0 code on 2019-01-02. In a way, what I am saying is that the period until the Change Date is already "a reasonable number of years". What the *exact* situation is on 2019-01-02 depends on how many new releases we will have by then. At any rate, we want to grow the user base of MaxScale. We are interested in large-scale adoption. There won't be much adoption if we don't fix bugs for a "reasonable number of years". All in all, on 2019-01-02, MaxScale 2.0 will be bug-wise of high quality and the only reason to use 2.1 (or 3.0 or whatever) instead of 2.0 will be the added functionality on top of what 2.0 has. So MariaDB Corporation has a high motivation to add desirable functionality. 3) From my understanding part of MariaDB code belongs to Oracle, thus cannot be closed-sourced by you. But what about connectors and some storage engines? Do you plan to change their license? 3. Correct, MariaDB Server cannot be closed sourced by us. We have no current plans for changing licenses of any connectors or storage engines. Thanks in advance for your answers.Federico Did this answer your questions? Kaj-- Kaj Arnö, Chief of Staff MariaDB Corporation