dw2

31 August 2008

Intellectual property and open source

Filed under: books, GPL, Intellectual property, Open Source — David Wood @ 7:17 pm

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.

27 July 2008

Understanding Open Source Licensing

Filed under: CPL, EPL, GPL, Open Source, OSiM, OSL — David Wood @ 8:18 pm

“What’s the best book to read for an introduction to Open Source?”

I’ve already given one set of answers to this question, in my article, “Clear thinking about open source“. One reply to that article – from Joel West, a writer and researcher on Open Innovation and Open Source whose advice I value – urged me to include one more book in my reading list: Lawrence Rosen’s “Open Source Licensing: software freedom and intellectual property law“. This weekend I’ve finished reading it. And indeed, I do now endorse it as being clearly written yet also highly insightful.

Initally, I tended to shy away from this book, instead preferring the book by Heather Meeker that I covered in my earlier article. Both books focus on open source licensing issues, but Meeker’s was published this year, whereas Rosen’s dates from 2004. So Rosen’s book makes no mention of GPL v3, or Sun’s experience with open-sourcing Java, or even the Eclipse Public License (EPL) which the Symbian Foundation is likely to adopt. That makes Rosen’s book appear out of date. However, I realised that one license which the book does cover (comprehensively) is the Common Public License (CPL) which is the precursor of the EPL and which differs from the EPL in very few places. Reassured, I dipped into the book – and then could hardly put it down.

In summary, I now recommend both the Meeker book and the Rosen book for their coverage of open source licensing. They complement each other nicely. There’s a bit of overlap, but also lots of good material in each book that you won’t find in the other.

Specifically, here are a few of the “aha”s or other learnings I took away from Rosen’s book:

1.) The ten principles of the Open Source Definition are actually quite hard to understand in places (this comment came as a relief to me, since I had been thinking the same thing).

2.) Patents and Copyrights should be approached as parallel sets of legal principle – the former applicable to ideas, and the latter to expressions of ideas. That’s a far better approach than initially just thinking about Copyrights, and then trying to squeeze in considerations about Patents at the end.

3.) One of the key differences between different open source licenses is in the treatment of patent licenses – and in the different circumstances in which patent licenses (and/or copyright licenses) can be withdrawn in the wake of various kinds of patent infringement suits. There’s a tricky balance that has to be drawn between the needs of both licensor and licensee concerning the continuing value of their respective patent portfolios.

4.) One piece of license evolution covered in the book – the difference between v2.0 and v2.1 of the Open Software License (OSL) – closely mirrors the principal difference between the CPL and the EPL: it’s a reduction in the circumstances in which a patent license can be withdrawn when a licensee brings a separate patent infringement case against the licensor.

5.) The insistence in GPL v2 about not being compatible with other licenses that introduce additional restrictions (even restrictions that the initial drafters of GPL v2 had not considered), is a real drawback of that license, since it unnecessarily hinders aggregation of code written under similar but different licenses. (Possible restrictions that have emerged more recently include provisions for defence against patent infringement lawsuits or to protect the licensor’s trademarks.)

6.) “… sections of the LGPL are an inpenetrable maze of technological babble. They should not be in a general purpose software license.” (page 124)

7.) Disclaimers of liability that are generally written into open source licenses may be overridden by general consumer legislation. Recognising this, the CPL (and hence the EPL) introduces a clause that allocates particular responsibility to “commercial contributors” to defend and indemnify all other contributors against losses, damages, or costs.

8.) One possible way for a company to make money from software is via the mechanism Rosen calls “Eventual Source”: code is released as open source after some delay period, but recipients can elect to pay an early access license fee to be able to work with the code (under a non-open source license) ahead of its release as open source.

I’ve still got lots of questions about open source licensing (for example, about the prospects for wider adoption of GPL v3, and about how successful Rosen’s own preferred OSL is likely to be in the longer run). I’ll be attending the Open Source in Mobile conference in Berlin in September, when I hope to find out more answers! (And no doubt there will be new questions too…)

6 July 2008

Clear thinking about open source

Filed under: GPL, Open Source — David Wood @ 9:12 am

