On Sun, Feb 10, 2019 at 6:53 PM Ted Dunning <ted.dunning@gmail.com> wrote:

On Sun, Feb 10, 2019 at 5:27 PM Hen <bayard@apache.org> wrote:

So there are three situations (I was trying to shoe-horn this into #2):

1) Apache publishing software.
2) Any third party publishing software that incorporates software from Apache under AL 2.0.
3) Any third party republishing Apache software.

Do we have any text published (outside of LEGAL-427) for #3?

How about the Apache license and the branding guidelines?

I didn't find anything that spoke to treating #3 and #2 differently above.

Assuming branding guidelines means the 18 different brand documents here: https://www.apache.org/foundation/marks/resources

License wise, there is "You must cause any modified files to carry prominent notices stating that You changed the files", though that's not been the clearest clause and could do with some FAQqage.

There is this to tell our PMCs to be careful linking to third parties (which reading sideways can apply to this situation, but doesn't provide guidance to the third-parties):

= Not Promoting Similarly Named Software Products

Any links on project pages to third party products or companies should not give the appearance of infringing on our own marks or products. The third party must not be infringing; if they are infringing and will not comply, the links should be removed.

In particular, PMCs should not provide links to any third party that is causing confusion with the public as to the source of any Apache software products, either from your project or any other Apache project.

There are an unbounded number of downstream channels -- we cannot
possibly interface with them all responsibly.

Our oversight mechanisms are stretched thin enough as it is.  The
Board must already review all project download pages periodically, and
on occasion must deal with creeping commercial influences there. It is
not feasible to review an ever-growing portfolio of distribution
channels, and since we can't do it right we shouldn't do it at all.

I think it's a jump to say it's not feasible. We reviewed GitHub, DockerHub and Maven Central.

> Who is "we" here?

Apache in general. Projects are blessed to publish on GitHub, DockerHub and Maven Central locations.

> Also, we don't (as a Foundation) release binaries. 
Yet we (as a Foundation) publish binaries (Apache website, ASF Nexus instance, DockerHub)


>From an administrative point of view, our top priority must be to
manage the canonical distribution channel and the project download
pages effectively. Then, we can deal with problems in downstream
distribution channels on an ad hoc basis, as they are found and
reported to us.

Yet the public are (generally) getting our software from downstream channels, not from us. 

> In packaged or compiled form, yes, they are getting it from packagers or compilers.

The 2000s agree with you. The folk taking Apache source (or those binaries that don't exist) were packaging communities. Debian, Red Hat etc. The newer locations however are far less packaging communities and far more artifact hosting services (Maven Central, PyPI, npm, ...). The projects themselves are the typical packagers for an artifact hosting service.

> We produce the canonical source. The only moderate exception really should be OpenOffice and they are definitely an outlier.

In a world where Debian package maintainers exist, sure I agree with you. Their community is designed to manage the topic of providing installables to their users. They're also designed to consider the liabilities and licensing decisions. That also makes sense in a lot of cases; the average group of 4 C, Perl, Python coders are not guaranteed to be deep on Debian.

I don't think that is the norm elsewhere. The norm in PyPI, npm, Maven Central, etc is that the project are the ones creaitng the upload. The average groupd of 4 Python coders can be expected to contain someone deep on PyPI. By washing our hands of this problem, Apache is merely trying to dump the problem onto our committers personally.