In article <44f4e1f8-5533-45a7-810e-b9c13530e...@stufft.io>, Donald Stufft <don...@stufft.io> wrote: > On Sep 23, 2013, at 7:34 PM, Ned Deily <n...@acm.org> wrote: > > [... license implications ...] > > As far as I know the certificate bundle is licensed under either GPL, MPL, > or LGPL. However there is debate about wether a CA bundle *can* be > licensed at all (see https://github.com/pypa/pip/pull/971). > > Pip also includes some code taken from other libraries however everything > is licensed as either 1, 2, or 3 clause BSD (besides the aforementioned > certificates). I can't think of us being ok with adding a copyleft license > such as GPL so code we bring in will likely be restricted to things like BSD.
IANAL, but I think it would be good if, at least, the setuptools license were clearer and the LGPL reference for the cert bundle was changed. It *might* be a good idea to get an opinion from Van Lindberg. But I'm happy to defer to Martin's judgement on this. > > [... easy_install on OS X ...] > > So this is an interesting question. On one hand I would say we shouldn't be > installing easy_install as that feels very user facing to me and the fact > that > setuptools is being installed is an implementation detail. On the other hand > if we put in stub commands that just simply direct the user to use pip then > people who *want* to use easy_install (perhaps for Egg support) won't be > able too (unless perhaps something is released on PyPI that restores the > easy_install commands?) I was thinking that, in the latter case, those users who really want to use easy_install could be told to just use pip to install a PyPI version of setuptools which would replace the stub commands with the real things - assuming that works. > > [... implementation plan ...] > > To further expand upon my original answer, I'm volunteering to do the initial > work on the ensurepip library, the scripts that will automated the ongoing > maintenance work, and the back porting of both of the above. I can also > attempt > to do the OSX Installer and Windows installer but I have zero idea how the > installers actually function so it's probably better for someone else to do > that. > > Since it sounds like you're willing to do the work for the OSX installer that > saves me from having to flail around trying to figure out how to do that > part, > so hopefully MvL or someone can do the same with the Windows installer. > > I'm not sure what needs done outside of the up front work, do I just propose > changes to PEP 101? Do I make a whole new PEP? Is there more than > just updating PEP 101? I think the thing to do is get review buy-in from the release managers for the affected active releases (2.7.x = Benjamin, 3.3.x = Georg, 3.4.x = Larry) and let them worry about updating PEP 101. The key point is that this PEP is implicitly adding some new responsibilities for the release team; I think they just need to be explicit. -- Ned Deily, n...@acm.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
