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.232031.15719@gateway.novell.com> Date: 1 Jul 92 23:20:31 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.