I've been a bit over a week in Taipei, mainly to co-present (with Armijn Hemel) the GPL compliance engineering workshop at Academia Sinica. The workshop was attended by more than 100 representatives of the local IT industry in Taiwan, from both legal and engineering departments.

I think even only the sheer number of attendees is a great sign to indicate how important the subject of Free Software license compliance has become in the IT industry, and specifically in the embedded consumer electronics market.

I would like to use this opportunity again to thank the OSSF at Academia Sinica for doing a great job in organizing this event.

Thanks also to Armijn, who not only does excellent work at gpl-violations.org but also covered the majority of the presentations at the workshop.

So what did I do the remaining week? Lots of meetings, mostly with companies regarding GPL compliance, but also with old friends like Wolfgang Spraul and Holger Freyther who happened to be in the city at the same time.

I also had some very exciting meetings related to my various GSM related FOSS projects, but it is too early to really say anything about them.

In the last two days, I have finally started to get some initial work done on the OsmocomBB port for the Mediatek chipsets. My current focus is the MT6139/6140 RF Transceiver, including stuff like setting it up for Rx and Tx, computing the VCO/PLL dividers for all ARFCNs in 4 bands for uplink and downlink, etc.

Next will probably be the drivers for the MTK digital baseband BPI (baseband parallel interface) and BSI (baseband serial interface), which are needed to actually use the MT6139/6140 driver, as well as the antenna switch module, power amplifier and other parts of the RF front-end.

I'm not really testing any of this code at the moment, as I'm travelling a lot without access to my Racal 6103 or other GSM handset testing equipment. However, writing even untested code helps me understand the chipset better and is a first step in the right direction. I guess January 2011 will provide more time to continue/complete this task.

Back in October I blogged about ST Ericsson hooking gstreamer into Android but apparently making that code proprietary. I may have been a bit opinionated at the time. The reasons for not disclosing the code allegedly were that it is assumed to be of no general use. However, it still felt very bad that two Free Software projects are interacting with each other through a proprietary layer.

I've since had a very pleasant contact with the Head of MeeGo Business Development at ST-Ericsson and they have now released and submitted the respective code-bases, like the gst-android git repository and the Audioflinger sink in the gst-plugins-bad repository as well as Android makefiles for all parts of gstreamer.

It is great to see this kind of development, and see that ST-Ericsson is trying hard to do the right thing: Not only releasing their extensions of gstreamer under a GPL-compatible license to their customers, but even actively pushing those changes upstream. Thanks to everyone involved, particularly Andrea Gallo and Benjamin Gaignard.

I'm back from Vienna where I attended a very exciting DeepSec 2010 conference. This years focus was clearly on mobile security: The GSM security workshop by Karsten Nohl and me, the various talks like All your baseband are belong to us by Ralf-Phillip Weinmann, a talk on Android security auditing / forensics and much more.

In a few days, I'll be leaving for Taipei/Taiwan again. Apart from the one-day GPL compliance engineering course together with Armijn, there will be a number of meetings with various companies - both GPL as well as GSM/3G related.

It will be great to be back to Taipei - unfortunately only for 10 days, which is a real pity. I still miss it a lot.

I've recently been able to look at packet traces of an Ericsson BTS (which they call RBS) and have been working on understanding their proprietary Abis-over-IP protocol stacking and OML layer.

By now, all equipment makers have migrated their BTS products from classic TDM (E1/T1) lines to some form of IP-based back-haul. However, the GSM specs as published by ETSI and 3GPP still only specify the E1/T1 transport layer, and every vendor seems to invent their own protocol for back-haul.

What we already know (and support) is the ip.access style Abis-over-IP, where they have their IPA multiplex layer inside TCP. Inside that they then have pretty straight-forward 08.58 (RSL) and 12.21 (OML) messages.

With Ericsson, they use a stacking like this: Ethernet, IPv4, L2TP, custom-HDLC, RSL/custom-OML.

The custom HDLC layer (I have called it Ericsson HDLC, or short EHDLC) seems to work quite different from all other forms of HDLC that I've seen:

