Sentry has brought yet another software license into the world – the Functional Source License – in an effort to balance user freedom and developer sustainability.
Sentry, a platform for error monitoring, adopted the Business Source License in 2019. While the company insisted at the time that the move was primarily to standardize one open-source license over all its products, it also listed “protection from other companies selling our work” as a factor in its decision.
Now, four years later, Sentry is shifting once again with the Functional Source License. Again, the goal is to stop the code from being used in rivals’ products, but this time, the non-compete time period is being cut from three to two years, and a Permitted Purpose clause has been added, preventing the code from being reused in a commercial product.
There’s remains a definite flavor of BSL to it all.
According to Sentry: “In plain language, you can do anything with FSL software except economically undermine its producer through harmful free-riding. You can read it, learn from it, run it internally, modify it, and propose improvements back to the producer.”
After two years, the license switches to Apache 2.0 or MIT.
Sentry says:
The company noted that the three years of its BSL was “probably too long,” and there will be open source advocates that will feel the same way about two years – or even two weeks.
Joe Brockmeier, Head of Community at Percona, said he approves of the intent but is worried about how FSL would implemented. He is also concerned about how vulnerabilities would be dealt with: if, for example, somebody discovers a zero-day issue in the project code covered by FSL, and that also exists in earlier versions that are available as open source – should the company owning the project update all the versions, or would this be down to the community to roll out?
“Would the company and the community collaborate?” he asked.
“Without getting some effective and understood policies in place, this seems ripe for finger-pointing and potential problems over time.”
The world of open source licensing is certainly becoming increasingly nuanced as companies mull how to protect their investments while still describing themselves as open source vendors. Or as source available vendors, as the case may be.
Brockmeier went on: “All of this really comes down to the same issue: single vendor stewardship isn’t great for open source projects that function as infrastructure … it’s a terrible model when you are supporting large swathes of infrastructure, and where you want to have vendor choice around how you support that infrastructure over time.”
He added: “It’s great to see more people looking at how to help software projects be more sustainable for the long term. FSL is another approach that is worth discussing. It might fit some companies and some projects. But we also have to look at the bigger picture for open source as a whole, too.” ®
