On Fri, 3 Oct 1997, Chris G. Demetriou wrote:

> Neil Carson wrote:
> > Chris G. Demetriou wrote:
> > 
> > > You, Causality, may not be able to write a driver and give it away in
> > > source form, since you agreed to an NDA.
> > > 
> > > However, is there any reason that The NetBSD Project couldn't _accept_
> > > a driver written by a third party, assuming it had a not-unreasonable
> > > pedigree?
> > 
> > The NDA was with the RiscBSD kernel team, rather than Causality.
> > Providing Cumana don't decide to take Russel to court (just in case he
> > reverse engineered or anything---I'm not alleging he did/has) then I
> > guess we could make use of the info.
> 
> I ask again: is there any reason that The NetBSD Project couldn't
> accept such a driver?

None assuming the source of the info was cleared.

> As far as I know, The NetBSD Foundation has signed no such NDA, or was
> even _aware_ of any such NDA signed by some of the NetBSD/arm32
> developers.  Even if you ("the set of people who you describe as the
> RiscBSD kernel team") are not capable of committing any such code to
> the NetBSD source tree, if another developer were to write the code,
> they could commit it, couldn't they?

The original NDA was signed about 3 years ago which gave us the register
mappings and memory map info of the card in question. This is the extent
of the NDA. It does not apply to any actual code only to the addressing of
the card and how it should be accessed. In fact the driver actually uses
the sfas216 driver so the code that is covere by the NDA is the card
specific attach. The only reason an NDA was accepted was that this used to
be a very popular card which we felt needed some support.
As a result a separate object file has been available from ftp sites that
can be linked in if required.

As things stand only myself and Scott have read the info or played with
the code so there is nothing stopping anyone else producing a driver and
getting it committed.

The problem is getting the info. Cumana will not make the info public
although we have discussed it a number of times and in my opinion most of
the reasons for the original NDA are now irrelvant 3 years on given the
number of other SCSI cards now available.
Obtaining the information by reverse engineering is a no-no so another
public source would be required for a third party to use. If such
information was publically available then we (RiscBSD) would consult with
Cumana and see if in this situation they would be prepared to lift the NDA
so the kernel team could release its driver.

Thus :
If the info is public we will try and renegotiate with Cumana the outcome
of which would dictate if we could release the existing driver.

Failing that, 3rd parties are welcome to write a new driver which should
be fairly easy given some of the other SCSI drivers already available.
This would have to be commited by another developer so that it was clear
I was not involved with the development.

However I would only want to see this happen if the source of the
information is clear and that Cumana are happy with that, purely on the 
grounds that Cumana have been very protective of this information and I
would want to know that they had no disagreement with the info being
public.

Cheers,
				Mark