www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: PyPI MXNet
Date Tue, 12 Feb 2019 07:27:45 GMT
As a peanut, IMO, Apache doesn’t have to have a separate position about all of these scenarios
involving external distribution channels.  Trademarks covers modification to the point where
it becomes confusing.  Release policy already says that the general public should not be encouraged
to use unapproved source packages.

As long as humans are writing content that describes these packages and other humans are reading
that content, there is always some chance of confusion.  If someone does get confused, we
say “Oh, sorry, see our policy page.  The only thing you can count on is these voted on
source packages with these checksums”   The ASF has some say over what PMCs put on their
official project web sites so they don’t add to the risk of confusion.  But the ASF can’t
really control what others say other than via trademarks.

And that should be good enough as long as folks are trying to help grow the communities. 
If we happen to notice something could be confusing, we ask the folks responsible to adjust
the language if they can.  No need to have more policy so we can shout “violation” at
them.  Be friendly, work it out.  That will probably work better at growing the community.

IMO, you can respond to someone on the users@ list and say, hey, I think I fixed your bug,
try the latest nightly.  I suppose you could remind them it isn’t an official release. 
But hey, you called it a nightly build.  You didn’t tell everyone to start using it.

Also, IMO, the biggest risk isn’t that someone didn’t get a chance to say that some change
broke their app, but rather, that someone found that the change contained IP that isn’t
legal to use and now people are depending on it.  A second risk is that it is legal, but doesn’t
conform to ASF licensing policy, so people are “mis-using it”.  Changes are going to break
apps as long as humans are making changes, even in voted-on releases.  Those are hopefully
easily fixed.  Replacing code you can’t use is usually harder.

If the content writers are at least attempting to distinguish official source release packages
from other packages or never distribute official source release packages and only distribute
convenience binaries that aren’t too different from what you’d get from building the official
source package, then they’ve made a good start, and it is probably good enough unless there
are signs of confusion from the users, like a thread on an ML where someone is complaining
about having relied on some unapproved code.

My 2 cents,

From: Hen <bayard@apache.org>
Reply-To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Date: Monday, February 11, 2019 at 9:46 PM
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Subject: Re: PyPI MXNet

On Mon, Feb 11, 2019 at 7:12 PM Daniel Shahaf <d.s@daniel.shahaf.name<mailto:d.s@daniel.shahaf.name>>
Hen wrote on Mon, Feb 11, 2019 at 09:28:56 -0800:
> Noting that we don't provide guidance/policy afaict that allows for
> https://pypi.org/project/apache-beam/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fapache-beam%2F&data=02%7C01%7Caharui%40adobe.com%7C17a987ac9446420d128e08d690ad64ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636855471728880449&sdata=QtHi8r%2BThl0tof9CDx3QgeJaljY%2Byttxhj1k%2FzjZhsA%3D&reserved=0>
(as my perennial example).
> Our guidance is:
> * Projects shall not publish on pypi.

Yes, projects shouldn't use pypi as their only release channel, but on the
other hand, ASF is not interested in preventing its releases from being
distributed via pypi (or any other downstream).

It feels very much that different folk have different positions on this and I'm unable to
figure out what Apache's position is. I'd happily mute my opinion in favour of the official
Apache position, but there doesn't seem to be a single coherent position.

> * Projects shall not publish unreleased material.

I don't care whether RC's are on pypi or not so long as they aren't the default
download.  There are good engineering reasons to make RC's available via as
same channels as possible to GA's, after all.

Is this your opinion, or is this an Apache position?

> * "Using Apache Trademarks in software product branding: In general you may
> not use Apache trademarks in any software product branding. However in very
> specific situations you may use the Powered By naming form for software
> products. "

This quote isn't about downstream distribution channels that don't modify the
source code.  Rather, it's about forbidding people from creating a C compiler
called "hadoop", or a compiler whose logo is the elephant or the feather,
without our permission.

I agree, except it's the only text that I see that can be argued to be relevant to a downstream

> Outside of Mark's text in the JIRA issue, I don't see any guidance that
> allows for the apache-beam pypi download.

The whole point of an Apache brand is that we allow downstream distributors
that don't modify the source code to use it.

It's a common Open Source trademark pain point. How many modifications can a Debian maintainer
make before they must rename the package, remove the logos? Flashbacks to Firefox and Iceweazel.
I have vague memories that this was a hard part of the Trademark Policy and I think we skipped
on writing it up.

Mark's text is good. I'll write it up as a policy FAQ/position and let people take shots at

View raw message