Subject: Re: ksh as option for shell [Re: Bash as Option for Shell]
To: None <current-users@NetBSD.org>
From: Chapman Flack <email@example.com>
Date: 08/31/2004 15:26:58
> 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
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
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
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.