Open source tricks! Changing the logo, inserting private goods, and passing keys | A pharmaceutical company modified Dify and was severely punished by a lawyer...
A series of "shameful operations" by the well-known pharmaceutical company Livzon Pharmaceutical on the open source project Dify caused controversy, exposing the company's misunderstanding of open source rules. This article will take you to an in-depth understanding of the whole incident and explore how to correctly participate in open source projects.
Core content:
1. Livzon Pharmaceutical's incorrect operations in the Dify project and their consequences
2. The three core principles that companies should follow when participating in open source projects
3. How to participate in open source in a compliant manner and become a builder rather than a destroyer
Dify incident review:
A bloody incident caused by an open source "magic modification"
Dify is an open source AI development platform under the MIT protocol, which allows users to freely modify the code and use it commercially, but the premise is that the original copyright statement must be retained. However, Livzon Pharmaceutical's operation accurately stepped on all the minefields. Why did this " oolong incident " happen ?
Logo replacement: Many companies mistakenly believe that " open source = free and unrestricted use " , but ignore the core spirit of the open source agreement - respecting the copyright of the original author . Dify adopts the MIT agreement, which allows free modification of the code, but the logo is independently protected as a project trademark, and unauthorized replacement is suspected of infringement;
Functionality overstepping: Dify clearly defines advanced features such as multi-tenancy as commercial version rights. Enterprises should purchase authorization if they need to use them, rather than modifying them on their own and submitting them to the main branch.
Key leakage: Submitting internal keys to public repositories exposes serious loopholes in the technical process, which can be called "self-destructive open source."
These actions not only exposed the misunderstanding of open source collaboration rules by enterprises, but also made the public focus again on the core issue of "how to properly participate in open source" . The essence of the farce is that enterprises regard open source as a "free buffet" but ignore the rules and risks.
Open source is not a lawless place: a guide for enterprises to avoid pitfalls
How to avoid repeating the same mistakes? GitCode combines open source collaboration experience to sort out three core principles for enterprises:
“
Agreement first, understand the rules before taking action
MIT agreement ≠ do whatever you want : MIT allows commercial use and modification, but the original author's copyright statement must be retained . When it comes to elements such as logos and brands, you need to contact the project owner for authorization.
Commercial features require payment : If the project has a commercial version (such as Dify's multi-tenant version), unauthorized cracking or bypassing it will not only constitute a breach of contract, but may also lead to legal risks.
GitCode Recommendation : The platform provides protocol interpretation tools and compliance check templates to help companies quickly identify red lines.
“
Fork workflow: the golden rule for compliant changes
Independent branch, clear ownership : Create an independent branch through GitCode's Fork function, retain the copyright of the original project after modification, and the new code can be marked with corporate contributions.
CI/CD automatic check : Integrate automated tools to scan sensitive information (such as keys) and detect protocol compliance before submission to avoid "slips" in the hands.
GitCode advantages : One-stop hosting + automated pipeline, allowing compliance review to be seamlessly integrated into the development process.
“
Community collaboration: using trust to achieve win-win results
Take small steps to build credibility: Start with low-risk contributions such as fixing typos in documents and optimizing code, and gradually build trust with the community.
Communicate fully before PR: When submitting a Pull Request, explain the purpose of the change in detail, respect the maintainer's decision, and do not "force" the requirement.
GitCode helps: The platform has a built-in community discussion area, which supports direct communication between developers and project parties, reducing communication costs.
Instead of "magic modification", it is better to become an open source builder!
The essence of open source is sharing and collaboration, not "freeloading" or "occupying a niche". If companies want to leverage open source, they should follow the rules and actively give back. Taking GitCode as an example, many companies have achieved win-win results through the following paths:
? Compliance secondary development: After forking the project, it can be independently iterated to meet customization requirements without interfering with the main branch;
? Ecosystem co-construction: Release own open source projects (such as tool libraries, middleware) to attract developers to jointly optimize;
? Commercial transformation: Provide value-added services (such as technical support and advanced functions) based on the open source version to achieve sustainable monetization.
Written in the end: the correct way to open source
The Dify incident has sounded a wake-up call for all companies - open source is not a free billboard, nor is it a shortcut to circumvent business rules. Only by respecting agreements and respecting the community can we truly enjoy the dividends of technology inclusion.
