www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: PyPI MXNet
Date Mon, 11 Feb 2019 13:16:54 GMT
On Mon, Feb 11, 2019 at 12:21 AM Justin Mclean <justin@classsoftware.com> wrote:

> Just as an aside I think we do need guidance on PyPi (and the IPMC is slowly
> working on that)., from this thread i’d guess Marvin might have something to
> say about that. :-) > At least one top level project uses it as the main form
> of distribution that I know of and serval incubating project do. It's where
> users expect to get Python code. I believe projects are also placing source
> releases there as well.  We’ve have one incident were a podling made 100+
> “releases” there without making an Apache release and while we may hand wave
> and say that really a 3rd party doing that IMO it's not in the spirt of how
> an Apache projects should work.

We do provide guidance:

    http://www.apache.org/legal/release-policy#publication

    Projects SHALL publish official releases and SHALL NOT publish unreleased
    materials outside the development community.

For packages available via PyPI, rubygems.org, cargo.io, Maven Central,
DockerHub, Bintray, PuppetForge, CPAN, NPM, Yarn, CRAN, Packagist, whatever Go
packager is popular this year, NuGet, CocoaPods, hex.pm, Hackage, LuaRocks,
haxelib, bpkg.sh, clib, cpm.rocks, hunter.sh, Leiningen... any of the Linux
packagers, any of the BSD packagers, homebrew, Chocolatey, any other
OS-specific packagers... any download aggregators or mirror networks whether
hosted by commercial entities or charities...

... If such packages are derived from official releases, obey our licenses,
and adhere to branding requirements, we're fine with that.  We've always been
fine with that.

Why must we spell out "don't publish unreleased code to X" once for every
possible downstream distribution channel?  Our project and podling
contributors aren't infants.

If project quickstart docs or even the project homepage suggest `pip install
apache-libcloud` or `gem install buildr` or `npm install cordova` as a way to
get the project code, that is in general OK (and has been OK for a long time)
so long as the mechanism points to *released* code, upholds vendor neutrality,
and so on.

Where things start to go awry is when packages under our trademarks are
injected with features that the community as a whole has not agreed upon via a
PMC VOTE in conformance with Release Policy.  That gives the parties who
happen to control the channels where such packages are published an advantage
over other community members, short-circuiting past project decision-making
mechanisms and stealing influence over the project's direction.

And that's why it's so important to push back hard on the notion that
distribution constitutes release: Release VOTEs are essential to project
independence.

Marvin Humphrey

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message