community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: What is the legal basis for enforcing release policies at ASF?
Date Fri, 21 Aug 2015 15:29:43 GMT
On Fri, Aug 21, 2015 at 8:54 AM, Shawn Heisey <apache@elyograg.org> wrote:

> On 8/20/2015 8:03 PM, Benson Margulies wrote:
> > If a distro takes a release of Apache X, and make significant changes to
> > it, and then distributes it, I believe that it's not OK with us for them
> to
> > simply call it Apache X. I've seen some evidence that Gentoo Linux makes
> a
> > regular habit of this, because their policies drive them to make some
> > pretty scary changes in some cases. Others may not share my view.
>
> This is how Debian ended up with "iceweasel" instead of "firefox."
> Mozilla was not OK with allowing its trademarks to be used for the
> version of those products that Debian was including.  Mozilla went
> 800-pound gorilla on Debian.  Debian complied, but took the rebranding
> route rather than allow Mozilla to force them to compromise on their
> internal guidelines.  They got a small measure of revenge with the
> package names they chose. :)
>
>
> https://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project
>
> Here's a similar situation applicable to Apache ... the Debian and
> Ubuntu projects include a very old version of Apache Solr.  The code
> gets patched quite a bit, and a few of the changes could probably be
> called intrusive, but it doesn't fundamentally change what the user
> gets.  When the packages are installed (they split the Solr/Lucene code
> into *many* binary packages), the file locations are *dramatically*
> altered compared to a binary or source download from the Solr website.
>
> Given what those projects do to our code and packaging, do we have any
> right to tell them they can't call their package "Solr"?  If we do have
> that right, are we losing anything by not exercising it?
>
> Their changes do mean that when people come to the solr-user mailing
> list looking for help, we sometimes have to refer them to the downstream
> maintainers, because we can't make any sense of where things are.  Even
> though it sometimes creates support issues, I personally don't think
> there's any big problem with the way that Debian/Ubuntu changes our
> software, but what would a lawyer say?
>

We have the same occurrence at httpd, both issues.  Linux distributors
rearrange the product to suit their own conventions, and then 'freeze' at
a particular release but keep pushing a regular assortment of patches
back into their released version, mostly backported from the ASF, plus
whatever they might change that doesn't find its way back upstream.

In your example, I'm looking at packages named liblucene3-contrib-java,
liblucene3-java, liblucene3-java-doc, libsolr-java, solr-common,
solr-jetty,
solr-tomcat all from Debian.  Potentially confusing.

It seems that if they want to fork and have a patchwork of what once was
an ASF solr release, they could do this by simply naming their packages
debian-libsolr-java, debian-solr-common, debian-solr-jetty,
debian-solr-tomcat.
There would be no confusion over similarly named apache-solr* packages.
Remember our trademark policy is to avert confusion by the public who
use our software.

However, they already seem to appropriately designate their packages as
not-ASF in the way they version the specific page name.  E.g. we find
solr-common_3.6.2+dfsg-6_all.deb which is apparently ASF solr 3.6.2
with their own dfsg 6th patch set applied to that package.  If it remains
solr 3.6.2 for all intents and purposes, then I'd suggest their existing
naming convention isn't far from the mark.

One could argue that poor trademark enforcement leads to ill will, just
look at the Mozilla example, look at the MikeRoweSoft example.  Yes
it is necessary for us to assert our brands, and police them, but we can
do this in a mutually beneficial way that doesn't diminish our brands or
our reputation.

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