Still Spinning

(This post disappeared from the blog a couple of days ago. I don't know why. It's back now.)

A little over a week ago, I posted some comments on Karsten Nohl's public A5/1 attack and the GSMA's response. Reuters & MSNBC think that carrying what is essentially a GSMA press release should somehow pass for journalism. (Thanks, Foneswitch, for bringing this to my attention.) I thought that the links to ads for cellular service were a particularly ironic touch. I hope a real person actually thought to put them there. Irony aside, two things about this press release strike me.

First, the GSMA is admitting that there are simple things that carriers can do to make their networks more secure and that they just haven't bothered doing those things yet. If that's really the case, then Dr. Nohl's public announcements are already having their intended effect of forcing the GSMA to pay attention the security security practices of its members. I'd really love to hear the specifics of these improvements, though, since traces of transactions in most EU and US networks show that they are already just about as secure as their current equipment allows. There's not much left to do.

Second, many GSM networks in other parts of the world, outside the US and EU, are not encrypted at all, not even with A5/2. Many governments simply do not allow their publics to use encrypted cellular networks. This is an issue that is not addressed by Dr. Nohl's project, by the GSMA or by the various media outlets who are providing free publicity for the GSMA's damage control campaign. For nearly half of the world's GSM users, all this bickering and posturing over A5 cracking is irrelevant because they are not even allowed that level of security. Worse yet, most of them probably don't even know that. That's a much bigger story that doesn't get covered.

Given all the recent spin, I think we should probably stop listening to the GSMA and just find out for ourselves how these networks are configured. In that spirit, I would like to propose a new crowd-sourcing project on GSM security: a public catalog of the security and encryption policies of all of the world's public cellular networks. A good place to put this might be somewhere in Wikipedia, where it will be very hard to censor once published. If anyone is interested in organizing something like that, please let me know.

Fun Facts about Copyright Law

I am not a lawyer and this is not legal advice. The point of this post is to help you understand your rights well enough to know when to call a lawyer and to help avoid ambiguities that will lead to wasteful conflict later. The topic here is US copyright law, specifically as it applies to computer software written by independent contractors.

Under US law, copyright originates with the author. If you write something, you hold the copyright until it expires or until you transfer it to another party. This transfer can happen in two ways, either through an explicit transfer agreement or through a "work for hire" agreement.

The explicit transfer is easy to understand, but can suffer complications. Suppose you are an independent contractor who writes software for a living. A client hires you for a project. You have a consulting contract that states that all copyrights for the commissioned work are transferred to the client. Done. Right? Maybe, maybe not.

For example, what if the software you deliver includes a library that you wrote several years ago for which you hold copyrights? You can save yourself a lot of grief if you make it clear to your client, in the agreement and in copyright notices on the code itself, that the client will not receive copyrights to that previous work. Sure, if there's a lawsuit, you can present evidence that the prior work existed before the agreement and therefore was not commissioned by the client. That will take several months and cost several tens of thousands of dollars and even then you risk a bad outcome, even if you are in the right, since the legal process has a lot more to do with how fast you can write checks than where the facts actually fall. It is much better to make the history and status of that prior work clear before you even start. And that's just one example of the kind of thing that can go wrong.

The work-for-hire transfer is a little trickier. It really has no place in the software world. The work-for-hire concept is based on the idea that work performed as part of a master-servant relationship belongs to the master, so copyrights to works produced in such a relationship transfer automatically. In the situation of the independent software contractor there are two problems with the work-for-hire concept.

First, in today's world a master-servant relationship is usually interpreted to mean regular employment, not contracting. If you are an independent contractor or consultant, then you are probably not performing work for hire, regardless of what any contract might say. Just calling something "work for hire" in a contract does not automatically make it so.

Second, the automatic copyright assignment of a work for hire relationship does not apply to software. US copyright law transfers copyrights for certain specific classes of works if they are commission as part of a work for hire agreement. The important point, though, is that computer software is not in that list of specific classes of work. Therefore, even under a work for hire agreement, copyrights to computer software remain with the author in the absence of an explicit copyright transfer. Let's pause for a minute while all the software developers (and their managers) go look at their employment agreements.

The chances are very good that any client who is asking you to sign a consulting agreement will just assume that paying you money automatically creates a work-for-hire relationship and that such a relationship automatically applies to software. Neither of these assumptions is true and the facts of the matter, as seen by a court, may include a number of factors, such as your degree of independence in your work, how you bill the client, etc. You will probably prevail, but it would be far better to avoid the inhumane machinery of the legal process by starting with clear contract language defining the copyright status of your work.

Kestrel's standing rule for work on cellular projects is that we will hold all copyrights to all source code that we produce. That is not negotiable; either the client agrees or we refuse the job. We make this clear in our communications with clients, put it in every statement of work and print it on our quotes and invoices. Much of that code goes into OpenBTS and those copyrights are reassigned to the Free Software Foundation, which offers a whole raft of advantages that will be fodder for a future post.