On Sat, 30 Mar 2002, Emiel Kollof wrote:

> On Friday 29 March 2002 21:31, Marko Karppinen wrote:
>
> > So, the important distinction here is that Emiel wouldn't be gathering
> > knowledge "on the workings of an existing work" (the driver), but on
> > the hardware he wants to support.

What was the background on this discussion?

> NetBSD already has an AWACS driver, it works somewhat, but hasn't got
> recording capabilities and the volume control sucks, and the fact that the
> driver hasn't been touched in a year. Hence my interest in using some working
> code from a system that's known to operate the hardware well.
>
> > Of course, it is very, very hard to read source code for a program and
> > then not be influenced by it when writing a workalike. This is what
> > cleanrooming is for; Emiel could find a friend to dig out the
> > hardware-specific information and relay it to him. This would at
> > least prevent accidental copyright infringement.

I don't think we really need to go to the extent of cleanrooming this.
While it does sanitize the legal trail, I think we are in an environment
where all the involved OSs (Darwin, Linux, and NetBSD) will do well enough
to just be "clean." If Emiel writes everything new himself, we're ok.

> I doubt if much of the apple code will survive the 'transition'. The Apple

Uhm, none of the apple code should survive the transition. Everything that
goes in should be your (Emiel's) own code.

> driver code is in C++, mine will be in C. NetBSD (and linux too btw) uses one
> driver for all the AWACS types, Darwin uses three. And APSL code can be in
> the NetBSD kernel with relatively few problems.

Note that APSL code needs special treatment in the kernel, which we aren't
ready to give it yet. Mainly because while we can freely make kernels with
APSL'd bits, third parties that want to use NetBSD to do something
(embedded apps, etc) have to realize that they need to keep Apple aware of
changes they make to the code.

For something like the Awacs driver, I think no APSL code should be put
in. For other things, like hfs+ support, I think APSL is worth the hassle.

> I'm taking this to the port-macppc@netbsd.org mailing list btw.

Oh, this is the tail of a private conversation.

> > P.S. I haven't followed the issue at all, but one would think that
> > there would be proof by now of previously undocumented hardware
> > information drifting from Darwin to the LinuxPPC side despite the
> > incompatible licenses...

Uhm, aren't the licenses on the source code, not the info about the
hardware? So that when hardware info moves around, that's ok? And isn't
that a big part of the _point_ of Darwin?

> I think Apple would have known that cross-pollination would occured when they
> openend Darwin. But hardware docs should be open to the public anyway.

I agree with Emiel, though I understand that why Apple doesn't open up the
hardware docs is that they 1) might not have them well documented other
than in code, and 2) the code might be exactly what they feel comfortable
documenting.

Take care,

Bill