• 1 Byte Address
• 1 Byte Length (including the header!)
• 1-2 Bytes Control
• n Bytes Data

The Control octets are just like in any HDLC, i.e. you have U/I/UI/S Frames and see commands like SABME, UA, RR, ... It mostly uses a two-octet control word that has both N(R) and N(S) for acknowledgements. At the beginning they actually do a XID exchange that seems compliant with ISO 8885 (if you cannot find that document, try reading the AX.25 spec instead, its XID is compatible with ISO 8885).

I have not fully understood the Address octet yet. I see lots of changes in the upper three bits, and it seems there is a SAPI or TEI that is the lower 5 bits of the octet.

Having a length field in an HDLC header instead of any flag bytes is indeed very uncommon to see.

The OML layer (called OM2000) is completely proprietary and shares nothing with the GSM specs 08.59/12.21 apart from the three byte header. However, I have managed to build a pretty complete dissector which you can find together with the EHDLC code in this rbs2409 patch which applies on top of the generic wireshark abis_oml.patch

It is my hope that this information (and particularly the dissector) will prove a valuable resource once we add Ericsson BTS support to OpenBSC. If there is anyone who can provide us real BTS (RBS) hardware, please let me know :)

During recent weeks I started to do some work related to SIM Application Toolkit (STK / SAT). Debugging this kind of application is hard, as you never really know what exactly is going on between your SIM and the phone, and you don't have the full source code for either of them.

Thus, the need for passively sniffing/tracing the smart card interface between SIM and phone was born. There are commercial solutions which are not only prohibitively expensive, but then they are again proprietary/closed, i.e. you cannot extend them how you want.

There are also some free/open projects like the good old Season scanner, or the slightly more modern RebelSIM Scanner. However, those are really dumb and you have to manually determine the bit-rate using an oscilloscope and then program the UART accordingly. Furthermore, their top speed is often limited. None of this is really useful if you e.g. want to test a variety of combinations between N SIM and M phones, where you don't want N*M times of manual determination of bit-timing on an oscilloscope.

As an alternative solution, I have now created Osmocom SIMtrace. It uses an AT91SAM7S micro-controller as hardware interface between the SIM card interface and USB. It properly sniffs the RST, CLK and I/O lines of the SIM and does auto-bauding, follows negotiation of new bit-rate negotiation via PPS/PTS and re-assembles / segments the APDUs as they come by.

Finally, the APDUs are picked up by a small command-line program that feeds them into wireshark, where you can inspect them like any other communication protocol that you're used to.

The code is still fairly experimental, but for anyone with an interest in this topic it should definitely be possible to reproduce my results.

There is not much specific to SIM cards in this project, by the way. It should work with any ISO 7816-3 T=0 smart card. Adding T=1 is just a matter of software, if you need that protocol..

And now I'm finally off to doing the actual work that I wanted to do.

As Marcin announced yesterday on the OsmocomBB mailing list, his initial u-boot and Linux port to the MT6235 baseband processor has been pushed to the git.osmocom.org server. He has also provided some instructions and pre-compiled kernel and u-boot images.

He's now working on the NAND, SD/MMC, GPIO and LCD drivers. If you want to help out, feel free to contact Marcin about this.

Meanwhile, I've been doing a bit of theoretical analysis on the GSM baseband / RF interface of the MT6235, based on the limited documentation that is available to the general public. Seems like it's about time to start with practical experiments soon..

Recently, I wanted to investigate when and how A5/2 has been withdrawn from both GSM networks and GSM phones alike. Unfortunately there was no existing article discussing this history online, so I went through dozens of meeting reports and other documents that I could find online to recover what had happened.

If you don't know what this is all about: It is about the A5/2 air-interface encryption algorithm that was used in certain GSM networks until about 2005-2007.

A5/2 was specified as a security by obscurity algorithm behind closed doors in the late 1980ies. It was intentionally made weaker than it's (already weak) brother A5/1. The idea was to sell only equipment with A5/2 to the countries of the eastern block, while the less-weak A5/1 encryption was to be used by the western European countries.

