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/ _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
