Python license question
Martitza
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.
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. :)
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?
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.
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. 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.
We would have a problem with our customers distributing our derivative
work or preparing derivative works of our derivative work. We could of
course apply our own restrictive license to things which are truly
ours, but we cannot do this to the work derived from python because
that would conflict with section 2 of the python license.
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.
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.
Martitza
Tim Peters
|> 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).
Martitza
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
> Mr. Peters:
Na, my father's dead -- you can call me Uncle Timmy ;-)
> 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.
I don't know BeOpen.com's legal status (for example, I don't know
whether a bankruptcy judgement was issued). CWI is a Dutch national
research institute, and CNRI and the PSF are both US 501(c)(3) public
charities -- BeOpen.com was the only for-profit entity in Python's
licensing history. It's quite intentional that the top three licenses
on the stack "look pretty much alike" -- if I had my way, there would
be only one license, but the parties involved couldn't agree to that
at the time.
While at least the PSF will pursue licence violations, the license is
so permissive that there hasn't yet been any need for that. To the
best of my knowledge, BeOpen.com, CNRI, and CWI have never had license
complaints against anyone's use of Python either.
Terry Reedy
"Tim Peters" <tim.p...@gmail.com> wrote in message
news:1f7befae0610081826o235...@mail.gmail.com...
> I'm not a lawyer, so can't give legal advice. I can explain intent,
> speaking as a Director of the Python Software Foundation.
This strikes me as an excellent reply, which would be worth adding to the
site as a FAQ (possilby after running it by PSF's lawyer). I am sure the
OP is not the first with such questions.
tjr