LaForge's home page (Linux and Free Software)

On Linux MAINTAINERS file removal of Russian developers

Harald Welte — Wed, 23 Oct 2024 16:00:00 GMT

I sincerely regret to see Linux kernel patches like this one removing Russian developers from the MAINTAINERS file. To me, it is a sign or maybe even a symbol of how far the Linux kernel developer community I remember from ~ 20 years ago has changed, and how much it has alienated itself from what I remember back in the day.

In my opinion this commit is wrong at so many different levels:

it is intransparent. Initially it gave no explanation whatsoever (other than some compliance hand-waving). There was some follow-up paraphrasing one paragraph of presumed legal advice that was given presumably by Linux Foundation to Linus. That's not a thorough legal analysis at all. It doesn't even say to whom it was given, and who (the individual developers? Linux Foundation? Distributors?) is presumed to be subject to the unspecified regulations in which specific jurisdiction
it discriminates developers based on their presumed [Russian] nationality based on their name, e-mail address domain name or employer.

A later post in the thread has clarified that it's about an U.S. embargo list against certain Russian individuals / companies. It is news to me that the MAINTAINERS file was usually containing Companies or that the Linux kernel development is Companies engaging with each other. I was under the naive assumption that it's individual developers who work together, and their employers do not really matter. Contributions are judged by their merit, and not by the author or their employer / affiliation. In the super unlikely case that indeed those individual developers removed from the MAINTAINERS file would be personally listed in the embargo list: Then yes, of course, I agree, they'd have to be removed. But then the commit log should of course point to [the version] of that list and explicitly mention that they were personally listed there.

