Here at Brontes Technologies we are looking to hire a Gentoo expert to join the systems group and help out with maintenance and development of our internal Gentoo systems and our Gentoo-based embedded medical product.
The company is based just outside Boston, MA and after being recently acquired we have an exciting ‘mature startup’ atmosphere but also the resources of a
big huge company. The product is an extremely cool handheld 3D scanning device, due for launch later this year.
The company recognises the benefits of open-source and tries to work closely with development communities and contribute back where possible. We also make a large effort to utilise the standard open source support tools where appropriate — as an example, we use catalyst to build our product release media.
This is a full-time office position. If you are interested, see the full job description. To apply, email your resume to the address listed on that page, mentioning that you read about the position on my weblog.
I just noticed that the fingerprint group at NIST have dropped NFIS2 and created NBIS: NIST Biometric Image Software.
NBIS is split into 2 parts:
- NBIS Non-Export Control: fingerprint quality analysis and feature detection tools. Source code available for download with no distribution restrictions.
- NBIS Export Control: fingerprint comparison utilities. Not available for download, CDROM must be requested.
This is good news – it is now much clearer which parts of NIST’s software are subject to export control concerns, and additionally, NIST have clarified the reasoning:
It is our understanding that NFSEG and BOZORTH3 fall within ECCN 3D980, which covers software associated with the development, production or use of certain equipment controlled in accordance with U.S concerns about crime control practices in specific countries.
Unfortunately the freely downloadable part is not enough to finish dpfp or create a generic fingerprinting library, because the code required to actually compare fingerprints is only present in the export controlled part. However, I’m now in a position to continue researching the legal issues.
Pressing questions I’d have for any experts here:
- What are the impliciations of ECCN 3D980 for an open source project?
- Can I legally export the NBIS Export Control CDROM to the UK without having to fill out any associated paperwork?
Earlier this month, I met with 25 other contributors at the 2nd Linux Wireless Summit. This was a followup from the 2006 summit.
The meeting happened in London and was scheduled to occur immediately after the IEEE 802.11 working group meeting. This enabled us to get some kind of vendor attendance.
While we had this opportunity, one of the biggest topics was discussion of why vendors still aren’t playing nice in releasing open source drivers (or providing the resources to let the community do so). The vendors in the room confirmed our suspicions – vendors are afraid of the FCC and other regulatory agencies who place restrictions on frequencies and power levels which these devices are legally allowed to transmit as.
Matt Norwood from the Software Freedom Law Center was in attendance and had studied the FCC regulations in some detail. The conclusion is that the FCC rules are vague and while they don’t explicitly say that open source drivers are not allowed, vendors are not prepared to risk falling out of compliance and are playing it safe (or not playing at all). Unfortunately there is no short term solution to this: it would take years for the FCC to clarify the regulations. Short term workarounds such as finding ways to encourage vendors to produce open drivers with only the regulatory part closed (such as Intel’s ipw3945 offering) are under investigation.
The other large topic was the merge of the new wireless stack (d80211) which was donated to the community by Devicescape. The stack has many more features than the current in-kernel ieee80211/softmac stack, and improves consistency between drivers. We are now much closer to getting d80211 merged into mainline Linux, but there are still some significant technical issues to be resolved.
Before the conference, several people asked me if I could raise issues with the suckiness of Intel’s ipw3945 driver offering in that it relies on this awkward closed-source userspace daemon. Fortunately Intel have found a way to rewrite their firmware so that the regulatory domain control is no longer at the driver level, therefore a fully open-source driver with no binary userspace part has been developed (iwlwifi). Although Intel have not yet announced it, the source code has been released here. This rewritten driver uses the d80211 stack mentioned above, so it’s not possible just to compile it against mainline Linux at the moment. The iwlwifi website includes instructions for how to check out the wireless-dev tree where d80211 is being held.
All slides and notes from the conference can be found here. Stephen Hemminger wrote a more detailed summary. Also, one other significant product of the summit was a central information source aimed at Linux wireless users – we have now launched linuxwireless.org.