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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
