incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Fri, 04 Aug 2017 11:17:32 GMT
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" <> 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
> (i.e. it needs a justification but isn't absolutely prohibited)

It depends.  Trying to start thinking about what matters from a brand

- 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.



- Shane

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message