A5/2 had been reverse engineered and disclosed in the late 1990ies, and has undergone a lot of attention from cryptographers such as Ian Goldberg and David A. Wagner. In a 1999 paper, they already expect that it can be broken in real-time.

It took several more papers until in August 2003, finally, the proponents of the GSM systems (ETSI/3GPP/GSMA) have realized that there is a problem. And the problem was worse than they thought: Since they key generation for A5/1 and A5/2 is the same, a semi-active downgrade attack can be used to retroactively break previously-recorded, encrypted A5/1 calls. The only solution to this problem is to remove A5/2 from all equipment, to make sure the downgrade is not possible anymore.

Starting from 2004 the security related working groups of 3GPP and GSMA thought about removing A5/2, and in the following years they convinced their respective bodies (3GPP, GSMA), and members thereof (operators, equipment makers) to fix this problem.

Ever since that time, it is known that using the same key generation for different algorithms enables down-grade attacks. However, the key generation for the then-new A5/3 algorithm was unmodified. So now that A5/1 has been broken in recent years, even if the operators deploy A5/3, the same model of down-grading attacks to A5/1 can be done again.

I have put down a time-line at the still mostly-empty security.osmocom.org website. Some of the goodies from it:

• It took from 1999-2007 until this gaping security hole was fixed. Call that incident response!
• Unnamed Northern American Operators (and the PTCRB) were the biggest blockers to remove A5/2 support from their networks. This is particularly strange since US operators should always have had A5/1 access.
• As a breaking of the more secure A5/1 was already anticipated even back then, in 2002 A5/3 was first specified. Five years later (2007) there was virtually no support for A5/3 among manufacturers of GSM network equipment
• It took until January 2009 until the GSMA discussed A5/3 testing with mobile phone makers
• It took until November 2009 until there was a plug-fest testing interoperability between A5/3 enabled GSM network equipment and A5/3 enabled phones.

And what do we learn from all this?

• GSM equipment manufacturers and mobile operators have shown no interest in fixing gaping holes in their security system
• Prior to that first A5/2 attack, they have never thought of procedures for upgrading the entire system with new ciphering systems (i.e. proactive plans for incident response)
• Even after the A5/2 disaster, they have not learned the slightest bit. The same problem that was happening with A5/1 - A5/2 downgrade attacks can today be done with A5/3 - A5/1 downgrade attacks. And this before the majority of the operators has even started to use the already-7-year-old A5/3 in their production networks.
• The security work group of 3GPP has had a lot of insight into the actual threats to GSM security even 10 years ago. You can see that e.g. in the Technical Recommendation 33.801. But nobody wanted to hear them!
• Similar problems exist with the authentication algorithms. It took 12 years from first practical attacks on COMP128v1 until the GSMA is looking at withdrawing it.

I'd like to point out the slides of the talk: All Your Baseband Are Belong To Us by Ralf-Philipp Weinmann.

Ralf is one of those few people on this planet who have understood the security implications of now being able to send arbitrary protocol frames (particularly GSM L3 04.08 frames) to mobile phones.

GSM protocol stacks have never been written with the assumption that somebody might send intentionally malformatted messages on the air interface. But at the same time, the GSM network does not authenticate itself to the phone, i.e. everyone who can present a network-side GSM air interface to a phone will be able to exchange arbitrary messages with the phones.

This problem has been outlined in all the GSM security workshops and presentations I have been giving during recent years. Still, apart from Ralf-Philipp Weinmann's work, I have not seen a lot of public research in that area.

Exploiting and owning the baseband processor is a dangerous threat, as the microphone and entire audio path are connected to that very processor. Whoever owns the baseband can turn the mobile phone into a passive surveillance device, commonly called 'bug'. Since application processor and baseband processor are very far apart these days, with various layers of software in between, the user interface will not show any indication of what the baseband processor does.

The last couple of days I've been at #days 2010 in Lucerne / Switzerland. It was the first incarnation of this new IT security conference.

