From owner-freebsd-hackers  Thu May  9 07:53:23 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA12907
          for hackers-outgoing; Thu, 9 May 1996 07:53:23 -0700 (PDT)
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA12902
          for <freebsd-hackers@FreeBSD.org>; Thu, 9 May 1996 07:53:20 -0700 (PDT)
Received: by pcnet1.pcnet.com (4.1/SMI-4.1)
	id AA00723; Thu, 9 May 96 10:50:05 EDT
Date: Thu, 9 May 96 10:50:05 EDT
From: eischen@vigrid.com (Daniel Eischen)
Message-Id: <9605091450.AA00723@pcnet1.pcnet.com>
To: hdalog@zipnet.net, jkh@time.cdrom.com
Subject: Re: Copyright question
Cc: eischen@vigrid.com, freebsd-hackers@FreeBSD.org
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> > What is Condor trying to achieve here?  Protection of sales, right?
> > More to the point, they'd like to sell this board to FreeBSD users as
> > a consequence of having this driver in FreeBSD by default, assuming
> > that they might be less willing to do so otherwise.  The "protection
> > of sales" issue is also actually a secondary one since, up to this
> > point, there _are_ no sales to protect.  So far, so good.
>
> This is a good point.  Anyone working with MIL1553 on FreeBSD
> probably has the budget to buy the Condor board over another board,
> and Condor's cooperation will, I bet, ensure 95% of the "market"
> for 1553 boards on *BSD.
>
> Though I haven't looked at the Condor board, I'm sure it is built
> out of off the shelf 1553 support parts and porting the driver to
>another board is probably a no-brainer.  It is probably little more
> than a 1553 chip on the ISA bus.
>
> As Condor has supplied their DOS driver to Dan, unrestricted
> distribution puts them in the position of potentially bootstrapping
> other vendor products.  Back to my previous point: Put Condor
> specific code in a single file, keep generic 1553 interfaces
> in an unrestricted file, ask nicely for release under the BSD
> copyright, but don't be surprised when they decline.

I looked into breaking apart the Condor specific code.  I made a lot
of modifications and enhancements to it and it's pretty integral to
the driver.  Breaking out the Condor specific code wouldn't leave
a usable driver.  Although it would allow someone to freely make
changes for another 1553 board :-)  If they refuse to release it
under the BSD copyright without clause #4, I'm not opposed to
breaking out Condor specific code.

The Condor board is really just a United Technologies M1553BCRTM
chip on the ISA bus.  Condor added up to 64K of RAM and tied in the
registers of the M1553BCRTM chip into IO memory address space.
There is one Condor-specific register which will tell us what kind
of board it is and how much RAM is available.

Dan Eischen
eischen@pcnet.com