*BSD News Article 1782


Return to BSD News archive

Path: sserve!manuel!munnari.oz.au!samsung!uakari.primate.wisc.edu!sdd.hp.com!mips!newsun!gateway.novell.com!terry
From: terry@npd.Novell.COM (Terry Lambert)
Newsgroups: comp.unix.bsd
Subject: Re: Funding 4.4BSD Development
Message-ID: <1992Jul1.232241.15779@gateway.novell.com>
Date: 1 Jul 92 23:22:41 GMT
References: <79@ampr.ab.ca> <1992Jun26.021947.28286@gateway.novell.com> <1992Jun28.204256.14620@uunet.uu.net>
Sender: news@gateway.novell.com (NetNews)
Organization: Novell NPD -- Sandy, UT
Lines: 247
Nntp-Posting-Host: thisbe.eng.sandy.novell.com

In article <1992Jun28.204256.14620@uunet.uu.net> kolstad@uunet.uu.net (Rob Kolstad) writes:
>
> Terry writes:
>
>  -->  In article <79@ampr.ab.ca>, lyndon@ampr.ab.ca (Lyndon Nerenberg) writes:
>  -->  |> At this point BSDI and CSRG aren't really that different. Yes, BSDI is
>  -->  |> in it for the bucks, but then again BSD from UCB was never really
>  -->  |> "free" either. We payed via the license fee, and the money that lets
>  -->  |> UCB operate to begin with doesn't come out of thin air.
>
>  -->  1)	CSRG sources are freely redistributable.
>
>  -->  2)  BSDI sources are a trade from one encumbered set of files (from
>  -->      AT&T) to another set of encumbered files (from BSDI).
>
>Only the BSDI-produced sources are not freely redistributable (with the
>exception in the future of a window driver or two).  Most sources in the
>BSD/386 release are, in fact, redistributable.

So what you are saying is that BSDI sources are partially encumbered.  That's
what I thought I said.

>  --> 3) The great attraction of CSRG is that I can freely distribute my
>  -->	 hacks of their sources and thus look like a nice guy (8-)).  Since
>  -->	 I have SVR3.* and SVR4.* source licenses, I don't care about
>  -->	 getting sources to BSDI's ideas of the "correct" files; I can have
>  -->	 CSRG's, no problem; what advantage does BSDI give me?  With
>  -->	 sources, I can be my own support service.
>
>You can indeed be your own support service!  Presuming, of course, that
>you can get technical manuals for devices that you have that are not
>supported and that you have the skills to find and fix problems in the
>networking, virtual memory, and windowing code.
>
>As for CSRG's files, you will also, of course, either have to write the
>missing modules in the kernel (and any utilities and window drivers you
>might need) or forsake your redistribution right (since you can only
>distribute SVR* sources to other licensees).

Actually, this is an incorrect argument.  You *can* redistribute hacks, as
diffs.  This is specifically allowed, as I have found out, in the license
agreement.  What is still in question is the fact that diffs have limited
utility to non-BSDI licensees, since they are to be applied to BSDI
encumbered sources.  This means that you are *not* required (as I was
erroneously informed, and then posted) to redistribute through non-public
channels, BSDI being one, changes to BSDI encumbered sources.  This does
not speak to the fact that there is not benefit gained in so doing for
anyone but a BSDI source licensee.  This is effectively the same thing as
if the sources encumbered were not redistributable.

>Please do not confuse writing software with providing service.
>Writing software is an important and good thing; providing service
>is another important and good thing.

I certainly do not confuse the two.  BSDI is doing both.  They are not simply
a service company.  It goes against my grain to relegate proprietership of
BSD to a company that benefits from large portions of the code being
proprietary and staying that way.  This "irk" comes from someone stating
that there should not be a BSD consortium, and that BSDI is a sufficient
replacement because "it does everything that CSRG does".  This is simply
not true.  The ends will and do moderate the means.  BDSI's ends are the
production of profit for those entities financially involved in BSDI,
period.  My complaint is in the assumption that the same research will get
done under the auspices of BSDI as would have gotten done done under the
auspices of CSRG.  This is simply not true.  BSDI has a vested interest in
performing research along financially rather than intellectually profitable
lines.  This is not to say that the two will never coincide, but it is
farcical to believe that they will *always* coincide, and it is probably
overoptimistic to believe that they will coincide over 50% of the time.

