dw2

I’ve just finished reading a third book, within two months, on the topic of open source licensing. The three books are:

1. Heather Meeker’s “The Open Source Alternative: Understanding Risks and Leveraging Opportunities” – which I reviewed here;
2. Lawrence Rosen’s “Open Source Licensing: software freedom and intellectual property law” – which I reviewed here;
3. Van Lindberg’s “Intellectual property and open source: a practical guide to protecting code“.

My headline summary is that all three books are well worth reading. They overlap to an extent, but they come at their shared subject from very different viewpoints, so each book has lots of good material that you won’t find in the others.

Van Lindberg targets his book at software engineers. He uses many analogies between legal concepts and deeply technical software engineering concepts. For example (to give a flavour of many of the clever pieces of writing in the book):

“One way to think about private goods is to analogize them to locks or mutexes in a multithreaded program. A number of different threads may want to use a protected resource, but control of the lock around the resource is rivalrous…”

Somewhat unexpectedly, the first half of the book hardly mentions open source. There’s good reason for this. The first seven chapters of the book cover the basic principles of intellectual property (IP), including patents, copyrights, trademarks, trade secrets, licences, and contracts. I found the very first chapter to be particularly engrossing, as it set out the philosophical foundations for IP. Van Lindberg highlighted the utilitarian justification for IP, in terms of legal measures to counter what would otherwise be two sorts of market failures:

• “The cost of creating knowledge is high, but the cost of consuming it is low…. Therefore there is a societal incentive to not create as much knowledge as we would ideally like to have” (hence the utilitarian rationale for copyright)
• “Secrets are more valuable to you personally, but shared knowledge is more valuable to society…. The resource is valuable to you because you have a key, but it is worthless to everyone else” (hence the utilitarian rationale for patents).

As I said, the very first chapter was particularly engrossing, but I thought the other early chapters dragged a bit. Although all the material was interesting, there were rather too many details for my liking.

Chapter eight (“The economic and legal foundations of open source software”) went back to philosophical principles, in an attempt to pinpoint what makes open source different from proprietary software. The difference, according to Van Lindberg, is that:

• Proprietary software is driven by corporate business goals (which inevitably involve profit-maximisation, and therefore – he claimed – a tension between what’s best for the customers and what’s best for the shareholders)
• Open source software is driven by cooperative goals, in which the goals of the customers have primacy. (Note the difference between the similar-looking words corporate and cooperative.)

This chapter also runs a pretty compelling extended comparison between proprietary software and open source software, on the one hand, and banks and credit unions, on the other hand. Again, the first member of each pair is driven by shareholder goals, whereas the second member of each pair is driven by customer goals (the legal owners are the same people as the customers).

The primary task of open source licences, according to this analysis, is to support cooperation. In more detail, Van Lindberg says that open source licences are intended to solve the “Programmer’s Dilemma” version of the famous and well-known “Prisoner’s Dilemma” problem from game theory:

“Open source licences serve two functions in a game-theoretic context. First, they allow programmers to signal their cooperative intentions to each other. By placing their code under a licence that allows cooperation, programmers indicate to their peers that they are willing to participate in a cooperative solution. Second… licences are based in copyright law, which allows the original developer to dictate (to some extent) the users and uses of his code. The legal penalties associated with copyright violations change the decision matrix for other programmers, leading to a stable cooperative (and optimal) solution.”

This (like everything else in the book) is thought-provoking. But I’m not fully convinced. I think this puts too much importance onto the licence aspect of open source. Yes, picking a good licence is important – but it’s insufficient to guarantee the kind of cooperative behaviour that will make an open source project a real success. And as I’ve argued elsewhere, picking the right licence is no guarantee against the software fragmenting. But despite this quibble, I still think the ideas in this chapter deserve wide readership.

The second half of the book changes gear. With the first eight chapters having carefully outlined the underlying legal framework, the remaining six chapters walk through the kind of real-life IP concerns that will face someone (whether an individual developer, or a company) who wants to become involved in an open source project:

• Issues with standard employment contracts that probably specify that everything you work on – even in your spare time – belongs to your company, and which you therefore are not free to assign to an open source project
• General guidelines on choosing between some of the more popular open source licences
• Legal complications over how to accept patches and other contributions, from outsiders, into your project
• Particular issues with the GPL
• Reverse engineering
• Creating a non-profit organisation or foundation (recommended if your project becomes larger).

There’s lots of good advice here. Every chapter of this part of the book has important material – but I was slightly disappointed with some parts. For example, given the careful attention to patents in the first half of the book (where two chapters were devoted to this topic), I was expecting more analysis of how some of the major open source licences differ in their approach to patent licences and patent retaliation clauses. On reflection, that’s something that the other two books (ie by Meeker and Rosen) handle better.

The chapter on the issues with the GPL confirmed and extended the opinion about that licence which I’d picked up from my previous reading: the interpretation of the GPL is subject to great uncertainty over ambiguities. The chapter includes a lengthy “Questions and answers” section, to which the answer to nearly every question is “Maybe” or “It depends”. (Apart from the last question, which is “Can I depend on the answers in this Q&A to keep me out of trouble?”; the answer to this is “No, this is our best understanding of copyright law as it stands right now, but it could change tomorrow – and nobody really knows…”)

Giving more evidence for this view of the ambiguities surrounding the GPL, Van Lindberg mentions an essay by Matt Asay, “A Funny Thing Happened on the Way to the Market“. Here’s an extract from that essay:

“I asked two prominent representatives of the Free Software Foundation – Eben Moglen, general counsel, and Richard Stallman, founder – to clarify thorny issues of linkage to GPL code, and came up with two divergent opinions on derivative works in specific contexts…”

“…it is telling how widely their responses diverge – there appear to be no definitive answers to the question of what constitutes a derivative work under the GPL, not even from the holders of the licenses in question.”

This looks decisive, but it could be argued that this quote from Matt Asay is itself misleading, since Matt’s article goes on to state that:

“Fortunately, as I will detail below, this issue has largely gone away, as it has become accepted practice to dynamically link to GPL code [without that code becoming part of the GPL program]. Linus Torvalds helped to build momentum for such a reading of the GPL. While some argue that kernel modules, including device drivers, must be GPL, Torvalds has stated: This [GPL] copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall under the heading of ‘derived work.’“

However, Van Lindberg seems to be right that the official FAQ about the GPL, maintained by the Free Software Foundation, advocates a stricter interpretation:

“Q: Can I release a non-free program that’s designed to load a GPL-covered plug-in?

“A: It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

“If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

“If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

“Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.”

Do these ambiguities over the GPL really matter? It’s hard to be sure, but I’m personally glad that the Symbian Foundation plans to adopt a licence – the EPL – which avoids these issues.

I’m also glad to have taken the time to read this book – it’s helped my understanding grow, in many ways.

Footnote: My thanks go to Moore Nebraska for drawing my attention to the Van Lindberg book.