On Fri, Aug 4, 2017 at 7:17 AM 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.* > > Agreed. > - Renaming is a MUST if the domain name is not being legally transferred > to the ASF before graduation. > > I would say unless there is strong evidence that the name will be transferred. > - Renaming is a MUST if parts of the domain name are still claimed as > trademarks by the donating party. > > Agreed. > - Other reverse domain names *really* should change to org.apache; > otherwise it's just confusing. > > Agreed. The one caveat to all this is the implementation of javax. namespace which is typically required and managed by the Geronimo TLP (typically). > -- 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 > >
