Doug referenced a groklaw article in the other thread. Package names are not trademarkable. On Feb 29, 2012 1:04 PM, "Mark Struberg" <strub...@yahoo.de> wrote:
> 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 > >