The conference went great, and I think the close-to-200 attendees were a great turnout for the first incarnation of an event. The talks were excellent, as was the delicious food that was served by the Radisson Blu hotel.

The GSM security workshop that David, Karsten and myself held over Wednesday and Thursday was attended by only 7 people, but we had some very lively discussions, particularly with some folks who were working for a GSM operator :)

Most notable about the event is the electronic conference badge, which was developed and produced with a lot of enthusiasm and numerous hours. To be honest, I think I would not have spent that much time on creating this. I mean, developing this type of gimmick is interesting, but then actually manually manufacturing it, without using a SMT line of any sorts - I wouldn't have done that 'just' for a badge. Respects to the team behind that. Hopefully the source code will still get released.

We were also running an experimental GSM + GPRS/EDGE network based on OpenBSC, OsmoSGSN and OpenGGSN, enabling users to run port scans and the like against the carrier-facing side of the IP stack of their own devices. While running this network, I discovered a number of new bugs, mostly in the GPRS stacks of various handsets.

At least one model of Blackberry seems to ignore the MS identity cannot be derived from the network cause of a Routing Area Update Reject message, which we send in case the TLLI of the messages from the phone is unknown. I would expect it to come back with a GPRS Attach Request, but it never does. All it does is to keep re-trying Routing Area Update

The other funny observation is: Several phones, including some iPhone models, react in a strange way if you REJECT them from the GSM network but ACCEPT them on GPRS (Assuming Network Mode of Operation III). They then seem to be perfectly happy with this connection, but will only supply data services and no voice service.

Getting back to the conference, though: The Radisson Blu is an quite costly, upscale hotel. I was really surprised by the type and number of small mistakes they made, particularly with the catering. One day they forget to put the sour cream next to the potatoes - despite a written sign indicating that they are supposed to be with sour cream. Another day they serve some mousse as desert, but there are no spoons placed at the desert buffet. Furthermore, the number of tables they provided during lunch time was always insufficient for the number of people who had lunch. The quantity of food was more than sufficient, though - indicating that it was not a problem of them not knowing the number of people who were eating.

I am really excited about some recent work by Marcin on starting a u-boot and Linux kernel port to the Mediatek MT6235 baseband processor.

Among GSM baseband processors, the MT6235 is a very unusual device. Unlike classic GSM baseband chips, it is not based on an MMU-less ARM7TDMI/ARM7EJS but on an ARM926EJS core. This is a full-blown ARMv5 core on which a standard Linux kernel could run.

The reason for the MT6235 to contain such an 'advanced' ARM core is simple: Mediatek is producing chipsets and reference designs for very inexpensive but feature-rich phones. Instead of going to a full-blown (and expensive) smart-phone design with separate ARM cores for the baseband and application processor, they simply make the base-band processor a bit stronger than needed for the GSM stack, and run the entire rich UI on the same cpu, including TCP/IP stack, touch-screen, web browser, e-mail client, H.264 playback / camera recording, etc.

The original firmware on the Mediatek chipsets is a Nucleus-kernel based software stack which is completely proprietary.

Now the mid-term vision for us is to have a Linux port to the MT6235, and run the OsmocomBB Layer1 (and possibly Layer2) code inside the kernel, while the Layer3 and a user interface program is running as application programs in userspace.

This would allow us to do a very rich user interface (imagine network monitoring modes, protocol tracing, manual cell selection, etc.) while still having to care only about one processor in the system. Furthermore, there are millions of MT6235 based devices, so there will be no shortage of inexpensive hardware to run this code on.

The MT6235 also has a built-in SD/MMC controller (for storing e.g. protocol traces that you take from the GSM network) and it has a fast, dual-mode USB2 high-speed USB controller for connecting it with a PC

Sure, porting our Layer1 to a completely different baseband chipset will be a lot of work, and I don't really have any idea how long it will take us. But I think the vision of such a powerful device (and finally bringing OsmocomBB and the Linux kernel together) should prove a very attractive motivational factor.

