www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hen <bay...@apache.org>
Subject Re: PyPI MXNet
Date Mon, 11 Feb 2019 06:35:13 GMT
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.

Hen

Mime
View raw message