I apologize in advance to those on the list for whom this lowers the signal to noise ratio. I hope by now you've killed the subject line and you won't even see this if you're not interested. I sill haven't heard where the proper forum is for discussing Zope licensing issues; here's my last post on the subject to zope-dev. Fred Barry wrote:
FWH> Knowing that the copyright holders have made a conscious FWH> decision not to allow developers to obtain Python and Zope FWH> under the terms of the GPL in the belief that this allows FWH> people to do "whatever they want" with it does help us FWH> evaluate the long-term prospects for these systems in the FWH> marketplace.
I'm not sure what point you're making.
That IMHO the copyright holders are unwittingly consigning Python and Zope to remain niche products. Perl and ruby (two competitors to Python -- one with a much larger installed base and the other with arguably superior features) both offer developers the choice to obtain the language under the GPL. In other words, the GPL is a competitive advantage for perl and ruby over python.
With respect to Python, the issue has been hashed to death over in c.l.py and other forums, so I think this will be my last post on the subject here.
I'll follow suit (this will be my last post on the subject here) with these final thoughts: 1. The GPL offers developers and end users a high comfort level. You can argue its shortcomings, but many influential people view it as the "gold standard" for free software licenses. In particular, since it is widely used, championed and studied, as legal counsel I don't have to strain my brain when my client asks me what can or cannot be done with software that is licensed under the GPL: I've already done the research and have the answer ready. This is not the case with the Python license or the ZPL. 2. Companies should offer their customers freedom of choice. Most companies have found that the "practical problems" raised by offering customers licensing choices are outweighed by practical benefits, including increased market share and profits. 3. Established companies are running scared of the GPL with good reason. Have you talked to a Microsoft lobbyist recently? New entrants with innovative business strategies may stand to gain at the expense of established software companies who base their business around keeping secrets and prohibiting people from sharing computer files. Finally, I'd like to respond to some specific points Barry raises:
IMO, the Python 2.0.1 license is the best of all possible worlds. In the words of the FSF themselves:
The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL.
This quote is from http://www.gnu.org/philosophy/license-list.html which states in relevant parts: The GNU General Public License, or GNU GPL for short. This is a free software license, and a copyleft license. We recommend it for most software packages. The License of Python 1.6a2 and earlier versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that newer versions of Python are under other licenses (see below). The License of Python 2.0.1, 2.1.1, and newer versions. This is a free software license and is compatible with the GNU GPL. Please note, however, that intermediate versions of Python (1.6b1, through 2.0 and 2.1) are under a different license (see below). Notice two things: 1) FSF explicitly recommends using the GPL; they not not explicitly recommend using the Python license. 2) Python 1.6 screwed up the Python license.
Dual licensing (a la Perl) has practical problems, which have been raised in other forums, and you really want to avoid it if possible. Python 2.0.1's license allows Python to be linked with GPL'd software such as GNU readline. I don't see what advantages "allowing developers to obtain Python [...] under the terms of the GPL" would provide above and beyond that.
The main advantage I see is that it would calm developer fears that the people behind Python don't have a clue what they are doing when it comes to licensing. Consider that Guido et al jumped ship twice and along the way managed to drag Python through a disastrous 1.6 release. I think this accounts for why Guido is tired of talking about licensing issues. We all make mistakes. It's what we do about them that counts.
Guido (and now, really the PSF) is clearly not concerned about freeloaders taking of Python and not contributing back, which is about the only additional thing a GPL release of Python could prevent.
I think "prevent" is the wrong way to think about Python. "Repair" the damage done with 1.6 and "reach out" to new developers are where efforts need to go now. The GPL can help on both counts.
Any Python module or extension you write can now be legally released under the GPL and linked with Python. So if you feel that the GPL affords your code useful benefits and protections, you now have that option, whereas under Python 1.6, 2.0, or 2.1 you didn't.
Yes, it could be (and was) worse! Here are my final thoughts (which admittedly seem to go against some other opinions expressed): 1) If we can convince Digital Creations to abandon the ZPL and at least license Python and Zope identically, then we're making progress. 2) Adopting a standard license already in wide use (instead of perpetuating a series of home-grown Python/Zope licenses) would be additional progress. 3) Nirvana will be achieved by joining with the true believers in GPL purity. ;-) Let me know if lawyers are welcome on the zope-licensing mailing list, if such a place exists. Peace and productive coding! Fred -- Fred Wilson Horch mailto:fhorch@ecoaccess.org Executive Director, EcoAccess http://ecoaccess.org/ P.O. Box 2823, Durham, NC 27715-2823 phone: 919.419-8567