incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: apache binary distributions
Date Tue, 04 Aug 2015 09:22:13 GMT
Am 03.08.2015 21:46, schrieb David Nalley:
> On Mon, Aug 3, 2015 at 5:55 AM, Jochen Theodorou <> wrote:
>> Hi all,
>> some of the general discussion recently made me wonder about one point with
>> regards to binary distributions. It was pointed out, that a binary
>> distribution of a source code release has to be handled like a release
>> itself, and that there should be no download source of it outside of apache.
>> This seems to be one motivation for the asf having its own maven repository.
>> I seem to misunderstand something here, or why can there be apache maven
>> artifacts in maven central and package in linux distributions for for
>> example httpd, if this policy is followed? I mean it was even suggested to
>> use the trademark to forbid the distribution through third parties. I am
>> quite irritated about this.
>> bye blackdrag
> I am not aware of any policy that dictates that (but would love to see links.)

yeah, next time I will do that better. Getting the stuff out of here, 
will require me reading thousands of mails through that stupid web 
interface and google doesn't help either.

> I am aware that releases MUST at least be distributed via
> [1], but that isn't exclusive, meaning the PMC is
> welcome to distribute _released software_ via other means (PyPy, NPM,
> Maven, Docker Registry, CPAN, Bintray, carrier pigeon, etc).
> --David
> [1]

The problem already starts with that what a release is on

I read that as anything that goes beyond the dev-list is to be handled 
as release. It does not say by whom. And there is no mentioning of the 
releasing of released software, only the distribution of releases. But 
anyway... le tme phrase some scenarios and question:

Let us assume httpd makes the release 2.4.10, a linux distributor takes 
the source, adapts them (for example security patches), compiles 
packages out of it and releases it as in source and 
binary form. Then it means they took a release and made their own 
release out of it, while using the apache name. The PMC might or might 
not be involved in this. Of course this is no released release in the 
sense of ttp://, since it was never voted 
on in this form and it never appeared in that form on or The point being here, for 
the end-user this will be the official release, not what is found on the 
apache servers. Why is this ok?

It was also mentioned here, that for example publishing snapshot builds 
to maven central is not allowed. I guess in the release document they 
are basically to be handled as nightly builds and as such not for the 
general public, thus only for the dev-list. It was said, that having the 
SNAPSHOT appendix in the jar name as well as not being able to 
automatically get them via maven without having to add that "tag" is not 
enough for the end-user to know for, that this is no official release. 
And that if such things are going into the distribution repository, they 
have to be handled as release, including voting and such. For that I 
guess it does not matter if it is the apache repository or something else.

What would happen if a third party would do this? Is the project/apache 
required to do something about this? I mean if you read this:

some even see nightly builds, not communicated beyond the dev-list on 
non-apache servers already as a problem.

Let us put that last part a step up... Let us assume someone takes one 
of the released sources of one of the java projects out there, makes 
maven artifacts out of it and publishes them at maven central. Is that 
ok? I mean that is very near the distributor case, so it should be ok, 
or not?

Oh and by chance I found the marks violation part:

If the Docker Hub page wasn't under the control of the Geode PMC, then 
I'd say it was a marks violation and they'd have to seek out control of 
it or removal.

Personal opinion mostly of course, but that is one of the problem... 
lot's of opinions based on a few fixed rules, that make not always 
sense, since their intend is not documented and thus it cannot be seen 
if their application is as intended.

bye blackdrag

Jochen "blackdrag" Theodorou

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message