>Your comment about publicly supported universities giving you free
>anything (e.g., software or an education) is a red herring.
>
>  --> 5) Everyone who has paid a license fee for the BSD sources, which has,
>  -->   lately, been more of a Kermit style distribution charge/donation,
>  -->   has put money toward the work on BSD, work which BSDI is directly
>  -->   benefitting from in their product.
>
>I'm surprised that you think this is a major revenue source.  I can't
>imagine that it is.

My comment about publically supported work being used for commercial intent
was *not* a comment about "publicly supported universities giving you free
anything"; rather it was a rebuttal of the two statements by the previous
poster to the effect that "paying $1000 to BSDI" was "cheap enough" as to
be equivalent to free, and that "BSD code has never been free, we've been
paying for it all along through industry support of CSRG".

I do *not* mistake this for a major revenue source, as I am well aware of
how funding of projects works, with or without industry involvement, in an
academic environment.  I am simply trying to point out the fallacy of the
statement that, "since we've been paying for it all along, what's wrong with
continuing to do so?".  The statements, when taken together, comprised a
logical sylogism, and thus were faulty in their reasoning.  It was akin to
stating "It doesn't cost anything, and besides, BSD cost just as much".

>As for who gets benefits from where, BSDI benefits when its customers give
>it money (presumably because they get benefit).  Portraying BSDI as a
>`sink' for benefit is certainly a misdirection.  BSDI doesn't `hog' the
>benefit -- BSDI does everything in its power to spread that benefit around
>(in exchange for fairly valued license fees).

I am not stating that BSDI does not provide benefit for their customers, nor
questing their right to do so.  I am questioning whether BSDI provides the
same benefit as CSRG has in the past.  I believe that the answer is "no", and
that, in fact, BSDI is providing benefit in excess of the benefit provided
by CSRG (from a purely commercial standpoint), but that benefit is more
restricted in scope than that derived by the UNIX community at large from
CSRG's efforts.

>  --> 6) As has already been pointed out, and probably will be again, BSDI is
>  --> 	 rumored to be planning to provide source for only those items which
>  --> 	 have been, by virtue of "copyleft", required to be freely available:
>  --> 	 ie: a binary BDSI/source BSD distribution.
>
>There is no truth to this rumor.  I state emphatically that it is BSDI's
>intention to distribute sources to those who wish them.
>
>Anyone who knows the source of the above rumor:  Please set them
>straight.  It is *not* BSDI's intention to distribute binary-only releases
>except to people who wish to purchase them for less money than source
>releases.

The base fear here is that BSDI will cease to provide full source releases
at some future date, restricting the source distributed to that which they
are required by BSD license to provide, and keeping BSDI encumbered sources
to themselves.  This would severely restrict the usability of the BSDI
sources in a teaching environment, especially if we relegate CSRG's current
standing to BSDI, which will inevitably result in more and more BSDI
encumberances as fixes and updates occur.  The problem is that BSDI's
*intent* is not warrantable throughout the forseeable future.  There is
no requirement for BSD derived sources to be made available (Sun, for
instance, does not tend to publish their TCP/IP, which is certainly BSD
derived); thus the only thing which can warrant their intent, or at least
have the same effect, is the continued existance of CSRG, or a similar
integrating body, such as might be provided by a "BSD consortium" or by
making Colorado's tenative offer of archival/integration services a reality.

>I'm working on a paper about why BSDI *does* cut it for teaching.  Expect
>it within a couple months.  I'm also working on educational pricing that
>is acceptable to financially strapped institutions.

Look, it's to BSDI's advantage to do this, in precisely the same way it is
in AT&T's (USL's) best interests.  Financially, and on the basis of
establishing market share.  That doesn't justify BSDI as a replacement for
CSRG, and it certainly doesn't; their goals are dissimilar.

>Mt. XINU didn't offer source, if I recall correctly.  It's up to you to
>compare the quality and functionality of the releases.

