incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: apache binary distributions
Date Thu, 06 Aug 2015 08:15:35 GMT
Am 06.08.2015 02:43, schrieb Roman Shaposhnik:
[...]
> As you probably remember we've discussed this issue not that long time
> ago: http://thread.gmane.org/gmane.comp.apache.incubator.general/49852
>
> The consensus there is that as long as you're communicating intent
> clearly you can let downstream developers test/develop against your
> development artifacts. IOW, the definition of "developers" starts including
> downstream developers integrating with your project.

yes, I remember that discussion, but for me the outcome is not as clear 
as it is for you it seems. Especially with regards to communicating that 
intend and if it has to go through the release voting cycle. You usually 
don't do that for SNAPSHOTS or nightly builds and for the nightly builds 
the release guide is quit clear that it must not be communicated beyond 
the dev-list. I read that as: a link on the websites of the project is 
forbidden.

>> 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 http://packages.ubuntu.com/vivid-updates/apache2-bin
>> 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.
>
> Correct. At that point it constitutes a derived work. The Apache License is
> very permissive that way, but it is considered a good practice to distinguish
> the derived work by at leas a version ID.
>
> That is also, how all of the Hadoop ecosystem vendors are creating dervived
> works when they distribute Apache Hadoop as part of their products. E.g.
> the version string of Cloudera's Hadoop is: ASF_VERSION-CDH_VERSION.
> This is in line with most of the Linux packaging guidelines as well.

the difference is that in Ubuntu I do for example:
"""
sudo apt-get install apache2
"""
that's it. No mentioning of a derived version in this at all. apache2 is 
the package name, something like 2.4.10-9ubuntu1.1 only a version 
string, which is maybe not looked at by the user.

>> 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?
>
> Because technically it is an artifact that is a derived work.

Of course that makes a difference, but every version from version 
control is a derivative work.

>> It was also mentioned here, that for example publishing snapshot builds to
>> maven central is not allowed.
>
> This is where it gets tricky with our current policy. Personally I see
> absolutely
> no reason to NOT publish Maven artifacts as widely as possible provide
> that the version ID or name communicates the intent. It seems, however,
> that I'm in a minority here (although truth be told nobody has been able
> to communicate a convincing enough argument for why my approach may
> be dangerous to the foundation and/or Projects).

Currently I read this thread as following... if a third party publishes 
a snapshot to bintray or wherever, there is not really a problem. But if 
the project does it, then it is. And if the third party is actually not 
a third party, but a contributor things get very very unclear.

>> 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:
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201506.mbox/%3CD1B01671.4EE90%25rvesse%40dotnetrdf.org%3E
>> some even see nightly builds, not communicated beyond the dev-list on
>> non-apache servers already as a problem.
>
> Third party is at complete liberty of doing so. Provide the artifact is marked
> in such a way that is can NOT be confused with an official ASF artifact
> (IOW it can be called a derived work).

not to be confused with an official ASF artifact... that's the part I am 
trying to extend my understanding. For me it is an official ASF 
artifact, if I download it from an ASF server. But then I have to 
include mirrors. And hat simplified version is already a problem... if I 
give a maven version information on an ASF page, does this make the 
maven package automatically an official ASF artifact, even though the 
download itself is not from ASF infrastructure? Same for links for 
example to docker image distribution servers... or let's say a link to 
an ubuntu package. On the other hand you can put disclaimers on the 
pages stating they are not official... Then again nightly builds should 
be ok, if they will have the same disclaimer? Or is it ok if the nightly 
build comes from non-apache? If that is ok, then why does the release 
document not say this and is instead very strict about not promoting 
anything even beyond the dev-list? It does not make sense for me and I 
am going in circles here.

Of course a third person would be someone unrelated to the project. So 
what they do is of lesser concern, unless they misuse things. But what 
if the person is ASF member, or contributor to that project, maybe even 
in the PMC? For example... assuming I would provide snapshot of Groovy 
on an external server and the web page mentions how to get this with a 
disclaimer, would that be ok? Even if it is a nightly build?

[...]
>> 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?
>
> I honestly see no problem with that, again provided that the artifact can NOT
> be confused with the one coming from Apache project.

the conditions for when there is confusion and when not are quite 
unclear to me.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message