This also means: Even if you have no clue about the GSM protocols, you can now start to contribute to OsmocomBB: A lot of Linux kernel drivers for e.g. SD/MMC, USB, frame-buffer, SPI, I2C, PWM and other integrated controllers of the MT6235 need to be written.

Like all Mediatek data sheets, the MT6235 data sheet describing all those peripherals can be found on various places on the Web, including (but not limited to) Chinese developer forums.

It also seems there is at least one MT6235 based phone where JTAG and serial console have been identified (Sciphone Dream G2), which should make debugging and bootstrapping convenient.

It is always surprising what kind of things the industry is coming up with ;)

Here at ELCE, ST-Ericsson has just presented how they replaced OpenCore with gstreamer as the supplier/provider of multimedia encoding/decoding to the Android software stack.

This is definitely an interesting technical solution - probably one that makes sense if you have existing gstreamer modules/drivers.

What really makes me wonder though, is their licensing. To make sure only ST-Ericsson customers can use it, they have implemented a glue layer library that ties into android, and this library is binary-only licensed and distributed under terms that permit to use it together with their hardware.

Isn't it strange? Now the Android software stack is Free Software, and gstreamer is Free Software. But ST-Ericsson needs to put some proprietary blob in the middle. Of course, legally they are allowed to do it: Android is Apache-style licensed and gstreamer is LGPL. But from a moral/ethical/technical point of view, it still is blasphemy to me.

UPDATE: The license is actually a 'standard' proprietary license. There seem to be technical reasons that tie this code to the specific SoC of ST-Ericsson. Nonetheless, I keep my original criticism: It has a bad aftertaste if you combine two FOSS programs by a proprietary layer in between

I've just attended the ELCE 2010 keynote by Ari Rauch, where he was talking about how much TI OMAP is committed to Linux. This doesn't really come as a big surprise to me. The OMAP SoCs are used mostly as Application Processors for smart phones. As TI is not a supplier of APs for Apple, Symbian and Windows Mobile are dead, this really only leaves Linux-based operating systems like Android, Meego, LiMo & co.

One of his main points was we have to be pragmatic, i.e. the customer requirements for performance etc. are key. If there is an open way to fulfill them: fine. If not: fine, too.

The only real question that was asked after the keynote was the usual question of whether there will be any Free/Open graphics drivers for the Imagination GPU thats inside their OMAP3/OMAP4 SoCs. I already predicted the response: We have to be pragmatic about it. TI is trying to convince Imagination to open up, but they are afraid of doing so and don't see what this would gain them.

He further added the statement if there is a competitive more open GPU, they will look into using it.

The other bad taste I got from this keynote is the frequent mention of the industry embracing innovation provided by the FOSS community. Embracing was the very term that Microsoft always used when they started to create their custom versions/dialects of HTML, Kerberos and other standards.

The think that seemed to be missing is any awareness for the sharing attitude: I.e. the industry using the innovations that the community creates, but giving back an equal amount, or at least opening up in response. This cannot be a one-way road where the industry simply taps into the creative potential of the community, to create closed products and profit from stuff they have simply scraped off the community backyard.

The OSSF at Academia Sinica in Taiwan has kindly organized a full-day GPL compliance workshop on December 2nd in Taipei, Taiwan.

Armijn Hemel and myself will be presenting on a variety of topics regarding GPL compliance, both from an administrative/organizational as well as a technical compliance engineering point of view.

I think this is an excellent opportunity to get in touch with product managers and engineers in Taiwan's computing and particularly embedded industry. We definitely still need more awareness in that industry, as the majority of the products in a variety of IT markets are predominantly designed in Taiwan.

So the better the know-how is there, the less GPL violations we will find further down the supply chain and finally in the retail-stores around the world.

Many thanks to the OSSF at Academia Sinica, and specifically Florence Ko and Lucien Lin for making this workshop possible [and giving me a reason to come to Taipei again ;) ]

The 7th Netfilter Workshop is just coming up next week in Seville, Spain. Once again it will be hosted at the ETS Ingeneria Informatica of the University of Seville.

I'd like to personally thank Pablo Neira for organizing and hosting the event again in Seville.

