Date: Sat, 24 Mar 2001 18:31:44 +0100 (CET) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: mjacob@feral.com Cc: Peter Wemm <peter@netplex.com.au>, Mike Smith <msmith@FreeBSD.ORG>, scanner@jurai.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Intel driver doc's Take 2. Message-ID: <200103241731.SAA49447@info.iet.unipi.it> In-Reply-To: <Pine.BSF.4.21.0103240847540.92915-100000@beppo.feral.com> from Matthew Jacob at "Mar 24, 2001 08:48:35 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103241731.SAA49447>