“What’s the best book to read for an introduction to Open Source?” That’s a question I’ve been asked several times in the last fortnight – as many of my colleagues in and around Symbian have realised that Open Source is a more complex and more intriguing subject than they first thought. (Of course, the announcements of 24 June have had something to do with this increased interest level.)

I’m still not sure how to answer that question. Over the years, I’ve read lots of books about Open Source – but with the passage of time, I’ve forgotten what I’ve learnt from each book.

Two books that stick out in my mind, through the veil of intervening years, as particularly enjoyable are:

Of these, the latter stands out as an especially easy and engrossing read. (It also happens to be the first serious book read independently by all three members of my immediate family – my wife, my son, and myself.) But when I pulled these two books from my bookshelf the other day and checked their inside cover, where I usually record the date when I purchase a book, I realised I had read them both as long ago as 2001. And Open Source has moved on a lot since that time. So while both these books are great sources of historical insight, readers will need to turn elsewhere for more up-to-date info.

A more recent book I remember making a big impact on my thinking at the time (2005, according to the inside cover) was:

Flicking through that book again just now, I see so many interesting snippets in it that I’m tempted to try to squeeze it back into my already hopelessly overfull reading in-box, for a second-time-round read. But even a 2005 book is dated.

That brings me to the book I’ve just finished reading:

Heather Meeker is Co-Managing Shareholder at the East Palo Alto law firm Greenberg Traurig. I first saw Heather speak at the Olswang “Open Source Summit” in London in November 2007. I was impressed at the time by the clarity of her grasp of the legal issues surrounding Open Source. Heather’s book has the same fine qualities:

  • It’s primarily exposition (education) rather than advocacy (evangelism)
  • I had many “of course!” and “aha!” moments while reading it
  • There are some particularly clear diagrams
  • Crucially, the language is easy to read
  • Also crucially, the book is comfortable both with legal matters and with technical matters (eg aspects of C and C++).

So I would say, this is the book to read, for a good account of the legal aspects surrounding open source.

One part that really shines comes about three quarters of the way through the book. It’s by far the best analysis I’ve read of “The border dispute of GPL2”. The question in the minds of many commercially-driven companies, of course, is whether they risk having to publish the source code of any of their own software that happens to interact with code (such as the Linux kernel) released under GPL. The book makes it strikingly clear that the commercial risks aren’t just because the original drafters of the GPL are philosophically opposed to closed source software. They’re also because of some deep-rooted ambiguities inside the license itself. To quote from page 188:

This is why attorneys who read the GPL quickly come to the conclusion that this phrase – upon which entire companies and development projects depend – is irretrievably vague.

And again from the footnote to page 189:

To provide context for nonlawyer readers, drafting unique (in the document) and unambiguous definitions is considered a baseline lawyering skill in transactional practice. Doing otherwise is generally a sign that the drafter is not a lawyer or, more precisely, does not have baseline drafting skills. If this seems harsh, consider that many programming languages require one, and only one, definition of a user-defined variable. (Some languages allow multiple definitions, or “overloading”, but using this feature requires intimate knowledge of the rules used by the compiler or interpreter to resolve them.) Failing to understand these rules properly creates bugs. So, in a sense, multiple or conflicting definitions [such as occur in the GPL] in a legal document, without express rules to resolve them, is a “bug” in drafting.

I can well imagine senior managers in mobile phone companies getting more and more worried as they read this book, finding more and more reasons, chapter by chapter (not just the chapter on the Border Dispute), to fear eventual legal cases against them, if they have code of their own in a phone that interacts with a GPL kernel.

Perhaps inevitably, the book has less to say about the EPL – which is the license to be used by the Symbian Foundation. After all, GPL is (the book suggests) the “most widely used license on the planet”. But the EPL has many fewer ambiguities, and is significantly more business-friendly.

Does v3 of GPL change matters? Not really. First, as the final chapters of the book make clear, many of the deep-rooted ambiguities remain, despite the massive (and impressive) work done by the drafting team for v3. Second, Linux is likely to remain on v2 GPL for the foreseeable future.

Blog at WordPress.com.