Python license question

[Martitza]

Mr. Peters:

Thank you for so kindly taking the time to resolve my misunderstandings
and to elaborate on the intent of the PSF.

In particular, thank you for explaining in plain language how the
licenses stack.  I'm sure our counsel will figure out what a license
from a defunct BeOpen means and anything we do will be in compliance
with all of the license stack.

Best Regards,
Martitza  Mendez


Tim Peters wrote:
> [Martitza]
> |> Hi.  I work for a small company (actually in process of forming)
> > interested in embedding or extending python as part of our commercial
> > non-open-source product.  We have legal counsel, but are interested in
> > the spirit as well as the letter of the law.  Not much seems to have
> > been written about the python license since version 2, so pointers to
> > more recent discussions or contacts are appreciated.  If this is not
> > the right place to ask these questions, I would welcome better ideas.
> >
> > We've read the license and "layman's language" at
> > http://www.python.org/psf/license/ and are need help reconciling the
> > two.
>
> There's also the informal license FAQ:
>
>     http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq
>
> I'm not a lawyer, so can't give legal advice.  I can explain intent,
> speaking as a Director of the Python Software Foundation.
>
> > First Observation
> > The entire license -- such as produced by license() -- includes a lot
> > of information which appears to be historical or anecdotal, not the
> > kind of language our lawyers usually see in licensing agreements.
> > Lawyers claim they don't like "extra" language.  You be the judge.  :)
>
> Section A (HISTORY OF THE SOFTWARE) isn't really part of the license.
> But because the PSF doesn't have the right to /re/license the portions
> of Python copyright by CWI, CNRI, or BeOpen.com, the history given
> there can be helpful if anyone is inclined to spend (IMO) too much
> time worrying about the licenses.
>
> > First Question
> > Is all of that information really a required part of the license we
> > pass on to our customers or is the "PYTHON SOFTWARE FOUNDATION
> > LICENSE VERSION 2" portion sufficient?
>
> Section A is not required.  All of section B is required.  Parts of
> Python are copyrighted by, and licensed by, the four entities whose
> licenses appear in section B.
>
> > Second Observation
> > Referring to sections 2 and 3 of the PSF License Version 2... Our
> > non-open-source product will be a derived work, either by extending or
> > embedding the python interpreter.  According to section 3, we will
> > briefly summarize these modifications to the python interpreter as
> > these relate to our product.  Good.
>
> Indeed ;-)  Note that there are no specific requirements about detail,
> and this is really for your benefit:  the more clearly you identify
> the parts that are your original work, the easier it will be to prove
> it is in fact your work (should that become necessary).
>
> The NEWS file that comes with a Python distribution is the PSF's
> version of meeting this requirement (by the similar terms in the CNRI
> and BeOpen.com licenses, the PSF is also required to summarize the
> modifications the PSF makes!).
>
> > Section 2 says that we (as Licensee of the original python) have to
> > include without our modified python a copy of the license.  The License
> > explicitly states in section 1 that it is between the PSF and the end
> > user.
>
> The phrase "end user" appears nowhere in the license.  You must mean
> Licensee.  As a Licensee, you're free (heck, encouraged) to make
> derivative works, but you have no legal authority to put a /different/
> license on any part of the Python you started with.  In exactly the
> same way, the PSF has no legal authority to put a different license on
> the versions of Python the PSF started with.
>
> When you distribute your derived work, your "end users" have rights to
> use the PSF-copyrighted portion of your work by exactly the same means
> you have:  they also become Licensees of the PSF.  And of CNRI, and of
> BeOpen.com, and of CWI.
>
> The license you put on your derived work as a whole only controls the
> portions of your derived work original with you, and your derived work
> as a whole.  You can neither diminish nor increase the rights your end
> users have wrt any of the Python code you obtained from the PSF --
> that's not your work, you don't have and can't get copyright on it,
> and you and your end users have exactly the same rights with respect
> to it (as spelled out in the license file you're asking about).
>
> > At the moment, we are the end user.  But when we sell our
> > software as a derived work, our customer becomes the end user.  So our
> > customers are entering into a direct agreement with PSF.  This
> > indemnifies the PSF (sections 4,5,6,7) -- also good.
> >
> > But there is a side effect of section 2 that would seem to give our
> > customers many rights ("to reproduce, analyze, test, perform and/or
> > display publicly, prepare derivative works, distribute...") to the
> > derived work we created.
>
> I think the licenses are clear about this.  For example, the PSF
> license at the top of the stack specifically says it only applies to
> "Python 2.4 alone or in any derivative version".  The phrases "alone"
> and "in any derivative version" intend to modify "Python 2.4".  It's
> not intended to be read as the two separate phrases "Python 2.4 alone"
> or "in any derivative version", and I'm not sure it even makes sense
> to try to read it that way.
>
> > We would have a problem with our customers distributing our derivative
> > work or preparing derivative works of our derivative work.
>
> It can simplify this a lot to remember that the entity holding
> copyright on a piece of code is the only entity able to license it.
> Thus your license applies to your work, the PSF license applies to the
> PSF's work, and so on down the stack.  That's why there /is/ "a
> stack":  nobody ever gets to forget about the licenses they started
> with, they can only add more licenses to the pile.
>
> > We could of course apply our own restrictive license to things which are truly
> > ours,
>
> And definitely should, if that's what you want.
>
> > but we cannot do this to the work derived from python because
> > that would conflict with section 2 of the python license.
>
> That's not the intent.
>
> > Second Question
> > Can we we prevent our commercial customers from freely redistributing
> > or modifying our derived version of python?  The answer seems like "no"
> > from the License itself but "yes" from the layman's language.  Of
> > course, our lawyers only look at the license.
>
> You set the license on your portion of the work.  While it's hard to
> conceive of anyone doing this, one of your customers certainly could
> /extract/ pieces original to the PSF Python, and distribute those
> (provided they met the PSF license terms, including reproducing the
> PSF license).  If they include any of your original work in the
> process, and the license you set doesn't allow that, then they're in
> violation of your licensing terms.
>
> > Thank you for your time.  Our goal is to understand and be good
> > corporate citizens.  We believe python would be a great benefit to our
> > customers, and we are looking for a viable business model that allows
> > that.
>
> Best wishes!  Everything you said you want to do is wholly consistent
> with the PSF's intent, and the PSF license definitely intends to be
> friendly to proprietary derivative works.  Ditto for the BeOpen.com,
> CNRI, and CWI licenses (although I can't speak for those three in any
> official capacity -- I can speak for the PSF in my role as a PSF
> director).