I’ve just finished reading a third book, within two months, on the topic of open source licensing. The three books are:
- Heather Meeker’s “The Open Source Alternative: Understanding Risks and Leveraging Opportunities” – which I reviewed here;
- Lawrence Rosen’s “Open Source Licensing: software freedom and intellectual property law” – which I reviewed here;
- 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.
dw2 
Hi,
I’d argue that the GPL is unquestionably ambiguous and that the question of dynamic linking with GPL’d code is an extremely grey area. That’s because (among other things) it is a matter of law and has not been tested in court enough for a clear precedent to be set.
It really doesn’t matter what Richard Stallman or Linus Torvalds think or state. Whether or not something is considered a derived work will be down to the details of specific cases until some clear guidelines are established through precedent.
The advantage Linus has over RS is that people are likely to accept his interpretation in the case of linking to the Linux kernel since he is one of the copyright owners that would have to prosecute any infringement.
Mark
P.S. I’m also very pleased that the Symbian Foundation has decided to avoid all of this by choosing the EPL.
Comment by m_p_wilcox — 1 September 2008 @ 2:03 pm
Hi,
I’d argue that the GPL is unquestionably ambiguous and that the question of dynamic linking with GPL’d code is an extremely grey area. That’s because (among other things) it is a matter of law and has not been tested in court enough for a clear precedent to be set.
It really doesn’t matter what Richard Stallman or Linus Torvalds think or state. Whether or not something is considered a derived work will be down to the details of specific cases until some clear guidelines are established through precedent.
The advantage Linus has over RS is that people are likely to accept his interpretation in the case of linking to the Linux kernel since he is one of the copyright owners that would have to prosecute any infringement.
Mark
P.S. I’m also very pleased that the Symbian Foundation has decided to avoid all of this by choosing the EPL.
Comment by m_p_wilcox — 1 September 2008 @ 2:03 pm
RMS’ opinion doesn’t really matter, since he’s not a lawyer.
It turns out the founding counsel of the Open Source Initiative, Larry Rosen, actually is a lawyer. And he’s written several times that no court is going to interpret “derivative work” the way RMS does, because it is a specific legal term with a specific legal meaning. Rosen made this point back in 2000, so it’s hardly new.
The real problem is that the FSF is doing everything it can to avoid a court test that would set a precedent. Does this means that it fears it would lose? Or is this just FUD to get people to do what FSF asks rather than what the contract says?
Comment by Joel West — 3 September 2008 @ 7:14 am
RMS’ opinion doesn’t really matter, since he’s not a lawyer.
It turns out the founding counsel of the Open Source Initiative, Larry Rosen, actually is a lawyer. And he’s written several times that no court is going to interpret “derivative work” the way RMS does, because it is a specific legal term with a specific legal meaning. Rosen made this point back in 2000, so it’s hardly new.
The real problem is that the FSF is doing everything it can to avoid a court test that would set a precedent. Does this means that it fears it would lose? Or is this just FUD to get people to do what FSF asks rather than what the contract says?
Comment by Joel West — 3 September 2008 @ 7:14 am
given all your recent posts about what you’re been reading, I’m beginning to wonder if you did any research on open source prior to making the Symbian Foundation decision. that’s a pretty scary thought.
Comment by ginswizzle — 6 September 2008 @ 11:47 am
given all your recent posts about what you’re been reading, I’m beginning to wonder if you did any research on open source prior to making the Symbian Foundation decision. that’s a pretty scary thought.
Comment by ginswizzle — 6 September 2008 @ 11:47 am
Hi Jon,
>"given all your recent posts about what you're been reading, I'm beginning to wonder if you did any research on open source prior to making the Symbian Foundation decision"
Sorry for giving the wrong impression! Those who know me better know that I’ve had been seriously tracking open source issues since (at least) June 1998, when the phrase “The Cathedral and the Bazaar” first cropped up on Symbian’s primary internal discussion database.
My philosophy as regards knowledge is that, for an important and complex topic (such as Open Source), it’s never wise to rest on your laurels and think that you’ve nothing more to learn. That’s why I’m continuing to read new books on Open Source, to challenge and improve my understanding. (And that’s also why I’ll be at the Open Source in Mobile conference in Berlin in around 10 days time.)
// dw2-0
Comment by David Wood — 6 September 2008 @ 12:51 pm
Hi Jon,
>"given all your recent posts about what you're been reading, I'm beginning to wonder if you did any research on open source prior to making the Symbian Foundation decision"
Sorry for giving the wrong impression! Those who know me better know that I’ve had been seriously tracking open source issues since (at least) June 1998, when the phrase “The Cathedral and the Bazaar” first cropped up on Symbian’s primary internal discussion database.
My philosophy as regards knowledge is that, for an important and complex topic (such as Open Source), it’s never wise to rest on your laurels and think that you’ve nothing more to learn. That’s why I’m continuing to read new books on Open Source, to challenge and improve my understanding. (And that’s also why I’ll be at the Open Source in Mobile conference in Berlin in around 10 days time.)
// dw2-0
Comment by David Wood — 6 September 2008 @ 12:51 pm
It is perhaps a little presumptuous of me but I’d suggest that you can also ignore Larry Rosen’s opinion, despite the fact that he is a lawyer that understands copyright. I suggest this because a reading of his published works (including the article you link Joel) and contributions to various online discussions suggest that he doesn’t have a deep enough understanding of software to make that call.
I think I could easily create examples on Symbian OS where only dynamic linking is involved that are unquestionably “derived works”, while it could be quite reasonable to statically link a library and have the resulting product as an original work. Ironically one of the key words is the “inheritance” that Larry chooses to describe what happens when linked software falls under the GPL.
Except of course in my case I’m talking about inheritance in C++. If I sub-class an exisiting plug-in type that is provided in a dynamic link library I could add a single extra function that uses some of the existing ones. I believe my contribution would be (without question) a derived work (it would be like adding an extra paragraph in the middle of a book that referenced other parts – completely meaningless without the rest of the book).
On the other hand, I could statically link to a library and only use a single simple function in it. My work would undoubtedly not be a derived work (and note that I don’t need to modify the original code of the library to statically link to it, despite what Larry suggests).
I think the fairly common understanding the user side Linux code is OK while device drivers and kernel modules is a grey area is pretty accurate. A Linux device driver cannot work without the driver framework (GPL’d) that it is written for. Similarly for a file system plug-in module. However, in both those cases, the amount of original code written is likely to be significantly greater than the amount of framework code used.
Existing copyright law and precedent doesn’t really cover this situation well as far as I am aware. It needs to be tested in court. It seems fairly likely (call me cynical here) that if there is a test it will probably come down on the side of some big corporate that’s not playing be the rules because they can afford much better lawyers (and the judge and jury – if there is one – won’t understand software sufficiently to make an informed decision either).
Mark
Comment by m_p_wilcox — 15 September 2008 @ 3:19 pm
It is perhaps a little presumptuous of me but I’d suggest that you can also ignore Larry Rosen’s opinion, despite the fact that he is a lawyer that understands copyright. I suggest this because a reading of his published works (including the article you link Joel) and contributions to various online discussions suggest that he doesn’t have a deep enough understanding of software to make that call.
I think I could easily create examples on Symbian OS where only dynamic linking is involved that are unquestionably “derived works”, while it could be quite reasonable to statically link a library and have the resulting product as an original work. Ironically one of the key words is the “inheritance” that Larry chooses to describe what happens when linked software falls under the GPL.
Except of course in my case I’m talking about inheritance in C++. If I sub-class an exisiting plug-in type that is provided in a dynamic link library I could add a single extra function that uses some of the existing ones. I believe my contribution would be (without question) a derived work (it would be like adding an extra paragraph in the middle of a book that referenced other parts – completely meaningless without the rest of the book).
On the other hand, I could statically link to a library and only use a single simple function in it. My work would undoubtedly not be a derived work (and note that I don’t need to modify the original code of the library to statically link to it, despite what Larry suggests).
I think the fairly common understanding the user side Linux code is OK while device drivers and kernel modules is a grey area is pretty accurate. A Linux device driver cannot work without the driver framework (GPL’d) that it is written for. Similarly for a file system plug-in module. However, in both those cases, the amount of original code written is likely to be significantly greater than the amount of framework code used.
Existing copyright law and precedent doesn’t really cover this situation well as far as I am aware. It needs to be tested in court. It seems fairly likely (call me cynical here) that if there is a test it will probably come down on the side of some big corporate that’s not playing be the rules because they can afford much better lawyers (and the judge and jury – if there is one – won’t understand software sufficiently to make an informed decision either).
Mark
Comment by m_p_wilcox — 15 September 2008 @ 3:19 pm