From: terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert)
Newsgroups: comp.unix.bsd
Subject: Selling 386BSD
Date: 14 Aug 92 19:56:09 GMT
Organization: Novell NPD -- Sandy, UT

In article <1557@hcshh.hcs.de> hm@hcshh.hcs.de (Hellmuth Michaelis) writes:
>In <1992Aug12.100430.3467@Urmel.Informatik.RWTH-Aachen.DE> kuku@acds.physik.rwth-aachen.de (Christoph Kukulies) writes:
>
>>Strangely, Chris Dimetrios (excuse wrong spelling) recently mentioned
>>in a patch he posted that he had put his *own* Copyright note on the patches.
>
>>And he further writes that if anyone want's to put hist software on CD-ROM 
>>that checking back with him would be required. 
>
>i can understand chris. yesterday i saw an ad in the german "unix magazin",
>where a company named "tuttle design" sells 386bsd 0.1 on tape for 399,- DM,
>which is about 250 US$. they say in the ad, that a contribution to bill jolitz
>is contained in this price....
>
>i tried to talk to them, but there is just an answering machine .....
>
>if anyone in germany thinks of buying from them, contact me, i will cut
>a tape for you if you contrib 250US$ (or whatever you can give) DIRECTLY
>to the jolitz's.
>
>conclusion: in every piece of software, i will put an equivalent copyright
>	    notice in. i spend an enormous amount of time writing an pccons
>	    device driver (watch out for it), and i do not like it, if some-
>	    one else is making money with it.
>
>don't misunderstand me, my contrib is on the way to bill & lynne, and if some-
>one sells 386bsd and gives ALL the money to the jolitz's, there is nothing
>wrong with it - i would like some sort of centralized version/revision 
>management for 386bsd >= 0.2, and in order to do it, they need money !

	The problem with this point of view is that it prevents the
commercialization of 386BSD derived works.  I know that some of you will
say "big deal!" or "the code is *mine*!".  The first I can dismiss with
the statement that, just because you're not interested in it doesn't
mean that someone else isn't.  The second I have to agree with, although
I would prefer that there was some licensing mechanism incorporated into
the copyright so that it didn't dismiss outright commercial use.  If there
was insistance on ownership, I would strongly lobby for *not* including
the code as a replacement for any core technology in 386BSD, or in BSD
in general.  Let the owner distribute it seperately, or distribute it
under seperate cover in a 'contrib' location, like X.  That way, there
will still be an unrestricted use BSD core technology.

	Why do I say this?  Am I planning on selling 386BSD myself and
competing with BSDI?  The answer is "No, I have no plans to compete with
BSDI".  They can keep their marketplace and the gentle attentions of AT&T.

	So what's in it for the rest of us?  This is simple to answer and
somewhat harder to explain: it buys us non-commercial control of BSD.

	Far from being dead, the concept of a BSD consortium is alive and
well.  Non-commercial control of BSD is one of it's major goals.  With
CSRG's stated intent of completing their work on BSD4.4 and then just
melting away to nothing, there are three alternatives:

o	Let BSD die, an abhorent thought.
o	Let BSDI control BSD's future direction, which would in time
	limit the research to areas of potential commercial profit.
o	Form a BSD consortium to provide steering and financial support,
	but keeping the redistributable nature of BSD intact so that it
	is not simply an academic curiousity or commercial product with
	nothing in between.


	The third option, to my mind, is closer to the way CSRG has been
managing the code in the past.  A fourth option, that of keeping CSRG
running, has been repeatedly shot down by CSRG members.  As much as I'd
prefer that option, I have to respect their wishes.

	I don't believe the Jolitz's have equivalent resources to CSRG.
As much as Bill and Lynne have already contributed, and as much as they
continue to contribute, I don't believe it is possible for them to do
with less people what CSRG was unable to continue doing with a much
larger group and larger financial backing.  To expect them to do this
is both unfair and likely to kill them.

	The deliberate restriction of code which is or becomes an accepted
part of 386BSD castrates the ability of a consortium (or the Jolitz's, for
that matter) to license the technology.  This prevents the "neat things"
in 386BSD from ever becoming part of commercial product, or finding their
way into systems you MIS department might buy you.  It also prevents the
formation of a "value added" company.  It could very well be that what the
"tuttle design" mentioned is selling is not the 386BSD code per se, but
rather *support* for a limited period of time (with opportunity to renew).

	A licensing/use restriction that the code modifications are the
property of (and must be sent to) the original author if used commercially
is much more of a reasonable restriction, if you *must* have a restriction.
Thus if your ethernet driver is used commercially, the commercial user
gets an ethernet driver and you get any bug fixes, which you are free to
rerelease under the same terms.  A restriction requiring mention of your
contribution in documentation, and refusal of the right to modify the
copyright spit out by your driver initialization (which will appear on
every boot) might also be deemed reasonable, if you are prevented by
your employer from being in it for the money (like myself).  Look at the
vast quantity of public domain code that has come out of Boeing for
precisely this reason.

	I don't want to denigrate either Chris' or Helmuth's work on the
serial or console drivers, repectively, but I don't believe that either
Chris or Hellmuth really expect to make large amounts of money for their
code being included in a commercial product, and neither do I expect that
a commercial licensee of the code from either a consortium or the Jolitz's
will be able to be competitive if it has to pay $10 per code file use per
sale... such an arrangement would inflate the price beyond the available
alternatives.  Likewise, a percentage requirement per file could push the
royalty above a commercially viable percentage, or even over 100%, thus
also killing it.

	Don't kid yourself that the BSD community has not benefitted, in
terms of features of other products, standardization, a large user base,
and recontribution of code back to BSD, from commercial interests, only
the most recent of which is BSDI.  But also keep in mind that the ability
to commercialize through bug fixes, support, and distribution is not less
important than the code itself in terms of the things we like about BSD
sticking around and turning up elsewhere.

	That we are able to have a free system now is due in large part
do the commercialization and recontribution of code by companies like
Genentech (which springs to mind; there are others -- check the various
redistribution copyright notices in the source files) to BSD for free
redistribution.  If you want to make money with it, set your code up as
binaries which aren't critical to the operation of the core technology,
sources to which you retain rights but which are not intended as an
included core piece replacement, or as shareware/commercial add-on
products.  As it stands now, I would certainly be against throwing out
an old, freely usable tape driver, as a manufactured example, in order
to have Mr. Spiffy's tape driver which was nicer but encumbered.  It
would degrade the overall value of the code for a set of uses which I
believe are not only reasonable, but, in my opinion, critical for the
continued existance and growth of BSD.  I see no reason that the old
tape driver would not remain part of the distribution until such time
as a donated tape driver met the redistribution conditions currently in
place for code acceptance by CSRG; at least in this fashion BSD is
likely to be a more rather than less prevalent alternative as time goes
on, and your file system won't become shareware.


					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, nor are they neceassarily representitive
of the views of other individuals involved in the effort to create a
BSD Consortium.
Newsgroups: comp.unix.bsd