Earlier this month, Sentry announced a new software license called the “Functional Source License.” The announcement has a tagline “Freedom without Free-riding”. It purports to address some of the issues with the Business Source License.

An improvement?

It does, in fact, address some issues with the Business Source License. The Business Source License is less of a license and more of a homework problem for a combinatorics class. It has many options that materially change the terms, so being told that software is under the Business Source License doesn’t tell you much. The Functional Source License has one choice: does the license change to the Apache Software License or the MIT license?

While the Functional Source License does reduce complexity, it still suffers from the same problem: it’s not open source. That’s not a problem in itself; it’s a problem because it tries to co-opt the well-known “open source” label without actually being open source. Ultimately, these are attempts to use a license to address a business model problem. As we all should know by now, open source is not a business model.

The “right” approach

I’ve seen some people ask “then what’s the right approach?” The answer depends on what it is you want to do.

If you’re trying to achieve ubiquity, make the source fully closed and give it away to people who aren’t going to pay you money anyway. Or go with a “freemium” or “open core” model.

If you want your users to see the code so that they can trust it, then just make it source-available. This doesn’t make a lot of sense in a software-as-a-service context (which is what the Functional Source License is geared toward) because the user has no way of knowing that the code they’re inspecting is that the code you’re running.

If you want to get community contributions, use an open source license. Otherwise, you’re the free rider. A copyleft license won’t prevent competitors from building a product on your software, but it does prevent them from keeping their changes to themselves.