incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Date Wed, 29 Feb 2012 18:04:09 GMT
Greg, from a legal standpoint I'm not 100% sattisfied.

Having a com.cloudera package in any Apache project is imo a show stopper. This should not
have been passing the IP clearance at all.

Cloudera is a company, and thus a trademark. 

If we write software and use the com.cloudera package name, then we might breach their trademark,

This is also true for other projects which have a trademark in their package names.
So even if they didn't sue us yet, I guess they could force us to drop those packages at any


----- Original Message -----
> From: Greg Stein <>
> To:
> Cc: 
> Sent: Wednesday, February 29, 2012 3:00 PM
> Subject: Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE]
Graduate Sqoop podling from Apache Incubator)
> On Feb 29, 2012 8:34 AM, "Ian Dickinson" <> 
> wrote:
>>  On 29/02/12 10:02, Mohammad Nour El-Din wrote:
>>>  I don't see that this getting to any clear end yet. So I suggest 
> that we
>>>  take this from a Sqoop instance to be a discussion on rules them 
> selves.
>>>  I would like to start a [VOTE] about whether it is a *must* for 
> podlings
> to
>>>  rename all packages before being a TLP or not over keeping the old
> package
>>>  names for backward compatibility. What ever the consensus going to be
> built
>>>  we definitely need to update the Incubator documents to clear this kind
> of
>>>  issue. But before starting the vote I would like to consider 
> others'
>>>  opinions.
>>>  Thoughts ?
>>  In the case of Apache Jena (incubating), we have more than ten years'
> worth of existence as an open-source project. In that time, there have been
> countless tutorials, articles, research papers, code snippets, books and
> add-on tools that make use of Jena code in the com.hp namespace. But Jena
> was never an HP *product*, it was an output from the HP research lab in the
> UK.
>>  Our intention as Apache project has been much like Sqoop's: to migrate 
> to
> org.apache names but keep a compatibility layer in place. We had thought
> that migration wasn't necessary for graduation, but if it is, no biggie.
> What would be problematic for our community is if we can't host the
> compatibility layer packages *at all* under Apache. If we have to expunge
> all references to com.hp.* packages, then all that back-catalogue of
> tutorials etc will be instantly obsolete ... unless folks know to go and
> separately download the jena-compatibility package from SourceForge or
> wherever it would hypothetically end up.
>>  Some of the discussion around Sqoop has been that the
> backwards-compatibility requirement is all about Cloudera's customers so
> it's Cloudera's problem. In the case of Jena, it has never been about 
> HP's
> customers, and it definitely isn't HP's problem since none of the 
> current
> committers work there any more.
> For Subversion, Craig Russell was concentrating on this aspect while we
> were incubating. He basically said, "no problem with graduation, as long as
> you have a plan in place." He followed up with an email about 18 months
> after graduation, and I replied, "yup, all moved over."
> Moving to org.apache.subversion gave us an opportunity to revamp our
> interfaces based on what we had learned from the first go-round in
> org.tigris.subversion. So we have the new hot interfaces under o.a.s, and
> the compat layer under o.t.s. Works great.
> Cheers,
> -g

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

View raw message