From owner-freebsd-hackers Sat Mar 24 9:32:20 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 55C5A37B719; Sat, 24 Mar 2001 09:32:11 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id SAA49447; Sat, 24 Mar 2001 18:31:44 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200103241731.SAA49447@info.iet.unipi.it> Subject: Re: Intel driver doc's Take 2. In-Reply-To: from Matthew Jacob at "Mar 24, 2001 08:48:35 am" To: mjacob@feral.com Date: Sat, 24 Mar 2001 18:31:44 +0100 (CET) Cc: Peter Wemm , Mike Smith , scanner@jurai.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have read the thread for a while, and i wonder: why in the world someone should go through the effort and responsibility of SIGNING THE NDA _and_ negotiating with Intel for getting permissions to redistribute the code ? I do not see how this is doing any good to the project, given that 1) there are alternatives (for 100Mbit quite a few of them), and some cards are even better and cheaper than the "fxp"; 2) even if you have hardware with an "fxp" on board, adding a second supported card is cheap and easy -- nothing like having to put in a second video card; Of course if you need support for this card in your own business, you do what you need (including NDA's etc), but that is a totally different story (and it appears to be a relatively straightforward and quick thing to do if you do not need to redistribute the source code). I think we all have better ways to use our time for FreeBSD than dealing with the legal department of some company. cheers luigi > > 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-hackers" in the body of the message