incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: What is the legal basis for enforcing release policies at ASF?
Date Fri, 21 Aug 2015 02:53:12 GMT
On Thu, Aug 20, 2015 at 9:37 PM, Ross Gardler <>

> I do not agree with this interpretation when viewed from a legal angle
> (though I do agree from a trademark angle). I have a feeling that the root
> of my disagreement is the same as the root of Jim's earlier statement
> (though I may be mistaken).

You've lost me already, but let's unwind this...

> There are two points of IP due diligence in an Apache project: At the
> point of contribution where the IP is validated by the committer and zero
> or more people who review the patch. The second phase of IP validation is
> at the point of release, where 3 our more PMC members validate that the
> foundation can legally release the code.

No, 3 or more PMC members make a best-effort that the code meets our
qualifications for release.  Not being copyright and patent atty's, we
presume they did not cast their votes based on a legal definition of due

> This means that taking a snapshot and building a release is *not*
> trademark-acceptable since the foundation, through the project PMC has not
> approved the release, therefore it is not an Apache release.

That much we agree on...

Only the ASF gets to say what is an ASF release and to do so requires a
> vote of the PMC. It has nothing to do with the number of changes made to
> what is in our repositories. It has everything to do with whether it's a
> release of the foundation.


> So, in the strictest sense, distributions that make minor changes for
> their distribution should call it Bar powered by Apache Foo in order to
> differentiate it from an official release of the foundation. In the real
> world the question is, from a legal point of view, do we care?

Here is where there is some room for interpretation, the httpd project can
probably be built more than 10^9 different ways (I extrapolate this from a
Chipotle drink cup that claimed the number of permutations of their
quick-service faux-tex-mex menu)

> (lets ignore the fact that some people vote on releases without doing
> proper validation, that's why we require 3 +1 votes, the assumption is that
> at least one of them did the job properly)
Define "Proper", I haven't read that page yet.

You still didn't comment on the license under which the repository is
licensed, so this wasn't a terribly helpful post.

From: William A Rowe Jr<>
> Sent: ‎8/‎20/‎2015 7:17 PM
> To:<>
> Subject: Re: What is the legal basis for enforcing release policies at ASF?
> On Thu, Aug 20, 2015 at 9:03 PM, Benson Margulies <>
> wrote:
> > This thread started as a discussion of Linux distros and trademarks.
> > Perhaps I could try to return it there?
> >
> > If a distro takes a release of Apache X, compiles it with minimal changes
> > that adapt it to the environment, and distributes it, I believe that
> it's a
> > fine thing for them to call it simple Apache X, and acknowledge our
> marks.
> >
> > 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.
> >
> > Further, if someone takes a snapshot (small 's') from source control and
> > starts from that, with minimal changes, I think that this would also be
> > trademark-acceptable, so long as they accurately describe what they did.
> >
> > The operative concept here, as Shane has taught it, is 'confusion in the
> > marketplace.' If some third party behaves so as to cause confusion as to
> > the identity of Apache X, there's a trademark issue. If not, not.
> >
> You summed this up to the best of my understanding ... +1.  If our legal VP
> agrees (and retracts earlier FUD) it appears we are entirely in agreement.

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