Andy Seaborne wrote on 8/4/17 5:00 AM: > On 03/08/17 23:20, John D. Ament wrote: >> Which must's do you see greg? >> >> On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tras...@stratuscom.com> wrote: >> >>> Does this actually need to be policy? What’s the harm to the foundation >>> if a project continues to use a non-Apache package name, assuming >>> that the >>> code was donated appropriately?
Because in some cases, the donating company may continue to market around the name, leading existing or completely new users to assume that the company still runs the project. When a project comes to Apache, it's an *Apache* project. That's obvious to those of us who read this list. It's not obvious to the average developer (i.e. potential future contributor), nor to the average CTO or other manager who decides if their employees are allowed to contribute to FOSS project X or if they're going to buy support from the original donating company. So the answer is: "it depends" on how the package name will be used in code examples or common use cases, and seen by new developers evaluating use of this software product. >>>> 1) package names with reverse domains MUST be renamed >>>> before graduation or have an IPMC approved plan for renaming > > SHOULD > (i.e. it needs a justification but isn't absolutely prohibited) It depends. Trying to start thinking about what matters from a brand perspective: - Renaming is a MUST if the reverse domain name starts with com.* - Renaming is a MUST if the domain name is not being legally transferred to the ASF before graduation. - Renaming is a MUST if parts of the domain name are still claimed as trademarks by the donating party. - Other reverse domain names *really* should change to org.apache; otherwise it's just confusing. -- The criteria should be applied strictly for the packages that are the "main" class or the primary API programming interface for the most common functionality of the product. All other packages (utilities, shims, standards, etc.) have more freedom in keeping existing names. - Functionality-derived package names - that's up to the community; I can definitely see it making sense to stick with existing names. ...snip... -- - Shane https://www.apache.org/foundation/marks/resources --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
