Dify Might Not Be Open Source Software? | Starting from a Pharmaceutical Company Receiving a Dify Lawyer Letter

Recently, an “interesting story” appeared on GitHub.

A pharmaceutical company’s series of operations while “using” Dify got many developers involved in the gossip.

But during the gossip, everyone discovered another issue:

Dify might not qualify as “open source software.”

Considering that many companies and independent developers plan to use Dify to build their AI applications or workflows,

I think it’s necessary to analyze its license agreement.

*This article represents the author’s personal opinions and should not be considered as legal advice or opinions.

I. The Pharmaceutical Company that Modified Resources and Submitted PRs

As an LLM application development platform, Dify occupies half of the low-code AI workflow market domestically alongside Coze.

Especially since Dify can be deployed locally and is officially promoted as “open source,” many companies and independent developers try to use it to deploy a local AI service backend.

The pharmaceutical company was no exception.

But the employee tasked with this deployment was a bit of an “outsider.”

Including but not limited to:

1. Pushing locally modified content to the Dify main repository and applying for merge (Pull Requests, PR)

The normal usage method is to clone a copy of the software code to your local machine for modification and use via Git’s clone feature. The PR method is only suitable for optimizing, fixing, or adding features to open source software code, which belongs to collaborative development.

2. Including key files in the submitted modifications

3. Leaking their own public email password (resulting in suspected account theft and sending abusive emails to all Dify developers)

4. And of course, the trigger for the “open source dispute”: modifying Dify’s ICON

Under the watchful eyes of various developers, Dify’s official team quickly responded by entrusting their partner law firm to send a “Lawyer Letter” to the pharmaceutical company, pointing out that their usage violated Dify’s “Open Source License.”

However, it was precisely this “Lawyer Letter” that led developers to re-examine Dify’s License published on GitHub.

They found that it might not be “open source.”

II. Dify Might Not Meet the Definition of “Open Source Software”

Dify is divided into Community Edition, Cloud Service Edition, and Commercial Edition.

The Community Edition’s code is placed on GitHub for the public to deploy and use for free.

However, Dify does not use a common open source license. Instead, it “modified” its own version based on Apache License 2.0.

DeepSeek’s translation of Dify’s latest version License is as follows:

It can be seen that although Dify allows other developers to use it for commercial operations, it prohibits multi-tenant services and modifying the ICON and copyright information.

However, these two points may already conflict with the Open Source Initiative’s (OSI) definition of “open source.”

Multi-tenancy is also a form of commercialization.

What is multi-tenancy?

“Multi-tenancy” is a concept in software architecture that refers to a system’s ability to serve multiple independent users or customer groups (i.e., “tenants”) simultaneously, with these tenants being isolated from each other.

“Multi-tenancy” is a common business model (such as SaaS services).

In its license, Dify defines a workspace within Dify as a “tenant.”

If a user creates multiple workspaces, it constitutes “multi-tenant” use, which violates Dify’s authorization agreement.

But the OSI’s definition of “open source software” explicitly states that it must not restrict the software’s use in specific fields, including commercial use.

Dify’s license restricts a certain type of commercial use, which clearly conflicts with this principle.

Moreover, Dify’s license is vague about what constitutes “multiple workspaces”—whether it’s “a single Dify backend not allowing multiple workspaces” or “not allowing the creation of multiple Dify backends forming multiple workspaces.”

The interpretation power is entirely in Dify’s hands.

Strictly speaking, LOGO does not belong to copyright files.

Dify’s license restricts users from modifying logo images and various copyright information in the /web directory. The logo in the web folder is as follows:

In the specific front-end pages, it is roughly reflected in the following places:

According to the open source software definition, open source software should allow free modification and redistribution, including the creation of derivative works.

When creating derivative works, prohibiting the removal of copyright information is a common restriction in open source software, as it protects the original author’s attribution rights.

However, generally speaking, as in the original Apache License, Version 2.0, it usually only requires retaining relevant copyright, patent, trademark, and attribution notices in the source form.

Moreover, LOGO typically falls under trademark rather than copyright.

