Subject: Re: Summer of Code: Wifi Browser / Kismet clone
To: Ricardo Correia Pinto <firstname.lastname@example.org>
From: oliver gould <email@example.com>
Date: 04/22/2006 11:22:08
Content-Type: text/plain; charset=us-ascii
On Sat, Apr 22, 2006 at 11:38:50AM +0100, Ricardo Correia Pinto wrote:
> While catching up with the latest changes, I've noticed
> wpa_supplicant's BSD driver already implements scanning using the ioctl's
> I mention in the PDF (It's also mentioned in tech-kern by rpaulo). It also
> has a control interface wich can be used to trigger scans, and perform
> some wpa-related tasks.
> This raises a question: reinvent the wheel by implementing the
> scanning functions of wpa_supplicant or use the functions offered by it?
While I definitely agree that code reuse is a Good Thing, let me play
devil's advocate for a second..
There are two approaches (presumably) to using wpa_supplicant: copying
their scanning code over into this project; or interfacing with the
wpa_supplicant daemon. There might be some problems with both of these.
Since wpa_supplicant is licensed under the GPL, importing their source
would require this project to be licensed under the GPL. I don't know
if this is desirable.
If there is a way to interface with the daemon, this would not force
these licensing constraints. However, it would require all users to run
this extra daemon, whether they are using WPA or not. The
wpa_supplicant page  indicates support isn't global across chipsets
and drivers. Of course, it may not be possible to support all chipsets,
but I would assume we'd want to go with the broadest coverage possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (NetBSD)
-----END PGP SIGNATURE-----