Public Domain Python

William Tanksley wtanksle at
Fri Sep 15 03:45:13 CEST 2000

On Thu, 14 Sep 2000 22:26:37 GMT, Grant Edwards wrote:
>In article <slrn8s2gbs.5rr.wtanksle at>, William Tanksley wrote:

>>>That sounds _exactly_ like all of the commercial software vendors I've ever
>>>dealt with.  

>>First of all, Python isn't supposed to be commercial software.  Comparing
>>it to worst-case commercial software isn't right -- I don't want Python to
>>ever be as bad as BEST-case commercial software.

>>Second, no it doesn't.  Commercial software vendors are tyrants, but
>>they're also accountable to their users.

>You must be a bigger customer than I ever was -- few if any of
>the vendors I dealt with ever acted accountable.

Perhaps you just have a shorter view than I do.  I remember when copy
protection schemes were sought after, and when no scheme was too onerous
for SOME company to try.  I remember the customer backlash, and how
relatively quickly copy protection disappeared, as companies learned why
it's stupid to treat customers as enemies.

There are other examples, and other battles yet to be fought.  Free
software is in a sense the biggest of those battles yet.

But I'm not claiming that companies like to treat their customers well.
They don't.  I'm claiming that companies which aren't FORCED by their
customers to treat their customers well invariably fail to do so.  See the
first sentance of the next quote:

>>CNRI is NOT accountable to us, yet it IS changing the license.  That is
>>enough right there to strike fear into anyone's heart.  The fact that THIS
>>license is nice doesn't mean that they won't just up and do it again!

>Very true.  However, they can't take _back_ previous licenses
>that have been granted.  If the new license isn't acceptible,
>users can split off and continue to develope Python under the
>old license.

Keep in mind that I'm deliberately overreacting to illustrate my point:

Well, if they can't retroactively change licenses in the future, than why
are they being allowed to change them retroactively now?  Why isn't BeOpen
basing 2.0 off of 1.5.2 instead of 1.6, to avoid the legal wrangling?

Do you see how frightening this looks?

Add in the fact that the term most under dispute specifies a UCITA state,
a state in which software licenses are RIDICULOUSLY slanted in favor of
copyright owners and against licensees, and you see another reason to

>>>The difference is that with things like Python, gdb, etc. 

>>> 4) if other people stop supporting the product I at least have the
>>>    choice of supporting it myself if I want to. 

>>This is the beautiful thing about open source.  It's what I'm
>>worried about CNRI taking away from us!  If they can change the
>>license like this, and make the license retroactive to the
>>first version they released,

>IANAL, but I don't think they can do that, can they?
>If they can retroactively change the terms of a license which
>had been granted at some point in the past, then that is scary.

...and, thinking like my boss, I won't take the risk -- I'll go with a
language without the risk, like Perl.

And it *looks* like a serious risk; after all, the community *appears* to
be allowing them to change the licenses of 1.3 through 1.5.x

>Grant Edwards

-William "Billy" Tanksley

More information about the Python-list mailing list