--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 18, 2005 at 09:15:25AM +0200, Igor Sobrado wrote:
> > If these commands still need work, how is it they are better from a
> > technical point of view? We didn't start this conversation talking about
> > this feature or that feature being better in the *BSD versions as I
> > recall, but about what needs to be done to get them good enough to go i=
nto
> > NetBSD.
>=20
> Hello Bill.
>=20
> I am sorry, I cannot understand that comment.  On the previous email

This thread, many months ago, did not start out indicating how the OpenBSD
versions of these commands had feature X that ours did not, or indicating
that they were faster or smaller in this or that way. For the bc and dc
commands, the thread consisted of seeing if the bc and dc commands from
OpenBSD were good enough for our tree.

"Technical superiority" stems from the superior program being better than
other programs when assessed by technical criteria. As I recall, the
thread indicated the OpenBSD bc and dc were bigger and slower and less
featureful than the GNU ones. Those are technical criteria and the OpenBSD
bc and dc are not better by those criteria.

> I wrote "I hope that work on a replacement for the commands currently
> being used will continue".  I am NOT asking for immediate replacement,
> but I do not want the OpenBSD Team development to be dropped.  IMHO,
> these commands are fine... is the problem that these commands have few
> gnu-isms?  These commands follow standards as close as possible and
> are reliable.
>=20
> > So it seems like it really is a "political" issue. There can be good
> > reasons for this, but please let's not confuse the issue.
>=20
> No, it is not a political issue.

How is it not?

The OpenBSD dc and bc have not come out as being better in terms of
technical criteria (performance, correctness) from the things I remember=20
seeing in this thread. So choosing them is not choosing the technically-=20
superior program. You describe them as, "fine." Not "superior" nor=20
"excellent," but "fine."

So once again I ask, how is selecting the OpenBSD versions not a political=
=20
decision?

Choosing to replace code with other code due to license is a political=20
decision. It is one the NetBSD project has chosen to make and has=20
indicated it will make in the future. It however still is a political=20
decision.

For instance, we now use pax, a non-GPL tool, for our tar. That was one=20
place where we made the political decision to go with a new tool front end=
=20
over the tool we had used for the entire life of the project. So saying it=
=20
is a political decision doesn't mean it's a bad thing nor that we souldn't=
=20
do it.

I think the quickest way to get a non-GNU bc and dc in NetBSD is not to=20
replace the code. Phil, who also is a long-term NetBSD developer, has=20
indicated he is open to changing the licensing to a dual-use license.=20
However there is some work needed, which he won't be able to do until this=
=20
summer. If you help him do the work, the license will change and NetBSD=20
will have a non-GPL (well dual-use) bc and dc.

Take care,

Bill

--3MwIy2ne0vdjdPXF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCY+T7Wz+3JHUci9cRAkzFAJ4g/j3b4jTuypN1Vkj+KrwERZS3ugCdH6/G
9w1ufuvClNEGbIv25h5Jhdo=
=7t8P
-----END PGP SIGNATURE-----

--3MwIy2ne0vdjdPXF--