Skip to main content

Licensing Changes FAQ

Written by Christoph Sonn
Updated over a week ago

FAQs

1. Is Safe moving away from “open source”?

a. No. Safe’s smart account, user interfaces and all developer SDKs remain open source. Only new releases of a defined set of service-layer components operated by Safe Labs change to a Functional Source License (FSL). These components are part of the operational infrastructure required to run Safe reliably, not the onchain protocol itself.

b. The updated license ensures that:

  1. The code remains visible and auditable.

  2. Internal and non-commercial use remains free.

  3. Competing hosted or managed services cannot immediately commercialize the latest releases without a license.

  4. The code automatically becomes permissive open source (MIT) after a fixed sunset period of two years.

2. What is the difference between MIT, GPL-3.0, FSL, BSL and Proprietary licensing model?

a. MIT (permissive open source)
Allows broad reuse, modification, distribution, and commercial use with minimal obligations. It does not protect the code from being exploited by third parties who can extract commercial value from it.

b. GPL-3.0 (copyleft open source)
Allows reuse and modification, but if you distribute derivatives, you generally must release source under GPL as well. Strong “share-alike” obligation.

c. FSL (Functional Source License) – “source available” with anti-competing-use clause
Code is visible and reusable for Permitted Purposes, but not for “Competing Use” (i.e., offering a commercial product/service that substitutes for the software or similar functionality). It explicitly permits internal use, non-commercial education/research, and professional services provided to a licensee using it

d. BSL (Business Source License) – “source available,” typically restricts production use until a change date. You can copy/modify/redistribute and make non-production use by default; production use may require an Additional Use Grant or commercial license. Later, it “changes” into an open source license (change license) on a set timeline.

e. Proprietary / “All rights reserved” (closed or no public license grant)
Copyright holder keeps all rights unless they grant them via contract. Source may or may not be published; if published without a public license, visibility does not equal permission to deploy/redistribute commercially.

3. Does this mean that the code will be not-auditable now?

No, the code is still auditable. The stated approach is to keep source code publicly available for transparency and auditability.

4. Will developers have to pay to build on Safe?

a. If you are building on top of Safe smart contracts: no, this does not affect you.

b. If you are using the SDK and APIs to interact with Safe accounts: no, this does not affect you.

c. If you are running the services commercially for others to use: please get in touch with us to discuss licensing options: partnerships@safe.global.

5. What repos are going to be affected by this?

Please see the GitHub to know if the repo you are interested in will be affected by this change

6. I cloned a Safe repo — what happens to me now?

Nothing retroactively changes for what you already received under the original license. Going forward:

  1. If you keep using an older version that was published under MIT/GPL/etc., you can generally keep doing so under those terms. However, these versions might not be maintained over time.

  2. If you pull newer versions that switched to FSL, your rights regarding the code added for new releases depend on the new license terms (and may require a commercial agreement for certain uses).

7. I’m running a modified Safe internally for my DAO or company — am I affected?

Usually not, if:

  1. You’re using the open-source layer (contracts/SDKs), and/or

  2. You’re using FSL-licensed components for internal use (FSL’s “Permitted Purposes” explicitly include internal use).

8. I deployed Safe for a client as part of a consulting engagement — does that count as commercial use?

a. In most cases, no.

  1. If you are deploying or integrating Safe smart contracts or using SDKs as part of a client engagement, this is generally considered “building on Safe” and is not affected.

  2. If you are hosting or operating Safe Labs’ service-layer components as a paid or managed service for others, this may be considered commercial use depending on the component and release.

b. If you’re unsure, or your use case involves running these services on behalf of clients, please get in touch with us at to discuss the specifics: partnerships@safe.global

9 I’m offering Safe setup as a paid service — is that resale?

a. Not necessarily.

b. What’s clearly OK:

  1. Paid setup, configuration, and onchain deployment of Safe smart accounts for clients

  2. Advisory, training, or operational support around Safe usage

  3. Building custom workflows or integrations using Safe smart contracts and SDKs

c. What may require a license:

  1. Operating a hosted or managed service that offers Safe-like functionality to end users

  2. Running Safe Labs’ service-layer components on behalf of others commercially

10. I run a managed service where Safe is one component — does this apply to me?

It depends whether Safe-derived restricted components are a substituting core of what you sell. FSL draws the line at “Competing Use” (substituting for the software or substantially similar functionality). If Safe is incidental and you’re not offering “Safe-as-a-service,” you may be fine; if it’s effectively the product, you likely need a license.

11. I’m building a UI or frontend on top of Safe — am I impacted?

a. If you’re building your own UI that interacts with Safe contracts/SDKs, usually not.

b. If you are forking or customizing existing open-source UI components, this change does not apply, as user interface licenses are unchanged.

c. The licensing update applies only to new releases of specific service-layer components, not to frontends or user interfaces.

12. I wrapped Safe inside another protocol or product — is that considered redistribution?

a. If you’re integrating with Safe (calling contracts, using SDKs), that’s standard “build on.” No changes.

b. If you’re operating FSL-licensed service-layer components (or providing them as a commercial hosted substitute), that’s where redistribution/competing-use rules can apply.

13. What happens if our provider doesn’t comply with Safe licensing?

If a third-party provider is offering you a Safe-based service using restricted components without the needed rights, they may be exposed to enforcement and could be forced to change/stop the service — creating continuity risk for you. The safest path is to ask your provider what Safe license path they are on (e.g., authorized partner license).

14. How does Safe enforce this without becoming centralized?

a. Enforcement is handled through licensing and commercial agreements, not through protocol-level controls.

b. Safe’s onchain contracts remain open and permissionless, with no technical restrictions or “kill switches.” The licensing terms apply only to offchain service-layer software and govern how it can be commercially operated or distributed.

c. This approach preserves decentralization at the protocol level while setting clear, non-technical boundaries around the operation of specific services.

15. Does this apply cross-chain?

Licensing is about software rights, not chain jurisdiction. If a component is under FSL, the restrictions apply regardless of which chain you deploy/use it on. (Chain choice doesn’t change copyright/licensing obligations.)

Did this answer your question?