> The license is an open one, but there are restrictions which may cause
> problems with including this KSH in base.

Hmm, you mean, with including ksh in base instead of pdksh?  ("This ksh"
makes it sound like there's more than one. ;)

> If I've read their FAQ correctly, if I make proprietary extensions,
> I would  have to supply any patches back to AT&T if I provide the
> source code to anyone else. (faq 3).

I think your reading is correct.  That would put the license somewhere
between Berkeley and GPL:

2. If you prepare a Patch which you distribute to anyone else you shall:

   1. Contact AT&T, as may be provided on the Website or in a text
      file included with the Source Code, and describe for AT&T such
      Patch and provide AT&T with a copy of such Patch as directed by
      AT&T; or,

   2. Where you make your Patch generally available on your Internet
      website, you shall provide AT&T with the URL of your website and
      hereby grant to AT&T a non-exclusive, fully-paid up right to
      create a hyperlink between your website and a page associated
      with the Website.

From our http://www.netbsd.org/Goals/redistribution.html:

  One thing that some people don't realize about Berkeley-style
  licenses is that they allow licensees (the users of the licensed
  work) to sell the code, in any form, with or without modification,
  and that they make no requirement that licensees give away the source
  code, even if they're selling binaries. This provides a striking
  contrast to the license terms granted by the GNU General Public
  License, because the GPL requires that, if you're distributing
  binaries, you be willing to give away the sources to build those
  binaries.

The ast-open license doesn't say you have to give your source to anyone
(so < GPL), but if you choose to, you're also willing for AT&T to have
a nonexclusive right to use it as well (so > Berkeley).

Of course there's GPL'd stuff in the tree now, and redistribution.html
also says:

  In summary, the people involved in the NetBSD Project use a
  Berkeley-style license where possible because it closely matches our
  goal of allowing users to do whatever they'd like with our software,
  while making sure that we get credit for the work we have done. We
  are pragmatic, however, and will include software with different
  license terms in the NetBSD operating system if it significantly
  improves the quality of the system.

My vote is that a mature, full-function shell that is the same one
the big guys use, runs all ksh scripts by definition and doesn't
crap out in various surprising cases, would be that kind of an
addition to the system.

> This might not be acceptable to people who base commercial
> products on NetBSD and so on.

I can see the concern in some cases but in the specific case of ksh I'm
not sure this restricts anything a smart developer would want to do. 
In general, the reason you would consider making proprietary extensions
to a piece of code is to add value.  But the chief value of having ksh
in a distribution is that, well, it's ksh.  You know what it does, you
know it works, and you know it does the same things on your system it
does on everybody else's.  It won't become crippled any time you
redirect fd 3 (as our /bin/sh did from 3 April 2002 to 27 January 2003,
and still does in the official 1.6.2 release because the fix wasn't
pulled in) or any of the other things you really don't expect to see in
a utility as fundamental as the shell in a 2004 official release of an
OS. It will do just what you and all your ksh scripts expect. That
value can only be subtracted from by making proprietary extensions.

I should sharpen that point.  Not to forget that ksh has mature
mechanisms for loadable extensions and for embedding ksh itself
in applications - which in neither case would require opening your
source to AT&T or anyone else - there are some distinct classes of
extension to be made:

1.  Functionality that can be added as a ksh builtin or ksh-embedding
    application.  No worries here.  Furthermore you can package up your
    builtin or application and ship it off to anybody else who
    has ksh in their OS and it will work for them too, as long as
    nobody's been mucking inside ksh.

2.  Fixes of ksh bugs.  It makes little sense not to send these back to
    AT&T.  There's no glory in being the only kid on the block whose
    ksh does not have the foo bug.  Bug or not, realistically, that
    just means ksh foos and you don't.  But everybody's better off if
    the fix gets rolled in.

3.  Changes to core ksh semantics other than what can be
    accomplished with the builtin/embedding mechanisms.  These would
    be the only problem cases, but licensing isn't the biggest thing
    wrong with doing something like that.

> We would have to keep NetBSD changes seperate in our base source
> (faq 5,6).

Right ... the license talks of redistributing the (unmodified)
"capsule" (1.a.i) and, separately, "patches" (1.b)--as well as the
built software that includes the patches, of course.  Maybe that
would require a little technical cleverness to work into the current
repository structure, but it's cleverness that would probably pay
off for other 'external' technology that's in the tree, too.  As a
NetBSD user I would actually *prefer* to know that something like
ksh is being maintained as necessary patches against an official
ksh, and has not just been vaguely assimilated into the throbbing
hum of NetBSD development.

I don't know how AT&T would feel about loading it into CVS as a
vendor branch and hacking on the trunk, in the usual CVS style;
that's conceptually the same as capsule+patches but works easily with
the tools already in place.  I imagine their technical people would
see that but maybe the lawyers wouldn't.  They might also object to
webcvs visibility to people who haven't clicked 'I agree'.  Worst
case, webcvs could probably be tweaked to support that kind of thing,
and maybe the tweak would be of use to other webcvs users as well.

I don't expect though that there would be much activity in local
hacking to the ksh distribution; realistically if anything in the
ksh build doesn't Just Work(tm) it's rather likely to point to
something else that needs fixed.

-Chap