As most readers of this blog will know, my current relationship to netfilter/iptables is somewhat dormant. I haven't been writing any code for probably something like five years ago, when I was seriously distracted with stuff like OpenPCD, OpenPICC, OpenBeacon and later the Openmoko project.

Nonetheless, it is always great to learn what Patrick, Pablo, Martin, Jozsef, Yasuyuki and the others have been up to. With a slight chance I may actually still have some advice/ideas or other input I can contribute.

There have been various reports and blog posts about HTC again committing copyright infringement by not fulfilling the GPLv2 license conditions in their latest Android phone, the G2.

While at this point I haven't studied the situation enough in order to confirm or deny any actual violations, let me state this: The number of GPL Violation reports/allegations that we receive at gpl-violations.org on HTC by far outnumber the reports that we have ever received about any other case or company.

In addition, HTC seems to have had a long trail of problems with GPL compliance in their devices. Ever since they have started to ship Android devices containing the Linux kernel, licensed under GPLv2+, we have received those reports.

The reason I have never taken any legal action is merely a result of the fact that HTC seems to first introduce their new devices in the US, then at some point release the corresponding source code before shipping those devices into Europe and Germany. So by the time the devices are sold over here, the legal issues appear to have been resolved before.

Nonetheless, I think it is outrageous for a company of this size and significance in the market to consistently commit copyright violation (or at least walk borderline with it) and thus mistreat the very copyright holders that have created the operating system kernel they use in their devices. The linux kernel developers and the Free Software community as a whole deserve fair treatment.

Also, the competitors of HTC deserve fair treatment: Samsung, e.g. is very forthcoming with their Android phone source code releases. If I was them and would see HTC to fail to comply with the GPL, I would consider filing a unfair competition lawsuit...

I just want to point out: If you haven't yet submitted a proposal for FOSS.in/2010, the FOSS.in/2010 Call for Participation is closing in less than 48 hours!

This means you still have a chance to submit a talk, workout or BoF on your personal FOSS, hacking or otherwise technology related work and actively participate in the event.

FOSS.in is an excellent chance to spread the word about what technical work you have been doing, and to motivate others to participate and join your projects. It's a great opportunity to reach out to the Indian FOSS community, meet old friends and make new ones. Don't miss it :)

If you're following my blog because you have an interest in GSM security related topics, there is currently a very interesting job offer by Frank from GSMK. It is about a job doing research into over-the-air attacks against baseband firmware in real-world GSM/UMTS telephones. Whoever gets the job will likely use/extend OpenBTS, OpenBSC or other GSM foss projects.

So if you're familiar with the GSM/3G protocol specs, have an interest in software security / exploiting and may even have existing exposure to OpenBSC, OpenBTS or OsmocomBB: Please send Frank a message and apply for what I personally consider one of the most exciting opportunities in the IT security industry today.

Yesterday night I took the train down to Nuremberg, where Linux Kongress 2010 is taking place. It's always nice to meet old friends and colleagues there, including Arnaldo Carvalho de Melo, Patrick McHardy, Lars Marowsky-Bree, Jon Corbet, Jos Vos, Heinz Mauelshagen, Dhaval Giani, Lennart Poettering and many more...

Being on the programme committee might make me biased, but I really think that there is a very impressive talk schedule. What makes me a bit sad is the relatively small audience. I don't know the numbers, but it definitely feels like the lecture halls could hold many more attendees.

At linux kongress 2010, Patrick McHardy has just started to give his presentation on the Linux DECT stack he has been working on in the last 1.5 years.

He looked at the deDECTed.org code and found it very limiting, mainly targeted to passively listen into DECT conversations, showing the weaknesses of DSC, DSAA and its implementations. His new DECT stack is meant as a full and generic implementation for receive and transmit.

I'm especially happy to announce that this project will now be hosted under the Osmocom umbrella project at dect.osmocom.org. Right now it only has a README file and the git repository. However, a trac site will be up and running soon.

