Be Open Source (for our RFID library)

Starting from today, we will open our internal rfid library to the world, first as a public sdk and then as an open source project under GPLv3 license.

RFID and Open Sourcing

We can resume the current state of public contactless libraries to these projects:

• PC/SC - pcsclite: not a rfid library.
• rfidiot.org: for Python.
• libnfc-nxp (libnfc.org): nfc oriented library, mainly supported by NXP. In fact LibLogicalAccess could support libnfc-nxp as a Reader Provider.
• libfreefare: api based on libnfc-nxp to manage mifare chips family
• Virtual Smart Card and PC/SC Relay projects: smart card emulation
• OpenNFC: NFC oriented library, mainly supported by InsideSecure.
• librfid from OpenPCD guys: this project looks abandoned - no update since 4 years.
• OpenSC: smart card library, not oriented to manage rfid chips
• SpringCard pc/sc sdk: C oriented sdk for pc/sc and springcard readers. Its license doesn't allow free use if you're not using hardware from this company.

I believe LibLogicalAccess have a place into the community as it is developed in C++, frequently maintained, not limited to nfc, and its development cycle and use are independent from any manufacturer.

LibLogicalAccess project vision

It was designed to be the contactless layer for most of our products. It provides low level commands access and high level generic abstraction for several chips and reader of the market on 125Khz, 13.56Mhz (ISO14443 / ISO15693) and 433Mhz frequencies. The abstraction allows software using that library to support newly implemented technologies without any modification.

Developed in C++, the library is available on Windows and Linux operating systems, 32-bit and 64-bit, user mode only. The build process is not maintained anymore on Mac OS X but it should still work with limited modifications. More precisely, the current build and test process is on Windows >= XP SP3 and Debian Squeeze.

On Windows we wanted to support mainly used development language like C# / VB.NET (and by extension VB and Delphi). C++ objects are wrapped into COM objects layer that can be used directly into these languages.

Why

Because we already have a well internally used rfid library. Why not making it open for everyone?

Because transforming a company project into an open source project is a bit challenging.

Because we are already convinced about the community advantage as most of the development tools, applications server and libraries we use are open source. Giving back to the community what we get from the community.

Because some of our customers use our software for security purpose. Making the rfid layer open source will serve that purpose.

Because we are a small company always looking for new competencies.

What will change

For our customers

In the immediate effect: nothing. Our products (IDTransfer, DataWriter, ...) will work as usual and we don't have any plan for open sourcing end-user products. Step by step... we want to get some feedbacks first.

 

For our partners

Even if we encourage public information you don't have to worry about our mutual agreement.
If you act as a reader manufacturer with specific api and your reader is supported by LibLogicalAccess, it has even more value for you as new people can develop application with your hardware more quickly.

 

For our current LibLogicalAccess library users 

You will now have a dedicated LibLogicalAccess web space where you can find information, get fresh news, freely download updates and the possibility to contribute.

 

For you

If you are reading this post I believe that you are interested about rfid development. This library will allow you to go ahead with many already supported technologies with some helper on business target like Access Control and NFC use.

 

For us

More coffee. We have to adopt few changes in our work to be community driven instead of being corporate driven. Changes are technical (see next point) but also organizational.

Next stages

1. Making the library available publicly as a sdk without source code. Documentation, headers, binaries and dependencies will be freely available for download without registration. A specific web space and communities tools must be set-up (mailing list, ...).
2. Making uniform the build process between the different platforms. On Windows the build process is managed by Maven, on Linux you have to use SConstruct directly.
3. Cleaning code and separate few content that we are not allowed to communicate into another library. That's the hard stuff because we are using several libraries and information under different licenses and sometimes NDA that doesn't match well with GPLv3. In the result we have to add a dynamic plug-in functionality where plug-ins are also under GPLv3 but with license exception because they are linking with NON-GPL libraries.
4. Making the source code available on a public git repository. Setting-up a new Continuous Integration Server and Maven repository for the community.

License

At the end the project will be available under GPLv3 license with an exception for ISLOG.
Because in the coming weeks we will focus on Stage 1 only, until we reach Stage 4 the library will be temporary available under another license that GPLv3.


Stage 1 in the coming weeks. I believe everything should be ready for October but do not hesitate to give feedbacks asap.
We look forward to give you some news soon !

Versioning and other things

I like to see versioning as the project's foundation.

Whereas good versioning doesn't mean good development process, you can be sure that bad versioning means bad development process. Product version history can give you a good idea about a software development company quality and I thing it should be an important criteria if you're looking for outsourcing.

As an example, I will describe how we manage versions at ISLOG. Which I truly believe is far from perfect as we make improvement every month.

Most of our projects code is stored on SubVersion respositories. Those projects use the following version description:

[MAJOR].[MINOR].[SCM REVISION].[BUILD NUMBER]

Recently, we start to migrate projects to Git repositories that required changes to the version description (because of the Git distributed orientation):

