incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Date Wed, 29 Feb 2012 20:48:54 GMT
Doug referenced a groklaw article in the other thread. Package names are
not trademarkable.
On Feb 29, 2012 1:04 PM, "Mark Struberg" <struberg@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 <gstein@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" <ian@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message