[Catalog-sig] PyPI terms (was: Deprecate External Links)

[Noah Kantrowitz]

On Feb 28, 2013, at 2:22 AM, M.-A. Lemburg wrote:

> On 27.02.2013 19:11, Noah Kantrowitz wrote:
>> 
>> On Feb 27, 2013, at 9:28 AM, M.-A. Lemburg wrote:
>>> [reasons for not hosting distribution files on PyPI]
>>> * giving up control
>> 
>> This is the point of running a package server, the author gives up control over distribution in order to reap the benefits of solid infrastructure and discoverability. This is a feature.
> 
> Please see below.
> 
>>> 
>>>> The legal restrictions on code on pypi itself is nothing more than needed to let people actually install things, which is kind of the point of listing on pypi. If someone really wants their own universe, run a package server yourself. What other reasons are there? Agreeing to an extra license would block pip anyway, so no loss there. Huge package files maybe? 
>>> 
>>> That's not quite true:
>>> 
>>> http://www.python.org/about/legal/
>>> 
>>> """
>>> ... third party content providers grant the PSF and all other users of the web site an irrevocable,
>>> worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform,
>>> and publish such content, including in digital form.
>>> """
>>> 
>>> Once you upload the files to PyPI, you completely give up control,
>>> because that license is irrevocable. This goes far beyond what the
>>> Python license does:
>>> 
>>> http://docs.python.org/2/license.html
>>> 
>>> Changing the PyPI terms to be more author-friendly is on my agenda,
>>> but I haven't found the time for that particular discussion yet ;-)
>> 
>> You are comparing an artifact distribution requirement with a source code license. PyPI's terms don't say a thing about source code or anything else, just that if you want a package file to be installable, we need to be able to send it to people. There is nothing even remotely author unfriendly here, it is just common sense. Again, PyPI is _not_ the only way to publish packages, we are allowed to expect interoperability from people that choose to participate in our community.
> 
> The distributions files are the "content" the license is talking about,
> just as the Python distribution files are distributed under the
> Python license, so those two are really addressing the same thing.
> 
> Unlike the PyPI terms, the Python license does not grant an irrevocable
> license on the content. It even comes with a termination clause, which
> explicitly says that the license is revoked in case breached.
> 
> The PyPI terms, OTOH, do not allow revoking the license to distribute
> the files. This wouldn't be a problem for the PyPI itself, since we'd,
> of course, help the author to get the files removed.
> 
> However, the PyPI terms go beyond this in giving "all other users of the
> website" those same irrevocable rights... which is a pretty large
> crowd to ping in case of problems and ask nicely to take down the
> files. What makes this worse for the author is that they are not
> required to comply per the current PyPI terms.
> 
> This is what I meant with giving up control.
> 
> Removing the "irrevocable" in the PyPI terms would already go a long
> way to make the terms more author-friendly, but this will have to
> be hashed out with our legal counsel.
> 
> One of the reasons I had started the CloudPyPI project was to
> address this aspect: having the whole mirror infrastructure
> under PSF control would resolve the above issues, since we could
> then remove the "all other users..." part of the terms altogether.
> 
> BTW: I've never seen a hosting website require agreeing to
> giving users of the website the same distribution rights
> as the owner of the website.
> 

You should read terms of service more closely then, this is standard because of how lawyers interpret the general foundation of the internet. Because we cannot promise private caches and such will _ever_ delete something just because it is removed from PyPI we need that bit of legal protection. None of us are lawyers to the best of my knowledge so this is not the right place to discuss such things. If our counsel says that requirement isn't needed, we will remove it, otherwise we won't.

--Noah


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130228/a03a5934/attachment-0001.pgp>