+1 Thanks, Dianjin, for the clear summary and thoughtful proposal.
I support the phased approach for the following reasons: - It addresses ASF legal guidance while minimizing disruption to users familiar with the legacy tooling. - The runtime warning and blog post provide transparency and early notice to downstream consumers. - Renaming in 2.1 aligns with our goal of full ASF compliance before graduation, without forcing abrupt changes in 2.0.0. - Providing symlink-based aliases is a practical bridge for traditional users migrating scripts and habits. This approach strikes the right balance between legal, technical, and community considerations. Best, Ed Espino On Mon, Jun 23, 2025 at 12:19 AM Dianjin Wang <wangdian...@gmail.com> wrote: > Hi all, > > Our ongoing discussion about renaming the filenames > `greenplum_path.sh` & `generate-greenplum-path` files (GitHub Issue > #1149[1], PR #1156[2]) has revealed important legal and community > considerations worth summarizing and discussing before proceeding. > > ## Background > > Here’s an updated summary of the situation: > > 1. Trademark ownership update > > Cloudberry evolves from the open-source Greenplum Database. Since > Broadcom Inc. acquired VMware, “Greenplum®” is now a registered > trademark owned by Broadcom. > > 2. Files in question > > Two installation scripts currently include “greenplum” in their filenames: > - greenplum_path.sh > - gpMgmt/bin/generate-greenplum-path.sh > > These files are part of the user-visible and executable interface and > were flagged during our 2.0.0 RC1 release review, which will be at the > risk of potential legal issues, and may also be a blocker for our > graduation from the ASF incubator. > > Some PPMC members and contributors have shared feedback on this matter > - thanks for all the valuable input. To further clarify the legal > perspective, I also created a JIRA ticket to request advice from the > ASF legal team[3]. The legal guidance supports renaming the files but > also suggests a phased approach to avoid breaking compatibility for > existing users. Key recommendations include: > > * Adding headers in scripts clarifying the legacy naming usage and > trademark attribution > * Printing warnings when the scripts are invoked > * Communicating with users ahead of the renaming, while renaming — > ideally in a later release > > ## Proposal: Phased Approach > > Given the feedback and advice, the following is the phased approach on > this matter: > > 1. Phase 1 – Cloudberry 2.0.0 > > * Add header comments to related files signaling legacy naming and > lack of affiliation with Broadcom Greenplum. > ``` > These files use the term 'greenplum' to maintain compatibility with > original versions of Apache Cloudberry, which was originally called > Greenplum. This usage does not relate to the VMware Tanzu Greenplum > product, neither do we imply that Apache Cloudberry (Incubating) is > affiliated with, endorsed by, or sponsored by Broadcom Inc. > ``` > * Modify scripts to emit a runtime warning on usage. (If possible) > * Publish a NOTICE Blog post (on mailing lists and our website) > explaining the change and timeline - We can make the changes in the > Cloudberry 2.1 Release. > > 2. Phase 2 – Cloudberry 2.1 > > * Rename files to Cloudberry* names (e.g., cloudberry_env.sh), > removing “greenplum” from user-visible interfaces. > * Clearly document the change in the release note. > Optionally provide compatible aliases in the docs for traditional > Greenplum users, like: `sudo ln -s > /usr/local/cloudberry-db/cloudberry-env.sh > /usr/local/cloudberry-db/greenplum_path.sh` > > Benefits of This Plan > * Balance between the traditional user behavior and the coming changes > * Provides transparency to users and downstream consumers > * Ensures full removal of third-party trademark terms before graduation > > ## Request for Feedback > > * Do you agree this phased plan strikes the right balance? > * Any concerns regarding implementation details, user impact, or > communication? > * Suggested warning messages, blog format, or alias strategy? > > Requesting your thoughts before committing to PRs. > > Thanks for your input! > > [1] https://github.com/apache/cloudberry/issues/1149 > [2] https://github.com/apache/cloudberry/pull/1156 > [3] https://issues.apache.org/jira/browse/LEGAL-703 > > Best, > Dianjin Wang > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org > For additional commands, e-mail: dev-h...@cloudberry.apache.org > > -- Ed Espino