[MAJOR].[MINOR].[MMDD].[BUILD NUMBER]

Where MAJOR number change rarely and MINOR number is incremented on each release.

Of course, as soon that a release is done, the SCM repository is tagged with that version to facilitate code browsing between versions when required.

The current development version is continuously built and tested thanks to continuous integration servers (Jenkins) which looks on code changes. Some native projects are multi-platform and have to pass successfully jobs on Windows CIS and Linux CIS before any release authorization.

Binaries files generated for tagged and development versions are stored on artifacts servers to be reuse independently on other projects. We mainly develop in .NET (C#) and C++ technologies. Maven is use for native projects, with Archiva as the repositories server. NuGet is use for .NET projects, but we have to do a lot of tricks to have snapshot repository equivalence (our hope is on the coming versions).

Every binary has a generated symbol file (pdb file).

That file is linked to the SCM revision and stored on a local Microsoft Symbols Server. Thus, if a project use an artifact as dependency and the developer want to debug the dependency code, symbol is retrieve automatically from the Symbols Server, code source revision retrieved from the SCM, and then displayed to the developer.

And the version regulate all this stuff.

New reader support: STid and Elatec

Two new RFID readers are now supported into the development snapshot of our products.

- STid STR reader
A French RFID reader with nice cryptographic functionalities.

- Elatec TWN3 reader
Popular mainly into the German market, this reader exists for various RFID technologies.

DESFire EV1 support

Oh god, it should be on the road-map since two years. I breathed deeply when I changed the ticket status to "fixed".

We always knew how the chip worked, but never had the time to implement it to the software. You could imagine how frustrating it was.

The RFID Suite 2011 version will support Mifare DESFire EV1, just like any other chip.

Windows Phone 7 and NFC

I'm just back from a Microsoft Days event, with of course the current main Microsoft product at the top: Windows Phone 7. This event was technical and I could discuss shortly with one speaker.

The operating system looks great, performs, with good features. Nothing really new except good integration with other Microsoft product. Which it by itself already a big value.
You can quickly throw four limitation:
- Material is almost imposed by Microsoft. Due to performance.
- You can't create application running as "service", not shown => no code executed
- You can't develop outside DotNet with Silverlight and XNA. No native development, no other runtime or graphical engine.
- You can only deploy the application using the marketplace.

That means company deployment is not possible at this time.
That means innovation will evolve with Microsoft. Hope your physical and system component is already integrated, or even planned. Otherwise you're really stuck. NFC compability is not here, neither planned.

Nokia do research and works on it since more than two years, with already few available phone, Apple just released a NFC reader for iPhone and Google implements NFC technologies into the software through OpenNFC for Android system. Microsoft doesn't event think about it for the latest mobile operating system on the market... And the business can't do it by itself.
I don't know if this eight month old OpenNFC WM7 compability new is still true now. Seems difficult.

End-user is clearly targeted by Windows Phone 7, not the corporate user, and things will probably be unlocked later in the time when feedbacks will come. But time go fast and innovation doesn't wait.

Update January 07, 2011:

Other people can enable NFC on Windows Mobile 6.5 using a NFC sticker which communicate with the phone on bluetooth, see TwinLinx.

For important project under Windows Phone 7, nothing stop you to directly work with the phone manufacturer to add NFC hardware and specific native application. Only available for a minority, but better than nothing :)

Update June 01, 2011:

Windows Phone 7.5 "Mango" Updates should bring NFC support to Windows Phone. Let me see it.

Update October 08, 2011:

And it comes with Windows Phone 8... finally !

Custom format and new reader support: Prox'N'Roll and LGM5600

Compatibility with two new readers:
- Prox'N'Roll reader: look pretty, and I really enjoy to develop on it. It is also the key to make our application Calypso compliant. (more info here)
- LGM 5600 reader: the main feature is the IP connection directly available through the reader. (more info here)


The big new for Arnaud and me, is the Custom Format availability (finally !).
You can create your own Access Control format without any additional development from our side.

More freedom is always better in this world :).

New reader support: Deister and RFIDeas

One part of our job is to be compliant with majority of readers and chips on the market. We just end up Deister reader integration, from the German company, and RFIDeas reader integration, from the US company. We are glad to have those companies as new partner for our product today.

To refresh the list, here is what our products support (and is tested with) in the current development phase:

RFID readers:

• Omnikey (5321, 5325, 6321, ...)
• Cherry
• SCM
• HID SmartID
• ELA
• Deister
• RFIDeas
• All PC/SC readers

RFID chips:

• Mifare Classic 1k/4k
• Mifare DESFire
• HID iClass (and so PicoPass)
  
• HID Prox
• Tag-It
• iCode
• Deister
• EM4001
• EM4002
• EM4100
• EM4102
• EM4135
• Indala
• All ISO 15693 chips

I don't talk only about chip identification, but high level chip functionalities too.