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, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 07 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
