No, we aren’t rerunning blog posts during the summer. We published a review by Romuald Restout of this book last January. It’s worth reading, but I hadn’t paid much attention to it, as it didn’t seem to me that he was working in the trenches of consuming and creating open-source software. It turns out many developers will get a lot out of this book as well. Here’s my perspective.
I’ve been working with open-source software for over ten years now. Which means that I’ve been working with open-source licenses for the same time as well. And right from the first time I read through the GPL, I wondered how these licenses were treated where it matters, in the courts. It reminded me of a course I took in university on American Constitutional Law (as an elective – IANAL).
The text of the constitution was provided in an appendix, but we rarely referred to it, instead studying supreme court decisions, and occasionally looking at historical context (i.e., the facts of the case). I was more interested in the interpretation and commentary than the letter of the law, but hadn’t found a coherent, not too comprehensive treatment of the subject.
There are other sources, but they weren’t what I was looking for. On one hand, I’ve got a copy of a slightly older textbook on internet law (about 5 years old) edited by Michael Geist, professor specializing in IP at the University of Ottawa. But it’s obviously for law students and practitioners, and I haven’t summoned the motivation or time to start wading through it.
On the other side of the attention-span spectrum are blogs like Groklaw, but I was looking for a coherent treatment, a 10,000-foot view.
My search hasn’t ended, but it’s advanced a step or two, in the form of a recent O’Reilly book by attorney/software engineer Van Lindberg called Intellectual Property and Open Source: A Practical Guide to Protecting Code. It covers the basics, such as the differences between and reasons for patents, copyrights, trademarks, and trade secrets. But it goes into useful depth in each area as well, covering various cases to explain the nuances of the law.
Many different sections came together in one particular case, placed in the chapter on why you (as a software developer) should not write your own license, covering Jacobsen v. Katzer. This was the case where the founders of the Java Model Railroad Interface project (JMRI) were hit with a patent infringement suit by a company called KAM. JMRI had released code under the Artistic License. KAM built some proprietary products with that code, filed for patents, and then sued JMRI for infringing such patents. The essence is that the language of the Artistic License made it interpretable only as a contract, and not as a copyright license. This isn’t a central case in the book (and the book is definitely not one case after another), but it tied together material from several earlier chapters in the book.
It’s understandable that a book like this will reach out to analogies in the software and computing world, since that’s Lindgren’s target audience, though he takes this a bit too far sometimes. I’m still baffled at one analogy. In the section on how to write an article of incorporation, which explains the address field of the application: “If you think of the entity name as a pointer to a const object, this is the address referred to by the pointer”. I would use the reverse analogy if I was trying to teach a beginning C++ programmer the difference between “const *” and “* const”, but I don’t see why it was thrown in this book.
Apart from that, I’m happy this book is out there, and I’ve gone back to Groklaw with a deeper appreciation of the cases covered there.
And by fortuitous coincidence, ActiveState’s CEO, Bart Copeland, will be giving a webinar with Van Lindberg today June 16, 2010 on a guide to the most popular open source licenses, and their implications.  Feel free to register or listen to the recording after the live date (posted the day after)!
Title photo courtesy of Dariusz Sankowski on Pixabay.