
We are announcing something that we are very excited about: We decided to switch our core server-side (PowerSync Service) source code license from the Functional Source License (FSL), a source-available license, to Apache 2.0, a true open source license approved by the Open Source Initiative (OSI).
Why we chose FSL originally
Recap: FSL is a source code license that grants all of the freedoms typically associated with open-source licenses with one exception: it’s not permitted to re-use the code to launch a competing product. FSL enables free software, but prohibits so-called "free riding". Because of this, FSL is not technically “open-source”, because it doesn’t comply with the official open-source definition maintained by the Open Source Initiative (OSI), in which no usage restrictions are permitted.
We launched our Open Edition in May 2024 with an FSL license for the PowerSync Service, and Apache 2.0 for our client SDKs. At the time, we shared some important reasons behind that decision:
- It should be possible to self-host PowerSync indefinitely, no matter what happens to the company.
- We wanted to build PowerSync in public, because we think open source is a superior way to develop good software. As our CEO Conrad wrote: “Having a community of developers reviewing, giving feedback and contributing to code results in the best possible end-product."
- We never wanted to be in a future position where we “rugpull” our community by switching to a more restrictive software license. For example, if PowerSync were to become so popular that a big cloud hyperscaler starts free-riding off PowerSync, we foresaw that that could pressure us to change from an OSI-approved license to a more restrictive one.
What we learned: FSL didn't actually work well for us
PowerSync has been fortunate to experience healthy growth since launching the Open Edition. This has been possible due to an incredible amount of hard work by the entire PowerSync team, incredible engagement and contributions from the PowerSync developer community, as well as a solid dose of good fortune. Our Open Edition is widely deployed in real production environments, as is our Enterprise Self-Hosted edition, and PowerSync Cloud has also seen strong growth on both our Free plan as well as the paid tiers.
Initially, FSL seemed to be working well for us. However, more recent observations led us to believe that FSL was hurting PowerSync adoption, which prompted us to reconsider our source code licensing position:
- We received many enquiries from prospective users about whether their intended use case is permissible under FSL. In all cases, the answer was yes, but these inquiries made us realize that there’s probably significant survivor bias, and many prospects probably never even reached out in the first place. They might prefer an OSI-compliant license at the core, or they might believe FSL is too much of a legal grey area.
- While running prompt evals, we routinely found that agents loved putting a warning sign ⚠️ or a red cross ❌ next to PowerSync when it came to licensing. In other words we found that agents repeatedly flagged FSL’s non-OSI status.

We’ve also been seeing a community and ecosystem taking shape around PowerSync, and we want to support its growth by being reliable stewards of the project and maintaining our culture of building in public. We believe the best way to accomplish that is with OSI-approved open source licensing.
PowerSync has two sources of revenue that sustain its business model: paid plans on PowerSync Cloud, and our Enterprise Self-Hosted edition, which has some advanced closed-source features. Hence, we have an "open-core" business model. These paid offerings help fund our open source work. We publish an Enterprise roadmap so that contributors can understand our direction on closed-source features before investing their time on open source contributions. They are, naturally, welcome to implement whatever they want on their own forks.
Doubling down on open source
After careful consideration of all of the above, we decided to move the PowerSync Service from FSL to Apache 2.0 to give developers greater clarity on licensing and more freedom to build.
While it’s true that moving to Apache 2.0 also makes it easier for other companies to offer competing services using our code, we believe that the upside of clearer licensing, and associated broader adoption, is worth the risk. We’ve decided to optimize for maximum immediate clarity for our community rather than long-term hypothetical scenarios, especially with so much uncertainty in the industry at present around AI. Additionally, companies such as GitLab, Grafana, Supabase, Turso and more have demonstrated that you can commit to open source while building a successful business.
Clear rights make PowerSync easier to adopt, integrate, and extend. We hope that this results in a faster-growing community, which in turn will give us more opportunities to grow our commercial business, thereby accelerating the speed at which we can invest in our open source work.
