Urgent Question about Python licensing

[Tim Peters]

[Dave LeBlanc]
> When UCITA first came out, there was a lot of press about it's evils.

There still is!  There was also a lot of discussion about it on
comp.lang.python, specifically in relation to the 1.6 CNRI license at the
time.  You need to read the license and the actual text of UCITA to get
anywhere with this -- or ask a lawyer.  Whether UCITA is good or bad, the 1.6
license grants you very strong rights, and UCITA can't magically negate
those.

> ...
> However, after reviewing information at http://www.ucitaonline.com/
> and at http://www.2bguide.com, I came to the conclusion that i'd been
> mislead. Imagine! being mislead by the press! <g>.  (I should have
> known better - i'm a firm believer in the "believe none of what you
> hear and only half of what you read" school of thought.)

Both of those are UCITA advocacy sites, and set up by the same lawyer (Carol
Kunze, who "attended the UCITA drafting committee meetings from 1996 -
1999").  So on *those* sites, believe the negative halves (if you can find
any <0.5 wink>).

> ...
> As it turns out, after the fact license changes are NOT binding,
> "shrink wrap" or "click wrap" licenses ARE binding and have been
> upheld by the courts, can't make a bogus venue choice, and that a
> licensor CAN unilaterally disable software but only after a 2 week
> warning in many cases.

Note that what UCITA says is irrelevant unless read *in conjunction* with
what the 1.6 license says.  For example, section 308(2)(B) of UCITA holds
that the license is *perpetual* if "the license expressly grants the right to
incorporate or use the licensed information or informational rights with
information or informational rights from other sources in a combined work for
public distribution or public performance.".  The CNRI 1.6 license does so
expressly grant both rights.  I am not a lawyer, but I can read -- so can
you.  UCITA simply doesn't kick in except where the 1.6 license leaves holes,
and CNRI didn't intend to leave any holes.  IMO (and IANAL), the GPL does
leave holes, and that's the fundamental source of the conflict (when CNRI
plugs a hole that the GPL doesn't, that's "a restriction" not in the GPL,
hence automatically leaves the CNRI license "incompatible" with the latter,
which forbids additional restrictions of *any* kind).

> ...
> Moving along, I find it ironic that the Open Software Foundation calls
> the GPL an open source license since it violates the rules given for
> such. GPL software has source available, but it's use is constrained
> and contaminating (unlike the GLL library license).

I see that they've added a footnote to point 9 at

    http://www.opensource.org/docs/definition.html

It reads:

    Yes, the GPL is conformant with this requirement.  GPLed
    libraries "contaminate" only software to which they will actively
    be linked at runtime, not software with which they are merely
    distributed.

I'm unsure whether they added that before or after your post, though <wink>.

> P.S Guido is welcome to my first born if I ever have one - but he has
> to do his own cooking.

guido-does-not-eat-children-neither-cooked-nor-raw-ly y'rs  - tim