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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message