[Zope-dev] Re: ZPL and GPL

[Fred Wilson Horch]

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