This is getting rat-holed into another "GPL is evil" tirade...

The real "grep" source code is still available; sure it
means you have to assemble the parts instead of just taking
FreeBSD and running, but be honest: any product based on
FreeBSD, or any Open Source code, for that matter, has to
be productized before it is really useful.

I haven't heard this, and I have reason to doubt it: the
MySQL license was this way, and they moved away from that to
go with the GPL instead, which dropped the "no commercial
use" restrictions, including the performance for profit
restriction.

You may be sure, but you're also wrong.  8-).

Actually, the UI code on the InterJet is predominantly written
in C++, using C++ objects as models for form, frame, table,
and other objects.  The work was initiated at a time when you
could not write HTML code that would result in a consistant
user experience across different browsers, and the library
used to implement the code is called "libbif" for "Browser
Independent Framework".

The stuff that's not written that way is writen in C, and the
major guts of the system are also in C.  I rewrote the mail
services subsystem and the agent database management subsystem,
to use subschema entries, so mail configuration, mailing lists,
users, user capabilities, account information, etc., was all
based on a common data modelling system.

In fact, the only things that weren't in this model were the
legacy code in the system agent, the web publishing, and the
scheduling agent (the system agent handled network and other
system configuration settings, and was written in C by Archie,
while the scheduling code was written by Larry).

Even in the startup and shutdown scripts (at least two of which
are shell scripts which call grep, but the majority of which
are actually special purpose binary programs or wrapped versions
of special purpose binary programs, with perl or sh doing the
wrapping), there's no GPL infection, since calling something
from a shell script is _not_ linking.

Even if you were right and the rest of the world were wrong
about what constitutes risk in this neighborhood, I'd like
to point out an obvious fact that appears to have escaped you...

IBM does not sell InterJets, any more than your local cable
company sells set-top boxes: IBM sells services.  Since an
end user does not _buy_ an InterJet, they are not entitled to
the source code, even if it was all contaminated: they are
not being sold the software.

Consider if you were to run a program compilation service,
where people submitted code to be compiled, you compiled it
with GCC, and sent the object code back to them.  You charge
for this service, and you've made modifications to GCC to
make it more efficient: are your customers entitled to your
modifications?  No.  They are merely _utilizing_ your service.
This is the same distinction between "use" and "utilize" that
GPL proponents try to obfuscate, only this time it is working
against them.

Likewise, I could that GCC, modify it, make a compiler that
generates vastly superior code, use it to compile the stock
GCC, get a compiler that compiles the same unimproved code
as the stock GCC... but does so three times faster.  I now
sell binaries of this new compiler, and give away the source
code: after all, it's nothing more than the stock GCC source
code.  I don't have to give away my modified compiler source
code at all, any more than I have to give away the source code
to the DEC/Compaq Alpha compiler when I compile GCC using it
and get a faster, tighter GCC binary as a result.

So much for any "performance for profit" clause which might
come along later being worked around.  Until and unless the
entire software industry moves to the new model, _any_ new
model can be worked around, within the scope of it having to
be able to coexist with the current model for it to be able
to get anywhere.

Doubtful.  CGIs are underpowered, and scripted CGIs will
always lose out, performance-wise, to compiled code.  If
you are right, then someone is just going to build the same
product, throw out the scripting, and take their market away
from them, based on higher performance on equivalent CPU
cycles, or the same performance on lower cost hardware with
lesser CPU cycles.  Binary always beats scripts on everything
but prototyping.  Scripts are not a good idea for deployment,
since they are fragile in the face of system upgrades and
other changes which might change the underlying components
implementing their functionality (e.g.: grep), and since it
is almost impossible to do formal verification against a
script: you'd have to verify every system comonent with
which the script interacted, and then you'd have to invent a
formal validation tool for sh or perl, which while not quite
an NP-incomplete problem, would be close enough for the amount
of time remaining before your product is obsolete.

                                        Terry Lambert
                                        te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message