[Catalog-sig] [PSF-Board] Troubled by changes to PyPI usage agreement

[Steve Holden, Chairman, PSF]

Adding a Google-like clause might make us seem less Draconian.

regards
 Steve

M.-A. Lemburg wrote:
> VanL wrote:
>> M.-A. Lemburg wrote:
>>> Those are likely only a handful of users who'd need the
>>> added permissions and it doesn't explain the need for
>>> an irrevocable license.
>>>   
>> The irrevocability is there to protect the PSF. It is so that no one can
>> claim later that they got mad at the PSF and revoked the PSF's ability
>> to redistribute something that they previously uploaded.
>>
>>> If you replace "all other users of the web site" with "users
>>> granted permission by the PSF to use the PyPI data", the mirror
>>> requirement would be dealt with in a way that doesn't require
>>> giving redistribution rights to the general public.
>>>   
>> This also makes it easier for people to pass along PyPI packages to
>> their friends. As I have explained before, this doesn't give anybody the
>> right to relicense the content. What is provided to the PSF (and those
>> who get the package from the PSF) is the right to pass on to others
>> exactly what was received.
>>
>>> The "irrevocable" appears to be unnecessary, since developers
>>> can already revoke the permission by simply deleting the uploaded
>>> files.
>>>   
>> You are thinking like an engineer, not like a lawyer. It doesn't have to
>> make sense, it just is.
> 
> I guess that's the main problem here: developers do tend to
> think like engineers, not like lawyers, yet they still have
> to read and accept the new terms.
> 
> Perhaps a FAQ entry is needed to get the trouble resolved,
> or a slightly altered text that doesn't cause the raising
> eyebrows to begin with.
> 
> FWIW, Google uses similar wording in their TOC, but they
> also include this passage, which makes developers feel a lot
> better:
> 
> http://www.google.com/accounts/TOS?loc=US:
> """
> 11. Content licence from you
> ...
> This licence is for the sole purpose of enabling Google to display, distribute and promote the Services.
> ...
> """
> 
> ie. Google is *not* "free to use or disseminate such content
> on an unrestricted basis for any purpose", but only for
> the sole purpose of providing the service in question.
> That's a fair deal.
> 
> They also don't extend the license to all users of the web-site,
> since that's not necessary: the content will come with a license
> that defines how to use, copy and distribute it.
> 
> And these licenses, as example, may include a restriction on reexporting
> code to an embargo country which the PyPI license doesn't, but is
> needed in order to protect the package author from knowingly
> permitting reexport of such code.
> 
> What I'm trying to say is: Less is more :-)
> 
> The PSF should just try get the absolute minimum of what's
> needed to provide the service and protect itself against
> issues with e.g. export regulations, take-down notices,
> etc. Nothing more.
> 
>>> Note that the two paragraphs were added after I asked the board
>>> on their views of having crypto code on PyPI.
>>>
>>> The conclusion was that pypi.python.org would only be seen as
>>> platform for distribution, without the PSF actually redistributing
>>> the uploaded code and the uploader would be the one to determine
>>> whether it's ok to upload the code or not. That's a convenient
>>> understanding for the PSF, since it doesn't have to control
>>> the uploaded code.
>>>   
>> Not quite right. From the point of view of the United States, export
>> takes place when US-sourced code is uploaded to the server in the
>> Netherlands. This is done by the person uploading, so that is the person
>> that we require to have previously complied with any export
>> restrictions. You are incorrect about your assertion that the PSF does
>> not redistribute the code. It does.
>>
>>> However, the current wording makes it look a lot like the PSF is
>>> in fact regarding itself as a redistributor of the PyPI hosted
>>> code, so the PSF would have to follow export regulations of the
>>> Netherlands (where the servers are hosted) w/r to redistribution
>>> and reexport of crypto code. This again, is not really convenient
>>> for the PSF, since export rules are complicated.
>>>   
>> See above. I have rendered no opinion on Netherlands export laws, as I
>> am not qualified to do so. The question asked of me was with regard to
>> possible PSF complications relative to PyPI and crypto code. As the PSF
>> is a United States corporation, the advice was rendered relative to US law.
> 
> Understood. Thanks for clarifying this.
> 
> Doesn't the PSF have to follow the Netherlands' law for things
> that it publishes on the python.org servers ?
> 
>>> IMHO, it would be better to clearly state that PyPI is only
>>> providing a hosting service for the uploaded files, with the
>>> uploading user controlling the content and only imposing some
>>> limits of what can be uploaded rather than creating
>>> a licensing relationship between the uploader and the PSF,
>>> ie. the PSF provides the web space, the user the content -
>>> thereby avoiding all these issues.
>>>   
>> This is incorrect on several counts. The PSF is not a licensor under the
>> PyPI text, and therefore the text does not create a licensing
>> relationship between the PSF and anyone else. Besides, your proposed
>> solution would not solve the problem.
> 
> Perhaps there's a misunderstanding here: the text on PyPI
> does create a licensing relationship between the author of a
> package uploading code to PyPI and the PSF (and any user of
> the web-site). The author is licensor, the PSF and all
> others are licensees.
> 
> Anyway, the above was just a suggestion.
> 
> Thanks,


-- 
Steve Holden        Chairman, Python Software Foundation
Visit Us At                       http://python.org/psf/
Watch PyCon on video now!          http://pycon.blip.tv/