Public Domain Python

Huaiyu Zhu hzhu at
Wed Sep 27 22:12:48 CEST 2000

I'm really not so interested in discussion licencing, so I'll try to dump
all I want to say once and for all.  Hopefully I won't need to explain
further.  (With all the usual disclaimers implied.  ;-)

The main point I'm trying to make is, for open source to work, there need to
be some basic trusts between authors and users.

Author: I give you these.  Use at your own risk.  Don't sue me.  Don't hold
me responsible for bug fixes, upgrades, etc.  Don't tarnish my reputation by
attributing other stuff to my name.

User: I'm going to commit my resources to use your stuff.  Don't come up
with additional conditions later on.  Don't ask me to pay additionally
anytime in the future.  Don't prevent me from tinkering with it anyway I
want. If other users of the same technoledge is upgrading, don't force me to
pay additional just to keep alive.

I see GPL as an excellent way to generate this trust.  It is true that most
other open source licences have similar effects.  But there is one
particular advantage that GPL has, due to copyleft.  That is, it prevents
"lock in" by non-interoperative software:

Suppose you have a document in a particular format on a particular OS.
Suppose both the format and the OS are open source.  As time goes on,
everyone is moving on to an upgrade of the OS, which is not open source. Now
to survive you have to upgrade, but then you can't read your old document
unless you pay a premium for an upgraded word processor which doesn't have
much additional functionality you want.  If you don't pay you have to keep
two versions of OSes around (or more if the formats changes from version to
version) just to read your own document.

In essence, if an upgrade to an open source software is not open source, a
user's data is held hostage, as if he had encrypted his own data with
someone else's key, which expires from time to time.  This is a very
vulnerable position to be in.  Copyleft makes this very unlikely.

On Mon, 25 Sep 2000 21:21:11 -0400, Tim Peters <tim_one at> wrote:
>Perhaps, but that wasn't the point.  If you read the FSF's copyright
>assignment form (I have, because I've signed it in the past), you'll see
>that it promises *they* (the FSF) won't change the licensing terms for your
>contribution in various nasty ways as the years go by.  Will you promise
>that too, in a binding legal document?  If not, I'm no safer with your
>GPL'ed code than you are with CNRI's Python code.  From my POV, you and CNRI
>are the same thing <wink>:  copyright holders who can change their minds on
>a whim.

When talking about changing licence, there are at least serveral meanings:
1. affect every copy ever used, retrospectively
2. affect copies in use after the change
3. affect copies distributed after the change
4. affect copies distributed under the new licence

When it comes to derived work:
1. affect all derived work
2. affect derived work done after the change
3. affect work derived from copies distributed after the change
4. affect work derived from copies distributed under the new licence

I'm pretty much sure that GPL only allows change of licence in the least
intrusive way.  That is, if the copyright holder announces a new licence,
whatever its term is, the user merely gains more freedom, the freedom to use
the new copies under the new licence.  He can still do whatever stuff he
could do to the copies he already got and all the derivative works,
including distributing them under old licence.  If he's not bothered with
the new stuff under the new licence, he can pretend it doesn't exist.

It doesn't look to me like the CNRI licencing issue is similar.  Otherwise
why do people spending so much time here discussing it?  Why not just ignore
the new licence and use the CWI licence?  It doesn't look to me like that
CNRI is putting out a lot of new stuff we dearly love (all any new stuff at
all) under the new licence.

>>> Or you can put your stuff in the public domain, which, by
>>> removing copyright entirely, prevents anyone (including you!) from
>>> ever asserting copyright on it.  It also prevents you from telling
>>> anyone else what they can do with it.
>> That's another alternative.  But it requires giving up copyright.
>And the downside to that is what?  From my POV as your paranoid *user*, I'm
>wary of you wanting to retain copyright.  What motives could you have for
>*wanting* the right to change the licensing terms later?  I'll trust the FSF
>far more easily, because at least they promise not to renege; but that
>promise depends on assigning copyright to them first.

Well, that's because I'm selfish.  Why would I want to give up my copyright,
together with unknown amount of advantages?  I only give users the little
bit of freedom that's granted in GPL, and I think that's enough.  Why do you
greedy user want more?  :-) From user's point of view, I'd trust the text of
GPL more than either the FSF or the copyright holder.  And based on GPL, as
a user, I really don't care what the motives the copyright holder may or may
not have.  To me, GPL is enough guaranteed freedom already.

OTH, if you are going to release Public Domain Python, I'd be really glad.

>> Here's a scenario: Suppose Python had been GPLed with CNRI as copyright
>> holder, and CNRI announced that 1.6 would have a different licence.  The
>> developers could take the CVS tree at that time and release 1.6 under GPL.
>> If the developers can't do that due to employment contracts, anybody else
>> could do it.  Then when they move to BeOpen they could start from the
>> competing 1.6 under GPL. (Here 'GPL' is a generic term including 'LGPL'.)
>Why do you think people couldn't do that now?  Sure, CNRI has made some
>vague noises about terminating rights under the CWI license, but nobody has
>really pressed them on it, and at least we got a paid legal opinion stating
>they wouldn't prevail.  And any argument they could make against the
>legitimacy of the CWI license is likely one they could just as easily make
>against the GPL.  For example, that Python was "never really released" by
>CNRI before 1.6.  The specific license in question has nothing to do with
>most of those ploys.

Why do I think so?  Because either you or Guido once said here, that if you
release 2.0 with a licence that's not derived from CNRI licence, you'd have
to start forking from no later than 1.5.2 and lose more than a year's work.

So the question is, is the CVS tree covered by the CNRI licence only from
the point that the licence is in effect (like in July or August) , or is it
covered retrospectively?

>> The only code CNRI could prevent others from using under GPL are
>> those that have not been published under GPL.  If they are ever going
>> release these codes that has to be GPL'ed as well (if it falls under
>> derivative work).
>If they claim the code was never *legitimately* released under the GPL, that
>argument fails:  if they prevail on that point, the code was never really
>under the GPL to begin with.  Much the same is true of code released under
>the GPL that violates other peoples' copyrights or-- God forbid --even
>patents these days.  Merely slapping the acronym "GPL" on it doesn't make it
>legal, let alone make it "free".

There is this talk about CWI licence not really being a licence.  Does this

1. The text of the licence is legally defective in some way
2. The copyright holder has never authorized release under this licence
3. The licence does not have CNRI on it

If it's the second point, do you conceed it to be a valid point by adopting
the CNRI licence now?  CNRI must have known this and still asked authors to
transfer copyrights for years.  Can that be considered fraud?  Can all the
authors rescind the transfer, claiming that they were misled?

I guess most people are under the impression that point 3 was the only
thing, and CNRI had implied authorization if only CNRI were put in the same
place as CWI in the old licence.

>>> illusory-safety-isn't-really-better-than-none-ly y'rs  - tim
>> With GPL, what you see is what you get - there's no illusion to something
>> free that could be reclaimed by the owner in the future.
>Not unless the code was legitimately and legally released under the GPL.
>But if we're assuming legitimately and legally, the CWI license looks just
>as strong in this respect, and just possibly stronger due to its relative
>lack of legal novelty.

With GPL, authorization can be the only issue.  But with CWI vs CNRI licence
we (at least mere mortals like me) aren't really sure if this is the issue.


More information about the Python-list mailing list