One ideal is the open development model, where anyone can come along and submit patches, where multiple companies can conspire to create a project, and so on. O

One ideal is the open development model, where anyone can come along and submit patches, where multiple companies can conspire to create a project, and so on. Open core, where you have a central project that is open source, then a number of plugins that are less open source, is the better model towards this goal. The worry is that members of the community will begin recreating features that have already been added to the paid version, and releasing them as open source. Under the BSL, you have a tension here because the paid version will become part of the free version in a few years. Under open core, you'd ask the community members to release the feature as a plugin, and the two separate plugins can coexist. The other ideal is the principle of free software being like software I would write myself. MIT and the unlicense are strong versions of this, where I can use them in (nearly) any way I would use software I had written from scratch. The BSL is the better model for this, because it entails paying for software that, in a few years, you will own in this strong sense. Open core entails no such guarantee, and if the company producing it went under, there is no guarantee that they would release the source code under a permissive license. I think the impetus behind their decision is that they didn't observe a strong open development community, so they didn't feel they would impact that too strongly by using the BSL. The really interesting license would be a combination of both, that is having a truly open core, then licensing everything else under the BSL or equivalent. This is probably avoided for the complexity factor, but would probably entail the best of both worlds.