My latest candidate for gpl-violations.org (and hopefully the last before finally leaving for holidays): The Thecus N2100 and N4100 NAS devices.
The Thecus boxes seem nice, at first sight. Apparently somebody recognized the need for a bit more performance, so there's an Intel IOP 80219 with 64bit PCI-X support, DDR400 memory (actually in a socket), an empty miniPCI slot (great!), USB2.0 ports, and SATA (yay). This should definitely be more promising than the usual 33MHz 32bit PCI / IDE / MIPS / SDRAM based smaller NAS boxes. The only thing really lacking with those Intel I/O processors is a hardware crypto unit. Who wants to have unencrypted storage these days?
Looking at the software, the problems start. First, there is no NFS support. iTunes, SMB/CIFS, HTTP, FTP - but no NFS :( Secondly, the web configuration frontend requires flash. Duh! How can you use something as ugly and proprietary as flash for something as simple as a web configuration frontend for an embedded box. God knows.
Anyway, let's get back to the GPL issue. As usual, I cannot make such a claim without verifying it. First of all, the devices (and their firmware updates) ship without a copy of the GPL, any indication that GPL licensed software was used, no written offer and no source code.
But well, where the heck do I know from (and can prove) that they actually run Linux? I won't disclose the reason for my initial hints, since I don't want future vendors of future products to know how they can avoid me ;) But anyway, let's assume I was surprised to see a nmap fingerprint that indicates Linux on the box and now want to go further.
Looking at the firmware update images, they appear to be scrambled / encrypted somehow. At least there is no gzip/bzip2/LZMA/ext3/cramfs/romfs/... signature to be found in them. And even if the firmware updates contain Linux, this doesn't actually prove anything about the software pre-installed on the device.
The running device also doesn't offer any ports apart from the SMB-related ones and http(s). So we're stuck.
This is where I usually take the device apart, carefully analyze it's hardware and go looking for a serial port with my Oscilloscope probe. Unfortunately the PCB of the N2100 didn't seem to have one. It took me some time to figure out that the serial port connector (there's actually a standard 9pin header) is on the SATA backplane rather than on the CPU board ;)
Hooking up a serial console, you can see RedBoot wait for one second and then execute a boot script that loads initrd and kernel, finally executes it. Yay!. Too bad that the actual kernel seems to lack support for a serial console. So all you get is the 'Uncompressing Linux......................................................................................... done, booting the kernel.' line. Together with the firmware scrambling/crypto, this is definitely an attempt to hide the use of GPL licensed software and/or otherwise lock the user out of the device.
Unfortunately hex-dumping the whole memory contents from RedBoot via the serial port, and parsing it on the host side seemed like a rather clumsy - and otherwise unproductive approach to finding proof of GPL licensed software in the device.
Luckily, you can interrupt RedBoot and configure the network device, set up TFTP, cross-compile a kernel for the IOP 80219, and boot that. After some twisting of the .config, I got it to boot without any crashes, and even the RedBoot partition table is correctly recognized and parsed.
So now I'm running Linux on the device, great. But still I can't prove that the device actually ships GPL licensed software in an incompliant way. So all that is missing is a NFS-root capable installation of Debian-arm that we can boot into, and which we can use to read out the mtd partitions.
Oh, and yes. While I appreciate their love for the netfilter project and it's software: There's absolutely no place in a NAS box for having ip_conntrack linked statically into the kernel - unless you voluntarily want to loose performance. At least to my knowledge, performance of NAS devices counts. So, Thecus, in your own interest: disable ip_conntrack in the kernels you ship.