When we originally released BSL 1.0 together with MariaDB MaxScale 2.0 in August 2016, we were acutely aware that using a license not approved by the OSI equates swearing in the church (or your other favourite place of worship). That’s why we didn’t beat the BSL drum, just the MaxScale drum. We tested the waters, and after a while approached the authorities on Open Source. Specifically, based on earlier relationships from the late 1990s, we asked Bruce Perens to review the BSL. Bruce Perens is the founder of the Open Source Initiative, together with Eric Raymond (The Cathedral and the Bazaar).
Bruce had a number of comments , that have flown into what is nowBSL 1.1. From the perspective of MariaDB MaxScale users, nothing really changes. The changes aim at enabling the BSL to be a viable license for other vendors than ourselves, by setting consistent expectations for users and customers, about what the BSL is.
Take the Creative Commons. Great thing, but there’s many varieties of it, so you need to spend time evaluating the fine print. Given that BSL also allows for a parameter section, Bruce saw a need to constrain that parameter section. We concur. Out of three parameters, we managed to put clear constraints on two.
First, the duration of the time window, as defined by the Change Date. “This software will convert to Open Source in ninety years” is a possible BSL 1.0 parameter, but it makes little sense. Now there is an automatic cap at four years. That said, we encourage a shorter window (and for MariaDB MaxScale, the window is between two and three years).
Second, the Open Source license when the time window closes, as defined by the Change License. Even amongst OSI approved Open Source licenses, there are some odd ones. Now we require the Change License to be GPL compatible (you may pick between GPLv2 and GPLv3, or any other license that can be combined properly with GPL software). And you can add additional change licenses as you desire.
Third, the Use Limitation. There we failed at identifying a reasonable least common denominator, as software comes in so many different shapes. Even “non-commercial use” is hard to define. As an example, we want to enable App developers to distribute their free versions under the BSL, where a payment trigger would be getting rid of ads. And what exactly is commercial use? Internal use, where you save a lot of cost, in producing value for your own customers? If the users earn money directly or indirectly the developer should be fed.The outcome: We updated the BSL to accommodate these changes. We straightened the language, with the help of Heather Meeker of O’Melveny & Myers LLP [*]. We updated ourMaxScale specific and vendor oriented BSL FAQ s. And while our next MariaDB MaxScale releases [**] will use BSL 1.1, the more important part is that other vendors are in a better shape using a license endorsed by Bruce Perens. [*] Heather is author of Open (Source) For Business: A Practical Guide to Open Source Licensing , and has been a pro-bono counsel to the Mozilla, GNOME, and python foundations, so who better to ask than her. [**] To be specific: MariaDB MaxScale 1.4.5 (released 8 Feb 2017) is GPL and the following maintenance release MariaDB MaxScale 1.4.6 (whenever that may be) will remain GPL. MariaDB MaxScale 2.0.4 (also released 8 Feb 2017) is BSL 1.0 but the following maintenance release MariaDB MaxScale 2.0.5 (whenever that may be) will move to BSL 1.1. MariaDB MaxScale 2.1.0 will be released under BSL 1.1 from the start.
So, our suggestion to our fellow software vendors: Take the BSL. Build your business model around it, over time. During the time window, you’ll pay your developer salaries, and when the window is closed, you’ve contributed to the world of Open Source. It’s authentic, it’s honest, it’s fair for your users, your customers, your developers and your shareholders alike. Go BSL!
本文数据库（mysql）相关术语:navicat for mysql mysql workbench mysql数据库 mysql 存储过程 mysql安装图解 mysql教程 mysql 管理工具