Although many open source licenses require retaining original copyright notices and author information, restrictions on the use of trademarks (such as LOGO in pages) are usually handled separately. Many true open source projects manage their LOGO usage through trademark policies rather than licenses.

Dify’s requirement to forcibly retain the LOGO in the front-end actually limits users’ complete freedom to modify the software. If users need to create derivative works based on Dify or want to integrate Dify into their own branded products, they are forced to keep Dify’s LOGO (unless they don’t use Dify’s front-end), essentially forcing Dify advertising.

Once the LOGO is modified, like this pharmaceutical company, you get a “lawyer letter warning” from Dify.

III. Can Dify Still Be Used?

What should companies pay attention to when deploying Dify internally?

First, don’t fork the main version, modify it, and PR back to the main repository (lol).

Generally speaking, building Dify internally within a company is not a big problem.

Internal company AI services are usually set up by the IT team (or dedicated AI service personnel), generating corresponding open interfaces or services (such as a web chat bot) for employees’ daily use.

If ordinary employees just use these services without “self-improving” by trying to build Dify on their local machines, they generally won’t have the “multi-tenant” issue under Dify’s license.

The only “minor inconvenience” is having to accept Dify’s ubiquitous LOGO and restrain yourself from modifying these icon files in the source code.

If you’re just developing separate applications based on Dify’s API without directly calling Dify’s front-end pages, then you don’t even have the LOGO concern.

What to watch out for when building AI SaaS services with Dify?

Be cautious.

If you’re just building some AI workflows and providing them to third parties via API, that might barely be considered compliant with Dify’s license.

But if you’re providing tailor-made services for multiple third parties, creating separate workspaces for each (even by deploying multiple Dify Community Editions), you must contact the Dify team to purchase a commercial license.

Otherwise, you risk being warned or even sued by Dify for violating the license.

Also, if you use the [Embed Website] method in Dify’s native publishing feature to provide services to third parties, you must not modify any LOGO files—changing them would be a violation.

There’s one more thing to pay special attention to:

Dify’s license explicitly states that they have the right to adjust the “open source” terms at any time.

Therefore, if you plan to build commercial services based on Dify, you need to pay more attention to related compliance risks.

It is recommended to regularly check whether the license has changed, especially during version upgrades.

Although license changes generally do not retroactively affect older versions, if you don’t notice the license change and accidentally update to a new version with new terms, it could introduce unnecessary business risks.

IV. Bonus: Dify Actually Has Better Options

The current controversy surrounding Dify mainly stems from the fact that although they claim to be “open source” on both GitHub and in their documentation, their “modified” license does not actually conform to standard “open source software” specifications.

However, it’s understandable. Dify wants to leverage “open source” to expand its influence (Microsoft: I’m familiar with this), but the core profit still comes from cloud services and commercial licensed versions.

Once the community edition is allowed to be freely modified, it will inevitably affect its own revenue.

But instead of the current “fence-sitting” approach, Dify might as well directly adopt the Business Source License (BSL) as its base license, setting a time limit (e.g., 3-5 years) after which it automatically converts to Apache 2.0.

BSL allows companies to restrict commercial competition in the early stages (such as prohibiting direct use for SaaS services) while promising a return to the open source community in the future. Compared to the current modification of Apache 2.0, BSL has mature applications in the industry, is more easily accepted by developers, and can balance short-term commercial protection with long-term ecological development.

Additionally, if they want to protect their LOGO from being replaced, they could consider separating the front-end and back-end. The front-end could use conditional commercial licensing—free to use but prohibiting UI and LOGO modification. The back-end could use BSL or Apache 2.0 to maintain code modifiability.

This approach ensures the back-end is “purely open source” while protecting Dify’s brand image through front-end restrictions. Compared to the current practice of mixing brand protection (or should we say “advertising terms”) into technical licensing, separate library licensing is more standardized and easier to enforce.

But then again, if everyone builds their own front-end, how would Dify’s LOGO be everywhere?

Finally:

When using “open source” software, always pay close attention to the “open source” license.