And no, I am of course not a friend of the Russian government at all. They are committing war crimes, no doubt about it. But since when has the collaboration of individual developers in an open source project been something related to actions completely unrelated to those individuals? Should I as a German developer be excluded due to the track record of Germany having started two world wars killing millions? Should Americans be excluded due to a very extensive track record of violating international law? Should we exclude Palestinians? Israelis? Syrians? Iranians? [In case it's not obvious: Those are rhetorical questions, my position is of course no to all of them].

I just think there's nothing more wrong than discriminating against people just because of their passport, their employer or their place of residence. Maybe it's my German upbringing/socialization, but we've had multiple times in our history where the concept of **Sippenhaft** (kin liability) existed. In those dark ages of history you could be prosecuted for crimes committed by other family members.

Now of course removal from the MAINTAINERS file or any other exclusion from the Linux kernel development process is of course not in any way comparable to prosecution like imprisonment or execution. However, the principle seems the same: An individual is punished for mere association with some others who happen to be committing crimes.

Now if there really was a compelling legal argument for this (I doubt it, but let's assume for a second there is): In that case I'd expect a broad discussion against it; a reluctance to comply with it; a search for a way to circumvent said legal requirement; a petition or political movement against that requirement.

Even if there was absolutely no way around performing such a "removal of names": At the very least I'd expect some civil disobedience by at least then introducing a statement into the file that one would have hoped to still be listing those individuals as co-maintainers but one was forced by [regulation, court order, ...] to remove them.

But the least I would expect is for senior Kernel developers to simply do apply the patch with a one-sentence commit log message and thereby disrespect the work of said [presumed] Russian developers. All that does is to alienate individuals of the developer community. Not just those who are subject to said treatment today, but any others who see this sad example how Linux developers treat each other and feel discouraged from becoming or remaining active in a community with such behaviour.

It literally hurts me personally to see this happening. It's like a kick in the gut. I used to be proud about having had an involvement with the Linux kernel community in a previous life. This doesn't feel like the community I remember being part of.

udtrace - Unix domain socket tracing

Harald Welte — Thu, 29 Mar 2018 16:00:00 GMT

When developing applications that exchange data over sockets, every so often you'd like to analyze exactly what kind of data is exchanged over the socket.

For TCP/UDP/SCTP/DCCP or other IP-based sockets, this is rather easy by means of libpcap and tools like tcpdump, tshark or wireshark. However, for unix domain socket, unfortunately no such general capture/tracing infrastructure exists in the Linux kernel.

Interestingly, even after searching for quite a bit I couldn't find any existing tools for this. This is surprising, as unix domain sockets are used by a variety of programs, from sql servers to bind8 ndc all the way to the systemctl tool to manage systemd.

In absence of any kernel support, the two technologies I can think of to implement this is either systemtap or a LD_PRELOAD wrapper.

However, I couldn't find an example for using either of those two to get traces of unix domain soocket communications.

Ok, so I get to write my own. My first idea hence was to implement something based on top of systemtap, the Linux kernel tracing framework. Unfortunately, systemtap was broken in Debian unstable (which I use for decades) at the time, so I went back to the good old LD_PRELOAD shim library / wrapper approach.

The result is called udtrace and can be found at

git clone https://gitea.osmocom.org/laforge/udtrace

or alternatively via its github mirror.

Below is a copy+paste of its README file. Let's hope this tool is useful to other developers, too:

udtrace - Unix Domain socket tracing

This is a LD_PRELOAD wrapper library which can be used to trace the data sent and/or received via unix domain sockets.

Unlike IP based communication that can be captured/traced with pcap programs like tcpdump or wireshark, there is no similar mechanism available for unix domain sockets.

This LD_PRELOAD library intercepts the C library function calls of dynamically linked programs. It will detect all file descriptors representing unix domain sockets and will then print traces of all data sent/received via the socket.

Usage

Simply build libudtrace.so using the make command, and then start your to-be-traced program with

LD_PRELOAD=libudtrace.os

e.g.

LD_PRELOAD=libudtrace.so systemctl status

which will produce output like this:

>>> UDTRACE: Unix Domain Socket Trace initialized (TITAN support DISABLED)
>>> UDTRACE: Adding FD 4
>>> UDTRACE: connect(4, "/run/dbus/system_bus_socket")
4 sendmsg W 00415554482045585445524e414c20
4 sendmsg W 3331333033303330
4 sendmsg W 0d0a4e45474f54494154455f554e49585f46440d0a424547494e0d0a
[...]

Output Format

Currently, udtrace will produc the following output:

At time a FD for a unix domain socket is created:

>>> UDTRACE: Adding FD 8

At time a FD for a unix domain socket is closed:

>>> UDTRACE: Removing FD 8

At time a FD for a unix domain socket is bound or connected:

>>> UDTRACE: connect(9, "/tmp/mncc")

When data is read from the socket:

9 read R 00040000050000004403000008000000680000001c0300002c03000000000000

When data is written to the socket:

9 write W 00040000050000004403000008000000680000001c0300002c03000000000000

Where

9 is the file dsecriptor on which the event happened
read/write is the name of the syscall, could e.g. also be sendmsg / readv / etc.
R|W is Read / Write (from the process point of view)
followed by a hex-dump of the raw data. Only data successfully written (or read) will be printed, not the entire buffer passed to the syscall. The rationale is to only print data that was actually sent to or received from the socket.

TITAN decoder support

Getting hex-dumps is nice and fine, but normally one wants to have a more detailed decode of the data that is being passed on the socket.

For TCP based protocols, there is wireshark. But most protocols on unix domain sockets don't follow inter-operable / public standards, so even if one was to pass the traces into wireshark somehow, there would be no decoder.

In the Osmocom project, we already had some type definitions and decoders for our protocols written in the TTCN-3 programming language, using Eclipse TITAN. In order to build those decoders fro MNCC and PCUIF, please use

make ENABLE_TITAN=1

when building the code.

Please note that this introduces a run-time dependency to libttcn3-dynamic.so, which is (at least on Debian GNU/Linux) not installed in a default library search path, so you will have to use something like:

LD_LIBRARY_PATH=/usr/lib/titan LD_PRELOAD=libudtrace.so systemctl status

Report from the Geniatech vs. McHardy GPL violation court hearing

Harald Welte — Tue, 06 Mar 2018 16:00:00 GMT

Today, I took some time off to attend the court hearing in the appeal hearing related to a GPL infringement dispute between former netfilter colleague Partrick McHardy and Geniatech Europe

I am not in any way legally involved in the lawsuit on either the plaintiff or the defendant side. However, as a fellow (former) Linux kernel developer myself, and a long-term Free Software community member who strongly believes in the copyleft model, I of course am very interested in this case.

History of the Case

This case is about GPL infringements in consumer electronics devices based on a GNU/Linux operating system, including the Linux kernel and at least some devices netfilter/iptables. The specific devices in question are a series of satellite TV receivers built by a Shenzhen (China) based company Geniatech, which is represented in Europe by Germany-based Geniatech Europe GmbH.

The Geniatech Europe CEO has openly admitted (out of court) that they had some GPL incompliance in the past, and that there was failure on their part that needed to be fixed. However, he was not willing to accept an overly wide claim in the preliminary injunction against his company.

The history of the case is that at some point in July 2017, Patrick McHardy has made a test purchase of a Geniatech Europe product, and found it infringing the GNU General Public License v2. Apparently no source code (and/or written offer) had been provide alongside the binary - a straight-forward violation of the license terms and hence a violation of copyright. The plaintiff then asked the regional court of Cologne to issue a preliminary injunction against the defendant, which was granted on September 8th,2017.

In terms of legal procedure, in Germany, when a plaintiff applies for a preliminary injunction, it is immediately granted by the court after brief review of the filing, without previously hearing the defendant in an oral hearing. If the defendant (like in this case) wishes to appeal the preliminary injunction, it files an appeal which then results in an oral hearing. This is what happened, after which the district court of cologne (Landgericht Koeln) on October 20, 2017 issued ruling 14 O 188/17 partially upholding the injunction.

All in all, nothing particularly unusual about this. There is no dispute about a copyright infringement having existed, and this generally grants any of the copyright holders the right to have the infringing party to cease and desist from any further infringement.

However, this injunction has a very wide scope, stating that the defendant was to cease and desist not only from ever publishing, selling, offering for download any version of Linux (unless being compliant to the license). It furthermore asked the defendant to cease and desist

from putting hyperlinks on their website to any version of Linux
from asking users to download any version of Linux

unless the conditions of the GPL are met, particularly the clauses related to providing the complete and corresponding source code.

The appeals case at OLG Cologne

The defendant now escalated this to the next higher court, the higher regional court of Cologne (OLG Koeln), asking to withdraw the earlier ruling of the lower court, i.e. removing the injunction with its current scope.

The first very positive surprise at the hearing was the depth in which the OLG court has studied the subject matter of the dispute prior to the hearing. In the many GPL related court cases that I witnessed so far, it was by far the most precise analysis of how Linux kernel development works, and this despite the more than 1000 pages of filings that parties had made to the court to this point.

Just to give you some examples:

the court understood that Linux was created by Linus Torvalds in 1991 and released under GPL to facilitate the open and collaborative development
the court recognized that there is no co-authorship / joint authorship (German: Miturheber) in the Linux kernel as a whole, as it was not a group of people planning+developing a given program together, but it is a program that has been released by Linus Torvalds and has since been edited by more than 15.000 developers without any "grand joint plan" but rather in successive iterations. This situation constitutes "editing authorship" (German: Bearbeiterurheber)
the court further recognized that being listed as "head of the netfilter core team" or a "subsystem maintainer" doesn't necessarily mean that one is contributing copyrightable works. Reviewing thousands of patches doesn't mean you own copyright on them, drawing an analogy to an editorial office at a publisher.
the court understood there are plenty of Linux versions that may not even contain any of Patric McHardy's code (such as older versions)

After about 35 minutes of the presiding judge explaining the court's understanding of the case (and how kernel development works), it went on to summarize the summary of their internal elaboration at the court prior to the meeting.

In this summary, the presiding judge stated very clearly that they believe there is some merit to the arguments of the defendant, and that they would be inclined in a ruling favorable to the defendant based on their current understanding of the case.

He cited the following main reasons:

The Linux kernel development model does not support the claim of Patrick McHardy having co-authored Linux. In so far, he is only an editing author (Bearbeiterurheber), and not a co-author. Nevertheless, even an editing author has the right to ask for cease and desist, but only on those portions that he authored/edited, and not on the entire Linux kernel.
The plaintiff did not sufficiently show what exactly his contributions were and how they were forming themselves copyrightable works
The plaintiff did not substantiate what copyrightable contributions he has made outside of netfilter/iptables. His mere listing as general networking subsystem maintainer does not clarify what his copyrightable contributions were
The plaintiff being a member of the netfilter core team or even the head of the core team still doesn't support the claim of being a co-author, as netfilter substantially existed since 1999, three years before Patrick's first contribution to netfilter, and five years before joining the core team in 2004.

So all in all, it was clear that the court also thought the ruling on all of Linux was too far-fetching.

The court suggested that it might be better to have regular main proceedings, in which expert witnesses can be called and real evidence has to be provided, as opposed to the constraints of the preliminary procedure that was applied currently.

Some other details that were mentioned somewhere during the hearing:

Patrick McHardy apparently unilaterally terminated the license to his works in an e-mail dated 26th of July 2017 towards the defendant. According to the defendant (and general legal opinion, including my own position), this is in turn a violation of the GPLv2, as it only allowed plaintiff to create and publish modified versions of Linux under the obligation that he licenses his works under GPLv2 to any third party, including the defendant. The defendant believes this is abuse of his rights (German: Rechtsmissbraeuchlich).
sworn affidavits of senior kernel developer Greg Kroah-Hartman and current netfilter maintainer Pablo Neira were presented in support of some of the defendants claims. The contents of those are unfortunately not public, neither is the contents of the sworn affidavists presented by the plaintiff.
The defendant has made substantiated claims in his filings that Patrick McHardy would perform his enforcement activities not with the primary motivation of achieving license compliance, but as a method to generate monetary gain. Such claims include that McHardy has acted in more than 38 cases, in at least one of which he has requested a contractual penalty of 1.8 million EUR. The total amount of monies received as contractual penalties was quoted as over 2 million EUR to this point. Please note that those are claims made by the defendant, which were just reproduced by the court. The court has not assessed their validity. However, the presiding judge explicitly stated that he received a phone calls about this case from a lawyer known to him personally, who supported that large contractual penalties are being paid in other related cases.
One argument by the plaintiff seems to center around being listed as a general kernel networking maintainer until 2017 (despite his latest patches being from 2015, and those were netfilter only)

Withdrawal by Patrick McHardy

At some point, the court hearing was temporarily suspended to provide the legal representation of the plaintiff with the opportunity to have a Phone call with the plaintiff to decide if they would want to continue with their request to uphold the preliminary injunction. After a few minutes, the hearing was resumed, with the plaintiff withdrawing their request to uphold the injunction.

As a result, the injunction is now withdrawn, and the plaintiff has to bear all legal costs (court fees, lawyers costs on both sides).

Personal Opinion

For me, this is all of course a difficult topic. With my history of being the first to enforce the GNU GPLv2 in (equally German) court, it is unsurprising that I am in favor of license enforcement being performed by copyright holders.

I believe individual developers who have contributed to the Linux kernel should have the right to enforce the license, if needed. It is important to have distributed copyright, and to avoid a situation where only one (possibly industry friendly) entity would be able to take [legal] action.

I'm not arguing for a "too soft" approach. It's almost 15 years since the first court cases on license violations on (embedded) Linux, and the fact that the problem still exists today clearly shows the industry is very far from having solved a seemingly rather simple problem.

On the other hand, such activities must always be oriented to compliance, and compliance only. Collecting huge amounts of contractual penalties is questionable. And if it was necessary to collect such huge amounts to motivate large corporations to be compliant, then this must be done in the open, with the community knowing about it, and the proceeds of such contractual penalties must be donated to free software related entities to prove that personal financial gain is not a motivation.

The rumors of Patrick performing GPL enforcement for personal financial gain have been around for years. It was initially very hard for me to believe. But as more and more about this became known, and Patrick would refuse to any contact requests by his former netfilter team-mates as well as the wider kernel community make it hard to avoid drawing related conclusions.

We do need enforcement, both out of court and in court. But we need it to happen out of the closet, with the community in the picture, and without financial gain to individuals. The "principles of community oriented enforcement" of the Software Freedom Conservancy as well as the more recent (but much less substantial) kernel enforcement statement represent the most sane and fair approach for how we as a community should deal with license violations.

So am I happy with the outcome? Not entirely. It's good that an over-reaching injunction was removed. But then, a lot of money and effort was wasted on this, without any verdict/ruling. It would have been IMHO better to have a court ruling published, in which the injunction is substantially reduced in scope (e.g. only about netfilter, or specific versions of the kernel, or specific products, not about placing hyperlinks, etc.). It would also have been useful to have some of the other arguments end up in a written ruling of a court, rather than more or less "evaporating" in the spoken word of the hearing today, without advancing legal precedent.

Lessons learned for the developer community

In the absence of detailed knowledge on computer programming, legal folks tend to look at "metadata" more, as this is what they can understand.
It matters who has which title and when. Should somebody not be an active maintainer, make sure he's not listed as such.
If somebody ceases to be a maintainer or developer of a project, remove him or her from the respective lists immediately, not just several years later.
Copyright statements do matter. Make sure you don't merge any patches adding copyright statements without being sure they are actually valid.

Lessons learned for the IT industry

There may be people doing GPL enforcement for not-so-noble motives
Defending yourself against claims in court can very well be worth it, as opposed to simply settling out of court (presumably for some money). The Telefonica case in 2016 <>_ has shown this, as has this current Geniatech case. The legal system can work, if you give it a chance.
Nevertheless, if you have violated the license, and one of the copyright holders makes a properly substantiated claim, you still will get injunctions granted against you (and rightfully so). This was just not done in this case (not properly substantiated, scope of injunction too wide/coarse).

Dear Patrick

For years, your former netfilter colleagues and friends wanted to have a conversation with you. You have not returned our invitation so far. Please do reach out to us. We won't bite, but we want to share our views with you, and show you what implications your actions have not only on Linux, but also particularly on the personal and professional lives of the very developers that you worked hand-in-hand with for a decade. It's your decision what you do with that information afterwards, but please do give us a chance to talk. We would greatly appreciate if you'd take up that invitation for such a conversation. Thanks.

Obtaining the local IP address of an unbound UDP socket

Harald Welte — Thu, 19 Oct 2017 16:00:00 GMT

Sometimes one is finding an interesting problem and is surprised that there is not a multitude of blog post, stackoverflow answers or the like about it.

A (I think) not so uncommon problem when working with datagram sockets is that you may want to know the local IP address that the OS/kernel chooses when sending a packet to a given destination.

In an unbound UDP socket, you basically send and receive packets with any number of peers from a single socket. When sending a packet to destination Y, you simply pass the destination address/port into the sendto() socket function, and the OS/kernel will figure out which of its local IP addresses will be used for reaching this particular destination.

If you're a dumb host with a single default router, then the answer to that question is simple. But in any reasonably non-trivial use case, your host will have a variety of physical and/or virtual network devices with any number of addresses on them.

Why would you want to know that address? Because maybe you need to encode that address as part of a packet payload. In the current use case that we have, it is the OsmoMGW, implementing the IETF MGCP Media Gateway Control Protocol.

So what can you do? You can actually create a new "trial" socket, not bind it to any specific local address/port, but connect() it to the destination of your IP packets. Then you do a getsockname(), which will give you the local address/port the kernel has selected for this socket. And that's exactly the answer to your question. You can now close the "trial" socket and have learned which local IP address the kernel would use if you were to send a packet to that destination.

At least on Linux, this works. While getsockname() is standard BSD sockets API, I'm not sure how portable it is to use it on a socket that has not been explicitly bound by a prior call to bind().

Invited keynote + TTCN-3 talk at netdevconf 2.2 in Seoul

Harald Welte — Mon, 09 Oct 2017 16:00:00 GMT

It was a big surprise that I've recently been invited to give a keynote on netfilter history at netdevconf 2.2.

First of all, I wouldn't have expected netfilter to be that relevant next to all the other [core] networking topics at netdevconf. Secondly, I've not been doing any work on netfilter for about a decade now, so my memory is a bit rusty by now ;)

Speaking of Rusty: Timing wise there is apparently a nice coincidence that I'll be able to meet up with him in Berlin later this month, i.e. hopefully we can spend some time reminiscing about old times and see what kind of useful input he has for the keynote.

I'm also asking my former colleagues and successors in the netfilter project to share with me any note-worthy events or anecdotes, particularly also covering the time after my retirement from the core team. So if you have something that you believe shouldn't miss in a keynote on netfilter project history: Please reach out to me by e-mail ASAP and let me know about it.

To try to fend off the elder[ly] statesmen image that goes along with being invited to give keynotes about the history of projects you were working on a long time ago, I also submitted an actual technical talk: TTCN-3 and Eclipse Titan for testing protocol stacks, in which I'll cover my recent journey into TTCN-3 and TITAN land, and how I think those tools can help us in the Linux [kernel] networking community to productively produce tests for the various protocols.

As usual for netdevconf, there are plenty of other exciting talks in the schedule

I'm very much looking forward to both visiting Seoul again, as well as meeting lots of the excellent people involved in the Linux networking subsystems. See ya!

Power-cycling a USB port should be simple, right?

Harald Welte — Tue, 23 May 2017 16:00:00 GMT

Every so often I happen to be involved in designing electronics equipment that's supposed to run reliably remotely in inaccessible locations,without any ability for "remote hands" to perform things like power-cycling or the like. I'm talking about really remote locations, possible with no but limited back-haul, and a very high cost of ever sending somebody there for remote maintenance.

Given that a lot of computer peripherals (chips, modules, ...) use USB these days, this is often some kind of an embedded ARM (rarely x86) SoM or SBC, which is hooked up to a custom board that contains a USB hub chip as well as a line of peripherals.

One of the most important lectures I've learned from experience is: Never trust reset signals / lines, always include power-switching capability. There are many chips and electronics modules available on the market that have either no RESET, or even might claim to have a hardware RESET line which you later (painfully) discover just to be a GPIO polled by software which can get stuck, and hence no way to really hard-reset the given component.

In the case of a USB-attached device (even though the USB might only exist on a circuit board between two ICs), this is typically rather easy: The USB hub is generally capable of switching the power of its downstream ports. Many cheap USB hubs don't implement this at all, or implement only ganged switching, but if you carefully select your USB hub (or in the case of a custom PCB), you can make sure that the given USB hub supports individual port power switching.

Now the next step is how to actually use this from your (embedded) Linux system. It turns out to be harder than expected. After all, we're talking about a standard feature that's present in the USB specifications since USB 1.x in the late 1990ies. So the expectation is that it should be straight-forward to do with any decent operating system.

I don't know how it's on other operating systems, but on Linux I couldn't really find a proper way how to do this in a clean way. For more details, please read my post to the linux-usb mailing list.

Why am I running into this now? Is it such a strange idea? I mean, power-cycling a device should be the most simple and straight-forward thing to do in order to recover from any kind of "stuck state" or other related issue. Logical enabling/disabling of the port, resetting the USB device via USB protocol, etc. are all just "soft" forms of a reset which at best help with USB related issues, but not with any other part of a USB device.

And in the case of e.g. an USB-attached cellular modem, we're actually talking about a multi-processor system with multiple built-in micro-controllers, at least one DSP, an ARM core that might run another Linux itself (to implement the USB gadget), ... - certainly enough complex software that you would want to be able to power-cycle it...

I'm curious what the response of the Linux USB gurus is.

Overhyped Docker

Harald Welte — Tue, 02 May 2017 16:00:00 GMT

Overhyped Docker missing the most basic features

I've always been extremely skeptical of suddenly emerging over-hyped technologies, particularly if they advertise to solve problems by adding yet another layer to systems that are already sufficiently complex themselves.

There are of course many issues with containers, ranging from replicated system libraries and the basic underlying statement that you're giving up on the system packet manager to properly deal with dependencies.

I'm also highly skeptical of FOSS projects that are primarily driven by one (VC funded?) company. Especially if their offering includes a so-called cloud service which they can stop to operate at any given point in time, or (more realistically) first get everybody to use and then start charging for.

But well, despite all the bad things I read about it over the years, on one day in May 2017 I finally thought let's give it a try. My problem to solve as a test balloon is fairly simple.

My basic use case

The plan is to start OsmoSTP, the m3ua-testtool and the sua-testtool, which both connect to OsmoSTP. By running this setup inside containers and inside an internal network, we could then execute the entire testsuite e.g. during jenkins test without having IP address or port number conflicts. It could even run multiple times in parallel on one buildhost, verifying different patches as part of the continuous integration setup.

This application is not so complex. All it needs is three containers, an internal network and some connections in between. Should be a piece of cake, right?

But enter the world of buzzword-fueled web-4000.0 software-defined virtualised and orchestrated container NFW + SDN vodoo: It turns out to be impossible, at least not with the preferred tools they advertise.

Dockerfiles

The part that worked relatively easily was writing a few Dockerfiles to build the actual containers. All based on debian:jessie from the library.

As m3ua-testsuite is written in guile, and needs to build some guile plugin/extension, I had to actually include guile-2.0-dev and other packages in the container, making it a bit bloated.

I couldn't immediately find a nice example Dockerfile recipe that would allow me to build stuff from source outside of the container, and then install the resulting binaries into the container. This seems to be a somewhat weak spot, where more support/infrastructure would be helpful. I guess the idea is that you simply install applications via package feeds and apt-get. But I digress.

So after some tinkering, I ended up with three docker containers:

one running OsmoSTP
one running m3ua-testtool
one running sua-testtool

I also managed to create an internal bridged network between the containers, so the containers could talk to one another.

However, I have to manually start each of the containers with ugly long command line arguments, such as docker run --network sigtran --ip 172.18.0.200 -it osmo-stp-master. This is of course sub-optimal, and what Docker Services + Stacks should resolve.

Services + Stacks

The idea seems good: A service defines how a given container is run, and a stack defines multiple containers and their relation to each other. So it should be simple to define a stack with three services, right?

Well, it turns out that it is not. Docker documents that you can configure a static ipv4_address [1] for each service/container, but it seems related configuration statements are simply silently ignored/discarded [2], [3], [4].

This seems to be related that for some strange reason stacks can (at least in later versions of docker) only use overlay type networks, rather than the much simpler bridge networks. And while bridge networks appear to support static IP address allocations, overlay apparently doesn't.

I still have a hard time grasping that something that considers itself a serious product for production use (by a company with estimated value over a billion USD, not by a few hobbyists) that has no support for running containers on static IP addresses. that. How many applications out there have I seen that require static IP address configuration? How much simpler do setups get, if you don't have to rely on things like dynamic DNS updates (or DNS availability at all)?

So I'm stuck with having to manually configure the network between my containers, and manually starting them by clumsy shell scripts, rather than having a proper abstraction for all of that. Well done :/

Exposing Ports

Unrelated to all of the above: If you run some software inside containers, you will pretty soon want to expose some network services from containers. This should also be the most basic task on the planet.

However, it seems that the creators of docker live in the early 1980ies, where only TCP and UDP transport protocols existed. They seem to have missed that by the late 1990ies to early 2000s, protocols like SCTP or DCCP were invented.

But yet, in 2017, Docker chooses to

blindly assume TCP in https://docs.docker.com/engine/reference/builder/#expose without even mentioning it (or designing the syntax to accept any specification of the protocol)
design a syntax (/tcp) in the command-line parsing (see https://docs.docker.com/engine/reference/run/#expose-incoming-ports), but then only parse tcp and udp, despite people requesting support for other protocols like SCTP as early as three years ago

Now some of the readers may think 'who uses SCTP anyway'. I will give you a straight answer: Everyone who has a mobile phone uses SCTP. This is due to the fact that pretty much all the connections inside cellular networks (at least for 3G/4G networks, and in reality also for many 2G networks) are using SCTP as underlying transport protocol, from the radio access network into the core network. So every time you switch your phone on, or do anything with it, you are using SCTP. Not on your phone itself, but by all the systems that form the network that you're using. And with the drive to C-RAN, NFV, SDN and all the other buzzwords also appearing in the Cellular Telecom field, people should actually worry about it, if they want to be a part of the software stack that is used in future cellular telecom systems.

Summary

After spending the better part of a day to do something that seemed like the most basic use case for running three networked containers using Docker, I'm back to step one: Most likely inventing some custom scripts based on unshare to run my three test programs in a separate network namespace for isolated execution of test suite execution as part of a Jenkins CI setup :/

It's also clear that Docker apparently don't care much about playing a role in the Cellular Telecom world, which is increasingly moving away from proprietary and hardware-based systems (like STPs) to virtualised, software-based systems.

Things you find when using SCTP on Linux

Harald Welte — Sun, 16 Apr 2017 16:00:00 GMT

Observations on SCTP and Linux

When I was still doing Linux kernel work with netfilter/iptables in the early 2000's, I was somebody who actually regularly had a look at the new RFCs that came out. So I saw the SCTP RFCs, SIGTRAN RFCs, SIP and RTP, etc. all released during those years. I was quite happy to see that for new protocols like SCTP and later DCCP, Linux quickly received a mainline implementation.

Now most people won't have used SCTP so far, but it is a protocol used as transport layer in a lot of telecom protocols for more than a decade now. Virtually all protocols that have traditionally been spoken over time-division multiplex E1/T1 links have been migrated over to SCTP based protocol stackings.

Working on various Open Source telecom related projects, i of course come into contact with SCTP every so often. Particularly some years back when implementing the Erlang SIGTAN code in erlang/osmo_ss7 and most recently now with the introduction of libosmo-sigtran with its OsmoSTP, both part of the libosmo-sccp repository.

I've also hard to work with various proprietary telecom equipment over the years. Whether that's some eNodeB hardware from a large brand telecom supplier, or whether it's a MSC of some other vendor. And they all had one thing in common: Nobody seemed to use the Linux kernel SCTP code. They all used proprietary implementations in userspace, using RAW sockets on the kernel interface.

I always found this quite odd, knowing that this is the route that you have to take on proprietary OSs without native SCTP support, such as Windows. But on Linux? Why? Based on rumors, people find the Linux SCTP implementation not mature enough, but hard evidence is hard to come by.

As much as it pains me to say this, the kind of Linux SCTP bugs I have seen within the scope of our work on Osmocom seem to hint that there is at least some truth to this (see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1308360 or https://bugzilla.redhat.com/show_bug.cgi?id=1308362).

Sure, software always has bugs and will have bugs. But we at Osmocom are 10-15 years "late" with our implementations of higher-layer protocols compared to what the mainstream telecom industry does. So if we find something, and we find it even already during R&D of some userspace code, not even under load or in production, then that seems a bit unsettling.

One would have expected, with all their market power and plenty of Linux-based devices in the telecom sphere, why did none of those large telecom suppliers invest in improving the mainline Linux SCTP code? I mean, they all use UDP and TCP of the kernel, so it works for most of the other network protocols in the kernel, but why not for SCTP? I guess it comes back to the fundamental lack of understanding how open source development works. That it is something that the given industry/user base must invest in jointly.

The leatest discovered bug

During the last months, I have been implementing SCCP, SUA, M3UA and OsmoSTP (A Signal Transfer Point). They were required for an effort to add 3GPP compliant A-over-IP to OsmoBSC and OsmoMSC.

For quite some time I was seeing some erratic behavior when at some point the STP would not receive/process a given message sent by one of the clients (ASPs) connected. I tried to ignore the problem initially until the code matured more and more, but the problems remained.

It became even more obvious when using Michael Tuexen's m3ua-testtool, where sometimes even the most basic test cases consisting of sending + receiving a single pair of messages like ASPUP -> ASPUP_ACK was failing. And when the test case was re-tried, the problem often disappeared.

Also, whenever I tried to observe what was happening by meas of strace, the problem would disappear completely and never re-appear until strace was detached.

Of course, given that I've written several thousands of lines of new code, it was clear to me that the bug must be in my code. Yesterday I was finally prepare to accept that it might actually be a Linux SCTP bug. Not being able to reproduce that problem on a FreeBSD VM also pointed clearly into this direction.

Now I could simply have collected some information and filed a bug report (which some kernel hackers at RedHat have thankfully invited me to do!), but I thought my use case was too complex. You would have to compile a dozen of different Osmocom libraries, configure the STP, run the scheme-language m3ua-testtool in guile, etc. - I guess nobody would have bothered to go that far.

So today I tried to implement a test case that reproduced the problem in plain C, without any external dependencies. And for many hours, I couldn't make the bug to show up. I tried to be as close as possible to what was happening in OsmoSTP: I used non-blocking mode on client and server, used the SCTP_NODELAY socket option, used the sctp_rcvmsg() library wrapper to receive events, but the bug was not reproducible.

Some hours later, it became clear that there was one setsockopt() in OsmoSTP (actually, libosmo-netif) which enabled all existing SCTP events. I did this at the time to make sure OsmoSTP has the maximum insight possible into what's happening on the SCTP transport layer, such as address fail-overs and the like.

As it turned out, adding that setsockopt for SCTP_FLAGS to my test code made the problem reproducible. After playing around which of the flags, it seems that enabling the SENDER_DRY_EVENT flag makes the bug appear.

You can find my detailed report about this issue in https://bugzilla.redhat.com/show_bug.cgi?id=1442784 and a program to reproduce the issue at http://people.osmocom.org/laforge/sctp-nonblock/sctp-dry-event.c

Inside the Osmocom world, luckily we can live without the SENDER_DRY_EVENT and a corresponding work-around has been submitted and merged as https://gerrit.osmocom.org/#/c/2386/

With that work-around in place, suddenly all the m3ua-testtool and sua-testtool test cases are reliably green (PASSED) and OsmoSTP works more smoothly, too.

What do we learn from this?

Free Software in the Telecom sphere is getting too little attention. This is true even those small portions of telecom relevant protocols that ended up in the kernel like SCTP or more recently the GTP module I co-authored. They are getting too little attention in development, even more lack of attention in maintenance, and people seem to focus more on not using it, rather than fixing and maintaining what is there.

It makes me really sad to see this. Telecoms is such a massive industry, with billions upon billions of revenue for the classic telecom equipment vendors. Surely, they would be able to co-invest in some basic infrastructure like proper and reliable testing / continuous integration for SCTP. More recently, we see millions and more millions of VC cash burned by buzzword-flinging companies doing "NFV" and "SDN". But then rather reimplement network stacks in userspace than to fix, complete and test those little telecom infrastructure components which we have so far, like the SCTP protocol :(

Where are the contributions to open source telecom parts from Ericsson, Nokia (former NSN), Huawei and the like? I'm not even dreaming about the actual applications / network elements, but merely the maintenance of something as basic as SCTP. To be fair, Motorola was involved early on in the Linux SCTP code, and Huawei contributed a long series of fixes in 2013/2014. But that's not the kind of long-term maintenance contribution that one would normally expect from the primary interest group in SCTP.

Finally, let me thank to the Linux SCTP maintainers. I'm not complaining about them! They're doing a great job, given the arcane code base and the fact that they are not working for a company that has SCTP based products as their core business. I'm sure the would love more support and contributions from the Telecom world, too.

Keynote at Black Duck Korea Open Source Conference

Harald Welte — Thu, 26 May 2016 19:00:00 GMT

I've been giving a keynote at the Black Duck Korea Open Source Conference yesterday, and I'd like to share some thoughts about it.

In terms of the content, I spoke about the fact that the ultimate goal/wish/intent of free software projects is to receive contributions and for all of the individual and organizational users to join the collaborative development process. However, that's just the intent, and it's not legally required.

Due to GPL enforcement work, a lot of attention has been created over the past ten years in the corporate legal departments on how to comply with FOSS license terms, particularly copyleft-style licenses like GPLv2 and GPLv3. However,

License compliance ensures the absolute bare legal minimum on engaging with the Free Software community. While that is legally sufficient, the community actually wants to have all developers join the collaborative development process, where the resources for development are contributed and shared among all developers.

So I think if we had more contribution and a more fair distribution of the work in developing and maintaining the related software, we would not have to worry so much about legal enforcement of licenses.

However, in the absence of companies being good open source citizens, pulling out the legal baton is all we can do to at least require them to share their modifications at the time they ship their products. That code might not be mergeable, or it might be outdated, so it's value might be less than we would hope for, but it is a beginning.

Now some people might be critical of me speaking at a Black Duck Korea event, where Black Duck is a company selling (expensive!) licenses to proprietary tools for license compliance. Thereby, speaking at such an event might be seen as an endorsement of Black Duck and/or proprietary software in general.

Honestly, I don't think so. If you've ever seen a Black Duck Korea event, then you will notice there is no marketing or sales booth, and that there is no sales pitch on the conference agenda. Rather, you have speakers with hands-on experience in license compliance either from a community point of view, or from a corporate point of view, i.e. how companies are managing license compliance processes internally.

Thus, the event is not a sales show for proprietary software, but an event that brings together various people genuinely interested in license compliance matters. The organizers very clearly understand that they have to keep that kind of separation. So it's actually more like a community event, sponsored by a commercial entity - and that in turn is true for most technology conferences.

So I have no ethical problems with speaking at their event. People who know me, know that I don't like proprietary software at all for ethical reasons, and avoid it personally as far as possible. I certainly don't promote Black Ducks products. I promote license compliance.

Let's look at it like this: If companies building products based on Free Software think they need software tools to help them with license compliance, and they don't want to develop such tools together in a collaborative Free Software project themselves, then that's their decision to take. To state using words of Rosa Luxemburg:

Freedom is always the freedom of those who think different

I may not like that others want to use proprietary software, but if they think it's good for them, it's their decision to take.

Report from the VMware GPL court hearing

Harald Welte — Wed, 24 Feb 2016 16:00:00 GMT

Today, I took some time off to attend the court hearing in the GPL violation/infringement case that Christoph Hellwig has brought against VMware.

I am not in any way legally involved in the lawsuit. However, as a fellow (former) Linux kernel developer myself, and a long-term Free Software community member who strongly believes in the copyleft model, I of course am very interested in this case - and of course in an outcome in favor of the plaintiff. Nevertheless, the below report tries to provide an un-biased account of what happened at the hearing today, and does not contain my own opinions on the matter. I can always write another blog post about that :)

I blogged about this case before briefly, and there is a lot of information publicly discussed about the case, including the information published by the Software Freedom Conservancy (see the link above, the announcement and the associated FAQ.

Still, let's quickly summarize the facts:

VMware is using parts of the Linux kernel in their proprietary ESXi product, including the entire SCSI mid-layer, USB support, radix tree and many, many device drivers.
as is generally known, Linux is licensed under GNU GPLv2, a copyleft-style license.
VMware has modified all the code they took from the Linux kernel and integrated them into something they call vmklinux.
VMware has modified their proprietary virtualization OS kernel vmkernel with specific API/symbol to interact with vmklinux
at least in earlier versions of ESXi, virtually any block device access has to go through vmklinux and thus the portions of Linux they took
vmklinux and vmkernel are dynamically linked object files that are linked together at run-time
the Linux code they took runs in the same execution context (address space, stack, control flow) like the vmkernel.

Ok, now enter the court hearing of today.

Christoph Hellwig was represented by his two German Lawyers, Dr. Till Jaeger and Dr. Miriam Ballhausen. VMware was represented by three German lawyers lead by Matthias Koch, as well as a US attorney, Michael Jacobs (by means of two simultaneous interpreters). There were also several members of the in-house US legal team of VMware present, but not formally representing the defendant in court.

As is unusual for copyright disputes, there was quite some audience following the court. Next to the VMware entourage, there were also a couple of fellow Linux kernel developers as well as some German IT press representatives following the hearing.

General Introduction of the presiding judge

After some formalities (like the question whether or not a ',' is missing after the "Inc." in the way it is phrased in the lawsuit), the presiding judge started with some general remarks

the court is well aware of the public (and even international public) interest in this case
the court understands there are novel fundamental legal questions raised that no court - at least no German court - had so far to decide upon.
the court also is well aware that the judges on the panel are not technical experts and thus not well-versed in software development or computer science. Rather, they are a court specialized on all sorts of copyright matters, not particularly related to software.
the court further understands that Linux is a collaborative, community-developed operating system, and that the development process is incremental and involves many authors.
the court understands there is a lot of discussion about interfaces between different programs or parts of a program, and that there are a variety of different definitions and many interpretations of what interfaces are

Presentation about the courts understanding of the subject matter

The presiding judge continued to explain what was their understanding of the subject matter. They understood VMware ESXi serves to virtualize a computer hardware in order to run multiple copies of the same or of different versions of operating systems on it. They also understand that vmkernel is at the core of that virtualization system, and that it contains something called vmkapi which is an interface towards Linux device drivers.

However, they misunderstood that this case was somehow an interface between a Linux guest OS being virtualized on top of vmkernel. It took both defendant and plaintiff some time to illustrate that in fact this is not the subject of the lawsuit, and that you can still have portions of Linux running linked into vmkernel while exclusively only virtualizing Windows guests on top of vmkernel.

The court went on to share their understanding of the GPLv2 and its underlying copyleft principle, that it is not about abandoning the authors' rights but to the contrary exercising copyright. They understood the license has implications on derivative works and demonstrated that they had been working with both the German translation a well as the English language original text of GPLv2. At least I was sort-of impressed by the way they grasped it - much better than some of the other courts that I had to deal with in the various cases I was bringing forward during my gpl-violations.org work before.

They also illustrated that they understood that Christoph Hellwig has been developing parts of the Linux kernel, and that modified parts of Linux were now being used in some form in VMware ESXi.

After this general introduction, there was the question of whether or not both parties would still want to settle before going further. The court already expected that this would be very unlikely, as it understood that the dispute serves to resolve fundamental legal question, and there is hardly any compromise in the middle between using or not using the Linux code, or between licensing vmkernel under a GPL compatible license or not. And as expected, there was no indication from either side that they could see an out-of-court settlement of the dispute at this point.

Discussion of specific Legal Issues (standing)

In terms of the legal arguments brought forward in hundreds of pages of legal briefs being filed between the parties, the court summarized:

they do not see a problem in the fact that the lawsuit by Christoph Hellwig may be funded or supported by the Software Freedom Conservancy. Christoph is acting on his own behalf, using his own rights.
they do not see any issues regarding the place of jurisdiction being placed in Hamburg, Germany, as the defendant is providing the disputed software via the Internet, which according to German law permits the plaintiff to choose any court within Germany. The court added, of course, that whatever verdict it may rule, this verdict will be limited to the German jurisdiction.
In terms of the type of authors' right being claimed by the plaintiff, there was some discussion about paragraph 3 vs. 8 vs. 9 of German UrhG (the German copyright law). In general it is understood that the development method of the Linux kernel is a sequential, incremental development process, and thus it is what we call Bearbeiterurheberecht (loosely translated as modifying/editing authors right) that is used by Christoph to make his claim.

Right to sue / sufficient copyrighted works of the plaintiff

There was quite some debate about the question whether or not the plaintiff has shown that he actually holds a sufficient amount of copyrighted materials.

The question here is not, whether Christoph has sufficient copyrightable contributions on Linux as a whole, but for the matter of this legal case it is relevant which of his copyrighted works end up in the disputed product VMware ESXi.

Due to the nature of the development process where lots of developers make intermittent and incremental changes, it is not as straight-forward to demonstrate this, as one would hope. You cannot simply print an entire C file from the source code and mark large portions as being written by Christoph himself. Rather, lines have been edited again and again, were shifted, re-structured, re-factored. For a non-developer like the judges, it is therefore not obvious to decide on this question.

This situation is used by the VMware defense in claiming that overall, they could only find very few functions that could be attributed to Christoph, and that this may altogether be only 1% of the Linux code they use in VMware ESXi.

The court recognized this as difficult, as in German copyright law there is the concept of fading. If the original work by one author has been edited to an extent that it is barely recognizable, his original work has faded and so have his rights. The court did not state whether it believed that this has happened. To the contrary, the indicated that it may very well be that only very few lines of code can actually make a significant impact on the work as a whole. However, it is problematic for them to decide, as they don't understand source code and software development.

So if (after further briefs from both sides and deliberation of the court) this is still an open question, it might very well be the case that the court would request a techncial expert report to clarify this to the court.

Are vmklinux + vmkernel one program/work or multiple programs/works?

Finally, there was some deliberation about the very key question of whether or not vmkernel and vmklinux were separate programs / works or one program / work in the sense of copyright law. Unfortunately only the very surface of this topic could be touched in the hearing, and the actual technical and legal arguments of both sides could not be heard.

The court clarified that if vmkernel and vmklinux would be considered as one program, then indeed their use outside of the terms of the GPL would be an intrusion into the rights of the plaintiff.

The difficulty is how to actually venture into the legal implications of certain technical software architecture, when the people involved have no technical knowledge on operating system theory, system-level software development and compilers/linkers/toolchains.

A lot is thus left to how good and 'believable' the parties can present their case. It was very clear from the VMware side that they wanted to down-play the role and proportion of vmkernel and its Linux heritage. At times their lawyers made statements like linux is this small yellow box in the left bottom corner (of our diagram). So of course already the diagrams are drawn in a way to twist the facts according to their view on reality.

Summary

The court seems very much interested in the case and wants to understand the details
The court recognizes the general importance of the case and the public interest in it
There were some fundamental misunderstandings on the technical architecture of the software under dispute that could be clarified
There are actually not that many facts that are disputed between both sides, except the (key, and difficult) questions on
- does Christoph hold sufficient rights on the code to bring forward the legal case?
- are vmkernel and vmklinux one work or two separate works?

The remainder of this dispute will thus be centered on the latter two questions - whether in this court or in any higher courts that may have to re-visit this subject after either of the parties takes this further, if the outcome is not in their favor.

In terms of next steps,

both parties have until April 15, 2016 to file further briefs to follow-up the discussions in the hearing today
the court scheduled May 19, 2016 as date of promulgation. However, this would of course only hold true if the court would reach a clear decision based on the briefs by then. If there is a need for an expert, or any witnesses need to be called, then it is likely there will be further hearings and no verdict will be reached by then.

Back from netdevconf 1.1 in Seville

Harald Welte — Sun, 14 Feb 2016 16:00:00 GMT

I've had the pleasure of being invited to netdevconf 1.1 in Seville, spain.

After about a decade of absence in the Linux kernel networking community, it was great to meet lots of former colleagues again, as well as to see what kind of topics are currently being worked on and under discussion.

The conference had a really nice spirit to it. I like the fact that it is run by the community itself. Organized by respected members of the community. It feels like Linux-Kongress or OLS or UKUUG or many others felt in the past. There's just something that got lost when the Linux Foundation took over (or pushed aside) virtually any other Linux kernel related event on the planet in the past :/ So thanks to Jamal for starting netdevconf, and thanks to Pablo and his team for running this particular instance of it.

I never really wanted to leave netfilter and the Linux kernel network stack behind - but then my problem appears to be that there are simply way too many things of interest to me, and I had to venture first into RFID (OpenPCD, OpenPICC), then into smartphone hardware and software (Openmoko) and finally embark on a journey of applied telecoms archeology by starting OpenBSC, OsmocomBB and various other Osmocom projects.

Staying in Linux kernel networking land was simply not an option with a scope that can only be defined as wide as wanting to implement any possible protocol on any possible interface of any possible generation of cellular network.

At times like attending netdevconf I wonder if I made the right choice back then. Linux kernel networking is a lot of fun and hard challenges, too - and it is definitely an area that's much more used by many more organizations and individuals: The code I wrote on netfilter/iptables is probably running on billions of devices by now. Compare that to the Osmocom code, which is probably running on a few thousands of devices, if at all. Working on Open Source telecom protocols is sometimes a lonely fight. Not that I wouldn't value the entire team of developers involved in it. to the contrary. But lonely in the context that 99.999% of that world is a proprietary world, and FOSS cellular infrastructure is just the 0.001% at the margin of all of that.

One the Linux kernel side, you have virtually every IT company putting in their weight these days, and properly funded development is not that hard to come by. In cellular, reasonable funding for anything (compared to the scope and complexity of the tasks) is rather the exception than the norm.

But no, I don't have any regrets. It has been an interesting journey and I probably had the chance to learn many more things than if I had stayed in TCP/IP-land.

If only each day had 48 hours and I could work both on Osmocom and on the Linux kernel...

small tools: gpsdate

Harald Welte — Sat, 31 Oct 2015 16:00:00 GMT

In 2013 I wrote a small Linux program that can be usded to set the system clock based on the clock received from a GPS receiver (via gpsd), particularly when a system is first booted. It is similar in purpose to ntpdate, but of course obtains time not from ntp but from the GPS receiver.

This is particularly useful for RTC-less systems without network connectivity, which come up with a completely wrong system clock that needs to be properly set as soon as th GPS receiver finally has acquired a signal.

I asked the ntp hackers if they were interested in merging it into the official code base, and their response was (summarized) that with a then-future release of ntpd this would no longer be needed. So the gpsdate program remains an external utility.

So in case anyone else might find the tool interesting: The source code can be obtained from http://git.sysmocom.de/gpsdate/

small tools: rtl8168-eeprom

Harald Welte — Sat, 31 Oct 2015 16:00:00 GMT

Some time ago I wrote a small Linux command line utility that can be used to (re)program the Ethernet (MAC) address stored in the EEPROM attached to an RTL8168 Ethernet chip.

This is for example useful if you are a system integrator that has its own IEEE OUI range and you would like to put your own MAC address in devices that contain the said Realtek etherent chips (already pre-programmed with some other MAC address).

The source code can be obtaned from: http://git.sysmocom.de/rtl8168-eeprom/

The VMware GPL case

Harald Welte — Wed, 28 Oct 2015 16:00:00 GMT

My absence from blogging meant that I didn't really publicly comment on the continued GPL violations by VMware, and the 2015 legal case that well-known kernel developer Christoph Hellwig has brought forward against VMware.

The most recent update by the Software Freedom Conservancy on the VMware GPL case can be found at https://sfconservancy.org/news/2015/oct/28/vmware-update/

In case anyone ever doubted: I of course join the ranks of the long list of Linux developers and other stakeholders that consider VMware's behavior completely unacceptable, if not outrageous.

For many years they have been linking modified Linux kernel device drivers and entire kernel subsystems into their proprietary vmkernel software (part of ESXi). As an excuse, they have added a thin shim layer under GPLv2 which they call vmklinux. And to make all of this work, they had to add lots of vmklinux specific API to the proprietary vmkernel. All the code runs as one program, in one address space, in the same thread of execution. So basically, it is at the level of the closest possible form of integration between two pieces of code: Function calls within the same thread/process.

In order to make all this work, they had to modify their vmkernel, implement vmklinux and also heavily modify the code they took from Linux in the first place. So the drivers are not usable with mainline linux anymore, and vmklinux is not usable without vmkernel either.

If all the above is not a clear indication that multiple pieces of code form one work/program (and subsequently must be licensed under GNU GPLv2), what should ever be considered that?

To me, it is probably one of the strongest cases one can find about the question of derivative works and the GPL(v2). Of course, all my ramblings have no significance in a court, and the judge may rule based on reports of questionable technical experts. But I'm convinced if the court was well-informed and understood the actual situation here, it would have to rule in favor of Christoph Hellwig and the GPL.

What I really don't get is why VMware puts up the strongest possible defense one can imagine. Not only did they not back down in lengthy out-of-court negotiations with the Software Freedom Conservancy, but also do they defend themselves strongly against the claims in court.

In my many years of doing GPL enforcement, I've rarely seen such a dedication and strong opposition. This shows the true nature of VMware as a malicious, unfair entity that gives a damn sh*t about other peoples' copyright, the Free Software community and its code of conduct as a whole, and the Linux kernel developers in particular.

So let's hope they waste a lot of money in their legal defense, get a sufficient amount of negative PR out of this to the point of tainting their image, and finally obtain a ruling upholding the GPL.

All the best to Christoph and the Conservancy in fighting this fight. For those readers that want to help their cause, I believe they are looking for more supporter donations.

Another patch submit day.

Harald Welte — Thu, 20 Feb 2014 19:00:00 GMT

Today I've submitted hashlimit, CLUSTERIP and CONNMARK to the 2.6.x kernel. After resolving some glitches with CLUSTERIP, DaveM took all three :)

This means we're again one step further submitting stuff from patch-o-matic into mainline, which is always a good thing.

Problems with OpenVPN on high-latency satellite links

Harald Welte — Wed, 04 Sep 2013 19:00:00 GMT

So far I never had a need to look in detail how the OpenVPN protocol actually looks on the wire. It seems like not many people had that much of a close look, as the wireshark plugin is fairly recent (from 2012 I think) while OpenVPN is around for ten more years than that. If I was an OpenVPN developer, the wireshark plugin would be the first thing I'd write to help debugging and development. At least that's what I've been doing from OpenPCD to SIMtrace and through the various GSM and other protocols I encounter...

The reason for my current investigation is some quite strange and yet-unexplained problems when running OpenVPN on high-latency satellite links. I'm not talking about high-bandwidth VSAT or systems with dedicated / guaranteed bandwidth. The links I'm seeing often have RTT (as seen by ICMP echo) of 2 seconds, sometimes even 5. This is of course not only the satellite link, but includes queuing on the ground, possibly the space segment and of course the terminal, including (possibly) access arbitration.

What struck me _very_ odd is that OpenVPN is sending tons of UDP messages with ridiculously small size during the TLS handshake when bringing up the tunnel. Further investigation shows that they actually internally configure a MTU of '0' for the link, which seems to be capped at 100 bytes control payload, plus HMAC and OpenVPN header resulting in 124 to 138 bytes UDP payload.

Now you have to consider that the server certificate (possibly including even a CA certificate) can be quite large, plus all the gazillions of TLS handshaking options in ServerHello, the first message from server to client. This means that OpenVPN transmits that ServerHello in something like 40 to 60 fragments of 100 bytes each! And each of the fragments will have to be acknowledged by the remote end, leading 80 to 120 UDP/IP packets _only_ for the delivery of the TLS ServerHello.

Then you start reviewing the hundreds of OpenVPN configuration options, many of them related to MTU, MSS, fragmentation, etc. There is none for that insanely small default of 100 bytes for control packets during hand-shake. I even read through the related source code, only to find that indeed this behavior seems hard-coded. Some time later I had written a patch to add this option, thanks to Free Software. It seems to work on client and server and brings the ClientHello down to much smaller 4-6 messages.

The fun continues when you see that the timeout for re-transmitting fragments that have not been ACKed yet is 2 seconds. At my satellite RTT times this of course leads to lots of unneeded re-transmissions, simply because the ACK hasn't made its way back to the sender of the original message yet. Luckily there's a configuration option for that.

After the patch and changing that option, the protocol trace looks much more sane. However, I still have problems establishing a tunnel in a number of cases. For some odd reason, the last fragment of the ServerHello is not acknowledged by the client, no matter whether patched or unpatched OpenVPN is being used. I get acknowledgements always only up to fragment N-1 after having transmitted N. That last fragment is then re-transmitted by the server with exponential back-off, and finally some 60 seconds later the server gives up as the TLS handshake didn't finish within that time. Extending the TLS handshake timeout to 120 seconds also doesn't help.

I'm not quite sure why something like 39 out of 39 fragments all get delivered reliably and acknowledged, but always the last fragment (40) doesn't make it to the remote side. That's certainly not random packet loss, but a very deterministic one. Let's see if I can still manage to find out what that might be...

Rest In Peace, Atul Chitnis

Harald Welte — Sun, 02 Jun 2013 19:00:00 GMT

Today, very sad news has reached me: Atul Chitnis has passed away. Most people outside of India will most likely not recognize the name: He has been instrumental in pioneering the BBS community in India, and the founder and leader of the Linux Bangalore and later FOSS.in conferences, held annually in Bangalore.

I myself first met Atul about ten years ago, and had the honor of being invited to speak at many of the conferences he was involved in. Besides that professional connection, we became friends. The warmth and affection with which I was accepted by him and his family during my many trips to Bangalore is without comparison. I was treated and accepted like a family member, despite just being this random free software hacker from Germany who is always way too busy to return the amount of kindness.

Despite the 17 year age difference, there was a connection between the two of us. Not just the mutual respect for each others' work, but something else. It might have been partially due to his German roots. It might have been the similarities in our journey through technology. We both started out in the BBS community with analog modems, we both started to write DOS software in the past, before turning to Linux. We both became heavily involved in mobile technology around the same time: He during his work at Geodesic, I working for Openmoko. Only in recent years his indulgence in Apple products was slightly irritating ;)

Only five weeks ago I had visited Atul. Given the state of his health, it was clear that this might very well be the last time that we meet each other. I'm sad that this now actually turned out to become the thruth. It would have been great to meet again at the end of the year (the typical FOSS.in schedule).

My heartfelt condolences to his family. Particularly to his wonderful wife Shubha, his daughther Anjali, his mother and brother. [who I'm only not calling by their name in this post as they deserve some privacy and their Identities is not listed on Atuls wikipedia page].

Atul was 51 years old. Way too young to die. Yet, he has managed to created a legacy that will extend long beyond his life. He profoundly influenced generations of technology enthusiasts in India and beyond.

Back from FOSDEM 2013

Harald Welte — Sun, 03 Feb 2013 19:00:00 GMT

As (almost) every year, I attended the annual incarnation of FOSDEM. It is undoubtedly (one of?) the most remarkable events about Free Software in existence. No registration, no fees, 24 tracks in parallel, an estimated 5000 number of attendees. I also like that it brings together people from so many different communities, not _just_ the Linux or Gnome or KDE or Telephony or Legal people, but a good mixture of everything.

I have to congratulate the organizers, who manage to pull this off, year after year again. And as opposed to many other events, they do so quietly and without much recognition, I feel. I'd also like to thank the many volunteers working tirelessly before, at and after the event. Last, but not least, I'd like to thank the local university (ULB Solbosch) hosting the event.

What made me truly sad though, is the amount of littering that surprisingly many of the attendees did. This was particularly visible in the Cafeteria. Imagine an event run by volunteers, who put in a lot of time and effort. Imagine an event where food and drinks are sold by volunteers at such low prices that there can barely be any profit at all. And then imagine people eating there and leaving all their rubbish around, as if they were in some kind of restaurant where they are being served and where somebody is cleaning up after them. It really makes me feel very bitter to see this. Don't people realize that those very volunteers who are creating the event will then have to put in _their_ spare time just because those who just enjoyed their coffee or lunch didn't have the extra 30 seconds of bringing their trash to the trashcan? I feel ashamed for members of our community who behave this way. Please think next time before acting and show your respect to the people behind FOSDEM.

Talk Idea: How to write code to make later enforcement easy

Harald Welte — Sun, 03 Feb 2013 19:00:00 GMT

During FOSDEM 2013, I spoke with some fellow Free Software developers about how my knowledge on copyright and specifically legal aspects of software copyright has influenced the way how I write code, and particularly how I design architecture of programs.

This made me realize that this would probably make a quite interesting talk at Free Software conferences: How to architect and write code in order to make later [GPL] enforcement easy.

Of course there are all the general and mostly well-known rules like keeping track of who owns which part of the copyright, having proper copyright claims and license headers, etc.

But I'm more thinking in the sense of: How do I write code in a way to make sure people extending it in some way with their own code will be forced to create a derivative work. If that is the case, they will have absolutely no choice but to also license that under GPL.

This is particularly important in the case of GPL licensed libraries. The common understanding in the community is that writing an executable program against a GPL licensed library will constitute a derivative work and thus the main program must be licensed under the GPL, if it is ever distributed.

However, in reality there is of course no precedent, and in some particular cases, the legal framework, depending on the jurisdiction, might come to different conclusions if it ever ended up in court. The claim of a 'derivative work' would be particularly weak if the main program is only using a set of standard function calls whose function declarations are the same in many versions of the GPL licensed library you link against. So let's assume there was a GPL licensed standard C library for stuff like open(), close(), printf() and the like. I think it would be very difficult to argue in court that a program written against those functions and linked against such a library would constitute a derivative work of the library. As in fact, there are many other implementations providing the exact same interface, under different licenses, and the API was not even drafted by the author of the GPL licensed implementation.

So I think there are some things that an author of an (intentionally) GPL licensed library can do while writing the code, which will later help him to establish that an executable program is a derived work.

The same is true to some extent for executable programs, too. I very intentionally did not introduce a plug-in interface for BTS drivers in OpenBSC, even though while technically it would have been possible. I _want_ somebody who adds code for a different BTS to touch the main code of the program instead of just writing an external plugin. The mere fact that he has to edit the main program in order to add a new BTS driver indicates that he is creating a derivative work.

So I'll probably try to submit a talk on this topic to some upcoming conference[s]. If you think this is an interesting topic and want me to talk about it at a FOSS related event, please feel free to send me an e-mail.

Some comments on the heated debate on SFC / Busybox / Linux GPL enforcement

Harald Welte — Wed, 08 Feb 2012 19:00:00 GMT

During the past week[s], there has been a heated debate on the alleged methods of GPL enforcement as it is performed by the Software Freedom Conservancy on behalf of the Busybox copyright holders.

The extent of license enforcement on Busybox has apparently triggered the proposal to create a non-GPL replacement for it, which in turn has received quite harsh responses e.g. from Matthew Garrett.

It's been relatively difficult for me to figure out what is really going on here. It is well-known that the Free Software Conservancy has been actively enforcing the GPL on Busybox. But then, at the same time gpl-violations.org has been (and still is!) similarly active in enforcing the GPL on the Linux kernel. Still, I haven't yet seen calls to write a non-GPL Linux kernel replacement. Of course, the complexity is on an entirely different scale, so this point is moot.

However, for quite some time there have been rumors about the intensity (some would say aggressiveness) of the enforcement. I don't want to accuse anybody of anything, so I'm going to write speculatively about it.

This post is to summarize my thoughts on all of this:

It is well within the right of each author / copyright holder to decide on the enforcement strategy and license interpretation. As such, I respect the decision of the authors. It is their work, they should decide what to do.
In any kind of GPL enforcement, you of course not only want the complete corresponding source code to one program, but to all of the GPL/LGPL/AGPL or otherwise copyleft licensed programs contained in the product. We at gpl-violations.org have always been requesting the complete corresponding source code to all GPL licensed software during our communication with the infringing companies. This request was typically honored by everyone, without the need to apply any pressure onto it. After all, releasing only one bit of code causes the risk to get sued by somebody else who owns the other not-yet-compliant part of the code.
Now there have been rumors that SFC was not only requesting non-Busybox source code, but also making it a condition for the explicit re-instatement of the license on Busybox. Whether or not there was such a hard condition is subject to debate and there are different opinions on it. For those in the field of FOSS licensing, it has always known that there are different lines of thought with regard to the requirement to explicit reinstatement. We in Germany generally think that it is not required at all, and the existing preliminary injunctions at least implicitly acknowledge that as they enjoin companies from distributing a product as long as it is not in compliance with the license. In other (particularly the U.S.), it is generally assumed that explicit reinstatement is required. In such a case, it may very well be legally possible to use it as a lever to obtain source code for other programs like the Linux kernel. However, I am personally not sure if that really is the right strategy. Not everything that is possible legally is ethically the right thing to do. But then, ethics and legal customs differ widely in the FOSS communities, as they do in society in general. Some countries and communities believe in the death penalty, others don't. Some countries allow abortion, others don't. Some allow prostitution, others don't. So when judging about whether that "reinstatement lever" is acceptable or not, we have to accept that there may be different lines of thought. I for my part definitely think that the far superior method is, beyond doubt, to have a rights holder on those other program in order to make any demand for source code (as opposed to a mere request without implicit or explicit legal threat).
There also have been rumors about a requirement on submitting future source code releases to a compliance audit by the Conservancy. According to SFC sources, there never was any such demand, and the rumors are likely spawned by some incorrect claims of a defendant in a court case, which ended up in the public record. If there was such a requirement, I wouldn't think it is just - at least not for a first-time non-intentional infringement case. If there was repeated infringement and a clear sign that it would happen again and again, such a requirement for future audits may be justified, depending on the case.
People who claim that GPL enforcement is scaring away companies from using Linux and/or other Free Software also have to be careful in what they say. If a commercial entity enters a new market (let's say Android Tablets), then there is a certain due diligence required before entering that market. So if you don't understand Free Software and particularly GPL licensing, then you shouldn't place a Linux-based device on the market. Just think about an analogy: If you have a recycling company and enter a new market (disposal of hazardous chemicals), then you cannot simply treat those chemicals as regular waste, wait until you run into legal trouble and expect to get away with it.
I think there are still far too many GPL violations out there, and we need to see more enforcement in order to get all the major players in their respective lines of business into compliance. But come on, dealing with embedded devices in 2012 and still getting compliance outright wrong really means that there has not been the least bit of attention on this subject. And without enforcement, it is never going to change. People who want no enforcement should simply use MIT-style licenses.
Last, but not least, I also think GPL compliance is a matter of fair competition. There are some companies who really do a good job in ensuring compliance with the various Free Software licenses. If their competition doesn't invest the funds into the respective skills, procedures and business processes, they are getting an unfair competitive advantage against those who are doing it right. If there was no enforcement, the motivation would be to reduce efforts in compliance, not increase it.

Let me conclude with a clear statement to anyone who thinks that by replacing Busybox with a non-GPL licensed project they can evade GPL enforcement: It will not work. There are others out there enforcing the GPL. Last but not least gpl-violations.org. Despite the notoriously outdated webpage, we are still alive and kicking, churning down on the violation reports that we receive. Armijn Hemel, Joachim Steiger, Tim Engelhardt, Julia Gebert and Till Jaeger deserve much of the credit for all that work, while I'm mostly spending each awake minute hacking Free Software for mobile communications. Yes, we should publish more about our activities, and I hope to find the time to do so. There should at least be an annual report with the number of cases...

HTCs delays in releasing Linux source code are unacceptable

Harald Welte — Fri, 23 Dec 2011 19:00:00 GMT

The Taiwanese smart phone maker HTC is widely known to be delaying its Linux kernel source code releases of their Android products. Initially, this has been described to to the requirement for source code review, and making sure that no proprietary portions are ending up in the release.

While the point is sort-of moot from the beginning (there should be no proprietary portions inside the Linux kernel for a product that wants to avoid entering any legal grey zone in the first place), I was willing to accept/tolerate it for some time.

At one point more than one year ago, gpl-violations.org actually had the opportunity to speak in person to senior HTC staff about this. I made it very clear that this delay is not acceptable, and that they should quickly fix their processes in order to make sure they reduce that delay, eventually down to zero.

Recently, I received news that the opposite is happening. HTC still has the same delays, and they are now actually claiming that even a 120 days delay is in compliance with the license.

I do think neither the paying HTC customers, nor tha Free Software community as a whole have to tolerate those delays. It is true that the GPLv2 doesn't list a deadline until when the source code has to be provided, but it is at the same also very clear what the license wants: To enable people to study the program source code. Especially in todays rapid smart phone product cycles, 120 days is a very long time.

So I hereby declare my patience has ended here. I am determined to bring those outrageous delays to an end. This will be one of my new year resolutions for 2012: Use whatever means possible to make HTC understand that this is not how you can treat Free Software, the community, its customers, the GPL and in the end, copyright itself.

Back home after successful KOSS Legal Conference

Harald Welte — Sun, 27 Nov 2011 19:00:00 GMT

The first incarnation of the KOSS Legal Conference was a big success. There were many participants from a variety of backgrounds, such as

Independent Korean legal experts
Legal scholars from Korean law schools
International legal experts (e.g. Till Jaeger, Carlo Piana, etc.)
Representatives from the major Korean IT industry
Representatives of the community organizations like FSFE
Independent technical experts like Armijn Hemel and myself

The discussions have been a big success, with significant participation from the floor. There are many events that I attended where it was hard to actually get any participation from the audience - but the KOSS Law conference was definitely not one of them. Some of the questions were easy to respond to, some other questions really tackled the difficult issues in Free Software License Compliance.

What was clear to see from the Industry participants: FOSS License Compliance has become an important topic in the last couple of years: One the one hand as a result of virtually no TV set / mobile phone / PMP or other device running without Linux or other FOSS. On the other hand, I'm sure that the enforcement efforts of gpl-violations.org and the SFLC also have had significant impact on that.

What I personally find important is that compliance is only considered as part of the overall FOSS picture. Complying with the license text is the minimum that companies involved with FOSS should do. Rather, they should look beyond mere compliance and consider the benefit of engaging more actively with the community, contribute code back upstream/mainline and really becoming a first-class citizen of the Free Software world.

As a big surprise to everyone, Jim Zemlin of the Linux Foundation made a surprise visit towards the end of the second day of the conference.

Many thanks to the KOSS Law center for bringing this together and organizing such an event. Thanks also to the Korean NIPA (National IT Industry Promotion Agency) and the FSFE for their support of the event.

Going to attend Korean FOSS legal conference

Harald Welte — Mon, 07 Nov 2011 19:00:00 GMT

Recently I had been invited by the Korean Open Source Software (KOSS) Law Center to attend their 2011 KOSS conference scheduled for November 17 and 18 in Seoul, Korea.

This conference is organized by the KOSS Law Center with support by the Korean Government (National IT Industry Promotion Agency). Its primary purpose is to share best practises in terms of FOSS licensing, license compliance but also FOSS community interaction within the Korean IT industry and the public sector.

I'm happy to present on Beyond Legal Compliance - Embracing the FOSS community, where I will outline that the primary focus should not be on to-the-letter legal compliance, but to a proactive way of interacting with the FOSS community. After all, collaborative development is what FOSS is all about...

However, due to a schedule conflict with the DeepSec 2011 conference in Vienna (where I'm giving a two-day GSM security workshop), I'm only able to attend the second day of the KOSS conference.

The speaker line-up for the KOSS conference is quite impressive, and it includes Karsten Gerloff (FSFE), Till Jaeger (JBB), Carlo Piana (FSFE), Keith Bergelt (OIN), Armijn Hemel (gpl-violations.org/Tjaldur) and others.

Unfortunately there seems to be no homepage, at least none with an English language title that Google would be able to find. Carlo Piana has mentioned the event in his blog four days ago.

UPDATE: There now is a conference page, although in Korean language only ;)

Some thoughts on the Erlang User Conference 2011

Harald Welte — Mon, 07 Nov 2011 19:00:00 GMT

It seems I'm really getting too lazy to update this blog more frequently, which is a pity. Last week I was in Stockholm attending the Erlang User Conference 2011. This was the first Erlang conference I ever went to, and it was the first conference in many, many years where I was not speaking but merely a normal attendee.

Some of the readers of this blog will already have noticed my microblogging updates on identi.ca and Twitter that I made during the conference. They were not overly excited about the conference. Let me write some more details here. I have no idea how many technical conferences I have attended, but I am typically speaking at something like 10 to 14 every year, which I believe qualifies me as a "professional conference participant" ;)

Let me start with some positive feedback: There have been excellent and technical presentations, particularly by Kostis Sagonas (PropEr), Melinda Toth (Change impact analysis) and also the talk on Hashes/Frames/Structs as new built-in Erlang data types by Kenneth Lundin.

However, apart from those, i have quite a bit of criticism:

Some presentations ended way ahead of their schedule.
This is a pity, as it means that some hundred-odd highly paid software developers are then sitting in a room and wasting time. If you hold a presentation at a conference, you should make sure that this time is used in the most efficient way. If you have been allocated a 45 minute slot, please don't make a 15 minute presentation + 5 minute questions session. That's not what the audience expects!
Keynote presentation by Ulf Wiger contained lots of hot air
If I go to a technical conference aimed at Erlang users (i.e. software developers who write programs using the Erlang language, libraries and runtime system), then I expect it to be loaded with brilliant, technical content. I want to get excited about new developments, Erlang software projects, etc. The last thing that I'd want is having a real Erlang guru on stage talking about superficial, trivial aspects of embedded computing. Of course I respect the commercial decision of Ulf and/or Erlang Solutions to try to create a market for Erlang in the embedded sphere. But what is the technical relevance of this to the Erlang community? Ulf did not talk about great new schemes of optimizing the Erlang VM for battery-powered CPUs, or how he has extended powertop to give function or line-level accuracy on which of your Erlang code lines burn most CPU cycles or cause the highest number of CPU wake-ups from low power mode. That would have been exciting.
Erlang/OTP Road-map presentation without much technical details
When I see a slide with "Some SCTP improvements" then I want to see what exactly are those improvements. I think there was more than enough time to go into more details, if Kenneth would have spoken faster and put more content into the available time. Once again, the audience is a room full of intelligent, highly-paid professional software engineers. If you get their attention for whatever amount of time, I believe you should pack it as full with information as possible, rather than bore them with slowly and carefully reading each line from a slide...
No Internet available at the Tutorials Can you believe it? In 2011, a technical conference aimed at software developers hosts tutorials inside a facility owned by one of the largest communications equipment suppliers (Ericsson) and then there is no provision for Internet access. It's really ironic, especially since at least some of the tutorial trainers expected the attendees would be able to clone git repositories on their laptops during the workshops.

In my hallway conversations with other attendees (who also have a background outside of Erlang and are more familiar with other conferences in the FOSS community), they independently observed those very same issues and agreed with my assessment.

All in all, the conference was a good trigger for me to finally sit down and start to use dialyzer on the various Osmcoom Erlang-language projects such as osmo_ss7, osmo_sscp and signerl. I'm already adding type specifications all over the code and am looking forward to soon starting with some PropEr test cases in the next couple of days.

FOSS.in is dead, PRODUCTISE.in lives

Harald Welte — Fri, 14 Oct 2011 19:00:00 GMT

Team FOSS.in has announced lest year that the successful series of FOSS.in conferences has concluded. I'm still a bit sad that I was unable to make it to the grand finale.

But now, the very same team announces a new event called PRODUCTISE.in, with a different focus. It's not about Free and Open Source Software anymore, but about product developers - where the respective products of course could be FOSS based.

I remain curios to see what will happen to the event. Everyone who knows me knows that I'm probably a slightly pragmatic but otherwise orthodox Free Software fellow. As far as I can tell, the only proprietary software that I use (and license) in more than a decade is IDA Advanced.

But in any case, all the best to Team FOSS.in with their latest endeavour!

SIM-unlocking the Openmoko phones?

Harald Welte — Tue, 05 Jul 2011 19:00:00 GMT

I think it's quite funny that SIM-unlicking vendors like RebelSIM actually advertise that their products are compatible with Openmoko, as you can see in this PDF file.

What's funny about this? Well, Openmoko phones have never been sold with any form of SIM or Operator locking. The entire idea was to have a phone that is under the control of the user, not the operator...

Unbelievable statements in GPL related case in the Supreme Court of Mauritius

Harald Welte — Sun, 26 Jun 2011 19:00:00 GMT

I've recently received some documents regarding a court case at the Supreme Court of Mauritius.

The plaintiff is a company called Linux Solutions Ltd. in Mauritius. It seems to be covering an alleged breach of an NDA between a contracted freelancing developer and a company in Mauritius. That contractor (the defendant) has apparently published some of the work he had done while contracting for the plaintiff.

While none of that seems to be clearly connected with the GPL, what is extremely disturbing is the sworn affidavit / oath by one of the executives of the plaintiff. It says things like:

5. Licenses of open-source software like "Linux" and "Asterisk" have no copyright restrictions which in effect puts no restrictions on their use or distribution. As a consequence, any work which is derived from the open source software as conceptualized, created, installed and managed, by the Applicant becomes the ownership of the Applicant.

6. In the light of the above, therefore, the applications, configuration files and features so developed by the Applicant are the sole property of the Applicant, make up the knowledge base of the Applicant, make the basis of its business operations, and are highly confident in nature. The applications, configurations and features have been built and acquired by the Applicant through important capital investments and manpower over a period of time.

So let me phrase this more clearly: Somebody, under oath is stating at the Supreme Court, that GPL-Licensed software (which the Linux kernel definitely is), has no copyright restrictions? And that any derived work is the sole property of whoever created the derivative? What kind of pot are they smoking in Mauritius?

If there's anyone in the Free Software legal community interested in filing some kind of legal document to the Supreme Court of Mauritius to clarify this issue, feel free to contact me for more details on the case. No matter whether the defendant has broken some NDA, I think it's unacceptable to see such ridiculous claims being made at a Supreme Court.

In case you don't believe it, here are some scanned samples:

AVM trying to spread FUD about the Cybits case

Harald Welte — Thu, 23 Jun 2011 19:00:00 GMT

Unsurprisingly, AVM is now trying to claim their legal action is not related to any GPL violation. This couldn't be further from the truth.

In both the court hearings (in two independent cases), AVM has repeatedly declined to make a clear statement that the modification and installation of modified version of the GPL-Licensed parts (like Linux) is acceptable to them.

We have raised this question in front of court and out of court, and AVM was not willing to make such a declaration. If they had, I don't think I would have had much reason to join the lawsuit on the side of the defendant.

I have no connection to Cybits (the defendant). There has never been any business or other relationship to them, and they have not been involved in funding my legal expenses. To be honest, I don't even care about child filtering software in general, no matter from which vendor.

But I do care about the GPL, and the freedoms it grants. The GPL is intended to allow any third party to modify, recompile, re-install and run modified versions of the respective GPL licensed program. Any court order / verdict / judgement that tries to undermine this freedom is a substantial danger to the Free Software movement - and as such I will do what I can to prevent it.

AVM has stated in front of the court that AVM releases the source code compliant with the GPL, anyone can download, compile and use it - just not on OUR hardware. There you can clearly see their attitude: They see the FritzBox as their hardware. Last time I checked, the unit is not rented by AVM, but is legally sold to the customer. It is his decision to do with it what he wants. Under the terms of the GPL, it is his decision to install whatever software on the hardware, including modified versions of the GPL licensed Linux kernel.

Just imagine a world, where you buy a Laptop from HP, with Windows pre-installed. Now further imagine that there is a third-party software vendor (e.g. Canonical with its Ubuntu). Now imagine that HP was suing Canonical for offering different software that runs on their hardware. This is the kind of analogy that you need to think about.

I don't think AVM is truly understanding the daemons they are calling here. If they actually manage to get a finally awarded judgement that deprives third parties of their rights under the GPL, AVM will have violated the GPL, specifically clause 6: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. And what would that mean? That the GPLv2 is revoked and AVM looses the right to use the GPLv2 licensed software they use in the product.

Court hearing in the AVM / Cybits / GPL case

Harald Welte — Mon, 20 Jun 2011 19:00:00 GMT

Today was the court hearing at the Berlin district court in the case that I blogged about yesterday.

Nothing really new happened there. AVM still has a number of claims that I consider extremely dangerous to Free Software in the embedded market:

collective/aggregate work
They claim to have some rights on the collective work of their own proprietary components and the GPL licensed components. While that may or may not be true, they also argue that based on such rights, they can legally prevent anyone from installing modified versions of those GPL licensed components onto the device. To me, that would clearly be a further restriction under the GPL, and thus violate the terns of the License.
using rmmod on proprietary kernel module is a modification under copyright law
This is where it starts to get really ridiculous. Both the module unload feature inside the kernel as well as the rmmod command itself are licensed under GPL. Their sole intended purpose is to unload modules from the Linux kernel. AVM now claims that the defendant is violating AVMs copyright because he unloads a proprietary AVM kernel module. Not only is it legally extremely questionable to have binary-only kernel modules at all... but then trying to tell other people they cannot unload such code is outrageous. AVM seems to not understand that they have _sold_ the device to the user. He can stop and unload any program on the device. The device is not owned by or rented by AVM.
copying code from NAND flash to RAM requires explicit permission from the copyright holder
Once again, we have a situation where the user has bought the AVM product. He has obtained a license to the software programs. Under German copyright law there is even no requirement to have a license for 'normal use of the program' as long as the program was obtained lawfully. The CPU on the AVM device (like any CPU in any computer) can only execute code that's accessible to the memory/data bus. Code in NAND flash can never be executed directly, it always has to be copied into RAM before it can be executed. The claim that this operation requires separate permission by the copyright holder is wrong. The copying happens as part of the 'normal use of the program'.

AVM has filed several other claims against Cybits based on trademark and competition law. They go as far as to debating whether a certain LED on the product malfunctions after the user has installed the Cybits software on the product ;). I don't really want to go into details here, but I think it's mainly arguing for the sake of the argument. AVM wants to keep and extend its monopolistic power over those devices, even after they have been sold. That's where the real anti-competitiveness here is... If you look at popular alternative firmware projects like OpenWRT, you will find many vendors and literally hundreds of supported devices. None of them is from AVM. Isn't that striking, considering that AVM is told to have > 60% market share in Germany?

The court has heard arguments from all sides and is now adjourned. All parties are now again going to submit lengthy piles of paper to the court. Within those originating from my lawyers and myself, we will definitely once again outline our position. AVM can do whatever it wants, but it cannot use legal means to disallow the legitimate and intended modification + use of modified versions of GPL licensed code on their devices.

The implications of such a legal win for AVM go way beyond AVM or the DSL router business. They go all over the embedded market, and include NAS devices, Android smartphones, e-book readers, etc. Just think about the implications for OpenWRT, Cyanogenmod, Openinkpot and all the other firmware modification and 'homebrew' projects out there.

German dsl-router vendor AVM seeks to remove the GPLs freedoms

Harald Welte — Sun, 19 Jun 2011 19:00:00 GMT

Today, there has been a joint press release of gpl-violations.org and the Free Software Foundation Europe on a legal battle that has been ongoing for quite some time:

The German maker of popular dsl-routers (AVM) is using legal means to try to halt a third party company (Cybits) from modifying the GPL licensed components (like the Linux kernel) of AVM-branded routers. Furthermore, it seeks to ask courts to halt Cybits from distributing software by which end users can modify that GPL licensed software.

This is outrageous! AVM does not own the copyright to that GPL-licensed software. How can they seek to prevent anyone from exercising their right to modify the code and run modified versions of it? This is one of the most fundamental freedoms that Free Software grants its users.

In the last lawsuits (preliminary proceedings) that AVM has brought about, I have intervened on behalf of Cybits. At that time, the court was impressed and has restricted a previously-granted preliminary injunction against Cybits to not include any claims regarding the Free Software portions of the product.

But meanwhile, AVM has filed for the main/regular proceedings. Tomorrow (June 21st, 11am), there will be the first hearing at the district court (Landgericht Berlin, Room 2709, Littenstr. 12-17, Berlin).

I have applied to be a side intervener in those main proceedings, too. Given that the previous court accepted this, I assume it will be accepted in the district court, too.

Normally I wouldn't care much if two companies are taking it to court. But this case is not about Cybits or AVM. This case is about the fundamental question of whether a device maker using Linux and other GPL licensed software has the right to use legal means to prevent third parties from exercising their fundamental rights granted under the GPL.

For more information about the case and background information, please check out this background page at FSFE.

Interview with German newspaper taz about gpl-violations.org work

Harald Welte — Mon, 30 May 2011 19:00:00 GMT

There has been an interview for (at least) the online edition of the German newspaper taz - die tageszeitung. If you understand German, you can read it here.

By coincidence, I'm a subscriber to that very same newspaper for more than 10 years ;)

HTC announcement about no more locked-down phones

Harald Welte — Sun, 29 May 2011 19:00:00 GMT

As it has been covered at various news site, HTC has apparently announced that they will not be shipping Android phones with locked-down bootloaders.

If this is really true, it would mean that more people not only have the theoretical freedom to run modified versions of Linux (granted by GPLv2), but also the practical freedom. If there is no cryptographic restriction on only booting HTC-supplied versions of the Linux kernel (and other software), this is good news!

It comes as a bit of surprise though. "Traditionally", HTC is known for behaving unfriendly towards the community. Not only due to their source code releases being constantly too late, but also due to the fact that their phones were some of the first to use cryptographic signatures to keep people from installing their own versions of Linux (and Android).

The other surprising move has come from Motorola, who probably has the longest tradition of shipping Linux-based phones (in various degrees of GPL compliance), but then using technical means to deprive their customers of the Freedoms the GPL wants to grant to them, i.e. the freedom to run modified versions of the Software (Linux in this case). They did this with the later models of the EZX range, with their MAGX phones, as well as now with their Android phones over the last couple of years. So it was very puzzling to see the same Motorola announce a 180 degree turn in policy at least for their Xoom tablet.

Also, in recent news, Sony Ericsson made a similar announcement that at least some of their Xperia models can be bootloader unlocked.

It's really striking. During the least seven years, I used to be involved in a number of projects that tried to enable the user of mobile smartphones to have the full source code for (at least) the Linux kernel, and to be able to modify, tinker and re-program it any way they want. Now some of the vendors seem to be moving in the right direction.

What's sad is that Samsung is not capitalizing on their potential here. They have always had very timely and complete source code releases for all their Linux based phones at http://opensource.samsung.com/, and they have very rarely tried to lock any of the bootloaders. I don't know if this is intentional or not. But now the other vendors are getting good PR for stopping to do something that (to my knowledge) Samsung has not done, at least not to the extent of the others.

In any case, I still think the Nexus S is the best choice for anyone who wants to have a developer friendly device. It is fully supported in the main AOSP tree, everything in the kernel is GPLv2, and those binary userspace blobs that are required are distributed independently at https://code.google.com/android/nexus/drivers.html so they can be integrated into custom builds. This is by no means perfect, but the best compromise that seems available at this point. I still don't understand why the userspace drivers for the GSM/3G modem, Wifi, Bluetooth and GPS would need to be proprietary. Or even the NFC par, it's sort-of ridiculous to have that proprietary with Free Software RFID stacks like libnfc and librfid around...

Apple not providing LGPL webkit source code for latest iOS 4.3.x

Harald Welte — Thu, 05 May 2011 19:00:00 GMT

As some people may know, next to a plethora of BSD licensed code, Apple is using some LGPL licensed code in their iPhone products.

So far, it seems they have always provided the respective source code in a timely manner for each and every release they have made on a website www.opensource.apple.com.

However, in recent months it seems they have deviated from that policy for unknown reasons. As my friend and webkit developer zecke has blogged, Apple has stopped to release their webkit source code with iOS release 4.3.0. The corresponding website simply states: "coming soon".

iOS 4.3.0 was released on March 10, 4.3.1 on March 25, 4.3.2 on April 14 and 4.3.3 on May 4. For all of those releases, no source code has been published.

It cannot be a simple oversight, as multiple inquiries have been made to Apple by interested developers. However, the source code yet has to be released.

I think it is time that Apple gets their act together and becomes more straight-forward with LGPL compliance. It is not acceptable to delay the source code release for 8 weeks after shipping a LGPL licensed software. Especially not, if you have already demonstrated in the past that you are well aware of the obligations and have a process and a website to release the corresponding source code under the license conditions.

Jounrees Logiciels Libres / ENSA Tetouan, Morocco

Harald Welte — Sun, 01 May 2011 19:00:00 GMT

I've been invited to Tetouan, Morocco by the organizers of the second incarnation of the Journees Logiciels Libres. Tomorrow I'll have the pleasure of presenting about Free Software projects related to GSM, including OpenBSC and OsmocomBB.

The organizers have done a great job in caring about the foreign speakers (who include Richard Stallman and myself).

I've been listening to various talks by RMS RMS over the last 16 years or so... but right now I'm listening the first time to him giving a French presentation.

Overall, this trip has done more to improving my understanding French than anything else in a long time. I once had 4 years of French from 1st to 4th grade in school, but never really continued with it. However, what I remember, combined with my knowledge of Portuguese (and even English) is sufficient to e.g. understand all of the French language slides that have been presented at this conference. However, most spoken French is too hard to understand for me.

One striking observation is the apparently much higher percentage of women taking a communications or computer engineering degree here than what I'm used to in Germany or the so-called western world. It reminds me of India where you have the feeling that almost 50% of the IT related students are female. It would still be interesting to see some scientific research why the supposedly open and anti-discriminating, women-rights-embracing 'western world' is seeing less women taking up engineering studies...

Deutsche Telekom tried to register a trademark on netfilter

Harald Welte — Sun, 03 Apr 2011 19:00:00 GMT

I am currently doing some trademark related research, and just for fun I queried the database of the DPMA (German trademark and patent office) for "netfilter".

To my big surprise, you can find this record, indicating that Deutsche Telekom AG has applied for a trademark on the word "NetFilter" in July 2006.

I find that quite outrageous, as the netfilter project is using the name since about 1999, i.e. 7 years earlier. To our luck, the trademark office refused the application based on the generic nature of the name, i.e. "netfilter" being too generic for anyone obtaining a trademark on it - at least in Germany, under German laws.

Linux Beer, anyone?

Harald Welte — Sun, 03 Apr 2011 19:00:00 GMT

During my trademark research, I also discovered: A German beer brewer (St. Georgen Braeu, Buttenheim) has held a registered trademark "LINUX" from 1999 to 2009. This trademark was restricted to "beverages, beer and other alcoholic drinks".

You can find the respective entry in the DPMA trademark database here.

I am not quite certain whether I would have liked the idea of drinking a pint of Linux or not. It would certainly have been a popular gift to bring to international (Linux, Free Software) conferences.

Back from the GPL Compliance Engineering Workshop in Taipei

Harald Welte — Sat, 11 Dec 2010 19:00:00 GMT

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.

ST-Ericsson releases (and submits) Android GStreamer code

Harald Welte — Tue, 07 Dec 2010 19:00:00 GMT

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.

Back from DeepSec 2010

Harald Welte — Sun, 28 Nov 2010 19:00:00 GMT

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.

Hashdays 2010 in Lucerne, Switzerland

Harald Welte — Sat, 06 Nov 2010 19:00:00 GMT

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.

ST-Ericsson glues gstreamer into Android - and makes it proprietary

Harald Welte — Tue, 26 Oct 2010 19:00:00 GMT

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

The ELCE 2010 keynote by Ari Rauch (Texas Instruments / OMAP)

Harald Welte — Tue, 26 Oct 2010 19:00:00 GMT

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.

GPL compliance workshop on December 2nd in Taipei, Taiwan

Harald Welte — Mon, 25 Oct 2010 19:00:00 GMT

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 coming up

Harald Welte — Sat, 16 Oct 2010 19:00:00 GMT

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.

GPL violation reports in HTC G2 Android phone

Harald Welte — Mon, 11 Oct 2010 19:00:00 GMT

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...

FOSS.in/2010 CfP is closing

Harald Welte — Fri, 08 Oct 2010 19:00:00 GMT

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 :)

Linux Kongress 2010 in Nuremberg / Germany

Harald Welte — Wed, 22 Sep 2010 19:00:00 GMT

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.

Dell finally releases sources of GPL licensed software on the Streak

Harald Welte — Sun, 12 Sep 2010 19:00:00 GMT

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.

Motorola announces "Ming" phone with Android

Harald Welte — Wed, 01 Sep 2010 19:00:00 GMT

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.

More GPL enforcement work again.. and a very surreal but important case

Harald Welte — Tue, 31 Aug 2010 19:00:00 GMT

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.

Convert RSS feed subscriptions from N810 feed reader to Android com.meecal.feedreader

Harald Welte — Tue, 24 Aug 2010 19:00:00 GMT

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.

Started to play with the Galaxy S (GT-I9000) phone

Harald Welte — Fri, 20 Aug 2010 19:00:00 GMT

For many years I'm on a more or less consistent hunt for finding a reasonably open and free mobile phone. This started in 2004 with OpenEZX, has continued with Openmoko, project gnufiish and has resulted in a bit of peeking and poking in the Palm Pre. However, none of those projects ever had the success I was hoping for:

OpenEZX was never really finished, and only for the 1st generation phones (A780) by the time they were long end of life
OpenMoko Neo1973 and FreeRunner were a great project, and they are still the most open+free mobile phones that ever existed. However, they're GPRS only and the hardware is even more outdated now then it was when we created it.
gnufiish was an attempt of running software from the Openmoko days (such as freesmartphone.org) on some E-TEN glofiish phones. However, we never could make the SPI-based modem communication work from our re-engineered Linux driver :(
Palm Pre is an interesting device, in that Palm provides easy root access, does not attempt to lock the device down with cryptographic signatures and provides full recovery flashing tools by means of WebOS Doctor. But once again, the proprietary communication protocol with the 3G Modem was the big blocker item for using real custom software and not the WebOS stuff they ship.

So I've constantly been on the watch for new devices that are coming out. Most of the phones you can buy in recent years are either running proprietary software like Windows Mobile, Symbian, Apples iPhone-OSX - or they run Android but then use some integrated Qualcomm Smartphone-on-a-chip product. The problem with the latter (from a Free Software point of view) is that Qualcomm is very secretive about their products, does not provide any kind of public documentation, and the ever-increasing integration between application processor and baseband processor makes it more difficult to run custom software on them.

The Samsung Galaxy S (GT-I9000) seemed like a good candidate to me, for several reasons:

Samsung does not use cryptographic signature techniques and gaining root as well as flashing the AP software is relatively easy
The phone is based on a traditional separate application processor (AP) and baseband processor (BP) design. The AP is a Samsung S5PC110, the BP is some Qualcomm MSM6xxx.
High-end hardware, with the S5PC110 running at 1GHz and 512MB RAM
Samsung provides excellent "GPL source code offers" containing the Linux kernel used in their firmware - including detailed instructions in how to build it. Also, many of the drivers are included under GPL, such as drivers for all the integrated peripherals of the SoC, some custom components like the USB multiplexor ASIC, etc. as well as the driver for the dual-ported RAM between the AP and BP for the 3G Modem communication
The Android RIL shipped by Samsung contains lots of debugging/decoding/dumping code that can make reverse engineering the AP/BP protocol.

So right now I'm in the exploration phase, making myself familiar with the bootloader, the flashing process, the userspace ABI of the custom (GPL licensed) kernel drivers, etc. It's a fairly pleasant experience so far, and I now have a debootstrap'ed Debian lenny on an additional ext2 partition on the SD card. This provides me with an actually useful userland I can chroot() into, such as lsof, strace, ltrace, tcpdump, etc. to do some more exploration of the phone.

The only real ugliness on the software side so far is the use of proprietary Samsung filesystems (RFS/TFS4). The only reason those filesystems existed, as far as I can tell, was to run legacy filesystems like FAT on top of raw NAND or OneNAND flash. This is mainly necessary if you want to export e.g. a FAT partition via USB Mass Storage to a Windows PC. However, the GT-I9000 doesn't have any OneNAND, but only an internal moviNAND (basically a SD-Card in a BGA package that you can solder on the board). MMC/SD cards already include the wear leveling algorithm, so there is absolutely no point (from what I can tell) in running the RFS/TFS4 stack.

In fact, in several forums people are complaining about the slow I/O performance of the Galaxy S, and they have a much better performance when using ext2/ext3 directly on that moviNAND device.

Doing RFID related research and development again

Harald Welte — Mon, 16 Aug 2010 19:00:00 GMT

More or less a bit surprising to me, I got again involved in RFID research, on which I hadn't really done much ever since my involvement in the OpenPCD and OpenPICC projects some five-to-four years ago.

It's a lot of fun, and I didn't seem to forget much. What really bothers me a bit is that the OpenPCD / librfid / OpenPCD integration never really was completed, and that libnfc doesn't work with OpenPCD. Let's hope I'll somehow find some time to change this. It just feels wrong that OpenPCD was the first hardware project created to encourage (security) research into RFID, and now all the current tools only run on the Proxmark or on proprietary readers...

Wondermedia WM8505 Linux + u-boot source code

Harald Welte — Thu, 12 Aug 2010 19:00:00 GMT

In recent months, a number of alleged GPL-violation reports regarding products (tablet computers, mini netbooks and the like) using the Wondermedia WM850x line of ARM SoCs. People have been contacting me, as I was working as VIA Open Source Liaison, and there is the general belief that VIA and Wondermedia Technology (WMT) are one company.

I had investigated this issue even before there were any reports, and I'd like to publicly state that:

Wondermedia is a separate company from VIA, with independent management, making their own business decisions. The 850x SoC development was started inside VIA, but is no longer part of VIA for a long time.
Any references to VIA in the source code or old data sheets date from that time before the SoC business became part of Wondermedia
I have had assurances from Wondermedia, even before there were any allegations, that similar to VIA they explicitly notify their customers about the GPL and always provide their SDK / BSP as full corresponding source code.
Effectively, this means that GPLv2 Section "3a" is used. WMT has provided the Linux and u-boot source code to its customers, and thus has no obligation under GPLv2 Section "3b" to provide it to anybody else (any 3rd party)
So, if you buy a product including a WMT SoC and u-boot/Linux, like always, GPL compliance of what has been shipped to you has to be assured by the manufacturer of the product, not the semiconductor maker

Notwithstanding all of the above, Wondermedia was willing to provide the Linux kernel and u-boot source code of their SDK to me, so I can share it with the community. As indicated, they're not legally required to do this and I'm happy they do it anyway to show their good intentions.

You can download the released source code from the gpl-devices.org ftp-server, more specifically here are the latest Linux kernel (modified 2.6.29 android derivative) and u-boot source code archives.

This software is provided without any kind of support. If you see some GPL related legal problems (i.e. you believe it is incomplete), don't hesitate to contact me. To the best of my knowledge WMT (basically a small hardware start-up with small software development team) has no resources to actively push any of this mainline.

On my way to Taiwan for COSCUP

Harald Welte — Fri, 06 Aug 2010 19:00:00 GMT

Tomorrow early morning I'll be on my way to Tapei/Taiwan. The main reason for this trip is the invitation to speak at

More musings on locked-down mobile phones

Harald Welte — Fri, 16 Jul 2010 19:00:00 GMT

In recent days, the story about Motorola locking out its users (and developers) from their more recent Droid phones has made big news. As it seems, the exact functionality implemented by eFuses remains unclear, and the behavior of Motorola might thus not be too different from what has more or less become the industry standard.

For those of you who are not following the mobile world as close on a technical level as people like me do: In the last five years, more and more cellphone manufacturers have used cryptographic code signing to lock-down the software that you can run on the phone. Major parts of the system including the software update mechanism and the bootloader on the device contain a verification process of those cryptographic signatures to ensure that you can only software signed by the phone manufacturer.

I have seen this with the MotoMAGX phones like the ROKR2 v8, various Windows Mobile handhelds from HTC, The non-developer (non-ADP) version of the Google/Android G1 and many other phones.

This puts the user into a strange situation where he buys some hardware from the manufacturer, but yet doesn't have control over what this device does. Just imagine buying a computer, but being limited to run Windows 98 and Office 97 on it. You could not update to a later version of the operating system, and you could not install an alternative operating system such as a version of GNU/Linux. If the computer vendor decides that he will drop support for it, you will not even be able to install security updates to the operating system.

From my point of view, this is an abusive, anti-competitive behavior by the manufacturer. For no reason but his ever-growing hunger for power he makes you completely dependent on his decision. It is not in the control of the user, what operating system or even applications you can install. It is under the control of the manufacturer.

I would accept this if the phone was rented. In this case, I would only pay a small rental fee, but the phone is the property of the manufacturer and I am only using it. But the manufacturer actually sells the device. He wants to be paid the full price, but still not actually hand control over to the buyer.

Compare this with buying a CD-player that has arbitrary restrictions so it would only play CDs from one of the major music labels/distributors like EMI, but not CDs from any of the other publishers, for no technical reason whatsoever. Or buying a TV set that is locked down so you can only watch one TV channel, while you need to buy another TV for a different channel.

I actually think the antitrust authorities should investigate this behavior of the mobile phone industry. Simply compare it with the PC situation and look at the fact how often Microsoft has been judged in some kind of anti-competitive behavior in the PC world. In the mobile phone industry, the situation is worse than it ever was in the PC world, yet we do not see big antitrust cases being brought forward.

And please don't buy those pseudo-arguments that this has any relation to regulatory/FCC approval or the safety of mobile networks themselves. The entire software stack interacting with the mobile network runs on a separate processor (the baseband processor) anyway. It doesn't matter what you install on the application processor. Once again, compare it to laptops: You can insert a 3G miniPCI, expressCard or USB dongle. Inside this dongle you run the communications stack on a processor that is completely different from your main processor that runs your regular OS (be it GNU/Linux, OS X, Windows, Solaris or whatever makes you happy).

Motorola locking down the DroidX and Droid2 in a nasty way

Harald Welte — Thu, 15 Jul 2010 19:00:00 GMT

There are plenty of reports in recent days about the level of locking-down that Motorola is apparently doing on their most recent Android products, the Droid 2 and the Droid X.

This goes as far as to an (I believe unconfirmed) slashdot.org report claiming that not only there is the more or less typical DRM on software (i.e. cryptographic signature validation chain), but there also is an eFuse that that is blown if something happens wrong during the booting process.

To the best of my knowledge (and I'm doing mobile phone reverse engineering for about 6 years now), this is the first time I hear of something like this. If true, it sounds pretty dangerous to me. What if something goes wrong during an update (such as a power failure during software update)? What if you really have a non-correctable multi-bit error in your NAND Flash? In that case, cryptographic verification of the firmware fails and the eFuse would be blown, resulting in your device being a brick. This could eventually backfire massively to Motorola.

The best comment from the slashdot.org thread:
You can legally buy a gun that only shoots in the direction of the person pulling the trigger, but it doesn't mean it's a good idea.

Reading something like this almost makes me very depressed. Motorola is benefitting from the billions-of-dollar-worth development of existing Free Software projects like the Linux kernel, but they now want to take away the fundamental right to run modified versions of that very software. Somebody needs to slap them with a very large trout.

I'm not really surprised that they are doing it, though. Motorola has shown that direction even years ago when they first used SELinux as part of their later pre-Android Linux phones (EZX and MAGX). They didn't use it to enhance the security of the user, but to enhance the security _from_ the user.

Please also note this great post by Bradley M. Kuhn on the subject matter. If you don't know Bradley, he's been doing GPL enforcement for the last 12 years - for the Free Software Foundation and the Software Freedom Law Center. In his post, he actually thanks Motorola to publicly state that they actually want to lock their phones down (as opposed to Apple).

What's even more interesting though is his elaboration on the scripts to control compilation and installation clause of GPLv2. This is indeed something that most people tend to overlook when it comes to GPL[v2] compliance and we see this a lot during our gpl-violations.org work.

And in fact, for a very long time, I have been teaching and educating this fact during my GPL related talks and trainings: In software specific for embedded devices, the scripts to control installation are incomplete, if you do not provide a means to install the software onto the actual device. Where else would you be reasonably install the Linux kernel image that is made specifically to work on such a particular mobile phone model? Due to the custom nature of Linux kernels for embedded targets, it wouldn't even run anywhere else.

I've never taken any such issue to court so far - but it was a frequent dispute in out-of-court GPL enforcement we've been doing at gpl-violations.org. I'm definitely curious to see what will be the first court case addressing that issue. The ever power-hungry manufacturers of mobile phones seem like they deserve it.

UPDATE:
Apparently Motorola has released some statement that denies they use eFuses to brick the device. All it does is to render the device unable to boot until some Motorola-certified/signed/authorized software is loaded on the device again. They did not specify how that could be done, though. Still, even without the eFuse bricking, I find it outrageous that the Industry (including Motorola) expect their customers pay hundreds of dollars for a device that is then still owned by Motorola rather than that very customer. It's like selling something but still retaining ownership of it. Doesn't that make you feel strange, too?

COSCUP 2010 conference schedule has been posted

Harald Welte — Wed, 07 Jul 2010 19:00:00 GMT

The Schedule of the COSCUP 2010 conference has been posted on the conference homepage. I'm happy to see such a large number of talks from a wide range of speakers - including many friends from my time in Taiwan a couple of years back for Openmoko...

As it seems from this chinese blog entry, the organizers were overwhelmed by the number of attendee registrations, with all 610 available seats being occupied within 85 minutes of opening the registration. It seems they are in need of a bigger venue next year ;)

More thoughts on FSF action against Apple over GNU Go

Harald Welte — Mon, 14 Jun 2010 19:00:00 GMT

Last week, I blogged about the FSF action against Apple. This week, I intend to add a bit to that.

As it has been pointed out to me, Apple has immediately removed the GPL-infringing software from its app store. This of course means they have refrained from further infringing the GPL. It is not publicly known if they have made a declaration to cease and desist or not.

So yes, by removing the software that was distributed in violation of the GPL terms, Apple has done legally the right thing: Reduce the danger/risk of committing further (knowing) infringement.

The FSF (and probably the Free Software community in general) of course want something else: For Apple to alter their app store terms in a way that would enable software authors to have Apple distribute their GPL licensed software in it. While this might be possible very easily with small modifications to their legal terms and to the implementation of the app store, it is probably not quite easy to make a legal claim and try to force this upon Apple.

Anyone always has the choice to either distribute GPL licensed software compliant with its license terms - or not distribute it at all. If Apple prefers the latter, this is very unfortunate (and you might call it anti-social or even anti-competitive) but something that they can very well do.

The only questions that I see remaining from a legal point of view: What about the previous GPL infringements? What can (and/or has) Apple to do in return to the previous distribution of infringing software? This is where the legal pressure of the copyright holders leaves room for negotiation. Instead of monetary damages (which don't really resolve what the GPL aims to do), there could possibly be a solution where Apple has to provide the GPL license text and complete corresponding source code to the Go program through their app store. And while they're at it, they might just solve the distributing source code for copyleft style licensed software problem in a generic way. Or they might just decide that they're stupid and stubborn and not interested in solving any problems in the first place.

My take on the FSF action against Apple over GNU Go

Harald Welte — Thu, 10 Jun 2010 19:00:00 GMT

About two weeks ago, the FSF announced that it has taken action against the Apple App Store over their distribution of GNU Go. This has apparently set off some people like lefty and triggered a length and wide debate.

I personally very much support the action the FSF has taken. Anyone involved in distribution of copyrighted material is required to do due diligence on checking that he actually has a license to do so. This is not really related to the GPL.

Yes, this means that I can take GPL enforcement action to a retail store that is selling/distributing infringing products, and I can make them provide a declaration to cease and desist from further infringements. Of course, that declaration would only be valid for this single retail store. This is why in our gpl-violations.org work, we always try to go after whatever entity is responsible for the majority or all of those infringements, rather than after a single store owner.

The reason for this is simple: In many cases, it is impossible for you as the rights holder to find out who sold the product to the retail store, and track the entire supply chain back to whoever caused the GPL violation in the first place. Also, some of those entities might reside in a different jurisdiction, so you go after the first element in the supply chain that is in your own jurisdiction, to minimize the legal risk for you as plaintiff and maximize the output in terms of your local market.

But the case with Apple is different. They are not a small retailer down the road, but the entity responsible for providing the infringing software to (almost?) all of its users. They are running that App store as a commercial company and earn money from running it (even if individual apps might be free of charge). Free Software and copyleft licenses like the GPL are a very real phenomenon in the software industry today, so they should better have thought about a proper solution, not just for GNU Go but for the tens of thousands of existing GPL licensed software projects which people might want to port or re-use in iPhone applications.

They are already doing all kinds of verification/checking/review of software for other reasons (things many people might call censoring), and as part of that process they could just as well determine the license of the software, and provide a source code download link from their store. What is the big deal? If they (or other similar app store / market / ... providers) had thought how to address the problem, there are easy and pragmatic solutions to solve them in the architecture of such a app store / marketplace system.

Also, the fact that the FSF is taking legal steps is not wrong. Even if some people might dispute whether they actually have a valid case or not (I believe they do): This is what legal cases are for: To create a clear legal situation for all participants in the dispute, and to set precedent for future similar cases. Even only from that point of view it is good that they're doing this case. At the end of it, the legal situation will be more clear, both for Apple as well as for people who want to distribute GPL licensed software through their store.

The Linux-Kongress 2010 CfP is about to close

Harald Welte — Sun, 30 May 2010 19:00:00 GMT

The Linux-Kongress 2010 Call for Proposals is about to close.

So if you have anything interesting related to Linux that you would like to talk about at the 2010 incarnation of one of the most traditional Linux conferences, this is your last chance. There is no excuse, do it right now!

dfu-util release 0.1 has been announced

Harald Welte — Sun, 23 May 2010 19:00:00 GMT

Back in the early days of my work at Openmoko, I had come up with the idea to use the standardized USB Device Firmware Upgrade (DFU) protocol for flashing firmware to the Neo1973 and later FreeRunner phones. This encompassed a DFU device implementation that is part of the Openmoko u-boot variant (and has meanwhile been merged in one of the u-boot successor projects) as well as a tool for the host PC called dfu-util.

Since DFU is meant to be device and vendor-agnostic, I tried to code closely to the spec. This meant that it in fact was compatible to other devices, and some folks e.g. used it to flash firmware into their USB-Bluetooth controllers from CSR.

However, there never was any official information how to use dfu-util outside the context of Openmoko, and even more specifically: There never were any official releases.

Stefan Schmidt has stepped up to change this and maintain dfu-util as well as make official releases. The first such release has now been made at the new dfu-util project homepage.

I'll be presenting at COSCUP 2010 in Taiwan

Harald Welte — Wed, 19 May 2010 19:00:00 GMT

I have just received the great news that my attendance of the COSCUP 2010 conference in Taiwan is now confirmed. Thanks to COSCUP for inviting me!

I'll be participating in the legal track and presenting on GPL license compliance. The exact title and abstract is not yet decided.

As usual, I'm really looking forward at any chance to visit Taiwan, and the trip this August is definitely no exception. Now I only need to decide how long I'm going to stay before/after the conference...

Security product technical details need to be disclosed while importing to China

Harald Welte — Sat, 01 May 2010 19:00:00 GMT

According to this report at The Register, there are some new government regulations about the import of certain security products into China, including Smartcards, firewalls and routers. While importing the goods, the importer needs to submit the technical details to a government panel in order to get the import license.

However, the article claims there are no further details on what exactly needs to be disclosed. Anyone who knows more details: I'd be more than interesting to hear about them - maybe there's even an English translation of the respective law or regulation?

I think it is a most reasonable policy that a country can adopt. Security products whose operation relies on its secrecy are useless anyway. The concept of security-by-obscurity has never worked and has been proven wrong many times, e.g. in the NXP Mifare Classic, DECT cipher/authentication, GSM A5 cipher and many other proprietary encryption schemes.

The only thing the Chinese regulators are doing wrong: According to their rules, the information must be disclosed to a closed government panel. Instead, they should require such information to be published publicly, or at least to be released in full detail to all customers of the respective product.

Attending DORS/CLUC 2010 in Zagreb next week

Harald Welte — Thu, 29 Apr 2010 19:00:00 GMT

I'm looking forward to attend DORS/CLUC 2010 in Zagreb/Croatia next week. DORS/CLUC is a small but nice event, with a group of very warm and welcoming organizers. I've been there a couple of times before and always had a very good time.

Linux-Kongress 2010: Call for Proposals closes soon

Harald Welte — Thu, 29 Apr 2010 19:00:00 GMT

This years will mark the 17th incarnation of Linux Kongress. It is scheduled from September 21st through 24th in the city of Nürnberg (aka Nuremberg), which (as a personal side note) also happens to be the city where I was born and where I've grown up.

The Call for Proposals is out for quite some time, and will last for another month until June 1st. So if you have something exciting to talk about that is related to Linux and of technical nature: Please submit your proposal soon. Looking forward to listening to your presentation at LK2010 :)

I'll be presenting at the SSTIC 2010 conference

Harald Welte — Wed, 28 Apr 2010 19:00:00 GMT

I've been invited (as apparently the only non-french-speaker) to present at the SSTIC 2010 conference in Rennes/France.

There will be two presentations: One about OpenBSC, the other about OsmocomBB. Both will cover the use of the respective projects in the context of doing security analysis on a GSM protocol level.

Sony faces class action lawsuit on removing the Linux support on PS3

Harald Welte — Wed, 28 Apr 2010 19:00:00 GMT

As reported, a class action lawsuit has been filed against Sony in the US for removing the so-called Other OS feature from Playstation 3. The PS3 was originally advertised as being able to run Linux, and I know a number of people who have bought it for exactly that reason. Removing that feature after the purchase is thus significantly reducing the value of the product to many of its users.

I can only hope that this lawsuit will be successful. After I have bought a product, I own it and I decide what to do with it, not the original manufacturer. There have been somewhat related cases where Amazon removed already purchased books from the eBook readers of their customers. This is simply insane. With the ever growing power that corporations try to achieve over what their customers do or don't do, the outcome of this case might have significant importance for consumer rights in the decades to come.

The mid-term future of WebOS seems safe

Harald Welte — Wed, 28 Apr 2010 19:00:00 GMT

After HP announced its acquisition of Palm, I think we can be sure that the mid-time future of WebOS seems quite safe. I also expect mechanically much better hardware among the devices they will ship.

However, the acquisition could also mean a shift in politics, i.e. cause the new devices to be locked down with cryptographically signed kernel images. One of the big advantages of the existing Pre and Pixi is that they are not locked down and that as a user you can take full control over the device.

Another policy that might come under re-evaluation is the relationship between the WebOS Application Market and the third-party application installers like Preware.

Lets hope the managers responsible for WebOS future realize that their chance is to be less restrictive and more open than most of the competition - including most Android devices. At least, one could hope, HP has quite some experience with Linux and the Open Source community in other areas of their business.

Wikipedia discussion on deleting entry on David Miller

Harald Welte — Fri, 16 Apr 2010 19:00:00 GMT

As you can see, Wikipedia has started a discussion on whether or not to remove the Wikipedia entry about DaveM

I think this is pretty hilarious. By now, the Linux kernel is probably running on hundreds of millions of CPUs on this planet, most of them connected to some kind of TCP/IP network. And whom do we have to thank for the quality and scalability of that TCP/IP stack inside Linux: David Miller. He's probably one of the longest-running maintainers of a subsystem that's as essential as the networking subsystem.

And this is just one of his many contributions. The SPARC and UltraSPARC port might not be as important today than they were some time ago, but they have been large contributions nonetheless. And then let's talk about operating vger.kernel.org, the central mailing list host running (among others) what is probably one of the worlds largest mailing lists: linux-kernel aka LKML.

If you think that David Miller is a notable person, then please go to this Wikipedia page and argue that his article should not be deleted.

Becoming a licensee of the Open Invention Network

Harald Welte — Wed, 14 Apr 2010 19:00:00 GMT

As has been announced publicly, my sole proprietor company hmw-consulting has become a member of the Open Invention Network.

If you don't know what OIN is about: It's an organization creating a defensive pool of patents that may be used to deter patent aggression against what they call the Linux Environment.

New binary analysis tool for license compliance audits released

Harald Welte — Wed, 14 Apr 2010 19:00:00 GMT

My friends at Loohuis Consulting and Opendawn have just announced the first public release of their novel binary analysis tool.

This is a modular (python) framework facilitating the audit of compiled object code. Using it, you can analyze executable code (programs/libraries) or entire filesystem images or even complete firmware images and search it for strings, symbol tables and the like. Using a corresponding knowledge base, it can match this information against information derived from software source code and thus give some indication of whether a particular source code seems to have been used to create the binary.

It doesn't do actual instruction-level analysis or any of that sort, but it can help to automatize some of the steps that a license compliance engineer so far had to do entirely manually.

Let's hope this is a successful launch and that the project will find contributors to grow beyond the initial feature-set.

Thanks to the nlnet foundation and the Linux Foundation for sponsoring this project. I'm sure it will soon become a vital tool in compliance engineering.

Palm sued over GPL violation in muPDF

Harald Welte — Sun, 06 Dec 2009 19:00:00 GMT

As you can see in this techworld post.

Apparently they are using the GPL licensed muPDF library and link it against their proprietary PDF viewing application. If that is true, then it would be a very straight-forward, FAQ-type violation. muPDF is not LGPL but GPL licensed, thus you cannot create derivative works without licensing them under GPL, too.

The whole license management and even software release management at Palm seems to be very sloppy. For example, based on the object code and disassembly, I can prove that the source code for libpurpleadapter on opensource.palm.com does not (or no longer) correspond to the object code that they ship.

What's particularly surprising is that Palm actually is forcing Artifex to go to court over this issue. You would expect such a straight-forward issue to be resolved fairly quickly and settled out of court, before it ever escalates or turns into a PR disaster.

You would expect a company that is regularly building and releasing firmware images to have an automatic process that packages the source code as part of the build process. In fact, Palm uses OpenEmbedded to build their images, and it is a standard feature of OpenEmbedded to create the corresponding source tarballs for everything it builds.

Furthermore, the Palm kernel contains several binary-only modules that indicate MODULE_LICENSE("GPL") in it - which is clearly not true. If you inquire about the sources, they will respond that they will not provide the sources.

Palm's failure with the App Catalog / Preware to the rescue

Harald Welte — Thu, 03 Dec 2009 19:00:00 GMT

Especially since the 1.3.1 WebOS release, you can easily see the lack of success of the official Palm App Catalog: Only about 60 Applications are available to me from there. Why is that? Because the default setting in the app catalog for any developer uploading the application is "US Only", i.e. people who bought their Pre in other countries like Germany will not see the majority of applications. That's really weird considering how much effort Palm is spending in trying to convince people to write applications for WebOS to increase the attractivity of their product. Now they artificially reduce that for everyone outside the US.

So that's even one more reason to use the alternative package installer called Preware which is available from webos-internals.org. This alternative installer supports any number of feeds. It removes the single-point of failure that an official Palm App catalog creates, and replaces it with a proper community-driven approach. Anyone can write and publish applications, anyone can distribute them to the users, just like anyone is able to distribute/install MacOS, Windows or Linux applications on the PC!

FOSS.in/2009 has started

Harald Welte — Tue, 01 Dec 2009 19:00:00 GMT

I've arrived in India to attend FOSS.in/2009 in Bangalore. It's always great to be here and get in touch with Indian Free Software developers.

Unfortunately I'm suffering from lack of sleep during the flight and jetlag, so I had to miss large parts of the first day of the event :(

My keynote on Ooening up Closed Domains went fine and was apparently fairly well received. The main points being:

There are many areas in computing, beyond the desktop PC, where there's still no freedom and openness due to a lack of Free and Open Source Software
There's no real reason preventing developers to bring FOSS into those areas
As can be seen by existing projects like OpenPCD, OpenBTS, OpenBSC: Very small teams of developers can make a big difference

Leaving for FOSS.in

Harald Welte — Sun, 29 Nov 2009 19:00:00 GMT

I'm just about to go to the airport and leave for FOSS.in/2009. Most of my time there will again be spent working out on GSM protocol analysis, i.e. the airprobe project.

The workout wiki doesn't really have any content yet, and I shall fix that as soon as I get the password for the Workout Wiki (apparently passwords from las year don't work anymore).

It's going to be fun to meet all my Indian friends again - and at the same time I'm happy that a large international community will be present, including Stefan Schmidt, Holger Freyther and Andy Green of Openmoko fame, as well as people like Milosch and Brita Meriac from projects like OpenPCD, OpenBeacon and txtr, James Morris of netfilter/iptables and SELinux, Lennart Poettering of avahi and pulseaudio.

Android Mythbusters (Matt Porter)

Harald Welte — Tue, 03 Nov 2009 19:00:00 GMT

Some weeks ago I was attending Embedded Linux Conference Europe. My personal highlight at this event was the excellent Android Mythbusters presentation given by Matt Porter.

As you may know, Matt Porter was heavily involved in the MIPS and PPC ports of Android, so he and his team have seen the lowest levels of Android, more and deeper than even cellphone manufacturers ever have to look into it.

The slides of his presentation are now available for download. I would personally recommend this as mandatory reading material for everyone who has some interest in Android.

The presentation explains in detail why Android is not what most people refer to when they say Linux. What most people mean when they say Linux is the GNU/Linux system with it's standard userspace tools, not only the kernel.

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

Just one more practical example: You cannot even plug a USB drive to an android system, since /dev/sd* is not an expected device name in their hardcoded hotplug management.

Executive summary: Android is a screwed, hard-coded, non-portable abomination.

I can't wait until somebody rips it apart and replaces the system layer with a standard GNU/Linux distribution with Dalvik and some Android API simulation layer on top. To me, that seems the only way to thoroughly fix the problem...

Palm Pre: Nice UI, severe lack of functionality

Harald Welte — Sun, 25 Oct 2009 19:00:00 GMT

Using the Palm Pre: Everything but an exciting experience :(

During the last week I've started to use my new Palm Pre (for those of you who're living under a rock: The Palm Pre is a smartphone powered by an Operating System called WebOS, which is in turn powered by the Linux kernel and lots of other "standard" Linux programs like glibc, alsa, udev, ...

This adherence to a more standard Linux userland makes the Pre much more attractive than the Android based products out there. Android is reinventing the wheel everywhere, and things that Linux users and developers have been taking for granted during the last five to ten years simply don't exist on Android.

To be honest, the experience was everything but exciting. More about that later. Lets' start with the positive side of things. Yes, I like the device for the following facts:

it's using a not-too-ancient Linux kernel
it uses a fairly standard Linux userland, that
the development tools are also running on Linux (albeit proprietary)
there is an easy way to access the command line of the device via USB
there is software for re-flashing the phone in case it is bricked
the WebOS "distribution" is built using OE and uses the ipk packet format
they did not try to lock the device down from their users. You can easily be root on your phone, install additional ipks from third parties and own your phone

Which is what got me excited and made me buy one of those expensive devices.

However, looking at it from a strict user point of view, I am not very happy with it. It simply lacks so much in functionality that it is not even funny.

No RSS reader

The Nokia web tablets had a working, built-in RSS reader even many years ago when the n770 was released. Given the importance of RSS feeds and blogs in todays web, I'm surprised that webOS does not ship with a RSS reader. To make it even worse, I could not find any third-party RSS reader for it!

No Jabber / ICQ / AIM support

The messenger supports only SMS and Google Talk. WTF?!? What about the millions of Jabber, ICQ, YIM, MSN and other users? Don't you think they want to use their default messenger application with those accounts? This is particularly funny, since they're using libpurple for the actual messenger protocols, which is a LGPL'd library of the pidgin chat client. So the library has all those capabilities, but Palm decided to arbitrarily remove them in their LibpurpleAdapter program. Luckily that one is LGPL'd too, so removing the restriction is relatively easy. But not for a regular user!

Some applications always want to use the cellular network, even when wifi is available

This is particularly stupid when using their e-mail client. While I'm at home or in some other area with wifi coverage, I don't want to squeeze every bit through a high-latency cellular network. Why not simply make that decision a per-application property that the user can set?

Cheap mechanical quality

The mechanical quality is really disappointing for a device that sells for EUR 481. It's much lower than what one is used to from Nokia, Blackberry or HTC devices in a similar price range. As one example, the entire plastic of the device squeaks every time I carefully push one of the keys on the keyboard.

E-Mail client does not support pre-downloaded messages in subscribed IMAP folders

A standard feature that every desktop e-mail program has: Pre-download and cache the message headers for fast listing / browsing through a mailbox. Not on the Palm Pre, where the interactivity of the mail program is close to zero, fetching every bit over a high-latency link. The entire point of using IMAP is to have local copies/caches and to not suffer the latency/interactivity penalty of e.g. webmail!

Calendar offers no integration with standard calendar formats/servers

There is no way how you can simply feed data from ical or xcal calender data into the Palm Pre calendar. You can synchronize with Google and Exchange. WTF? Why do we have [more or less] standard file formats for calendar data? Exactly for enabling interoperability.

No support for standards-compliant address books

You can import your contacts from Facebook, but you cannot import contacts from vcard files, or let's say from a LDAP based address book. Great. So I first need to disclose all the personal contact details from all my contacts, put those into Facebook (into the US jurisdiction and a company that I don't trust) to simply get my contacts on the phone ?!?

Too low battery life

I can barely make it through one day even without making phone calls, simply having the e-mail client running. The battery is too small. I would not mind a bigger/heavier device in exchange for more power!

That is simply the user point of view. I also have many more technical points from a developer perspective, but that is probably better kept for another post. Meanwhile I'm not sure if the Pre was all that much of a good idea. The N900 is coming up next, and will be much closer to the standard Linux userland stack (including X11, GTK, Qt, ...) than the Palm Pre is.

Qualcomm launches Open Source subsidiary

Harald Welte — Sun, 25 Oct 2009 19:00:00 GMT

As several news sites have been reporting (here a report from LinuxDevices.com), Qualcomm has announced the launch of an Open Source Subsidiary.

As usual, I very much welcome such a move. Qualcomm is one of those companies who have a very bad reputation in the Open Source and particularly Linux community. They have so far failed to provide user manuals or other reference documentation for any of their parts. They haven't even managed to publish reference documentation on the external interfaces such as the AT command dialect or the binary shared memory protocols that are used to interface the GSM/CDMA/WCDMA baseband in their product.

So when it comes to an Open Source project that wants to interoperate with Qualcomms hardware, they have so far been doing everything to make that as hard as possible. Neither the community as large has access to the information that it needs, nor do the Qualcomm customers get the respective document under a license that allows them to actually contribute to Open Source projects.

If that documentation was available, or if Qualcomm was actually working on FOSS licensed drivers and contributing those mainline, the support for Qualcomm's hardware in Linux would be much better - resulting in less time to market for companies interested in using Qualcomms parts in their products.

The actual press release does not indicate that this newly-founded subsidiary truly understands this. It speaks of hardware-optimizing the performance of mobile operating systems. That sounds like "we'll take the existing code, make a fork, do non-portable micro-optimizations and ship that to our customers". It does not mention actually contributing to the community or understanding the benefit that the Open Source development model.

I remain to be convinced. Let's hope Qualcomm has scored somebody with a lot of actual hands-on Open Source community experience to advise them properly.

Symbian kernel Open Source release and Tanenbaum

Harald Welte — Sat, 24 Oct 2009 19:00:00 GMT

As most people have noticed by now, The Symbian Foundation has released the source code of their microcernel under an open source license. While any open source release of formerly proprietary software is something I warmly welcome, I doubt that it will take of as an actual open source project.

There's a difference between releasing software under a FOSS license and running a successful FOSS project. The latter involves a sufficiently large community of developers, ways how they can contribute, ...

Especially with special purpose code such as an operating system (kernel) for mobile devices, very few people will show interest as long as there is no actual hardware where they can run the software, without or with custom modifications. Sure, there will be academic interest and people who will look at the source code to find ways to exploit potentially existing security weaknesses, but no community of people who work on it since they will practically use it on their own device.

So what I'd do if I was the Symbian Foundation: I would release an actual mobile phone which is open enough for people to run (modified or unmodified) recompiled parts of the Symbian codebase which are now available as open source. This way it will be much more appealing. However, even at that point, many other parts of the system are (or even will forever be?) closed, limiting the amount of impact. Furthermore, since modified versions cannot be installed on any other regular non-developer phones, the impact of any contribution to the codebase can not be to the benefit of many people. Just compare that with contributing to the mainline Linux kernel, where a contribution will be used on at least almost every server/workstation/laptop after the next distribution (and thus kernel) update.

Another issue that I really was shocked is the following quote by Andrew S. Tanenbaum: 'I would like to congratulate Symbian for not only making the source code of its kernel open source, but also the compiler and simulation environment,' said Andrew S. Tanenbaum'

However, the compiler was not made open source. It is released as proprietary binary code, and is only "free as in beer" for organizations up to 20 employees. So either Tanenbaum did not really look at the hard facts of what was being released, or he was misquoted in a really bad way! That should not have made it into the final release, as it's now a damaging statement for both the Symbian Foundation and Mr. Tanenbaum.

By the way, according to a lwn.net comment thread, they're working on making it able to compile under gcc, and they're actually accepting patches, which is of course great.

Despite my negative comments: I wish them as much luck and success as possible with their new open source Symbian kernel. I personally just am not seeing it turning into a vibrant, community-maintained project - and I hope the founders of the Symbian Foundation did not start the project based on that assumption and will in the end perceive it as a negative experience when evaluating the open source move some years down the road.

One final note: The fact that they chose the EPL as license is really strange, as it prevents exchange of code with the major existing FOSS kernel projects (Linux, *BSD). Not that I think there is much to be exchanged, given the microkernel approach...

FOSS.in CfP running for quite some time

Harald Welte — Wed, 21 Oct 2009 19:00:00 GMT

In case you have been sleeping throughout last week: On October 16, The FOSS.in Call for Participation had been released.

FOSS.in is one of my regular conferences, and probably the only event aside from the Chaos Communication Congress that I managed to visit in five consecutive years. I'm looking forward for this year's incarnation, and I'll definitely do my part to make the event more interesting :)

I hope everyone will now hurry to submit their proposals for talks, workshops and work-outs! It's a collaborative event, and it lives by your contribution.

Letter to the European Commission opposing Oracle's acquisition of MySQL

Harald Welte — Mon, 19 Oct 2009 19:00:00 GMT

As can be found here, Knowledge Ecology International, the Open Rights Group and Richard Stallman have issued a joint letter to the European Commission asking it to disapprove the acquisition of MySQL by Oracle.

I very much welcome this move. There clearly is a conflict of interest between Oracle's own proprietary database software offerings and MySQL. Sure, the community could always fork MySQL, but at what cost? Potential disputes about the trademark, being forced to rename itself, and confusion among the millions of users world wide (well, might just be hundreds of thousands).

Palm Pre GSM model source code available

Harald Welte — Thu, 15 Oct 2009 19:00:00 GMT

Last night I got an e-mail by palm, that following-up to my request, the source code releases for the WebOS 1.1.2 and 1.1.3 releases have been uploaded to opensource.palm.com.

I think the response time was very quick, and I thank them for that. However, still sad that one has to remind them of it. Let's hope with future releases they have a fully automatic process for that.

Just to be very clear: The GPL does not state that you have to automatically have the source code on a web site. But the way how Palm's written offer is phrased, they say that you should visit the website to download the sources. In that case, the web site of course needs to contain the sources...

Additionally they also offer the source code on a storage medium, if you write them snail mail to a specific address - which is a good safeguard since the GPL says it has to be made available on a storage medium commonly used for software interchange.

Palm Pre GSM Version sells in Germany - No corresponding source code

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

Some 4 months ago, I wrote about Palm shipping the Palm Pre CDMA version in a GPL incompliant way. You should assume that the company has learned about their mistakes and created opensource.palm.com as a site to host their source code, compliant with the GPL and other Free Software licenses

Yesterday, the Palm Pre GSM model started to ship in Germany through O2 Telefonica. The WebOS version installed on the device is 1.1.2, and they are doing an OTA upgrade to 1.1.3.

Both of those versions are not available on the Palm opensource website!

Again the same mistake!

I wonder how much this tells us about the development procedures and release management inside Palm. We know they use OpenEmbedded to build their packages and filesystem image. OpenEmbedded can automatically generate the source code tarballs (+ patches), so the entire process of putting them up at the website could and should be automatized. No manual intervention, no mistakes, no license violations.

I have asked my lawyers to send a letter to Palm, demanding immediate release of the complete corresponding source code. If they do not comply, I am prepared to take legal action against O2 who is distributing the devices in Germany. I desperately hope we do not have to escalate to this point. If we go there, I'd better not imagine how upset O2 will be about Palm and how this will affect their business relationship.

It is so easy for Palm to have that source code on their website. We know that for technical reasons (see above). Why are they deliberately exposing themselves to the legal risk? Why are they willing to accept all the negative PR from them not respecting copyright and the GPL?

Please don't get me wrong. I am not set out to continuously complain about Palm. I would like to see more Linux phones. But why do they have to do everything wrong they can do wrong? Why do they not have somebody to advise them on playing nicely with the legal requirements of the technology they use?

Palm Pre privacy invasion

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

One great example of why we need more open source based mobile phones is that we can actually discover all the undocumented "features" of the devices that we use every day.

If I use a device for personal things like my private communication, my scheduling, contact information and similar, then I have to put a certain amount of trust into that device. I trust that the vendor selling this device will provide a device that is safe for me to use and where my information is stored securely.

However, the amount of closedness and control that equipment vendors and GSM operators traditionally have in the mobile world is a big conflict with my personal interest for privacy and security.

You can see this reflected by SIM Toolkit specifications that allow the operator to read and modify your phonebook, or with flash over the air where the operator is able to modify the software on your device.

In fact, in such cases the operators treat the device like they own the device, when in fact the customer has bought the device and owns it.

Since Palm's WebOS is [to a large extend] based on Free / Open Source software, we can analyze in more detail what they are doing. As it was pointed out in this blog post two months ago, they seem to regularly receive information when you were using which application, as well as the GPS coordinates of the phone!

This is outrageous, especially without any way for the user to switch it off - or even better: Have an opt-in, i.e. off by default but who wants it can enable it.

Palm has responded to it, but as that very same posting indicates: The Palm Privacy Policy is not even completely listing the information for which it is applicable.

I don't think Palm is particularly worse than other companies. But the question is: How do we know? How does the user know what his phone wants to communicate to the operator or the manufacturer without his knowledge or authorization? The only two ways I can imagine are:

by having more open source software on the phone, so users can study the code, determine what it is doing and then modify the software to remove such privacy invading surveillance features
by having more people with their own GSM/GPRS networks with projects like OpenBSC, where we can actually see from the network side what the phone is trying to do. Unfortunately GPRS support is still not finished in OpenBSC, but work is ongoing.

Since the Palm Pre units so far (CDMA and GSM) are not locked down, i.e. you can become root and modify the software, it will be much easier to have "custom ROMs" (where the name ROM is stupid since it is flash, ...)

I can only hope that people will quickly come up with custom Linux based firmware images for the Palm excluding the surveillance features.

In addition, everyone should write a letter to Palm, complaining about those features and the fact there is no way to opt out of them.

ST-Ericsson Community Workshop 2009

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

Today, I had the honor to hold the opening keynote of the ST Ericsson Community Workshop 2009.

At this event, ST-Ericsson presented their Nomadik STn8815 SoC, as well as their work on getting the u-boot and kernel ports submitted back into the upstream/mainline projects.

As anyone following the linux-arm-kernel list will have noticed: For the last months, they have worked hard on cleaning up and submitting the code for this SoC. Like many people in the community, I personally appreciate this very much. Finally, ARM SoC vendors actively putting resources to become a "first class" member of the community.

The STn8815 is a ARM926EJ-S core based SoC, including a ST DSP for video codec acceleration as well as a number of standard peripherals such as I2C, SPI, UART, SDIO, etc.

The STn8815 reference software that they released today, includes 100% open source drivers for everything that runs within Linux, inside Linux or on top of Linux on the application processor. The codec implementations inside the DSP are closed source / proprietary. However, the infrastructure to communicate with the DSP, as well as the gstreamer/ffmpeg integration on the Linux side is fully open source.

The attendees of the workshop are receiving the NHK-15 reference boards, which have the STn8815 SoC plus a total of 384MByte NAND flash and 128MByte of DDR memory. There's also a number of peripherals that you expect in such a product, including LCM, SD card slot, Bluetooth, Audio Codec, and Wifi.

Unfortunately, the Wifi driver is closed source. However, the Wifi is a dedicated peripheral component. The use/choice of this Wifi chip on the NHK-15 is probably a bad design choice from an open source point of view. But: This proprietary Wifi does not affect the openness of the actual STn8815 SoC.

Included with the kit for the attendees also a full programming manual as well as register-level specification for the STn8815, as well as the complete schematics of the development board. No NDA required :)

As a summary: I welcome ST-Ericsson to join the Linux community and to provide Open Source friendly solutions, provide the documentation and holding this workshop. However, the STn8815 is already quite 'old' hardware, as it is still ARM9 based - while much of the competition is shipping ARM11 or Cortex-A8 today. Let's hope at some point in the future we will have more competitive hardware with just as much openness.

The txtr e-book reader hardware architecture released

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

Today, the Berlin-baased start-up txtr has released more technical details on their first e-book reader.

They have also released their developer website including a wiki and access to a svn server with sources as well as fedora11 based source and binary RPM's.

What's also interesting is that they have disclosed a hardware block diagram and a PCB footprint on their developer website before the product even starts shipping to the mass market.

As few of you will know, some my friends and colleagues are behind the system-level software and hardware R&D. The electrical engineering is done by Milosch and Brita of bitmanufaktur, with whom I've had the pleasure to work on OpenOCD, OpenPICC, OpenBeacon as well as for a dedicated assignment inside Openmoko. Andy Green of Openmoko kernel + bootloader hacking fame has also been involved... last but not least for porting Qi (originally developed for the never manufactured Openmoko GTA03 based on the Samsung S3C6410) to the Freescale i.MX31.

TI tries to stop alternative operating systems on its calculators by the DMCA

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

Apparently, TI has been trying to use the DMCA and U.S. copyright to stop third-party developers from working on or distributing alternative operating systems for some of their calculators.

The stock OS that TI is shipping uses a cryptographic signature process to prevent the user from booting any non-TI operating system. However, the signature verification was broken and people have managed to run their own software, developed independent from TI's software.

TI is not claiming that the DMCA DRM restrictions are applicable to this case, and that the signature process constitutes a DRM system. This is obviously bogus to any technical person. The TI firmware is not encrypted, and you can copy and run it on other hardware or an emulator if you please. The protection mechanism is rather the other way around: The hardware authenticates the OS.

The Electronic Frontier Foundation has taken up the case and is defending some of the affected people from the community against TI.

As you can see from the EFF letter to TI, the EFF cites a number of precedent cases where the courts have ruled in very similar cases that such mechanism is not a DRM system on the software.

That precedent summarized in the EFF letter is actually very exciting to me. It is directly applicable to all kinds of locked-down devices. Let's assume we're talking about a Linux-powered device like the Tivo, Motorola MAGX phones, the G1 phone (non ADP-Version). They all use GPL Licensed software that is cryptographically signed to prevent the user from exercising his Freedom to run modified versions of the GPL licensed program.

Precedent that indicates that such a system does not constitute DRM as protected by the DMCA means there is a lot more freedom for people to break such systems and freely talk about how it was performed, as well as distribute alternate software images for the respective devices - as long as the code they use is either their own or Free Software and does not contain proprietary bits of the device vendor.

Netgear trying to fool their users with "Open Source Router"

Harald Welte — Tue, 06 Oct 2009 19:00:00 GMT

Two days ago, Netgear has announced the so-called "Open Source" WNR3500L router, together with an equally "Open Source" MyOpenRouter community.

The problem with this Open Source router is: It ships with binary-only kernel modules. Not only is this extremely Closed Source, but it also

has very practical security implications: You can never update your Linux kernel to get the latest security fixes, but have to run vulnerable old kernel versions
is a very questionable legal practise. Netgear as the vendor is simply relying on the fact that none of the authors who have written parts of the kernel against which their binary-only module links will ever make copyright claims against them

One would have hoped that Netgear did thoroughly study the Open Source market that they're trying to address. Apparently they either did not do that, or they chose to ignore the values/rules by which this community works, or they had somebody with limited understanding to advise them on this.

If anyone has a relationship with Netgear and contacts to the product manager responsible for this product, I would like to ask them for an introduction to that product manager. I would be very happy to help them understand the embarrassment and PR impact that they are putting themselves into by releasing an "Open Source" product that is in fact legally questionable and proprietary.

There are people in the various communities (like OpenWRT or OpenMoko) who have a very clear understanding of what it takes to create a true Open Source product to address the Open Source market. Why are they not asking those experts?

Netgear, you can do much better than that!

Palm has noticed their mistakes

Harald Welte — Mon, 05 Oct 2009 19:00:00 GMT

As has been described at TechCrunch, Palm has announced to fix their most prominent issues that many bloggers, including myself, palm has realized that they need to fix some issues with the way they are trying to over-control webOs development.

According to the TechCrunch article, Palm will allow people to write and distribute their own applications (though still you need some kind of URL forward from Palm), and there will be no registration or other fees for people who write open source software for webOs.

This is definitely good news. Let's hope the respective changes will be implemented soon.

Palm gives us a demonstration how they have _not_ understood Open Source

Harald Welte — Tue, 29 Sep 2009 19:00:00 GMT

As you can see in this post by Jamie Zawinski, Palm is doing as much as they can to prevent any Free / Open Source application development on their WebOS.

One really has to ask himself whether they have completely lost their mind. This very Free Software and Open Source development model has created the kernel, libc and many other components of their software stack. So Palm can clearly see and experience the benefit this model has to them.

Yet they chose to deprive all third party developers and their users from that very same freedom by

Not providing a way to install applications from third party websites or even physical storage media, thus
forcing all application programmers to use their application store, and
requiring that those application programmers do not disclose the software source or object code on any other website

This is so screwed, I literally want to bang my head on the wall for this level of stupidity. Can somebody please get some sense into Palm? They seem to have not only forgotten what has made their old PalmOS so successful (thousands of 3rd party apps that anyone could write + distribute), but also seem to lack any understanding of Free and Open Source software.

One week visit with Ben Dooks at Samsung System LSI

Harald Welte — Sat, 26 Sep 2009 19:00:00 GMT

I have just spent one week with Ben Dooks (the mainline Linux kernel maintainer for the Samsung s3c24xx and s3c64xx system-on-a-chip devices) in Korea, meeting extensively with Samsung System LSI and discussing future cooperation and a way to get support for all Samsung SoCs into mainline.

This is a remarkable step, considering that in the past, Samsung was working on their own Linux kernel ports, done in a typical semiconductor-vendor style and not very mainline-compatible - while Ben Dooks was writing his own independent code, accepting contributions from various individuals and companies.

Now everybody was on one table, discussing and defining a strategy and workflow how we can achieve complete support for all Samsung SoCs in the mainline kernel. It was a very constructive discussion, and hopefully we can follow quickly with a just as constructive and productive integration.

I'll report back to this blog once there is some visible result in terms of 'show me the code'.

LiMo foundation analysis explains business value to merge changes upstream

Harald Welte — Thu, 17 Sep 2009 19:00:00 GMT

The LiMo foundation has released an economic analysis that (among other things) explains business and economic reasons for 'deforking', i.e. contributing vendor-specific changes back into the upstream projects.

If you don't want to read the full paper, skip to Chapter 4.3 (Page 20) where they say things like: It is important that mobile industry platform providers engage with the open source communities as early as possible so that platform maintenance strategy is fully aligned with the upstream development agenda of these communities, which is far more cost efficient than managing the entire maintenance burden in-house.

Cancelling my trip to Linux plumbers conference

Harald Welte — Wed, 16 Sep 2009 19:00:00 GMT

I might have told some of you that I'd be visiting Linux Plumbers conference this year, but unfortunately I'm not able to make it, despite earlier planning. There's simply too much work at the moment :(

So to everyone who will be there: Have fun.

My personal conference schedule for the remaining year 2009 is something like this:

ST-Ericsson Open Source Community Workshop 2009

Harald Welte — Tue, 15 Sep 2009 19:00:00 GMT

ST-Ericsson is the maker of an ARM based SoC family called Nomadik. Over the last couple of months they have been working with members of the community to get their support into mainline Linux and u-boot.

They have recently announced the ST-Ericsson Community Workshop 2009, a small event limited to only 25 seats, where members of the community, together with ST-Ericsson present on the development of GNU/Linux on their Nomadik SoC platform.

The workshop registration fee is 200 EUR, but it includes a full NHK-15 development kit for the Nomadik platform!

I really think ST-Ericsson is doing the right thing, reaching out to the community, actively trying to get their code mainline, plus providing subsidized development boards at a to interested community members.

If you're interested, make sure you register soon, seats are limited...

FOSS.in turning from Linux/FOSS only event into more general hacker conference

Harald Welte — Sat, 12 Sep 2009 19:00:00 GMT

As can be seen from the FOSS.in/2009 "Omelette Post", in addition to the regular FOSS.in schedule until 5pm every day, there will be additional hacker talks until 10.30pm, which might not necessarily be directly connected with FOSS.

Since I'm personally a member of both the hacker community (in the very specific sense of working and uncovering weaknesses in communication systems) as well as a 100% Free and Open Source person, I obviously like this kind of combination. To me, both go hand in hand - even though I know not everyone will have the same opinion.

In the end, learning about and playing freely with technology is what both communities want to do.

I'm looking forward to see the FOSS.in CfP...

The reason for my trip to Korea: Samsung and mainline Linux

Harald Welte — Thu, 27 Aug 2009 19:00:00 GMT

Some weeks ago, I wrote that I'll be again in Korea without mentioning any details. As you can see from this and this mailing list posting to linux-arm-kernel, I have the pleasure of assisting the Linux kernel team at Samsung System LSI with adopting a development model that follows (and contributes to) mainline Linux.

Despite all the enthusiasm this might now create among users of the various Samsung ARM SoC's, I would like to keep the expectations low for now. After all, "talk is cheap, show me the code", I will only blog again about this once we see the first code submissions coming from the Samsung team.

I'd like to thank Samsung System LSI for their warm welcome and their willingness to change. I hope the community will understand what a big step it is for an organization like this, and will take it easy in case the first code submissions still have some glitches here and there. After all, everyone of us has started at some point.

GPL case in Denmark potentially involving NDS Viasat A/S and/or Samsung

Harald Welte — Tue, 18 Aug 2009 19:00:00 GMT

As you can at this website, somebody has discovered what seems very clear GPL violations in a device called "Samsung DSB-H670N". At the moment it is not clear who is the actual cause of the GPL violation.

However, what is outstanding about this case is that an individual on its own tries to bring the respective companies into compliance. I think it serves as a great example what somebody can do even if he is not one of the clear copyright holders and just keeps insisting enough and communicating with the companies involved.

I'm definitely looking forward to see how this turns out. gpl-violations was not involved in any sort. We're continuing with many cases at any time, so don't worry. I just thought this particular action is worth mentioning to the interested reader. Maybe some other people get inspired by it and also stand up for their rights to the source code of GPL licensed programs.

HAR2009 is over

Harald Welte — Sun, 16 Aug 2009 19:00:00 GMT

Running our own GSM network at HAR 2009 has kept me too busy to actually attend any lectures myself - apart from the A5/1 lecture in the GSM track just after my own presentations on OpenBSC and airprobe. So I'm hoping for the recordings to be available in some non-proprietary format soon. Apparently all they have now is some website with flash videos, something I'd almost call an abomination.

In any case, thanks once again to the HAR Organizers for obtaining the GSM test license. Thanks to the Agenschap Telecom for actually granting us such a license. And thanks to the many helping hands from the OpenBSC community, as well as the several hundreds of people who have tested the GSM network 204-42.

We shut down our operations at 2009-08-16 at 16:00 CEST. There were no complaints of either the regulatory authority nor the commercial network operators during the event.

We have complete debug logs of OpenBSC, as well as pcap files of all signalling data. In the weeks to come, we'll be working on extensive statistics on network usage / load, as well as relationship graphs i.e. who called/texted whom.

After a 7 hour car ride to my home in Berlin, and an 8 hour stop-over to pack my suitcases, I'm now currently in Helsinki enroute to Seoul, Korea. Following-up to my last trip in January, I'm happy to be able to visit the country at a time of much more pleasant weather (26-30 centigrade) this time.

I'm very excited about my work there in the coming months. As soon as there's anything I can state publicly about it, I'll keep you posted :)

Linux-Kongress date change - now longer collides with Linux Plumbers

Harald Welte — Sat, 25 Jul 2009 19:00:00 GMT

As I have just received today, Linux Kongress 2009 has shifted its dates to October 27 through October 30 (and changed the Location from Hamburg to Dresden).

This is good news, since it no longer collides with Linux Plumbers Conference 2009 on September 23rd through 25th. I guess that many speakers and some attendees would otherwise have ran into scheduling problems - with many preferring Linux Plumbers.

Also, the Call for Papers is out, it runs until August 31st, i.e. you (yes you, the reader!) have more than four weeks of time to decide what kind of topic you want to talk about :)