Jay Parkhill September 10th, 2008
I started poking around in some open source software issues recently, and then a significant case came down on almost exactly the same point, making the whole thing highly blog-worthy. Here are my thoughts on the Ninth Circuit’s Jacobsen v. Katzer decision along with the clusterf*ck of conflict between developers and lawyers on how to manage open source code.
Jacobsen v. Katzer – Open Source Licensing Requires Compliance with Attribution and Version Terms
The Jacobsen case contains a valuable lesson. Jacobsen developed software and made it freely available under the under the Artistic License, which says that a licensee is free to use the software and incorporate it in free or for-pay products, but that the licensee must provide full attribution of the licensed material and if the licensee changes aspects of the source files he is required to make the original versions available as well along with a description of the changes.
Katzer picked up Jacobsen’s code, changed files names and other aspects and used the modified versions in his own for-pay software without giving attribution or providing original versions as well. Jacobsen brought suit for copyright infringement.
Katzer then attempted some legal sleight of hand by saying that the license to Jacobsen’s software allowed Katzer to use the software freely. The attribution and version terms were not actually part of the license, but were a separate contractual issue. In other words, if Katzer screwed up, the remedy was not to rescind the license but to pay economic damages. Since Jacobsen didn’t charge for his product, damages were $0.
The court’s response was “No way”. The attribution and version terms are part and parcel of the license. Fail to comply and you lose the right to use the software.
My View – Right on, Ninth Circuit
The court has this right. If it had somehow found for Katzer it would have ripped the heart right out of open source licenses by saying that there is no penalty for failing to comply with the attribution and version control provisions- frequently the only conditions in an open source license agreement. The license conditions would be completely unenforceable.
[Note, however, Prof. Eric Goldman wondering whether, if the act of downloading and using the code subject license terms is enough to create a defensible contract]
. . . And Yet the Devil Remains in the Details
At the same time, I have worked with companies that use open source code regularly. They don’t just use one component- they use dozens or hundreds of open source elements by different authors, made available under different license terms. Good faith, meaningful compliance becomes genuinely difficult in that situation and requires careful documentation, oversight and management. No problem there- good developers and good lawyers both create clear trails of documentation to support their work product and tracking the elements being used is doable.
What may not be doable is figuring out exactly what the license terms are. I searched for several open source elements on a recent project and found them available on two web sites. The first site listed the applicable license as GPL (a more restrictive open source license) and Artistic License (less restrictive). The latter said GPL or Artistic License. GPL and Artistic License are similar, but have some important differences. Which one did the publisher intend to apply? There is no way to know from the sites on which the code resides.
[Again, see Prof. Goldman with an example of a photo posted on Wikipedia under the mutually incompatible Creative Commons and GFPL licenses and wondering how one might comply with the license requirements.]
Open source licensing also borrows from the software community by attaching version numbers to its licenses. GPL v3 is signficantly different from GPL v2, but developers frequently don’t indicate which version they intended to apply. As a good faith user, do I need to comply with both versions of the license? That doesn’t seem to help the open source cause much- it is hard to upgrade to v3 if we need to remain backward-compliant with v2 indefinitely as well.
Where the Developers Miss the Lawyers
My own theory here, and I would love to hear other views, is that the license terms are an afterthought for developers. Someone creates some code, uploads it to sourceforge or elsewhere and checks a box for GPL, Artistic or some other license terms. I believe that in most cases developers would like attribution and to see their code further developed by the community, but don’t care much about the details beyond that such as which version of GPL should apply.
All of this makes good faith compliance really difficult. The Software Freedom Law Center has an excellent guide to compliance with GPL that provides very good advice on how to document and comply with GPL’s requirements. The document assumes, however, that a good faith user can readily tell which licenses to comply with. In my experience that is not the case at all, which is a shame. Open source software is useful and pervasive, and is being enforced with more and more assurance. It will be too bad to see well-meaning companies dinged because of this lack of clarity.
Tags: Intellectual Property
, open source