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, right? 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 time. LieGrue, strub ----- Original Message ----- > From: Greg Stein <gst...@gmail.com> > To: general@incubator.apache.org > 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" <i...@epimorphics.com> > 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
