When Guido wrote about Unfreedonia, he was referring to a hypothetical country where the laws allow a judge to interpret the GPL in a way that subverts its intended purpose. The laws of Virginia do not subvert the GPL.
I presume that CNRI chose Virginia because that is the state where CNRI is located. I suspect it could also have chosen Massachusetts or California, where it also has offices, but neither of those states would satisfy RMS either. The problem for GPL compatibility is not UCITA, but specifying a state.
I think this is a technicality, and I hope RMS and CNRI will find a way to work it out. During the negotiations among CNRI, FSF, and BeOpen, RMS has made many helpful reviews of the CNRI licenses. He has always explained why provisions conflict with the GPL and proposed ways to revise them.
I am still hopeful that we will end up with Python distributed under a license that is compatible with the GPL. I am not convinced that the clause in question will end up being a problem. It really is a technicality; I expect even RMS would agree with that. Nearly every license I've ever seen has one.
No. Python 1.5 was compatible with the GPL. The clause about the state of Virginia in the 1.6 license is the only thing that is incompatible with the GPL, and it is new in the 1.6 license.
The Python 1.6 License FAQ may clarify some of these issues for you. CNRI owns the code that Guido and I and our co-workers wrote at CNRI -- and they have decided to release Python 1.6 with a license that RMS has an issue with.
The specific issue is that RMS believes that the clause in the Python license that says the contract is governed by the laws of Virginia is incompatible. The lawyers are still working on this one...
We are doing a lot of work at BeOpen with CNRI to get them to allow
the GPL as an alternative license across the CNRI-derived parts of the
codebase. Bob Kahn of CNRI seems to dislike the GPL so he has been against
doing this as part of a CNRI release but potentially has been amenable to
allowing it to be done by BeOpen in a derivative release. We shall see in
the next week whether or not this is true and will let everyone know how
it goes. We at BeOpen want GPL-compatibility and have pushed for that since
we started with any Python licensing issues.
Interesting that you think Python's OO features are added on and inspired by C or C++. Classes have been in Python since at least Python 0.9, which was released internally at CWI in 1991.
I don't want to speak for Guido, but I believe Modula-3 was much more of an inspiration than C++. What features do you think of as inspired by C++?
Take a look at the Python Web Programming Topic Guide. If that doesn't provide you with the answers you need, try asking your question on comp.lang.python.
The design stage for Python 3000 isn't exactly started at this point:-). Given that uncertainity, I do not expect that any changes introduced by Python 3000 will be so radical that you will need to re-learn Python programming. If you learn Python, you should not have any trouble adjusting to Python 3000.
There are good books and tutorials available for Python. The Python tutorial that comes with the documentation and books like Learning Python and The Quick Python Book are good places to start. They were written before Python 1.6, but there aren't too many changes; certainly not many that will affect teaching materials.
I don't know what will change in Python 3000, but I can tell you a little about what we hope to achieve. We would like to take the opportunity to fix some of the language's warts without being hamstrung by backwards compatibility. I think the language has few warts, though, so there should be few changes. Andrew Kuchling put together a list of language warts that captures the sort of thing we'd like to fix.
The internals of Python 3000 will change a lot, and the C API will surely be different. The internal changes are not going to cause a lot of monkey with the language definition.
I expect we'll be starting on Python 3000 much ealier than previously planned. I still wouldn't expect it anytime soon, but I imagine serious design work could begin in tandem with 1.7 work. The previously discussed schedules were conservative in part because we had day jobs doing other things.
Slashdot Mirror
When Guido wrote about Unfreedonia, he was referring to a hypothetical country where the laws allow a judge to interpret the GPL in a way that subverts its intended purpose. The laws of Virginia do not subvert the GPL.
I presume that CNRI chose Virginia because that is the state where CNRI is located. I suspect it could also have chosen Massachusetts or California, where it also has offices, but neither of those states would satisfy RMS either. The problem for GPL compatibility is not UCITA, but specifying a state.
I think this is a technicality, and I hope RMS and CNRI will find a way to work it out. During the negotiations among CNRI, FSF, and BeOpen, RMS has made many helpful reviews of the CNRI licenses. He has always explained why provisions conflict with the GPL and proposed ways to revise them.
I am still hopeful that we will end up with Python distributed under a license that is compatible with the GPL. I am not convinced that the clause in question will end up being a problem. It really is a technicality; I expect even RMS would agree with that. Nearly every license I've ever seen has one.
No. Python 1.5 was compatible with the GPL. The clause about the state of Virginia in the 1.6 license is the only thing that is incompatible with the GPL, and it is new in the 1.6 license.
The Python 1.6 License FAQ may clarify some of these issues for you. CNRI owns the code that Guido and I and our co-workers wrote at CNRI -- and they have decided to release Python 1.6 with a license that RMS has an issue with.
The specific issue is that RMS believes that the clause in the Python license that says the contract is governed by the laws of Virginia is incompatible. The lawyers are still working on this one...
You can find even more information in the license-py20 mailing list archive. The most recent post from Bob Weiner, BeOpen's CTO, says:
Interesting that you think Python's OO features are added on and inspired by C or C++. Classes have been in Python since at least Python 0.9, which was released internally at CWI in 1991.
I don't want to speak for Guido, but I believe Modula-3 was much more of an inspiration than C++. What features do you think of as inspired by C++?
Take a look at the Python Web Programming Topic Guide. If that doesn't provide you with the answers you need, try asking your question on comp.lang.python.
The design stage for Python 3000 isn't exactly started at this point :-). Given that uncertainity, I do not expect that any changes introduced by Python 3000 will be so radical that you will need to re-learn Python programming. If you learn Python, you should not have any trouble adjusting to Python 3000.
There are good books and tutorials available for Python. The Python tutorial that comes with the documentation and books like Learning Python and The Quick Python Book are good places to start. They were written before Python 1.6, but there aren't too many changes; certainly not many that will affect teaching materials.
I don't know what will change in Python 3000, but I can tell you a little about what we hope to achieve. We would like to take the opportunity to fix some of the language's warts without being hamstrung by backwards compatibility. I think the language has few warts, though, so there should be few changes. Andrew Kuchling put together a list of language warts that captures the sort of thing we'd like to fix.
The internals of Python 3000 will change a lot, and the C API will surely be different. The internal changes are not going to cause a lot of monkey with the language definition.
I expect we'll be starting on Python 3000 much
ealier than previously planned. I still wouldn't
expect it anytime soon, but I imagine serious
design work could begin in tandem with 1.7 work.
The previously discussed schedules were conservative in part because we had day jobs doing other things.