From owner-freebsd-isp Sat Mar 24 9:31: 7 2001 Delivered-To: freebsd-isp@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 40A0F37B719 for ; Sat, 24 Mar 2001 09:31:04 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id MAA04553 for ; Sat, 24 Mar 2001 12:32:05 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010324123145.038f58a0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 24 Mar 2001 12:48:49 -0500 To: isp@freebsd.org From: Dennis Subject: Re: Intel driver doc's Take 2. In-Reply-To: References: <200103240805.f2O856h92540@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A better approach is to find someone poor with no chance for employment (or a criminal, with no garnishable income), have them sign the NDA and then have them post the documents on a public site. NDAs have no value if the breechor has no net worth. Saves a lot of negotiating. Dennis At 11:48 AM 03/24/2001, you wrote: > > 1 - Give a select group of people the docs under NDA > > 2 - If there are any specific features Intel wants avoided, get them to > > identify > > them up front. > > 3 - Let them write a driver that uses whatever features that are > useful, with > > header files that define the register bits etc that are reasonably > related > > to the features used. > > 4 - Hand over the driver to intel for "final veto" with a pre-agreement in > > place so that if they do not respond in 30 days we can release it > as-is. > > 5 - If they have specific features or register bit definitions that > they want > > removed, then do so as long as it isn't going to hopelessly cripple the > > driver. If they want something removed that wasn't covered in the > list at > > the start and is going to cause severe performance problems (say a 10% > > performance or efficiency drop), too bad. > > 6 - Repeat the loop for 'final veto' but with a week timeout instead of 30 > > days. > > > > Regarding step 5; if the information is already "out there" (other open > > source drivers, leaked onto the internet, etc) then it is fair game and we > > can use it. > >Step 4 is a lose. That will never fly because they don't have the interest >or bandwidth to review. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message