Today I have received news that Dell has released the source code of the GPL licensed software on the Dell Streak at http://opensource.dell.com/releases/streak. This includes, among other things, the source code to the Linux kernel they are using on the Qualcomm Snapdragon processor.

This is good news! However, I have not yet checked if that source code release can be considered complete and corresponding as demanded by the GPL. At least it includes a small README file explaining how to build the sources.

I'm not very much into the Android world, but I have heard that Dell is already shipping different Android versions for the Streak. If this is true, then there should be multiple source code releases, one for each binary release they have. If you know more about available firmware versions for the streak, feel free to contact me privately.

Overall, it is great to see this release. On the other hand, it is pretty sad that we've had to do go down the gpl-violations.org enforcement route. Ever since the Streak released in the US months ago, customers are claiming to have contacted Dell forums, emailed Dell Support, asked in the Dell live web-chat and asked via twitter - without the source code being released.

Also, if you are under the impression that the Dell GPL source code as it has been released is incomplete, please let me know the exact technical details of what you think is missing, or why that source code is not matching what is running on your device. Thanks in advance.

For those who don't know: The Motorola Ming was the A1200, a commercially very successful Linux-based phone in China and other parts of Asia, using the EZX software platform, i.e. the kind of hardware that we once built the OpenEZX software.

Motorola has recently announced that they will follow-up with some android based ming phones. It is my suspicion that apart from some mechanical design aspects, those phones will not resemble the ming in any way, neither on the baseband hardware side, nor on the application processor side, and particularly not on the software side.

So it's probably nothing than a marketing coup, trying to connect to successes of the past. Not interesting from the OpenEZX point of view, I guess.

In recent days and weeks, I'm doing a bit more work on the gpl-violations.org project than during the last months and years. I wouldn't say that I'm happy about that, but well, somebody has to do it :/

Right now I'm facing what I'd consider the most outrageous case that I've been involved so far: A manufacturer of Linux-based embedded devices (no, I will not name the company) really has the guts to go in front of court and sue another company for modifying the firmware on those devices. More specifically, the only modifications to program code are on the GPL licensed parts of the software. None of the proprietary userspace programs are touched! None of the proprietary programs are ever distributed either.

If that manufacturer would succeed with such a lawsuit, it would create some very nasty precedent and jeopardize the freedom of users of Linux-based embedded devices. It would be a direct blow against projects that provide "homebrew" software for embedded devices, such as OpenWRT and many others.

I've seen many weird claims and legal strategies when it comes to companies trying to deprive developers of their freedom to modify and run modified versions of Free Software. But this is definitely so weird that I still feel like I'm in a bad dream. This can't be real. It feels to surreal.

It's a pity that I cannot speak up more about the specific company in question right now. I'm desperately looking forward to the point in time where I can speak up and speak out about what has been happening behind the scenes.

I'm subscribed to a considerable number of RSS feeds, and so far I actually used to read them all on my Nokia N810, which is more or less permanently located at the bedside table

Now I wanted to import all the subscriptions into an Android RSS feed reader on the Galaxy S. Unfortunately the feed reader that I found most useable doesn't have OPML import. However, looking at its sqlite3 database for feed subscriptions, it was pretty easy to come up with a small perl script to generate "INSERT" statements for all the feeds from the N810 OPML file. In case anyone is interested, the script is available from here.

If you have any suggestions on a good Android RSS reader that can manage large number of subscriptions and put them into a tree/hierarchy of groups, feel free to let me know.

According to several sources such as indianevm.com, Hari Prasad was being arrested. He is part of a team of IT security researchers that gathered evidence to demonstrate how incredibly weak the security of India's voting machines is. For more details, read the indianevm.com article linked above, and the various quotes/links in it.

This is very upsetting. They should jail those who have authorized the deployment of such an insecure system in the first place. Those are the people responsible - not some researchers who go out of their way to uncover the technical problems to warn the general public about the inherent risks of this technology.

I sincerely hope that the authorities will understand the grave mistake they're doing here. Don't shoot the messenger. It's not his fault that engineer, engineering management and/or regulatory government authorities have permitted such a system in the first place.