“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:
- “Rebel Code: Linux and the Open Source Revolution” by Glyn Moody
- “Just for Fun: The Story of an Accidental Revolutionary” by David Diamond and Linus Torvalds.
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:
- “The Success of Open Source” by Steven Weber.
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:
- “The Open Source Alternative: Understanding Risks and Leveraging Opportunities” by Heather Meeker.
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.