You recall incorrectly, although a System V source license has been required;
this will probably go away with MACH 3.0 and the BSD client, which would have
the effect of placing them in the same boat as BSDI.

>Your standards are very high.  Do you feel the same way about all
>software?  This sounds a lot like the `all software should be free because
>it's so easy to reproduce' argument.  I do not buy into that, as you might
>well guess.

Neither do I; but I have found the Jolitz code is a hell of a lot more useful
in an academic environment than a SVR4 source license.  The student can have
copies without a $180,000 lab fee.  In the same way, no lab fee still beats
a $1000 lab fee; as far as most traditional students are concerned, both
are equally unattainable.

A large number of compiler design classes, at least in the universities in
this area, use gcc. This beats the cost of a source license for SCDE from
USL per student, and gives hands-on experience working with peep-hole
optimization and preprocessing, something they could barely touch on if
they didn't have a working code example to touch.

My faulting of BSDI lies in its comparison to CSRG/Jolitz code as a tool
for education, not in it's efficacy or value as a commercial product.  I
certainly would put BSDI above SCO SVR3 as a product, even without source;
I would also put it above the CSRG/Jolitz code for use in a commercial
environment; I think CSRG and the Jolitz's would do this too.  The code
in their case has not been intended as a commercial product.  I think there
has been a lot of confusion about this due to people declaring themselves
386BSD "customers" and faulting the Jolitz's for not meeting some farcical
"delivery schedule".

>Thanks for keeping the dialogue alive.  We at BSDI really are trying to do
>the right thing -- but we can't give it all away or we couldn't continue
>development!
>
>RK
>
>
>     =================================================================
>         /\      Rob Kolstad           Berkeley Software Design, Inc. 
>      /\/  \     kolstad@bsdi.com      7759 Delmonico Drive
>     /  \   \    719-593-9445          Colorado Springs, CO  80919
>     =================================================================


I think people are confusing my attempt to state valid reasons for the
continued existance of CSRG or a CSRG-like entity with reasons BSDI should
not exist.

I am *not* attempting to say that "all software should be free" or that
"BSDI doesn't have a right to use the BSD code" or that "BSDI doesn't
fulfill a valid need".

I *am* saying that CSRG fulfills a valid need and BSDI doesn't do the same
thing; who is going to fill the need once CSRG is gone?  The existance of
BSDI is not sufficient answer.  Certainly, we have all benefitted from
CSRG's existance, including BSDI.  What are the possibilites?

1)	Try to keep CSRG around; a lot of people are willing to donate
	money in this cause, myself included.  I fear that this will fall
	far short of being sufficient if CSRG is to continue in both it's
	role as an integrator and as a research agency.

2)	Have other agencies pick up those portions of CSRG's effort which
	are deemed most critical.  One example is the Colorado proposal,
	wherein the integration part of the load is picked up.  There have
	been a few other proposals regarding the rest of CSRG's workload.

3)	Keep CSRG around, but remove the onus of support and integration
	so that they are not so involved in these that research can not
	occur.  This would depend in large part on the precise politics
	of the impending doom of CSRG.  It's been hinted that it is partly
	because research is impossible that support is being withdrawn; if
	so, such a plan may work around this problem, and funding agencies
	may be willing to reinstate their support.

I think the final answer must come from CSRG; we will certainly be impacted
by whomever they "will" BSD to, if anyone.  I dearly hope that CSRG's
beneficiary is not a commercial enterprise, which, by it's nature, must have
it's own agenda, and will hold that agenda in front of the one established
by CSRG, regardless of good intentions.  This is simply a matter of
economic necessity; a commercial entity must be physically self-supportive
or die.  The best soloution for us, obviously, is that CSRG stays around;
this is not the best soloution for CSRG (hence the trumps of doom).  The
second soloution is inferior to both the first and the third, in that the
overriding vision of CSRG is likely to be lost in the parcelling out.  The
third is a compromise, and vastly dependant on CSRG's willingness to let go
of some of the reins and stay on as the visionary for BSD.  Whatever happens,
it is certianly the passing of an era.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.