On 4 August 2017 at 12:17, Shane Curcuru <a...@shanecurcuru.org> wrote: > 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. >
Not only confusing - there's also the issue of who 'owns' the top package domain, i.e. who gets to decide what sub-package names can be used. > -- 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. Again, the community needs to consider whether they have complete control over the package names they are currently using and may wish to use in future. Using org.apache.project.* means that potential clashes are limited to the ASF project. > ...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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
